Home
Reading
Searching
Subscribe
Sponsors
Statistics
Posting
Contact
Spam
Lists
Links
About
Hosting
Filtering
Features Download
Marketing
Archives
FAQ
Blog
 
Gmane
From: Danny Smith <dannysmith-oKK1aGe2n869koe0gwxAeg <at> public.gmane.org>
Subject: Re: Apparent _alloca bug in MinGW gcj
Newsgroups: gmane.comp.gnu.mingw.devel
Date: Sunday 28th September 2003 11:24:44 UTC (over 14 years ago)
From: "Mohan Embar"

> Danny,
>
> Would you be able to comment on my post to the gcj java
> mailing list?:
>
> http://gcc.gnu.org/ml/java/2003-09/msg00336.html
>
> This is from a MinGW 3.4 CVS build without any
> MinGW-local patches.
>
> I've been able to work around this by building with
> -mno-stack-arg-probe, but I doubt this is the right
> thing to do.

No, it is not right thing.

 In particular, jar.exe suddenly stopped
> working, though I don't know if this is related. (Haven't
> had time to investigate.) Since there are no MinGW-local patches
> for the 3.4 tree, yet, I don't know if this _alloca issue
> has been fixed with the 3.3 local patches. And
> unfortunately, I can't use a 3.3 (Linux,MinGW)
> cross to build a 3.4 native MinGW compiler.
>
> So I guess what I'm asking is:
>
> - Do you know if the fix for this _alloca bug
>   supposed to be fixed in GCC CVS, the MinGW-local
>   patches, or not at all?
>
No local patches for this.
I haven't tried gcj lately, but I do have problems with -funit-at-a-time
which is
turned on by -O2.  Maybe, it is stepping on prologue expansion and the
strange not-your-normal-function-call to '_alloca'.

Have you tried building with -fno-unit-at-time?

> - If the answer is "in the MinGW-local patches",
>   then isn't the stability of any of my interim
>   builds (i.e. 3.4) that don't incorporate any
>   MinGW-local patches seriously compromised?
>
> - Do you want me to follow up on this in any way?

Have a look in i386.c (ix86_expand_prologue).  This in where the stack
checking code is generated.  There were problems there at least twice
before.

The first was fixed by the addition of an emit_insn (gen_blockage
(const0_rtx)) barrier

2003-01-08  Danny Smith 


 PR optimization/8750
 * config/i386/i386.c (ix86_expand_prologue): Don't allow
 scheduling pass to move insns across __alloca call.


The second was about changes to ix86_compute_frame_layout:

2003-03-19  Jan Hubicka  

 * i386.h (machine_function): New fields use_fast_prologue_epilogue.
 * i386.c (use_fast_prologue_epilogue): Remove.
 (ix86_frame): New field save_regs-using_mov;
 (ix86_compute_frame_layout):  Decide on fast prologues;
 allocate saved registers in red zone.
 (ix86_expand_epilogue, ix86_expand_prolgoues): Obey new parameters.

and was fixed by

Thu Apr  3 00:18:49 CEST 2003  Jan Hubicka 


 * i386.c (override_options):  Disable red zone by default on i386.
 (compute_frame_layout, ix86_force_to_memory, ix86_free_from_memory):
 Do not test TARGET_64BIT together with TARGET_RED_ZONE

Danny

>
> Thanks.
>
> -- Mohan
> http://www.thisiscool.com/
> http://www.animalsong.org/
>
>
>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> MinGW-dvlpr mailing list
> MinGW-dvlpr-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
 
CD: 3ms