[Bug fortran/42189] gfc_is_constant_expr has unacceptable side effects

[jvdelisle at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42189

Jerry DeLisle  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #8 from Jerry DeLisle  2011-03-20 
04:32:44 UTC ---
Closing

[Bug driver/48208] New: -F option is not joined

[gcchelp.5.adept at 0sg dot net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48208

   Summary: -F option is not joined
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: driver
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: gcchelp.5.ad...@0sg.net


The darwin linker complains that the argument to the -F option is not joined.
There seems to be code in the driver to do just this (gcc.c)

case OPT_F:
  /* Likewise -F.  */
  save_switch (concat ("-F", arg, NULL), 0, NULL, validated);
  return true;

but this can never be called since the -F option does not have CL_DRIVER flag
(c.opt)

F
C ObjC C++ ObjC++ Joined Separate MissingArgError(missing path after %qs)
-F Add  to the end of the main framework include path

please change it to

F
Driver C ObjC C++ ObjC++ Joined Separate MissingArgError(missing path after
%qs)
-F Add  to the end of the main framework include path

[Bug fortran/48174] DWARF for subroutine with no args indicates 'varargs'

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48174

--- Comment #6 from Tobias Burnus  2011-03-19 
23:35:12 UTC ---
(In reply to comment #5)
> -  else if (sym->attr.is_main_program)
> +  else if (sym->attr.if_source != IFSRC_UNKNOWN)

Probably better OR the old condition (is_main_program || if_source != UNKNOWN).

[Bug fortran/45304] Functions/subroutines without arguments always treated like varargs

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45304

--- Comment #4 from Tobias Burnus  2011-03-19 
23:31:33 UTC ---
Related (duplicate): PR 48174 (see patch there).

[Bug fortran/48174] DWARF for subroutine with no args indicates 'varargs'

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48174

Tobias Burnus  changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu.org

--- Comment #5 from Tobias Burnus  2011-03-19 
23:26:22 UTC ---
Hmm, I am surprised about this PR. The test case from comment 0 indicates that
the FE generates the wrong declaration for the procedure (subroutine) itself. I
was only aware about issues where the declaration of procedures with implicit
interfaces caused problems (e.g. PR 40976, PR 33097, PR 44471).

As the interface is explicitly known, it should be rather straight forward to
fix this issue (contrary to the other PRs) ...

Untested draft patch. (I am not sure about the if_source part, but I think
leaving it as is should be best for the moment; the real solution for that part
is to fix the issue outlined in the first paragraph.)

--- a/gcc/fortran/trans-types.c
+++ b/gcc/fortran/trans-types.c
@@ -2618,7 +2618,7 @@ gfc_get_function_type (gfc_symbol * sym)

   if (typelist)
 typelist = chainon (typelist, void_list_node);
-  else if (sym->attr.is_main_program)
+  else if (sym->attr.if_source != IFSRC_UNKNOWN)
 typelist = void_list_node;

   if (alternate_return)

[Bug debug/48203] ICE in dwarf2out.c while building eglibc.

[ramana at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48203

--- Comment #11 from Ramana Radhakrishnan  
2011-03-19 22:14:50 UTC ---
(In reply to comment #10)
> (In reply to comment #9)
> > Can you try with -mcpu=cortex-a9 -mfpu=vfpv3-d16 -mfloat-abi=softfp -mthumb 
> > ?
> > It fails in that case . #c1 has the configuration options that I used. 
> 
> Can't reproduce, neither with the above options, nor with a fresh cross
> configured the way you mentioned in #c0.

I see the ICE with -mcpu=cortex-a9 -mfpu=vfpv3-d16 -mfloat-abi=softfp -marm . 

It appears as though when I did a quick rebuild of the tools to verify your
patch I missed the --with-mode=thumb. Sorry about the confusion. 


I've dug into this a bit further and it appears as though the ICE at 


21979gcc_assert (prev
21980&& (CALL_P (prev)
21981|| (NONJUMP_INSN_P (prev)
21982&& GET_CODE (PATTERN (prev)) == SEQUENCE
21983&& CALL_P (XVECEXP (PATTERN (prev), 0, 0);




Looking at the backtrace it appears as though the assertion failure is because
we don't see the call before the note. Looking at the dumps the ARM backend
ends up generating the minipools to interleave the constant pools within the
function because of range issues and thus end up breaking the assertion. The
work around is then to emit the barriers and the minipools after the notes
rather than just after the "call insn".

 2265 call [`obstack_free'] argc:0
  REG_DEAD: r1:SI
  REG_DEAD: r0:SI
 4874 pc=L4876
i4875: barrier
L4877:
 4878 unspec/v{0;}
L4879:
 4880 unspec/v{1.399911182158029987476766109466552734375e+0;}
 4881 unspec/v{`swap_endianness_p';}
 4882 unspec/v{const(`*.LANCHOR1'+0x7d0);}
 4883 unspec/v{const(`*.LANCHOR1'+0x2c);}
 4884 unspec/v{const(`*.LANCHOR1'+0x7bc);}
 4885 unspec/v{const(`*.LANCHOR1'+0x7a8);}
 4886 unspec/v{const(`*.LANCHOR1'+0x70c);}
 4887 unspec/v{const(`*.LANCHOR1'+0x218);}
 4888 unspec/v{0;}
i4889: barrier
L4876:
 4011 NOTE_INSN_CALL_ARG_LOCATION
 4012 NOTE_INSN_VAR_LOCATION
 4013 NOTE_INSN_VAR_LOCATION

[Bug bootstrap/44107] libstdc++ (dylib) is built with an erroneous dependency towards /usr/lib

[howarth at nitro dot med.uc.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44107

--- Comment #6 from Jack Howarth  2011-03-19 
22:02:58 UTC ---
 Doesn't the darwin linker developer's comments on PR48097
(http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48097#c8) imply that libjava's
Throw2 test case is expected to fail on the current Apple system unwinder? Thus
your epilogue patch should be fine as it only regressed Throw2 for me.

[Bug libstdc++/41495] libstdc++ --enable-clocale=ieee_1003.1-2001 fails

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41495

Paolo Carlini  changed:

   What|Removed |Added

 CC||milan.jurik at xylab dot cz

--- Comment #4 from Paolo Carlini  2011-03-19 
21:56:49 UTC ---
*** Bug 48205 has been marked as a duplicate of this bug. ***

[Bug libstdc++/48205] clocale ieee_1003.1-2001 broken

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48205

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE

--- Comment #2 from Paolo Carlini  2011-03-19 
21:56:49 UTC ---
Looks like a duplicate of 41495, the first error seems still the same.

*** This bug has been marked as a duplicate of bug 41495 ***

[Bug lto/48207] ICE in lhd_set_decl_assembler_name, at langhooks.c:158

[d.g.gorbachev at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48207

--- Comment #1 from Dmitry Gorbachev  
2011-03-19 20:05:44 UTC ---
Created attachment 23728
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23728
Backtrace

[Bug lto/48207] New: ICE in lhd_set_decl_assembler_name, at langhooks.c:158

[d.g.gorbachev at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48207

   Summary: ICE in lhd_set_decl_assembler_name, at langhooks.c:158
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: d.g.gorbac...@gmail.com
CC: rgue...@gcc.gnu.org


Created attachment 23727
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23727
Testcase (compile with `g++ -flto -g pr48207.cc')

[Bug debug/48203] ICE in dwarf2out.c while building eglibc.

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48203

--- Comment #10 from Jakub Jelinek  2011-03-19 
20:02:04 UTC ---
(In reply to comment #9)
> Can you try with -mcpu=cortex-a9 -mfpu=vfpv3-d16 -mfloat-abi=softfp -mthumb ?
> It fails in that case . #c1 has the configuration options that I used. 

Can't reproduce, neither with the above options, nor with a fresh cross
configured the way you mentioned in #c0.

[Bug c++/44499] No default constructor available

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44499

--- Comment #18 from Jonathan Wakely  2011-03-19 
19:56:49 UTC ---
(In reply to comment #17)
> OK, I'll update the changes page with a variation of the note in comment 11,

done

[Bug debug/48203] ICE in dwarf2out.c while building eglibc.

[ramana at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48203

--- Comment #9 from Ramana Radhakrishnan  2011-03-19 
19:25:30 UTC ---
(In reply to comment #8)
> ./cc1 -O2 -g ld-collate.i -quiet; echo $?
> 0
> 
> if you are talking about #c2 testcase.  I have cross configured with
> ../configure --disable-bootstrap --target armv5tel-unknown-linux-gnueabi
> --enable-languages=c
> Perhaps some -m* cpu selection etc. options are needed to reproduce?

Can you try with -mcpu=cortex-a9 -mfpu=vfpv3-d16 -mfloat-abi=softfp -mthumb ?
It fails in that case . #c1 has the configuration options that I used. 

cheers
Ramana

[Bug debug/48203] ICE in dwarf2out.c while building eglibc.

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48203

--- Comment #8 from Jakub Jelinek  2011-03-19 
19:21:27 UTC ---
./cc1 -O2 -g ld-collate.i -quiet; echo $?
0

if you are talking about #c2 testcase.  I have cross configured with
../configure --disable-bootstrap --target armv5tel-unknown-linux-gnueabi
--enable-languages=c
Perhaps some -m* cpu selection etc. options are needed to reproduce?

[Bug debug/48203] ICE in dwarf2out.c while building eglibc.

[ramana at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48203

--- Comment #7 from Ramana Radhakrishnan  2011-03-19 
19:16:34 UTC ---
(In reply to comment #5)
> Created attachment 23725 [details]
> gcc47-pr48203.patch
> 
> Untested fix.

Please ignore comment #6 - I was using the wrong compiler accidentally. 


This fixes the ICE with min.i but the ICE with ld-collate.i still remains at a
different place. 


ramana@gcc10:~/cross-build/arm-none-linux-gnueabi/objpr48203/gcc2/gcc$ ./xgcc
-B`pwd` -S -O2 -g /tmp/ld-collate.i 
programs/ld-collate.c: In function ‘collate_output’:
programs/ld-collate.c:2500:1: internal compiler error: in
dwarf2out_var_location, at dwarf2out.c:21983
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

I think there are a couple of problems here.

cheers
Ramana

[Bug debug/48203] ICE in dwarf2out.c while building eglibc.

[ramana at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48203

--- Comment #6 from Ramana Radhakrishnan  2011-03-19 
19:13:30 UTC ---
(In reply to comment #5)
> Created attachment 23725 [details]
> gcc47-pr48203.patch
> 
> Untested fix

Bootstrap and cross-testing on in parallel.

Ramana(In reply to comment #5)
> Created attachment 23725 [details]
> gcc47-pr48203.patch
> 
> Untested fix.

ramana@gcc10:~/cross-build/arm-none-linux-gnueabi/obj/gcc2/gcc$ ./xgcc -B`pwd`
-S -O2 -g ~/min.i 
/home/ramana/min.i:96:1: warning: useless storage class specifier in empty
declaration [enabled by default]
/home/ramana/min.i:101:49: warning: ‘struct tm’ declared inside parameter list
[enabled by default]
/home/ramana/min.i:101:49: warning: its scope is only this definition or
declaration, which is probably not what you want [enabled by default]
/home/ramana/min.i:131:8: warning: ‘struct random_data’ declared inside
parameter list [enabled by default]
/home/ramana/min.i:133:16: warning: ‘struct drand48_data’ declared inside
parameter list [enabled by default]
/home/ramana/min.i:164:16: warning: ‘struct timezone’ declared inside parameter
list [enabled by default]
/home/ramana/min.i:241:5: warning: no semicolon at end of struct or union
[enabled by default]
/home/ramana/min.i:267:10: warning: ‘struct iovec’ declared inside parameter
list [enabled by default]
/home/ramana/min.i:448:14: warning: conflicting types for built-in function
‘__strcpy_chk’ [enabled by default]
/home/ramana/min.i:450:14: warning: conflicting types for built-in function
‘__strncat_chk’ [enabled by default]
/home/ramana/min.i:548:1: warning: declaration does not declare anything
[enabled by default]
/home/ramana/min.i:548:1: warning: no semicolon at end of struct or union
[enabled by default]
/home/ramana/min.i:562:14: warning: conflicting types for built-in function
‘dcgettext’ [enabled by default]
/home/ramana/min.i:573:1: warning: unnamed struct/union that defines no
instances [enabled by default]
/home/ramana/min.i:575:7: warning: ‘struct __gconv_step’ declared inside
parameter list [enabled by default]
/home/ramana/min.i: In function ‘read_directions’:
/home/ramana/min.i:906:32: warning: incompatible implicit declaration of
built-in function ‘calloc’ [enabled by default]
/home/ramana/min.i: In function ‘insert_weights’:
/home/ramana/min.i:976:4: warning: incompatible implicit declaration of
built-in function ‘memcpy’ [enabled by default]
/home/ramana/min.i: In function ‘handle_ellipsis’:
/home/ramana/min.i:1043:21: warning: incompatible implicit declaration of
built-in function ‘strlen’ [enabled by default]
/home/ramana/min.i:1059:14: warning: assignment makes pointer from integer
without a cast [enabled by default]
/home/ramana/min.i: In function ‘collate_read’:
/home/ramana/min.i:1238:16: warning: assignment makes pointer from integer
without a cast [enabled by default]
/home/ramana/min.i:1260:21: warning: assignment makes pointer from integer
without a cast [enabled by default]
/home/ramana/min.i:1306:6: warning: incompatible implicit declaration of
built-in function ‘sprintf’ [enabled by default]
/home/ramana/min.i:1307:8: warning: passing argument 2 of ‘sprintf’ makes
pointer from integer without a cast [enabled by default]
/home/ramana/min.i:1307:8: note: expected ‘const char *’ but argument is of
type ‘int’
/home/ramana/min.i:1424:120: warning: incompatible implicit declaration of
built-in function ‘strlen’ [enabled by default]
/home/ramana/min.i:1447:82: warning: initialization makes pointer from integer
without a cast [enabled by default]
/home/ramana/min.i:1447:4: warning: passing argument 5 of ‘error_at_line’ makes
pointer from integer without a cast [enabled by default]
/home/ramana/min.i:363:1: note: expected ‘const char *’ but argument is of type
‘int’
/home/ramana/min.i: In function ‘read_directions’:
/home/ramana/min.i:941:1: internal compiler error: in mem_loc_descriptor, at
dwarf2out.c:13885
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


cheers
Ramana

[Bug c++/48206] Issue with using std::shared_ptr with custom equality operator and STL (gnu++0x)

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48206

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #3 from Jonathan Wakely  2011-03-19 
19:03:41 UTC ---
(In reply to comment #0)
> 
> It seems that even though the equality operator of shared_ptr should compare
> the underlying objects the program compiled by gcc compares the memory
> addresses.

No, the equality operator should compare the addresses

[Bug libstdc++/48205] clocale ieee_1003.1-2001 broken

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48205

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.03.19 18:56:29
 Ever Confirmed|0   |1

--- Comment #1 from Jonathan Wakely  2011-03-19 
18:56:29 UTC ---
Confirmed.  I have a patch fixing some of the problems.
See also http://gcc.gnu.org/ml/libstdc++/2010-12/msg00045.html and
http://open-std.org/JTC1/SC22/WG21/docs/lwg-active.html#2028

[Bug c++/48206] Issue with using std::shared_ptr with custom equality operator and STL (gnu++0x)

[comaddcor at gmx dot net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48206

--- Comment #2 from comaddcor at gmx dot net 2011-03-19 18:37:19 UTC ---
Comment on attachment 23726
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23726
Sample program to demonstrate the issue.

I had to zip the source code since it would not have been accepted o/wise.

[Bug c++/48206] Issue with using std::shared_ptr with custom equality operator and STL (gnu++0x)

[comaddcor at gmx dot net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48206

--- Comment #1 from comaddcor at gmx dot net 2011-03-19 18:36:25 UTC ---
Created attachment 23726
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23726
Sample program to demonstrate the issue.

[Bug debug/48203] ICE in dwarf2out.c while building eglibc.

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48203

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 AssignedTo|unassigned at gcc dot   |jakub at gcc dot gnu.org
   |gnu.org |

--- Comment #5 from Jakub Jelinek  2011-03-19 
18:35:38 UTC ---
Created attachment 23725
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23725
gcc47-pr48203.patch

Untested fix.

[Bug c++/48206] New: Issue with using std::shared_ptr with custom equality operator and STL (gnu++0x)

[comaddcor at gmx dot net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48206

   Summary: Issue with using std::shared_ptr with custom equality
operator and STL (gnu++0x)
   Product: gcc
   Version: 4.5.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: comadd...@gmx.net


Hi

I'm not 100% sure if this is actually an issue with gcc. It might be with boost
(or even more likely my understanding of c++ :) ) but from what I could gather
it seems that when using std::shared_ptr together with a overloaded equality
operator and a std::list the behavior of the equality operator of shared_ptr is
not what it should be considering the source code.

It seems that even though the equality operator of shared_ptr should compare
the underlying objects the program compiled by gcc compares the memory
addresses.

I'm using:
gcc:
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/i686-pc-linux-gnu/4.5.2/lto-wrapper
Target: i686-pc-linux-gnu
Configured with: /build/src/gcc-4.5-20110127/configure --prefix=/usr
--enable-languages=c,c++,fortran,objc,obj-c++,ada --enable-shared
--enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu
--enable-gnu-unique-object --enable-lto --enable-plugin --enable-gold
--with-plugin-ld=ld.gold --disable-multilib --disable-libstdcxx-pch
--with-system-zlib --with-ppl --with-cloog
--with-cloog-include=/usr/include/cloog-ppl --libdir=/usr/lib
--libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info
Thread model: posix
gcc version 4.5.2 20110127 (prerelease) (GCC)

system:
Linux firebird 2.6.37-ARCH #1 SMP PREEMPT Tue Mar 8 08:08:06 UTC 2011 i686 AMD
Athlon(tm) 64 X2 Dual Core Processor 4800+ AuthenticAMD GNU/Linux

command line:
g++ -g -O0 -std=gnu++0x test.cpp

compiler output:
none

A sample program which shows the issue is attached as test.ii

I would expect the attached sample program to finish with "Success" and not
throw an exception.

If this is not a gcc bug I apologize and kindly ask if you could point my to
the right forum to readdress this issue.

Best regards
Cornelius

[Bug libstdc++/48205] New: clocale ieee_1003.1-2001 broken

[milan.jurik at xylab dot cz]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48205

   Summary: clocale ieee_1003.1-2001 broken
   Product: gcc
   Version: 4.5.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: milan.ju...@xylab.cz


Build 4.5.2 with --enable-clocale=ieee_1003.1-2001 on Solaris 11 Express x86
fails:

/usr/bin/ksh ../libtool --tag CXX   --mode=compile
/export/home/sfebuild/packages/BUILD/SFEgccruntime-4.5.2/gcc/./gcc/xgcc
-shared-libgcc
-B/export/home/sfebuild/packages/BUILD/SFEgccruntime-4.5.2/gcc/./gcc
-nostdinc++
-L/export/home/sfebuild/packages/BUILD/SFEgccruntime-4.5.2/gcc/i386-pc-solaris2.11/libstdc++-v3/src
-L/export/home/sfebuild/packages/BUILD/SFEgccruntime-4.5.2/gcc/i386-pc-solaris2.11/libstdc++-v3/src/.libs
-B/usr/gcc/4.5/i386-pc-solaris2.11/bin/ -B/usr/gcc/4.5/i386-pc-solaris2.11/lib/
-isystem /usr/gcc/4.5/i386-pc-solaris2.11/include -isystem
/usr/gcc/4.5/i386-pc-solaris2.11/sys-include
-I/export/home/sfebuild/packages/BUILD/SFEgccruntime-4.5.2/gcc/i386-pc-solaris2.11/libstdc++-v3/include/i386-pc-solaris2.11
-I/export/home/sfebuild/packages/BUILD/SFEgccruntime-4.5.2/gcc/i386-pc-solaris2.11/libstdc++-v3/include
-I/export/home/sfebuild/packages/BUILD/SFEgccruntime-4.5.2/gcc-4.5.2/libstdc++-v3/libsupc++
-I/usr/gnu/include -fno-implicit-templates -Wall -Wextra -Wwrite-strings
-Wcast-qual  -fdiagnostics-show-location=once  -ffunction-sections
-fdata-sections  -g -O2 -c -o codecvt.lo
../../../../gcc-4.5.2/libstdc++-v3/src/codecvt.cc
libtool: compile: 
/export/home/sfebuild/packages/BUILD/SFEgccruntime-4.5.2/gcc/./gcc/xgcc
-shared-libgcc
-B/export/home/sfebuild/packages/BUILD/SFEgccruntime-4.5.2/gcc/./gcc
-nostdinc++
-L/export/home/sfebuild/packages/BUILD/SFEgccruntime-4.5.2/gcc/i386-pc-solaris2.11/libstdc++-v3/src
-L/export/home/sfebuild/packages/BUILD/SFEgccruntime-4.5.2/gcc/i386-pc-solaris2.11/libstdc++-v3/src/.libs
-B/usr/gcc/4.5/i386-pc-solaris2.11/bin/ -B/usr/gcc/4.5/i386-pc-solaris2.11/lib/
-isystem /usr/gcc/4.5/i386-pc-solaris2.11/include -isystem
/usr/gcc/4.5/i386-pc-solaris2.11/sys-include
-I/export/home/sfebuild/packages/BUILD/SFEgccruntime-4.5.2/gcc/i386-pc-solaris2.11/libstdc++-v3/include/i386-pc-solaris2.11
-I/export/home/sfebuild/packages/BUILD/SFEgccruntime-4.5.2/gcc/i386-pc-solaris2.11/libstdc++-v3/include
-I/export/home/sfebuild/packages/BUILD/SFEgccruntime-4.5.2/gcc-4.5.2/libstdc++-v3/libsupc++
-I/usr/gnu/include -fno-implicit-templates -Wall -Wextra -Wwrite-strings
-Wcast-qual -fdiagnostics-show-location=once -ffunction-sections
-fdata-sections -g -O2 -c ../../../../gcc-4.5.2/libstdc++-v3/src/codecvt.cc 
-fPIC -DPIC -o .libs/codecvt.o
In file included from
/export/home/sfebuild/packages/BUILD/SFEgccruntime-4.5.2/gcc/i386-pc-solaris2.11/libstdc++-v3/include/locale:41:0,
 from ../../../../gcc-4.5.2/libstdc++-v3/src/codecvt.cc:25:
/export/home/sfebuild/packages/BUILD/SFEgccruntime-4.5.2/gcc/i386-pc-solaris2.11/libstdc++-v3/include/bits/locale_classes.h:303:37:
error: ‘_GLIBCXX_NUM_CATEGORIES’ was not declared in this scope
In file included from
/export/home/sfebuild/packages/BUILD/SFEgccruntime-4.5.2/gcc/i386-pc-solaris2.11/libstdc++-v3/include/bits/locale_facets.h:2601:0,
 from
/export/home/sfebuild/packages/BUILD/SFEgccruntime-4.5.2/gcc/i386-pc-solaris2.11/libstdc++-v3/include/locale:42,
 from ../../../../gcc-4.5.2/libstdc++-v3/src/codecvt.cc:25:
/export/home/sfebuild/packages/BUILD/SFEgccruntime-4.5.2/gcc/i386-pc-solaris2.11/libstdc++-v3/include/bits/locale_facets.tcc:
In member function ‘_OutIter std::num_put<_CharT,
_OutIter>::_M_insert_float(_OutIter, std::ios_base&, _CharT, char, _ValueT)
const’:
/export/home/sfebuild/packages/BUILD/SFEgccruntime-4.5.2/gcc/i386-pc-solaris2.11/libstdc++-v3/include/bits/locale_facets.tcc:1021:10:
error: ‘__convert_from_v’ is not a member of ‘std’
In file included from
/export/home/sfebuild/packages/BUILD/SFEgccruntime-4.5.2/gcc/i386-pc-solaris2.11/libstdc++-v3/include/bits/locale_facets_nonio.h:1930:0,
 from
/export/home/sfebuild/packages/BUILD/SFEgccruntime-4.5.2/gcc/i386-pc-solaris2.11/libstdc++-v3/include/locale:43,
 from ../../../../gcc-4.5.2/libstdc++-v3/src/codecvt.cc:25:
/export/home/sfebuild/packages/BUILD/SFEgccruntime-4.5.2/gcc/i386-pc-solaris2.11/libstdc++-v3/include/bits/locale_facets_nonio.tcc:
In member function ‘virtual _OutIter std::money_put<_CharT,
_OutIter>::do_put(iter_type, bool, std::ios_base&, char_type, long double)
const’:
/export/home/sfebuild/packages/BUILD/SFEgccruntime-4.5.2/gcc/i386-pc-solaris2.11/libstdc++-v3/include/bits/locale_facets_nonio.tcc:594:19:
error: ‘__convert_from_v’ is not a member of ‘std’
gmake[4]: *** [codecvt.lo] Error 1
gmake[4]: Leaving directory
`/export/home/sfebuild/packages/BUILD/SFEgccruntime-4.5.2/gcc/i386-pc-solaris2.11/libstdc++-v3/src'
gmake[3]: *** [all-recursive] Error 1
gm

[Bug libfortran/35667] HP-UX 10 has broken strtod

[danglin at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35667

--- Comment #7 from John David Anglin  2011-03-19 
17:25:21 UTC ---
Author: danglin
Date: Sat Mar 19 17:25:18 2011
New Revision: 171182

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=171182
Log:
PR fortran/35667
* io/io.h (convert_infnan): Declare.
* io/read.c (convert_infnan): New.
(read_f): Use convert_infnan to convert INFs and NANs.
* list_read.c (parse_real, read_real): Likewise.


Modified:
trunk/libgfortran/ChangeLog
trunk/libgfortran/io/io.h
trunk/libgfortran/io/list_read.c
trunk/libgfortran/io/read.c

[Bug tree-optimization/48172] [4.5/4.6/4.7 Regression] incorrect vectorization of loop in GCC 4.5.* with -O3

[irar at il dot ibm.com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48172

Ira Rosen  changed:

   What|Removed |Added

 CC||irar at il dot ibm.com

--- Comment #5 from Ira Rosen  2011-03-19 17:11:46 UTC 
---
(In reply to comment #4)

> 
> In particular for all tests the segment size we use for the alias tests
> is not enough for data-refs with differing DR_STEP.  It would need to
> take the number of iterations into account.

Right, instead of checking
init_addr1 + step1 * vf < init_addr2
we should check something like
init_addr1 + step1 * vf + scalar_niters * (step1 - step2) < init_addr2
(or the other direction).

[Bug rtl-optimization/48143] [4.6/4.7 Regression] ICE: in reset_sched_cycles_in_current_ebb, at sel-sched.c:7114 with custom flags

[steven at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48143

Steven Bosscher  changed:

   What|Removed |Added

 CC||steven at gcc dot gnu.org

--- Comment #4 from Steven Bosscher  2011-03-19 
16:51:02 UTC ---
Is it possible to check for this kind of problem in genautomata?

[Bug rtl-optimization/48156] [4.6/4.7 Regression] wrong code with -fcrossjumping

[steven at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48156

Steven Bosscher  changed:

   What|Removed |Added

 Status|ASSIGNED|NEW
 AssignedTo|steven at gcc dot gnu.org   |unassigned at gcc dot
   ||gnu.org

[Bug debug/48203] ICE in dwarf2out.c while building eglibc.

[ramana at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48203

Ramana Radhakrishnan  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.03.19 16:36:13
 CC||jakub at gcc dot gnu.org
 Ever Confirmed|0   |1

--- Comment #4 from Ramana Radhakrishnan  2011-03-19 
16:36:13 UTC ---
svn+ssh://gcc.gnu.org/svn/gcc/trunk@171033 => Broken
svn+ssh://gcc.gnu.org/svn/gcc/trunk@171031 => Good

Ramana

[Bug debug/48204] New: [4.5/4.6/4.7 Regression] ICE: in decimal_to_decnumber, at dfp.c:115 with -fno-tree-ccp -fno-tree-dominator-opts -fno-tree-fre -g

[zsojka at seznam dot cz]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48204

   Summary: [4.5/4.6/4.7 Regression] ICE: in decimal_to_decnumber,
at dfp.c:115 with -fno-tree-ccp
-fno-tree-dominator-opts -fno-tree-fre -g
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zso...@seznam.cz
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu


Created attachment 23724
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23724
reduced testcase

Compiler output:
$ gcc -O -fno-tree-ccp -fno-tree-dominator-opts -fno-tree-fre -g testcase.c
testcase.c: In function 'foo':
testcase.c:5:1: internal compiler error: in decimal_to_decnumber, at dfp.c:113
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Tested revisions:
r171179 - crash
4.6 r170955 - crash
4.5 r170955 - crash
4.4 r170955 - OK

[Bug c/48190] [regression?] Huge memory use while compiling qemu-0.4.0

[w41ter at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48190

--- Comment #1 from walt  2011-03-19 16:20:24 UTC ---
This bug is a duplicate of https://bugs.launchpad.net/gcc-linaro/+bug/714921

I tried to mark it as a duplicate, but bugzilla won't accept a bug number
from a different project.  Hmph.

[Bug fortran/48202] Internal compiler error

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48202

Tobias Burnus  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||burnus at gcc dot gnu.org
 Resolution||DUPLICATE

--- Comment #2 from Tobias Burnus  2011-03-19 
15:35:31 UTC ---
Thanks for the report. This regression has already been reported 5 days ago and
is tracked at PR 48117.

Work around: Use an older GCC - or GCC 4.6/4.7, cf.
http://gcc.gnu.org/wiki/GFortranBinaries

*** This bug has been marked as a duplicate of bug 48117 ***

[Bug fortran/48117] [4.5 Regression] ICE: OpenMP; in build_int_cst_wide, at tree.c:1178

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48117

Tobias Burnus  changed:

   What|Removed |Added

 CC||pmarguinaud at hotmail dot
   ||com

--- Comment #3 from Tobias Burnus  2011-03-19 
15:35:31 UTC ---
*** Bug 48202 has been marked as a duplicate of this bug. ***

[Bug fortran/48202] Internal compiler error

[kargl at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48202

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #1 from kargl at gcc dot gnu.org 2011-03-19 15:20:30 UTC ---
Code compiles on 4.6 branch (and I suspect trunk but I 
don't have a 4.7 aka trunk build to test.)

[Bug c/48197] possible wrong code bug at -O0

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48197

--- Comment #10 from Jakub Jelinek  2011-03-19 
15:17:06 UTC ---
BTW, this failed already in gcc 2.7.2.3, so doesn't seem to be a regression.
I think we want to fix it in 4.6 nevertheless, but only after 4.6.0 is
released.

[Bug target/47930] -marm is undocumented; driver accepts -mno-thumb

[ramana at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47930

Ramana Radhakrishnan  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.03.19 15:16:49
 CC||ramana at gcc dot gnu.org
 Ever Confirmed|0   |1

[Bug debug/48203] ICE in dwarf2out.c while building eglibc.

[ramana at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48203

--- Comment #3 from Ramana Radhakrishnan  2011-03-19 
15:12:55 UTC ---
This also breaks bootstrap in stage3 for arm-linux-gnueabi while building
c-common.c 

Ramana

[Bug c/48197] possible wrong code bug at -O0

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48197

--- Comment #9 from Jakub Jelinek  2011-03-19 
15:06:14 UTC ---
Created attachment 23723
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23723
gcc47-pr48197.patch

Maybe, but it might not be very easy, as it is related to diagnostics too (both
this routine issues warnings and I believe some warnings like -Wconversion rely
on the shortening too).

In the mean time, here is an untested fix.

[Bug bootstrap/44107] libstdc++ (dylib) is built with an erroneous dependency towards /usr/lib

[iains at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44107

--- Comment #5 from Iain Sandoe  2011-03-19 15:06:07 
UTC ---

in addition to the attachment at c #4  - you'll also need this:

Index: gcc/toplev.c
===
--- gcc/toplev.c(revision 171158)
+++ gcc/toplev.c(working copy)
@@ -1338,9 +1338,10 @@ process_options (void)
   if (flag_rename_registers == AUTODETECT_VALUE)
 flag_rename_registers = flag_unroll_loops || flag_peel_loops;

-  if (flag_non_call_exceptions)
+  if (flag_non_call_exceptions 
+  && !global_options_set.x_flag_asynchronous_unwind_tables)
 flag_asynchronous_unwind_tables = 1;
-  if (flag_asynchronous_unwind_tables)
+  if (flag_asynchronous_unwind_tables || flag_non_call_exceptions)
 flag_unwind_tables = 1;

   if (flag_value_profile_transformations)

[Bug target/48085] [x32] Unnecessary zero-extension

[hjl.tools at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48085

--- Comment #1 from H.J. Lu  2011-03-19 15:03:05 
UTC ---
The existing testcase is gcc.target/i386/pr32661-1.c.

[Bug debug/48203] ICE in dwarf2out.c while building eglibc.

[ramana at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48203

--- Comment #2 from Ramana Radhakrishnan  2011-03-19 
15:02:15 UTC ---
Created attachment 23722
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23722
Original test.

Unreduced testcase.

[Bug bootstrap/44107] libstdc++ (dylib) is built with an erroneous dependency towards /usr/lib

[iains at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44107

--- Comment #4 from Iain Sandoe  2011-03-19 15:00:14 
UTC ---
Created attachment 23721
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23721
work in progress patch to suppress unwind epilogues on Darwin

There was a change in gcc unwinding during 4.5 which is incompatible with the
system unwinders on Darwin 9 (and incompatible with the unwind compacter on
Darwin 10).  Specifically we now emit function epilogues.

This is an unreviewed, unapproved,  "work in progress" patch ; ergo, it has a
health warning that it might not be acceptable to the maintainers, even if it
works (which I think it does).

If this solves your problem then I think we should alter the description &c.
accordingly.

If it doesn't then, as Mike says, we'll need a reduced test-case to work on.

[Bug debug/48203] ICE in dwarf2out.c while building eglibc.

[ramana at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48203

--- Comment #1 from Ramana Radhakrishnan  2011-03-19 
14:59:37 UTC ---
Created attachment 23720
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23720
Testcase

Reduced testcase with delta.

[Bug debug/48203] New: ICE in dwarf2out.c while building eglibc.

[ramana at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48203

   Summary: ICE in dwarf2out.c while building eglibc.
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ram...@gcc.gnu.org


With this reduced testcase (min.i) and the original test.i cleaned from
ld-collate.c,  trunk ICE's building eglibc trunk. 


GCC was configured as --with-cpu=cortex-a9 --with-mode=thumb
--with-float=softfp --with-fpu=vfpv3-d16 

Compiling command line options are -O2 -g :

Here's a debug backtrace. 

(gdb)bt
#0  fancy_abort (file=0x116d200
"/home/ramana/cross-build/src/trunk/gcc/dwarf2out.c", line=13885,
function=0x11741c0 "mem_loc_descriptor") at /home/ramana/cross-build/src/trun\
k/gcc/diagnostic.c:892
#1  0x0069c359 in mem_loc_descriptor (rtl=0x77355c70, mode=SImode,
initialized=VAR_INIT_STATUS_INITIALIZED) at
/home/ramana/cross-build/src/trunk/gcc/dwarf2out.c:1\
3885
#2  0x0069c4f0 in mem_loc_descriptor (rtl=0x77246d68, mode=SImode,
initialized=VAR_INIT_STATUS_INITIALIZED) at
/home/ramana/cross-build/src/trunk/gcc/dwarf2out.c:1\
3913
#3  0x0069dd2f in loc_descriptor (rtl=0x77246d50, mode=SImode,
initialized=VAR_INIT_STATUS_INITIALIZED) at
/home/ramana/cross-build/src/trunk/gcc/dwarf2out.c:14562
#4  0x0069de43 in loc_descriptor (rtl=0x77247280, mode=SImode,
initialized=VAR_INIT_STATUS_INITIALIZED) at
/home/ramana/cross-build/src/trunk/gcc/dwarf2out.c:14590
#5  0x0069ebb4 in dw_loc_list_1 (loc=0x7746de60,
varloc=0x77247280, want_address=2, initialized=VAR_INIT_STATUS_INITIALIZED)
at /home/ramana/cross-build/src/tr\
unk/gcc/dwarf2out.c:14861
#6  0x0069f43c in dw_loc_list (loc_list=0x77246f48,
decl=0x7746de60, want_address=2) at
/home/ramana/cross-build/src/trunk/gcc/dwarf2out.c:15117
#7  0x006a06b2 in loc_list_from_tree (loc=0x7746de60,
want_address=2) at /home/ramana/cross-build/src/trunk/gcc/dwarf2out.c:15469
#8  0x006a6c26 in add_location_or_const_value_attribute
(die=0x7723b2d0, decl=0x7746de60, attr=DW_AT_location) at
/home/ramana/cross-build/src/trunk/gcc/dwarf2\
out.c:16954
#9  0x006b0973 in gen_variable_die (decl=0x7746de60, origin=0x0,
context_die=0x7723bd20) at
/home/ramana/cross-build/src/trunk/gcc/dwarf2out.c:19831
#10 0x006b6e21 in gen_decl_die (decl=0x7746de60, origin=0x0,
context_die=0x7723bd20) at
/home/ramana/cross-build/src/trunk/gcc/dwarf2out.c:21317
#11 0x006b4eab in process_scope_var (stmt=0x774b1000,
decl=0x7746de60, origin=0x0, context_die=0x7723bd20) at
/home/ramana/cross-build/src/trunk/gcc/dwarf2\
out.c:20864
#12 0x006b4f33 in decls_for_scope (stmt=0x774b1000,
context_die=0x7723bd20, depth=0) at
/home/ramana/cross-build/src/trunk/gcc/dwarf2out.c:20886
#13 0x006af0d7 in gen_subprogram_die (decl=0x774b,
context_die=0x77560320) at
/home/ramana/cross-build/src/trunk/gcc/dwarf2out.c:19457
#14 0x006b6aa9 in gen_decl_die (decl=0x774b, origin=0x0,
context_die=0x77560320) at
/home/ramana/cross-build/src/trunk/gcc/dwarf2out.c:21250
#15 0x006b7ad3 in dwarf2out_decl (decl=0x774b) at
/home/ramana/cross-build/src/trunk/gcc/dwarf2out.c:21624
#16 0x006b7aea in dwarf2out_function_decl (decl=0x774b) at
/home/ramana/cross-build/src/trunk/gcc/dwarf2out.c:21632
#17 0x00728fc0 in rest_of_handle_final () at
/home/ramana/cross-build/src/trunk/gcc/final.c:4280
#18 0x009041f1 in execute_one_pass (pass=0x16dc860) at
/home/ramana/cross-build/src/trunk/gcc/passes.c:1556
#19 0x009045b8 in execute_pass_list (pass=0x16dc860) at
/home/ramana/cross-build/src/trunk/gcc/passes.c:1611
#20 0x009045d6 in execute_pass_list (pass=0x16dd220) at
/home/ramana/cross-build/src/trunk/gcc/passes.c:1612
#21 0x009045d6 in execute_pass_list (pass=0x16dd1c0) at
/home/ramana/cross-build/src/trunk/gcc/passes.c:1612
#22 0x00a89dcd in tree_rest_of_compilation (fndecl=0x774b) at
/home/ramana/cross-build/src/trunk/gcc/tree-optimize.c:422
#23 0x00d018e8 in cgraph_expand_function (node=0x774ac580) at
/home/ramana/cross-build/src/trunk/gcc/cgraphunit.c:1576
#24 0x00d01a98 in cgraph_expand_all_functions () at
/home/ramana/cross-build/src/trunk/gcc/cgraphunit.c:1635
#25 0x00d0211c in cgraph_optimize () at
/home/ramana/cross-build/src/trunk/gcc/cgraphunit.c:1899
#26 0x00cff4ee in cgraph_finalize_compilation_unit () at
/home/ramana/cross-build/src/trunk/gcc/cgraphunit.c:1096
#27 0x004beb81 in c_write_global_declarations () at
/home/ramana/cross-build/src/trunk/gcc/c-decl.c:9871
#28 0x009fb08a in compile_file () at
/home/ramana/cross-build/src/trunk/gcc/toplev.c:591
#29 0x009fd388 in do_compile () at
/home/ramana/cross-build/src/trunk/gcc/

[Bug libfortran/47439] Fun with scratch files on Windows MKTEMP only allows for 26 files

[fxcoudert at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47439

Francois-Xavier Coudert  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #6 from Francois-Xavier Coudert  
2011-03-19 14:36:13 UTC ---
(In reply to comment #4)
> FAIL: gfortran.dg/scratch_1.f90  -O0  execution test

Must be a limit on the number of concurrently open files (the test checks for
3000). Next commit fixed it.

[Bug libfortran/47439] Fun with scratch files on Windows MKTEMP only allows for 26 files

[fxcoudert at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47439

--- Comment #5 from Francois-Xavier Coudert  
2011-03-19 14:35:12 UTC ---
Author: fxcoudert
Date: Sat Mar 19 14:35:05 2011
New Revision: 171180

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=171180
Log:
PR libfortran/47439
* gfortran.dg/scratch_1.f90: Adjust test.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/scratch_1.f90

[Bug libfortran/47439] Fun with scratch files on Windows MKTEMP only allows for 26 files

[hjl.tools at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47439

--- Comment #4 from H.J. Lu  2011-03-19 14:30:37 
UTC ---
On Linux/ia32, revision 171179 gave:

FAIL: gfortran.dg/scratch_1.f90  -O0  execution test
FAIL: gfortran.dg/scratch_1.f90  -O1  execution test
FAIL: gfortran.dg/scratch_1.f90  -O2  execution test
FAIL: gfortran.dg/scratch_1.f90  -O3 -fomit-frame-pointer  execution test
FAIL: gfortran.dg/scratch_1.f90  -O3 -fomit-frame-pointer -funroll-all-loops
-finline-functions  execution test
FAIL: gfortran.dg/scratch_1.f90  -O3 -fomit-frame-pointer -funroll-loops 
execution test
FAIL: gfortran.dg/scratch_1.f90  -O3 -g  execution test
FAIL: gfortran.dg/scratch_1.f90  -Os  execution test

[Bug pch/48201] ndefined reference to `__builtin_stdarg_start' when compiling util-vserver-0.30.216 on gentoo

[praktakus at go2 dot pl]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48201

--- Comment #2 from praktakus at go2 dot pl 2011-03-19 14:22:30 UTC ---
How should i fix my problem then?
Should I relly on anyone?
Best regards,
MB


Dnia 19 marca 2011 3:54 "pinskia at gcc dot gnu.org" 
napisał(a):

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48201
> 
> Andrew Pinski  changed:
> 
>What|Removed |Added
> 
>  Status|UNCONFIRMED |RESOLVED
>  Resolution||INVALID
> 
> --- Comment #1 from Andrew Pinski  2011-03-19 
> 02:54:17 UTC ---
> __builtin_stdarg_start has been removed as it was broken and not used by GCC's
> headers any more (it was really internal to GCC's stdards headers). 
> __builtin_va_start is the replacement.
> 
>

[Bug fortran/48202] New: Internal compiler error

[pmarguinaud at hotmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48202

   Summary: Internal compiler error
   Product: gcc
   Version: 4.5.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: pmarguin...@hotmail.com


The following piece of code caused gfortran to report an ICE, when used with
the following options : " -c -fopenmp -O2 ".

The code follows :

__

SUBROUTINE ESLEXTPOL(KASLB1,KMASK3)  

IMPLICIT NONE

INTEGER,INTENT(IN):: KASLB1  
INTEGER,OPTIONAL,INTENT(OUT)   :: KMASK3(KASLB1) 

!$OMP  PARALLEL
IF (PRESENT(KMASK3)) KMASK3=1
!$OMP END PARALLEL

END SUBROUTINE ESLEXTPOL

__

[Bug c/48197] possible wrong code bug at -O0

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48197

--- Comment #8 from Richard Guenther  2011-03-19 
12:34:55 UTC ---
(In reply to comment #7)
> I think the bug is in shorten_compare.
> We are called for GT_EXPR with op0 0LL and op1 (unsigned) (short) ((short) 0 ^
> (short) y)
> with long long result type. ^ above is BIT_XOR_EXPR with short type (shortened
> earlier, but that's fine, (unsigned) (short) ((short) 0 ^ (short y)) is still
> (unsigned) (short) y, i.e. sign extending y from 16 bits to 32 bits.  In the
> above the (short) cast doesn't really exist, it is simply a NOP_EXPR with
> unsigned int type of BIT_XOR_EXPR with short int type.
> get_narrower gives us 0LL (no change, unsignedp0 set to 0) and the short int
> BIT_XOR_EXPR (again, with unsignedp1 set to 0).  That is IMHO also fine,
> unsignedp1 says that the BIT_XOR_EXPR needs to be sign extended to the type.
> 
> But in the end shorten_compare says that the comparison just should be done in
> short int, which is wrong.

Ah, one of my special friends and endless source of wrong-code bugs ;)

Can we just remove this premature frontend optimization?

[Bug libfortran/47439] Fun with scratch files on Windows MKTEMP only allows for 26 files

[fxcoudert at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47439

--- Comment #3 from Francois-Xavier Coudert  
2011-03-19 12:09:34 UTC ---
Author: fxcoudert
Date: Sat Mar 19 12:09:27 2011
New Revision: 171178

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=171178
Log:
PR libfortran/47439

* io/unix.c (tempfile): Work around poor mktemp() implementations.

* gfortran.dg/scratch_1.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/scratch_1.f90
Modified:
trunk/gcc/testsuite/ChangeLog
trunk/libgfortran/ChangeLog
trunk/libgfortran/io/unix.c

[Bug c/48197] possible wrong code bug at -O0

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48197

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Last reconfirmed|2011-03-19 11:41:51 |

[Bug c/48197] possible wrong code bug at -O0

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48197

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.03.19 11:41:51
 AssignedTo|unassigned at gcc dot   |jakub at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1

[Bug bootstrap/44107] libstdc++ (dylib) is built with an erroneous dependency towards /usr/lib

[mikestump at comcast dot net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44107

--- Comment #3 from Mike Stump  2011-03-19 
09:49:35 UTC ---
> With an appropriate DYLD_LIBRARY_PATH, the problem disappears.

So, can you elaborate?  Which value makes the problem disappear?  I'd assume
you if you include $prefix/lib?

I fear this is going to be a hard bug...  If one wants any compatibility, the
routines in gcc_s from /usr/lib have to be used, in particular, the unwinder. 
But, that is exactly the thing that appears to be causing the problems.

I think we're going to need a test case, or if you could, could you try and
binary search the gcc trunk for the patch that caused this to break for you?

Also, you have this in bootstrap, does that mean that this doesn't bootstrap? 
If you could include the error messages from the bootstrap, or the name of the
gcc test case in the testsuite that is failing, that would help.

Thanks.

[Bug bootstrap/44107] libstdc++ (dylib) is built with an erroneous dependency towards /usr/lib

[Denis.Excoffier at airbus dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44107

Denis Excoffier  changed:

   What|Removed |Added

Version|4.5.0   |4.6.0

--- Comment #2 from Denis Excoffier  
2011-03-19 08:41:51 UTC ---
More or less the same applies for GCC 4.6.0 RC 20110314.

If i don't perform the modification indicated above in t-slibgcc-darwin (ie
force the build of libgcc_s_10.[45].dylib even when /usr/lib is not
$(shlib_slibdir), see line 31), the executable of my
(simple) C++ program gets stuck near its end (and never finishes).