gcj/sparc64?

gcj/sparc64?

[Jay]

This is an incomplete bug report.

 unified gcc 4.3.1/binutils 2.18/gmp/mpfr tree: 


  -bash-3.00$ gcc -v  
  Using built-in specs.  
  Target: sparc-sun-solaris2.10  
  Configured with: /home/jay/src/gcc/configure  
  Thread model: posix  
  gcc version 4.3.1 (GCC)  

    
  ~/src/gcc/configure sparc64-sun-solaris2.10 -disable-multilib -disable-bootstrap  \
   -disable-nls sparc64-sun-solaris2.10 CFLAGS=-m64 MAKEINFO=echo && make \
   MAKEINFO=echo CFLAGS=-m64  
    
    
  libtool: compile:  /home/jay/obj/gcc.1/gcc/gcj -B/home/jay/obj/gcc.1/sparc64-sun  
  -solaris2.10/libjava/ -B/home/jay/obj/gcc.1/gcc/ -Usun -fclasspath= -fbootclassp  
  ath=/home/jay/src/gcc/libjava/classpath/lib --encoding=UTF-8 -Wno-deprecated -fb  
  ootstrap-classes -g -O2 -c -fsource-filename=/home/jay/obj/gcc.1/sparc64-sun-sol  
  aris2.10/libjava/classpath/lib/classes -MT gnu/javax/swing/text/html/parser/HTML  
  _401F.lo -MD -MP -MF gnu/javax/swing/text/html/parser/HTML_401F.deps @gnu/javax/  
  swing/text/html/parser/HTML_401F.list  -fPIC -o gnu/javax/swing/text/html/parser  
  /.libs/HTML_401F.o  
  gcj: Internal error: Segmentation Fault (program jc1)  
  Please submit a full bug report.  
  See  for instructions.  
  make[3]: *** [gnu/javax/swing/text/html/parser/HTML_401F.lo] Error 1  
  make[3]: Leaving directory `/home/jay/obj/gcc.1/sparc64-sun-solaris2.10/libjava'  

    
  make[2]: *** [all-recursive] Error 1  
  make[2]: Leaving directory `/home/jay/obj/gcc.1/sparc64-sun-solaris2.10/libjava'  

    
  make[1]: *** [all-target-libjava] Error 2  
  make[1]: Leaving directory `/home/jay/obj/gcc.1'  
  make: *** [all] Error 2  


  -bash-3.00$ uname -a  
  SunOS unknown 5.10 Generic_118833-17 sun4u sparc SUNW,Sun-Blade-100  



 The build gcc -v itself was built with the output of "half Canadian" cross from 
 Cygwin. ie: target==host (==sparc-sun-solaris2.10), but target!=build (i686-pc-cygwin). 
 That should be all I need, but is having some problems, so I figured I'd just it to build native. 
 (I also had to rename away the output of fixincl, as they used the undefined macro _PARAMS.) 


 I'll try again with just -enable-languages=c,c++,fortran,objc.


 Perhaps I should suck it up, ignore the "biarch-ness" and:  


  ~/src/gcc/configure \
      -host=sparc64-sun-solaris2.10 \
      -target=sparc64-sun-solaris2.10 \
      -enable-languages=c,c++,fortran,objc \
      -disable-nls \
      -disable-multilib \
      MAKEINFO=echo && make MAKEINFO=echo 


  but that fails:  
    checking whether byte ordering is bigendian... unknown  
    configure: error: unknown endianness  
    presetting ac_cv_c_bigendian=no (or yes) will help  
    make[1]: *** [configure-libiberty] Error 1  
    make[1]: Leaving directory `/home/jay/obj/gcc.1'  
    make: *** [all] Error 2


I shouldn't need this MAKEINFO=echo, but I do for some reason.
btw, it'd be cool if one could easily add languages later, remove -disable-multilib later, etc.
  ie: "reconfigure slightly differently/larger && make" and have it be super duper smart about what to rebuild 
And -disable-libiconv would be nice.


 - Jay

Re: gcj/sparc64?

[Tom Tromey]

>>>>> "Jay" == Jay  <jayk123@hotmail.com> writes:

Jay> This is an incomplete bug report.
Jay>  unified gcc 4.3.1/binutils 2.18/gmp/mpfr tree: 
Jay>   -bash-3.00$ gcc -v  
Jay>   Using built-in specs.  
Jay>   Target: sparc-sun-solaris2.10  

[...]
Jay>   /.libs/HTML_401F.o  
Jay>   gcj: Internal error: Segmentation Fault (program jc1)  
Jay>   Please submit a full bug report.  

Knowing this particular file, maybe gcj just ran out of memory.
Anyway, please file in bugzilla.  If you can include a jc1 stack
trace, that would be helpful.

Jay> I shouldn't need this MAKEINFO=echo, but I do for some reason.
Jay> btw, it'd be cool if one could easily add languages later, remove
Jay> -disable-multilib later, etc.  ie: "reconfigure slightly
Jay> differently/larger && make" and have it be super duper smart
Jay> about what to rebuild And -disable-libiconv would be nice.

Send bug reports and/or patches...
Thanks.

Tom

RE: gcj/sparc64?

[Jay]

Sorry Tom, I find opening bugs often tedious..sign up an account, fill in a bunch of fields..
I'll try to get more details "later" (if it repros consistently, callstack in a debugger) 
 
 - Jay

> To: Jayk 
> CC: gcc 
> Subject: Re: gcj/sparc64? 
> From: Tom  
> Date: Thu, 24 Jul 2008 08:49:13 -0600 
> 
>>>>>> Jay writes:
> 
> Jay> This is an incomplete bug report.
> Jay> unified gcc 4.3.1/binutils 2.18/gmp/mpfr tree: 
> Jay> -bash-3.00$ gcc -v 
> Jay> Using built-in specs. 
> Jay> Target: sparc-sun-solaris2.10 
> 
> [...]
> Jay> /.libs/HTML_401F.o 
> Jay> gcj: Internal error: Segmentation Fault (program jc1) 
> Jay> Please submit a full bug report. 
> 
> Knowing this particular file, maybe gcj just ran out of memory.
> Anyway, please file in bugzilla. If you can include a jc1 stack
> trace, that would be helpful.

Re: gcj/sparc64?

[Andrew Haley]

Tom Tromey wrote:
>>>>>> "Jay" == Jay  <jayk123@hotmail.com> writes:
> 
> Jay> This is an incomplete bug report.
> Jay>  unified gcc 4.3.1/binutils 2.18/gmp/mpfr tree: 
> Jay>   -bash-3.00$ gcc -v  
> Jay>   Using built-in specs.  
> Jay>   Target: sparc-sun-solaris2.10  
> 
> [...]
> Jay>   /.libs/HTML_401F.o  
> Jay>   gcj: Internal error: Segmentation Fault (program jc1)  
> Jay>   Please submit a full bug report.  
> 
> Knowing this particular file, maybe gcj just ran out of memory.
> Anyway, please file in bugzilla.  If you can include a jc1 stack
> trace, that would be helpful.
> 
> Jay> I shouldn't need this MAKEINFO=echo, but I do for some reason.
> Jay> btw, it'd be cool if one could easily add languages later, remove
> Jay> -disable-multilib later, etc.  ie: "reconfigure slightly
> Jay> differently/larger && make" and have it be super duper smart
> Jay> about what to rebuild And -disable-libiconv would be nice.
> 
> Send bug reports and/or patches...

I know what this is.  It's one of the optimization passes recursing too
deeply and blowing the stack.  It usually happens if the compiler has
been built with -O0.

Try this patch.

Andrew.


Index: tree-vrp.c
===================================================================
--- tree-vrp.c	(revision 136670)
+++ tree-vrp.c	(working copy)
@@ -4049,6 +4049,8 @@
    the predicate operands, an assert location node is added to the
    list of assertions for the corresponding operands.  */

+static size_t depth;
+
 static bool
 find_conditional_asserts (basic_block bb, tree last)
 {
@@ -4062,6 +4064,10 @@
   need_assert = false;
   bsi = bsi_for_stmt (last);

+  depth++;
+  if (depth > 500)
+    goto ret;
+
   /* Look for uses of the operands in each of the sub-graphs
      rooted at BB.  We need to check each of the outgoing edges
      separately, so that we know what kind of ASSERT_EXPR to
@@ -4121,6 +4127,8 @@
   FOR_EACH_SSA_TREE_OPERAND (op, last, iter, SSA_OP_USE)
     SET_BIT (found_in_subgraph, SSA_NAME_VERSION (op));

+ ret:
+  depth--;
   return need_assert;
 }

RE: gcj/sparc64?

[Jay]

Thanks.

While I have an easy repro, it's less easy to repro with any "onion peeling" or logging.
For a while I was avoiding the problem via -enable-languages=c,c++.

This command is what fails (but not always)

 /obj/gcc.1/i686-pc-cygwin/sparc64-sun-solaris2.10/gcc/jc1.exe /src/gcc/libjava/
classpath/lib/gnu/javax/swing/text/html/parser/HTML_401F.class -fuse-divide-subr
outine -fcheck-references -fuse-boehm-gc -fkeep-inline-functions -quiet -dumpbas
e HTML_401F.class -mcpu=v9 -auxbase-strip gnu/javax/swing/text/html/parser/HTML_
401F.o -g -O2 -Wno-deprecated -version -fencoding=UTF-8 -fbootstrap-classes -fso
urce-filename=/obj/gcc.1/i686-pc-cygwin/sparc64-sun-solaris2.10/sparc64-sun-sola
ris2.10/libjava/classpath/lib/classes -fbootclasspath=./:/src/gcc/libjava/classp
ath/lib/ -faux-classpath /d/DOCUME~1/jay/LOCALS~1/Temp/cciZj3jk.zip -MD_ -MT gnu
/javax/swing/text/html/parser/HTML_401F.lo -MF gnu/javax/swing/text/html/parser/
HTML_401F.deps -o /d/DOCUME~1/jay/LOCALS~1/Temp/ccqOtWtu.s

output is:

GNU Java (GCC) version 4.3.1 (sparc64-sun-solaris2.10)
        compiled by GNU C version 4.3.1, GMP version 4.2.2, MPFR version 2.3.1.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Class path starts here:
    /d/DOCUME~1/jay/LOCALS~1/Temp/cciZj3jk.zip/ (zip)
    ./ (system)
    /src/gcc/libjava/classpath/lib/ (system)
/src/gcc/libjava/classpath/gnu/javax/swing/text/html/parser/HTML_401F.java: In c
lass 'gnu.javax.swing.text.html.parser.HTML_401F':
/src/gcc/libjava/classpath/gnu/javax/swing/text/html/parser/HTML_401F.java: In m
ethod 'gnu.javax.swing.text.html.parser.HTML_401F.defineElements()':
/src/gcc/libjava/classpath/gnu/javax/swing/text/html/parser/HTML_401F.java:0: in
ternal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

and then here it is under a debugger:

Program received signal SIGSEGV, Segmentation fault.
0x008fc34a in htab_mod (hash=7818600, htab=0x27b75c8)
    at /src/gcc/libiberty/hashtab.c:270
270       return htab_mod_1 (hash, p->prime, p->inv, p->shift);
(gdb) bt
#0  0x008fc34a in htab_mod (hash=7818600, htab=0x27b75c8)
    at /src/gcc/libiberty/hashtab.c:270
#1  0x008fc752 in htab_find_slot_with_hash (htab=0x27b75c8, element=0x330a0,
    hash=7818600, insert=INSERT) at /src/gcc/libiberty/hashtab.c:624
#2  0x008fc8fc in htab_find_slot (htab=0x27b75c8, element=0x330a0,
    insert=INSERT) at /src/gcc/libiberty/hashtab.c:678
#3  0x006ce782 in get_def_blocks_for (var=0x3ba6b40)
    at /src/gcc/gcc/tree-into-ssa.c:466
#4  0x006d2d78 in mark_use_interesting (var=0x3ba6b40, stmt=0x7c0ec6a0,
    bb=0x79a11300, insert_phi_p=1 '\001') at /src/gcc/gcc/tree-into-ssa.c:2375
#5  0x006d2bb8 in prepare_block_for_update (bb=0x79a11300,
    insert_phi_p=1 '\001') at /src/gcc/gcc/tree-into-ssa.c:2448
#6  0x006d2cec in prepare_block_for_update (bb=0x79a11280,
    insert_phi_p=1 '\001') at /src/gcc/gcc/tree-into-ssa.c:2464
#7  0x006d2cec in prepare_block_for_update (bb=0x79a111c0,
    insert_phi_p=1 '\001') at /src/gcc/gcc/tree-into-ssa.c:2464
#8  0x006d2cec in prepare_block_for_update (bb=0x79a110c0,
    insert_phi_p=1 '\001') at /src/gcc/gcc/tree-into-ssa.c:2464
#9  0x006d2cec in prepare_block_for_update (bb=0x79a11040,
    insert_phi_p=1 '\001') at /src/gcc/gcc/tree-into-ssa.c:2464
#10 0x006d2cec in prepare_block_for_update (bb=0x79a10f80,
    insert_phi_p=1 '\001') at /src/gcc/gcc/tree-into-ssa.c:2464
#11 0x006d2cec in prepare_block_for_update (bb=0x79a10e80,
    insert_phi_p=1 '\001') at /src/gcc/gcc/tree-into-ssa.c:2464
#12 0x006d2cec in prepare_block_for_update (bb=0x79a10e00,
    insert_phi_p=1 '\001') at /src/gcc/gcc/tree-into-ssa.c:2464
#13 0x006d2cec in prepare_block_for_update (bb=0x79a10d40,
    insert_phi_p=1 '\001') at /src/gcc/gcc/tree-into-ssa.c:2464
#14 0x006d2cec in prepare_block_for_update (bb=0x79a10c40,
    insert_phi_p=1 '\001') at /src/gcc/gcc/tree-into-ssa.c:2464
#15 0x006d2cec in prepare_block_for_update (bb=0x79a10bc0,
    insert_phi_p=1 '\001') at /src/gcc/gcc/tree-into-ssa.c:2464
#16 0x006d2cec in prepare_block_for_update (bb=0x79a10b00,
    insert_phi_p=1 '\001') at /src/gcc/gcc/tree-into-ssa.c:2464
#17 0x006d2cec in prepare_block_for_update (bb=0x79a10a00,
    insert_phi_p=1 '\001') at /src/gcc/gcc/tree-into-ssa.c:2464
#18 0x006d2cec in prepare_block_for_update (bb=0x79a10980,
    insert_phi_p=1 '\001') at /src/gcc/gcc/tree-into-ssa.c:2464
#19 0x006d2cec in prepare_block_for_update (bb=0x79a108c0,
    insert_phi_p=1 '\001') at /src/gcc/gcc/tree-into-ssa.c:2464
#20 0x006d2cec in prepare_block_for_update (bb=0x79a107c0,

...
... pages and pages ...
...

#9950 0x006d2cec in prepare_block_for_update (bb=0x7c82e7c0,
    insert_phi_p=1 '\001') at /src/gcc/gcc/tree-into-ssa.c:2464
#9951 0x006d2cec in prepare_block_for_update (bb=0x7c82e740,
    insert_phi_p=1 '\001') at /src/gcc/gcc/tree-into-ssa.c:2464
#9952 0x006d2cec in prepare_block_for_update (bb=0x7c82e6c0,
    insert_phi_p=1 '\001') at /src/gcc/gcc/tree-into-ssa.c:2464
#9953 0x006d2cec in prepare_block_for_update (bb=0x7c82e640,
    insert_phi_p=1 '\001') at /src/gcc/gcc/tree-into-ssa.c:2464
#9954 0x006d2cec in prepare_block_for_update (bb=0x7c82e5c0,
    insert_phi_p=1 '\001') at /src/gcc/gcc/tree-into-ssa.c:2464
#9955 0x006d4aa5 in update_ssa (update_flags=2048)
    at /src/gcc/gcc/tree-into-ssa.c:3257
#9956 0x006c918f in compute_may_aliases ()
    at /src/gcc/gcc/tree-ssa-alias.c:1897
#9957 0x004c7b42 in execute_function_todo (data=0x100001)
    at /src/gcc/gcc/passes.c:913
#9958 0x004c78b8 in do_per_function (
    callback=0x4c7a6b , data=0x100001)
    at /src/gcc/gcc/passes.c:809
#9959 0x004c7d56 in execute_todo (flags=1048577) at /src/gcc/gcc/passes.c:993
#9960 0x004c811f in execute_one_pass (pass=0x9839f0)
    at /src/gcc/gcc/passes.c:1144
#9961 0x004c81b1 in execute_pass_list (pass=0x9839f0)
    at /src/gcc/gcc/passes.c:1175
#9962 0x004c81cd in execute_pass_list (pass=0x9837f0)
    at /src/gcc/gcc/passes.c:1176
#9963 0x006c5129 in tree_rest_of_compilation (fndecl=0x7ef43200)
    at /src/gcc/gcc/tree-optimize.c:404
#9964 0x0051baf9 in cgraph_expand_function (node=0x7ef64d08)
    at /src/gcc/gcc/cgraphunit.c:1157
#9965 0x0051a972 in cgraph_assemble_pending_functions ()
    at /src/gcc/gcc/cgraphunit.c:523
#9966 0x0051ac1e in cgraph_finalize_function (decl=0x7ef43200, nested=0 '\0')
    at /src/gcc/gcc/cgraphunit.c:641
#9967 0x00411071 in finish_method (fndecl=0x7ef43200)
    at /src/gcc/gcc/java/decl.c:1862
#9968 0x00410ec5 in end_java_method () at /src/gcc/gcc/java/decl.c:1810
#9969 0x0042fa0f in parse_class_file () at /src/gcc/gcc/java/jcf-parse.c:1698
#9970 0x0043039f in java_parse_file (set_yydebug=0)
    at /src/gcc/gcc/java/jcf-parse.c:1986
#9971 0x0043ef44 in compile_file () at /src/gcc/gcc/toplev.c:1042
#9972 0x00440850 in do_compile () at /src/gcc/gcc/toplev.c:2240
#9973 0x004408b5 in toplev_main (argc=29, argv=0x2562088)
    at /src/gcc/gcc/toplev.c:2272
#9974 0x0043dffa in main (argc=29, argv=0x2562088) at /src/gcc/gcc/main.c:35

I don't think the patch worked -- assuming I applied, built, ran it correctly.
From the callstack too, seems not likely.
If you really think so, I'll double check.

Personally I've been taught: "Don't use machine stack recursion, at least not
to a depth determined by user input." User will be able to blow your stack,
which is tricky but not impossible to recover from and report "out of memory".
Instead use recursion with a "manual heap based stack", or such. You know, std::stack::push/pop.
Failure to heap allocate is a much simpler thing to detect and report, portably.
Granted, yes, I know, heap is much much much much slower than stack.

The PIC variant of the command always seems to succeed. Wierd?
Personally I think compiling non-PIC is a waste.
Compile everything twice? Yuck.
I wish Windows code was PIC, then wouldn't worry about base addresses and
the cost of relocs.. (even if AMD64 is mostly PIC, the data still isn't, e.g. vtables).

 - Jay


> Date: Sat, 26 Jul 2008 16:09:36 +0100
> From: aph@redhat.com
> To: tromey@redhat.com
> CC: jayk123@hotmail.com; gcc@gcc.gnu.org
> Subject: Re: gcj/sparc64?
>
> Tom Tromey wrote:
>>>>>>> "Jay" == Jay  writes:
>>
>> Jay> This is an incomplete bug report.
>> Jay> unified gcc 4.3.1/binutils 2.18/gmp/mpfr tree:
>> Jay> -bash-3.00$ gcc -v
>> Jay> Using built-in specs.
>> Jay> Target: sparc-sun-solaris2.10
>>
>> [...]
>> Jay> /.libs/HTML_401F.o
>> Jay> gcj: Internal error: Segmentation Fault (program jc1)
>> Jay> Please submit a full bug report.
>>
>> Knowing this particular file, maybe gcj just ran out of memory.
>> Anyway, please file in bugzilla. If you can include a jc1 stack
>> trace, that would be helpful.
>>
>> Jay> I shouldn't need this MAKEINFO=echo, but I do for some reason.
>> Jay> btw, it'd be cool if one could easily add languages later, remove
>> Jay> -disable-multilib later, etc. ie: "reconfigure slightly
>> Jay> differently/larger && make" and have it be super duper smart
>> Jay> about what to rebuild And -disable-libiconv would be nice.
>>
>> Send bug reports and/or patches...
>
> I know what this is. It's one of the optimization passes recursing too
> deeply and blowing the stack. It usually happens if the compiler has
> been built with -O0.
>
> Try this patch.
>
> Andrew.
>
>
> Index: tree-vrp.c
> ===================================================================
> --- tree-vrp.c (revision 136670)
> +++ tree-vrp.c (working copy)
> @@ -4049,6 +4049,8 @@
> the predicate operands, an assert location node is added to the
> list of assertions for the corresponding operands. */
>
> +static size_t depth;
> +
> static bool
> find_conditional_asserts (basic_block bb, tree last)
> {
> @@ -4062,6 +4064,10 @@
> need_assert = false;
> bsi = bsi_for_stmt (last);
>
> + depth++;
> + if (depth> 500)
> + goto ret;
> +
> /* Look for uses of the operands in each of the sub-graphs
> rooted at BB. We need to check each of the outgoing edges
> separately, so that we know what kind of ASSERT_EXPR to
> @@ -4121,6 +4127,8 @@
> FOR_EACH_SSA_TREE_OPERAND (op, last, iter, SSA_OP_USE)
> SET_BIT (found_in_subgraph, SSA_NAME_VERSION (op));
>
> + ret:
> + depth--;
> return need_assert;
> }
>

Re: gcj/sparc64?

[Brian Dessent]

Jay wrote:

> /src/gcc/libjava/classpath/gnu/javax/swing/text/html/parser/HTML_401F.java:0: in
> ternal compiler error: Segmentation fault
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See  for instructions.

This stack exhaustion is PR36218 which was supposedly fixed on
mainline.  Two problems: the fix needs to be extended to Cygwin as well
as MinGW, and you're not building mainline.

> I wish Windows code was PIC, then wouldn't worry about base addresses and
> the cost of relocs.. (even if AMD64 is mostly PIC, the data still isn't, e.g. vtables).

With --enable-auto-image-base this becomes nearly a non-issue.  Libtool
has been enabling that by default on PE for a long time.  There was also
a patch several years ago to support a variant of ELF-style PIC on
Windows, but it was never reviewed nor commented on.  The ABI
implications probably make this infeasible anyway.  In any case this has
zero to do with the topic of this thread.

Brian

RE: gcj/sparc64?

[Jay]

> From: brian@
>>
> This stack exhaustion is PR36218 which was supposedly fixed on
> mainline. Two problems: the fix needs to be extended to Cygwin as well
> as MinGW, and you're not building mainline.
>
>> I wish Windows code was PIC
>
> zero to do with the topic of this thread.

I agree it's a tangent.

It seems the PIC compilation succeeds.
The whole thing where things get compiled twice, PIC and non-PIC, bugs me.
It's a "great" way to slow down builds.
I guess configure -only-pic might be nice.
I understand the results, if only linked into an executabe, might be slower.

Picking a base address that might not conflict with other code/data
doesn't eliminate the problem, just reduces it, and a cost
of random burning of address space. (I don't know the algorithm,
"random" isn't the right word).
If the code/data were really PIC, it could be tightly packed.

Thanks.
I'm trying it out with an 8meg stack like was applied to mingwin.
I believe Solaris hosts need a fix here too.
And djgpp.
And perhaps others. AIX? Irix? HP-UX? *BSD?
Or most systems default to 8 or 32meg?

Not worth changing the gcc code to reduce or eliminate the recursion?

 - Jay

Re: gcj/sparc64?

[Andreas Schwab]

Jay <jayk123@hotmail.com> writes:

> I guess configure -only-pic might be nice.

It's spelled --with-pic.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

RE: gcj/sparc64?

[Jay]

This seems t have worked, applied against 4.3.1,
based on what I saw was the MinGW fix.

$ diff -u /src/gcc.orig/config/mh-cygwin /src/gcc/config/mh-cygwin
--- /src/gcc.orig/config/mh-cygwin      2002-12-16 18:58:05.000000000 -0800
+++ /src/gcc/config/mh-cygwin   2008-08-10 06:09:39.718750000 -0700
@@ -4,3 +4,5 @@
 all-gdb: maybe-all-libtermcap

 install-gdb: maybe-all-libtermcap
+
+LDFLAGS = -Wl,--stack,8388608


I'll retest the break and a fix for Solaris /significantly later/.

>> From: brian@
>>>
>> This stack exhaustion is PR36218 which was supposedly fixed on
>> mainline. Two problems: the fix needs to be extended to Cygwin as well
>> as MinGW, and you're not building mainline.
>> zero to do with the topic of this thread.

> Not worth changing the gcc code to reduce or eliminate the recursion?

Thanks,
 - Jay