[Bug bootstrap/43073] libiberty fails to build when using gcc-core

[laguest at archeia dot com]

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

Luke A. Guest  changed:

   What|Removed |Added

 CC||laguest at archeia dot com

--- Comment #6 from Luke A. Guest  2011-02-06 
04:45:03 UTC ---
This still turns up in 4.6 trunk downloaded from yesterday. doing a make
all-gcc fixes the problem.

[Bug preprocessor/47047] Support for path translation in __FILE__

[joerg at netbsd dot org]

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

--- Comment #4 from Joerg Sonnenberger  2011-02-06 
04:10:12 UTC ---
(In reply to comment #3)
> Please fill in the form at
> http://gcc.gnu.org/wiki/CopyrightAssignment
> and send it to fsf-reco...@gnu.org and they will then send you the 
> appropriate assignment form.

Done and processed.

[Bug target/47269] DSYMUTIL_SPEC doesn't handle -gtoggle

[howarth at nitro dot med.uc.edu]

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

--- Comment #4 from Jack Howarth  2011-02-06 
02:15:08 UTC ---
Mike,
   I thought it was pretty clear in the man page...

   -gtoggle
   Turn off generation of debug info, if leaving out this option would
   have generated it, or turn it on at level 2 otherwise.  The
   position of this argument in the command line does not matter, it
   takes effect after all other options are processed, and it does so
   only once, no matter how many times it is given.  This is mainly
   intended to be used with -fcompare-debug.

It inverts whatever the final status of debug code generation was. I think this
is why
you see it handled in toplev.c...

  if (flag_gtoggle)
{
  if (debug_info_level == DINFO_LEVEL_NONE)
{
  debug_info_level = DINFO_LEVEL_NORMAL;

  if (write_symbols == NO_DEBUG)
write_symbols = PREFERRED_DEBUGGING_TYPE;
}
  else
debug_info_level = DINFO_LEVEL_NONE;
}

rather than in opts.c.

[Bug c/47617] SSE rounding mode works -g, not -O3

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  2011-02-06 
02:13:37 UTC ---
I think you need to use -frounding-math.  GCC assumes by default the rounding
mode is round-to-nearest.  See
http://gcc.gnu.org/onlinedocs/gcc-4.5.2/gcc/Optimize-Options.html#index-frounding_002dmath-819
.

[Bug target/47269] DSYMUTIL_SPEC doesn't handle -gtoggle

[mikestump at comcast dot net]

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

--- Comment #3 from Mike Stump  2011-02-06 
01:31:52 UTC ---
If I understand what they intend, though, the documentation isn't clear on this
point:

%{!gtoggle:
  %{gdwarf-2:%{!gstabs*:%{!g0: -idsym}}}\   
  %{.c|.cc|.C|.cpp|.cp|.c++|.cxx|.CPP|.m|.mm: \ 
  %{gdwarf-2:%{!gstabs*:%{!g0: -dsym
}

%(gtoggle:
%{!gdwarf-2:%{!gstabs*:%{!g0: -idsym}}}\
  %{.c|.cc|.C|.cpp|.cp|.c++|.cxx|.CPP|.m|.mm: \ 
  %{!gdwarf-2:%{!gstabs*:%{!g0: -dsym
}

that said, I'd have the explain in detail exactly what happens with -g0 and
-gstabs.  You'd have to check to {} nesting to make sure I the } at the very
end is right.

[Bug target/47269] DSYMUTIL_SPEC doesn't handle -gtoggle

[mikestump at comcast dot net]

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

--- Comment #2 from Mike Stump  2011-02-06 
01:10:06 UTC ---
Luckily specs can do this:

  %{!fdump=*:%{!fsyntax-only:foo}}

says to put in foo, if those two flags are not given; this is and.

[Bug gcov-profile/47618] New: Collecting multiple profiles and using all for PGO

[roland at rschulz dot eu]

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

   Summary: Collecting multiple profiles and using all for PGO
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: gcov-profile
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: rol...@rschulz.eu


Currently only the file from one profiling run can be used for PGO. Especially
for MPI programs it would be nice if several folders containing profiling files
could be merged or several directories could be used together for
-fprofile-use.

For saving the profiling files it would be great if the folder name could
contain an environment variable or could be set by an environment variable.

Thus I suggest that one could either say:
-fprofile-dir /some/path/%q{SOME_ENV}  #same syntax as valgrind
or
export GCC_PROFILE_DIR=/some/path/$SOME_ENV

This would be very useful because MPI implementation provide the MPI rank as a
environment variable. Thus with the suggestion one could store the profile of
each MPI rank in a different folder.

[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO

[hubicka at gcc dot gnu.org]

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

--- Comment #38 from Jan Hubicka  2011-02-05 
22:38:41 UTC ---
Created attachment 23253
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23253
failing testcase

With current mainline and top of tree mozilla, things seems to go well, sqlite
issues are gone.  I now however get elfhack fault:

jh@evans:/abuild/jh/build-mozilla-new9/build/unix/elfhack>
/abuild/jh/build-mozilla-new9/build/unix/elfhack/elfhack -b test.so
test.so: terminate called after throwing an instance of 'std::runtime_error'
  what():  Section index out of bounds
Aborted (core dumped)

I am attaching test.so I get to see if it is elfhack miscomplation or the
binary.

[Bug other/42333] complex division failure on darwin10 with -lm

[mrs at gcc dot gnu.org]

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

m...@gcc.gnu.org  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.02.05 22:30:43
 CC||mrs at gcc dot gnu.org
 Ever Confirmed|0   |1

--- Comment #53 from mrs at gcc dot gnu.org  2011-02-05 
22:30:43 UTC ---
I think we should fix this by patching in a new linkage name for the routine in
question with darwin_patch_builtins and creating a forwarding stub from the old
name to the new name that we link against.  We could mix in _ieee into the new
name.  If we compile with -fast-math we can call the old routine, no patch, and
if one wants accuracy, the we call the new name.

[Bug c/47617] New: SSE rounding mode works -g, not -O3

[cck0011 at yahoo dot com]

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

   Summary: SSE rounding mode works -g, not -O3
   Product: gcc
   Version: 4.3.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: cck0...@yahoo.com


Created attachment 23252
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23252
generated .i file

Hi folks,

  I'm working with SSE intrinsics and think I have a rounding problem. When I
try to change modes with _MM_SET_ROUNDING_MODE, I see different results when
compiled "-g", but not "-O3". 

  What am I missing?

thanks!

Using built-in specs.
Target: i386-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl
=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared
--enable-threads=posix --enable-che
cking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-languages=c,
c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi
--enable-plugin --with-java-home=/us
r/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile
--enable-java-maintainer-mode --with-ecj-jar
=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib --with-cpu=generic
--build=i386-redhat-linux
Thread model: posix
gcc version 4.3.2 20081105 (Red Hat 4.3.2-7) (GCC)
COLLECT_GCC_OPTIONS='-O3' '-Wall' '-o' 'round' '-msse' '-mmmx' '-save-temps'
'-v' '-mtune=generic'
 /usr/libexec/gcc/i386-redhat-linux/4.3.2/cc1 -E -quiet -v round.c -msse -mmmx
-mtune=generic -Wall -O3 -fp
ch-preprocess -o round.i
ignoring nonexistent directory
"/usr/lib/gcc/i386-redhat-linux/4.3.2/include-fixed"
ignoring nonexistent directory
"/usr/lib/gcc/i386-redhat-linux/4.3.2/../../../../i386-redhat-linux/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/include
 /usr/lib/gcc/i386-redhat-linux/4.3.2/include
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-O3' '-Wall' '-o' 'round' '-msse' '-mmmx' '-save-temps'
'-v' '-mtune=generic'
 /usr/libexec/gcc/i386-redhat-linux/4.3.2/cc1 -fpreprocessed round.i -quiet
-dumpbase round.c -msse -mmmx -
mtune=generic -auxbase round -O3 -Wall -version -o round.s
GNU C (GCC) version 4.3.2 20081105 (Red Hat 4.3.2-7) (i386-redhat-linux)
compiled by GNU C version 4.3.2 20081105 (Red Hat 4.3.2-7), GMP version
4.2.2, MPFR version 2.3.2.
GGC heuristics: --param ggc-min-expand=55 --param ggc-min-heapsize=48000
Compiler executable checksum: 3bee52601079f736b7b63b762646f4ba
round.c: In function ‘test_sse1_feature’:
round.c:150: warning: unused variable ‘sig’
round.c:150: warning: unused variable ‘extensions’
round.c:149: warning: ‘edx’ may be used uninitialized in this function
COLLECT_GCC_OPTIONS='-O3' '-Wall' '-o' 'round' '-msse' '-mmmx' '-save-temps'
'-v' '-mtune=generic'
 as -V -Qy -o round.o round.s
GNU assembler version 2.18.50.0.9 (i386-redhat-linux) using BFD version version
2.18.50.0.9-8.fc10 20080822
COMPILER_PATH=/usr/libexec/gcc/i386-redhat-linux/4.3.2/:/usr/libexec/gcc/i386-redhat-linux/4.3.2/:/usr/libe
xec/gcc/i386-redhat-linux/:/usr/lib/gcc/i386-redhat-linux/4.3.2/:/usr/lib/gcc/i386-redhat-linux/:/usr/libex
ec/gcc/i386-redhat-linux/4.3.2/:/usr/libexec/gcc/i386-redhat-linux/:/usr/lib/gcc/i386-redhat-linux/4.3.2/:/
usr/lib/gcc/i386-redhat-linux/
LIBRARY_PATH=/usr/lib/gcc/i386-redhat-linux/4.3.2/:/usr/lib/gcc/i386-redhat-linux/4.3.2/:/usr/lib/gcc/i386-
redhat-linux/4.3.2/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-O3' '-Wall' '-o' 'round' '-msse' '-mmmx' '-save-temps'
'-v' '-mtune=generic'
 /usr/libexec/gcc/i386-redhat-linux/4.3.2/collect2 --eh-frame-hdr --build-id -m
elf_i386 --hash-style=gnu -
dynamic-linker /lib/ld-linux.so.2 -o round
/usr/lib/gcc/i386-redhat-linux/4.3.2/../../../crt1.o /usr/lib/gc
c/i386-redhat-linux/4.3.2/../../../crti.o
/usr/lib/gcc/i386-redhat-linux/4.3.2/crtbegin.o -L/usr/lib/gcc/i3
86-redhat-linux/4.3.2 -L/usr/lib/gcc/i386-redhat-linux/4.3.2
-L/usr/lib/gcc/i386-redhat-linux/4.3.2/../../.
. round.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed
-lgcc_s --no-as-needed /usr/lib/gc
c/i386-redhat-linux/4.3.2/crtend.o
/usr/lib/gcc/i386-redhat-linux/4.3.2/../../../crtn.o

[Bug fortran/47613] [4.6 Regression] namelist read with -static

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #12 from janus at gcc dot gnu.org 2011-02-05 22:03:15 UTC ---
Apparently the failure goes away when configuring with
--enable-version-specific-runtime-libs. Sorry for the noise.

[Bug other/42333] complex division failure on darwin10 with -lm

[howarth at nitro dot med.uc.edu]

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

--- Comment #52 from Jack Howarth  2011-02-05 
21:49:14 UTC ---
Filed bug report upstream against compiler-rt with testcase...

http://llvm.org/bugs/show_bug.cgi?id=9150

[Bug other/42333] complex division failure on darwin10 with -lm

[howarth at nitro dot med.uc.edu]

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

--- Comment #51 from Jack Howarth  2011-02-05 
21:11:30 UTC ---
The __divdc3 in Snow Leopard come from the compiler-rt llvm project. Here are
the tests they they use to validate their __divdc3...

http://llvm.org/svn/llvm-project/compiler-rt/trunk/test/Unit/divdc3_test.c

Any ideas on how to convert the failing test case here into a line for their
divdc3_test.c so we can submit a bugzilla with test case upstream?

[Bug middle-end/47610] [4.6 Regression] cp-demangle.c:1970:1: error: cplus_demangle_builtin_types causes a section type conflict

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #10 from Jakub Jelinek  2011-02-05 
21:04:54 UTC ---
Fixed.

[Bug rtl-optimization/47612] RTL crash when cc0 setter moved away from cc0 user

[mikpe at it dot uu.se]

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

Mikael Pettersson  changed:

   What|Removed |Added

 CC||bernds at gcc dot gnu.org,
   ||mikpe at it dot uu.se

--- Comment #4 from Mikael Pettersson  2011-02-05 
20:48:53 UTC ---
I can reproduce the ICE with a cross to m68k-elf.  It's caused by r167779:

Author: bernds
Date: Tue Dec 14 00:23:40 2010
New Revision: 167779

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=167779
Log:
gcc/
PR rtl-optimization/44374
Reapply patch with fixes.
...

[Bug middle-end/47610] [4.6 Regression] cp-demangle.c:1970:1: error: cplus_demangle_builtin_types causes a section type conflict

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek  2011-02-05 
20:35:19 UTC ---
Author: jakub
Date: Sat Feb  5 20:35:16 2011
New Revision: 169855

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=169855
Log:
PR middle-end/47610
* varasm.c (default_section_type_flags): If decl is NULL,
and name is .data.rel.ro or .data.rel.ro.local, set SECTION_RELRO
bit.

* gcc.dg/pr47610.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr47610.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/varasm.c

[Bug fortran/42434] Documentation should provide advice about clock resolutions

[jb at gcc dot gnu.org]

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

Janne Blomqvist  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #3 from Janne Blomqvist  2011-02-05 20:22:45 
UTC ---
Closing. CPU_TIME documentation already mentions the achievable resolution, now
SYSTEM_CLOCK, and for DATE_AND_TIME the interface specifies millisecond
resolution which we achieve provided the target supports gettimeofday().

[Bug fortran/42434] Documentation should provide advice about clock resolutions

[jb at gcc dot gnu.org]

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

--- Comment #2 from Janne Blomqvist  2011-02-05 20:20:52 
UTC ---
Author: jb
Date: Sat Feb  5 20:20:48 2011
New Revision: 169854

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=169854
Log:
PR 42434 Update SYSTEM_CLOCK documentation

Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/intrinsic.texi

[Bug fortran/42434] Documentation should provide advice about clock resolutions

[jb at gcc dot gnu.org]

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

Janne Blomqvist  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
URL||http://gcc.gnu.org/ml/gcc-p
   ||atches/2011-02/msg00331.htm
   ||l
 AssignedTo|unassigned at gcc dot   |jb at gcc dot gnu.org
   |gnu.org |

--- Comment #1 from Janne Blomqvist  2011-02-05 20:06:48 
UTC ---
Patch: http://gcc.gnu.org/ml/gcc-patches/2011-02/msg00331.html

[Bug target/47558] 163267 breaks exception traceback in xplor-nih

[dominiq at lps dot ens.fr]

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

--- Comment #62 from Dominique d'Humieres  
2011-02-05 19:23:09 UTC ---
> ... FYI, I don't
> see why getting ___divdc3 fixed in time for Lion should be that difficult.

>From the audit trail of PR42333, this is not a bug but a choice of speed over
safety: the safe implementation of the complex division is not more accurate
that the fast/naive implementation when the later works, it just extend the
range for large/small values of the modulus. If you know that you data are in
the safe region, you may prefer the fast case.

[Bug target/47558] 163267 breaks exception traceback in xplor-nih

[howarth at nitro dot med.uc.edu]

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

--- Comment #61 from Jack Howarth  2011-02-05 
19:04:18 UTC ---
Actually the two issues are entirely intertwined. PR47558 was due to not
prioritizing symbols from libSystem over those from libgcc_ext. FYI, I don't
see why getting ___divdc3 fixed in time for Lion should be that difficult.
Since this issue is in the compiler-rt open source project, I'm sure the linux
users of llvm would not be happy to see their math routines degraded.

[Bug target/47558] 163267 breaks exception traceback in xplor-nih

[iains at gcc dot gnu.org]

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

--- Comment #60 from Iain Sandoe  2011-02-05 18:57:20 
UTC ---
(In reply to comment #59)
> I can confirm that the patch in Comment 58 both eliminates the failure in the
> reduced test case from Comment 56 as well as the failure in the dipCoup test 
> in
> xplor-nih. I am less certain that we want the
> current phrasing of the comment...
> 
> +/* FIXME: Work around PR47558 by linking against libSystem ahead of 
> +   libgcc_ext. */

My feeling is that the FIXME should relate to the problem at hand - which is
that our existing _ext design is incompatible with -flat_namespace.  That is
what needs fixing.

> We should arrive at a consensus on whether symbols which overlap between
> libgcc_ext and libSystem should be given priority in libSystem and resolved
> there. This patch achieves this and if we agree this should be the case, the
> comment should instead read...

the way to achieve that is to make a proper 10.6.ver to control which symbols
we wish to export - (but not the subject of this PR).

> +/* Linking libSystem ahead of libgcc_ext prioritizes those overlapping 
> symbols
> in libSystem
> +over those from libgcc_ext which re-exposes PR42333. */
> 
> This is the correct behavior for the long-run on darwin and we should 
> re-double
> our efforts to get
> ,  ___divdc3 slightly wrong, fixed in Lion.

Well, indeed ... highly desirable to have bugs fixed (but that, again, is not
this bug).

However, I'm not going to nail colours to the mast over the wording of the
FIXME - so long as it is not confusing or misleading to some future maintainer
trying to fix the problem ;)

[Bug target/47558] 163267 breaks exception traceback in xplor-nih

[howarth at nitro dot med.uc.edu]

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

--- Comment #59 from Jack Howarth  2011-02-05 
18:40:15 UTC ---
I can confirm that the patch in Comment 58 both eliminates the failure in the
reduced test case from Comment 56 as well as the failure in the dipCoup test in
xplor-nih. I am less certain that we want the
current phrasing of the comment...

+/* FIXME: Work around PR47558 by linking against libSystem ahead of 
+   libgcc_ext. */

We should arrive at a consensus on whether symbols which overlap between
libgcc_ext and libSystem should be given priority in libSystem and resolved
there. This patch achieves this and if we agree this should be the case, the
comment should instead read...

+/* Linking libSystem ahead of libgcc_ext prioritizes those overlapping symbols
in libSystem
+over those from libgcc_ext which re-exposes PR42333. */

This is the correct behavior for the long-run on darwin and we should re-double
our efforts to get
,  ___divdc3 slightly wrong, fixed in Lion.

[Bug fortran/47613] [4.6 Regression] namelist read with -static

[hjl.tools at gmail dot com]

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

--- Comment #11 from H.J. Lu  2011-02-05 18:14:14 
UTC ---
On Fedora/14, I got

execve("./a.out", ["./a.out"], [/* 34 vars */]) = 0
uname({sys="Linux", node="gnu-34.sc.intel.com", ...}) = 0
brk(0)  = 0x251d000
brk(0x251e1a0)  = 0x251e1a0
arch_prctl(ARCH_SET_FS, 0x251d880)  = 0
brk(0x253f1a0)  = 0x253f1a0
brk(0x254)  = 0x254
fstat(0, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 2), ...}) = 0
fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 2), ...}) = 0
fstat(2, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 2), ...}) = 0
getcwd("/export/regression/rrs", 4096)  = 23
open("fort.20", O_RDWR|O_CREAT, 0666)   = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fff24fecd10) = -1 ENOTTY
(Inappropriate ioctl for device)
read(3, "", 8192)   = 0
read(3, "", 8192)   = 0
write(1, "  -1 T\n", 15  -1 T
)= 15
close(3)= 0
exit_group(0)   = ?

[Bug fortran/47613] [4.6 Regression] namelist read with -static

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #10 from Steve Kargl  
2011-02-05 18:11:02 UTC ---
On Sat, Feb 05, 2011 at 05:59:49PM +, janus at gcc dot gnu.org wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47613
> 
> --- Comment #9 from janus at gcc dot gnu.org 2011-02-05 17:59:40 UTC ---
> (In reply to comment #7)
> > > What else can I do to nail this down?
> > 
> > Please show
> > 
> > # strace ./a.out
> 
> Here you go:
> 
> > strace ./a.out 
> execve("./a.out", ["./a.out"], [/* 91 vars */]) = 0
> uname({sys="Linux", node="manzanita.site", ...}) = 0
> brk(0)  = 0x6be000
> brk(0x6bf150)   = 0x6bf150
> arch_prctl(ARCH_SET_FS, 0x6be850)   = 0
> brk(0x6e0150)   = 0x6e0150
> brk(0x6e1000)   = 0x6e1000
> fstat(0, {st_mode=S_IFCHR|0600, st_rdev=makedev(136, 0), ...}) = 0
> fstat(1, {st_mode=S_IFCHR|0600, st_rdev=makedev(136, 0), ...}) = 0
> fstat(2, {st_mode=S_IFCHR|0600, st_rdev=makedev(136, 0), ...}) = 0
> getcwd("/home/jweil/GSoC/PRs/47613", 4096) = 27
> open("fort.20", O_RDWR|O_CREAT, 0666)   = 3
> fstat(3, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
> ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fffe9e133a0) = -1 ENOTTY
> (Inappropriate ioctl for device)
> read(3, "", 8192)   = 0
> read(3, "", 8192)   = 0
> write(1, "5010 F\n", 155010 F
> )= 15
> close(3)= 0
> exit_group(0)   = ?

Does strace on linux work with the dynamically linked image?
It would probably be profitable to compare strace of dynamic
vs static linkage.  The ioctl above looks odd.  ENOTTY?

[Bug fortran/47613] [4.6 Regression] namelist read with -static

[janus at gcc dot gnu.org]

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

--- Comment #9 from janus at gcc dot gnu.org 2011-02-05 17:59:40 UTC ---
(In reply to comment #7)
> > What else can I do to nail this down?
> 
> Please show
> 
> # strace ./a.out

Here you go:

> strace ./a.out 
execve("./a.out", ["./a.out"], [/* 91 vars */]) = 0
uname({sys="Linux", node="manzanita.site", ...}) = 0
brk(0)  = 0x6be000
brk(0x6bf150)   = 0x6bf150
arch_prctl(ARCH_SET_FS, 0x6be850)   = 0
brk(0x6e0150)   = 0x6e0150
brk(0x6e1000)   = 0x6e1000
fstat(0, {st_mode=S_IFCHR|0600, st_rdev=makedev(136, 0), ...}) = 0
fstat(1, {st_mode=S_IFCHR|0600, st_rdev=makedev(136, 0), ...}) = 0
fstat(2, {st_mode=S_IFCHR|0600, st_rdev=makedev(136, 0), ...}) = 0
getcwd("/home/jweil/GSoC/PRs/47613", 4096) = 27
open("fort.20", O_RDWR|O_CREAT, 0666)   = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fffe9e133a0) = -1 ENOTTY
(Inappropriate ioctl for device)
read(3, "", 8192)   = 0
read(3, "", 8192)   = 0
write(1, "5010 F\n", 155010 F
)= 15
close(3)= 0
exit_group(0)   = ?

[Bug libfortran/47567] Wrong output for small absolute values with F editing

[jvdelisle at gcc dot gnu.org]

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

--- Comment #10 from Jerry DeLisle  2011-02-05 
17:58:51 UTC ---
Author: jvdelisle
Date: Sat Feb  5 17:58:48 2011
New Revision: 169853

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=169853
Log:
2011-02-05  Jerry DeLisle  

PR libgfortran/47567
* io/write_float.def (output_float): Eliminate some redundant code.
Adjust width for case of F0.X for values of zero and all other values.
Expand cases where '*' is set to give cleaner results.

Modified:
trunk/libgfortran/ChangeLog
trunk/libgfortran/io/write_float.def

[Bug fortran/47613] [4.6 Regression] namelist read with -static

[jvdelisle at gcc dot gnu.org]

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

--- Comment #8 from Jerry DeLisle  2011-02-05 
17:57:09 UTC ---
Do you have environment variables set for buffering or non-buffering? I am on
Fedora 14 and don't see it.  Its puzzling.  Have you tried clean bootstrap with
an empty install directory?

[Bug fortran/47613] [4.6 Regression] namelist read with -static

[hjl.tools at gmail dot com]

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

--- Comment #7 from H.J. Lu  2011-02-05 17:50:43 
UTC ---
(In reply to comment #6)
> For completeness, I'm seeing this issue on openSUSE 11.3 (x86_64) with
> 
> What else can I do to nail this down?

Please show

# strace ./a.out

[Bug fortran/47616] ICE with allocate(a,source=(/1/))

[tkoenig at gcc dot gnu.org]

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

--- Comment #1 from Thomas Koenig  2011-02-05 
17:31:19 UTC ---
Same error with mold:

ig25@linux-fd1f:~/Krempel/Arr> cat arr-3.f90

program main
  implicit none
  integer, dimension(:), allocatable :: a
  allocate (a, mold=(/ 1 /))
end program main
ig25@linux-fd1f:~/Krempel/Arr> gfortran arr-3.f90
0x1450c70
f951: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

The test case from comment #1 is invalid F 2003:

C628 (R628) An allocate-shape-spec-list shall appear if and only if the
allocate-object is an array.

... but valid F 2008:

C633 (R631) If allocate-object is an array either allocate-shape-spec-list
shall appear or source-expr shall appear and have the same rank as
allocate-object. If allocate-object is scalar, allocate-shape-spec-list shall
not appear.

[Bug middle-end/47610] [4.6 Regression] cp-demangle.c:1970:1: error: cplus_demangle_builtin_types causes a section type conflict

[dave at hiauly1 dot hia.nrc.ca]

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

--- Comment #8 from dave at hiauly1 dot hia.nrc.ca 2011-02-05 17:09:48 UTC ---
> Can't reproduce that with a cross to hppa64-hp-hpux11.11, I get the expected
> error instantly.

Sorry, this is my fault.  I misapplied your patch.

Dave

[Bug fortran/47613] [4.6 Regression] namelist read with -static

[janus at gcc dot gnu.org]

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

--- Comment #6 from janus at gcc dot gnu.org 2011-02-05 17:06:20 UTC ---
For completeness, I'm seeing this issue on openSUSE 11.3 (x86_64) with

> gfortran-4.6 -v
Using built-in specs.
COLLECT_GCC=gfortran-4.6
COLLECT_LTO_WRAPPER=/usr/lib64/gcc/x86_64-unknown-linux-gnu/4.6.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /home/jweil/gcc46/trunk/configure --program-suffix=-4.6
--prefix=/usr --libdir=/usr/lib64 --libexecdir=/usr/lib64
--enable-languages=c,fortran --enable-checking --disable-multilib --enable-lto
--disable-bootstrap
Thread model: posix
gcc version 4.6.0 20110202 (experimental) [trunk revision 169518] (GCC)


What else can I do to nail this down?

[Bug middle-end/47610] [4.6 Regression] cp-demangle.c:1970:1: error: cplus_demangle_builtin_types causes a section type conflict

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  2011-02-05 
16:57:10 UTC ---
Can't reproduce that with a cross to hppa64-hp-hpux11.11, I get the expected
error instantly.

[Bug fortran/47571] [4.6 Regression] undefined reference to clock_gettime in Linux build of 02/01/2011

[jb at gcc dot gnu.org]

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

--- Comment #22 from Janne Blomqvist  2011-02-05 
16:22:09 UTC ---
Author: jb
Date: Sat Feb  5 16:22:04 2011
New Revision: 169852

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=169852
Log:
PR 47571 Fix HPUX bootstrap regression, cleanup

Modified:
trunk/libgfortran/ChangeLog
trunk/libgfortran/intrinsics/date_and_time.c
trunk/libgfortran/intrinsics/system_clock.c
trunk/libgfortran/intrinsics/time_1.h

[Bug target/46779] wrong code generation for array access

[avr at gjlay dot de]

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

Georg Lay  changed:

   What|Removed |Added

 CC||avr at gjlay dot de

--- Comment #5 from Georg Lay  2011-02-05 16:01:14 UTC ---
Probably we see PR45291 here introduced by the byte-shift w <<= 8. Some
versions of avr backend emit bad subreg rtx which is still present in 4.5.2 and
4.6.0

http://gcc.gnu.org/PR45291

FYI, not clobbering R1 resp. R0 will not trigger a bug because there regs are
fixed.

[Bug middle-end/47610] [4.6 Regression] cp-demangle.c:1970:1: error: cplus_demangle_builtin_types causes a section type conflict

[danglin at gcc dot gnu.org]

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

--- Comment #6 from John David Anglin  2011-02-05 
15:45:01 UTC ---
I'm seeing the following new fail on hppa64-hp-hpux11.11:

Executing on host: /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/
/te
st/gnu/gcc/gcc/gcc/testsuite/gcc.dg/20051207-3.c   -fno-unit-at-a-time -S  -o
20
051207-3.s(timeout = 300)
FAIL: gcc.dg/20051207-3.c  (test for errors, line 7)

-bash-3.2$ less /test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/20051207-3.c
/* GCC doesn't generate any .eh_frame data for this TU itself, so it
   shouldn't warn about "a" conflicting with the built-in idea of
   .eh_frame.  The warning therefore belongs on the second decl.  */
/* { dg-options "-fno-unit-at-a-time" } */
/* { dg-require-named-sections "" } */
int a __attribute__((section (".eh_frame"))) = 1;
const int b __attribute__((section (".eh_frame"))) = 1; /* { dg-error "section
t
ype conflict" } */

[Bug tree-optimization/46188] [4.5 regression] -fipa-cp removes destructor call

[mikpe at it dot uu.se]

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

Mikael Pettersson  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org,
   ||mikpe at it dot uu.se

--- Comment #10 from Mikael Pettersson  2011-02-05 
15:19:22 UTC ---
This was fixed for 4.6 by r159907:

Author: hubicka
Date: Thu May 27 02:07:01 2010
New Revision: 159907

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159907
Log:
* cgraphunit.c (verify_cgraph_node): Do checking that DECL match
edge only when checking is enabled; check using former_clone_of;
check inline clones too.
(cgraph_materialize_clone): Record former_clone_of pointer.
(cgraph_redirect_edge_call_stmt_to_callee): Assert that we are not
combining redirections; dump args_to_skip bitmap
(cgraph_materialize_all_clones): Do no redirection here.
* ipa-inline.c (inline_transform): Do redirection here.
* cgraph.h (struct cgraph_node): Add former_clone_of filed (enabled
cheking only).

See also:
http://gcc.gnu.org/ml/gcc-patches/2010-05/msg02029.html

The patch doesn't apply as-is to 4.5.2 so I haven't checked if it solves the
bug there too.

[Bug fortran/47613] [4.6 Regression] namelist read with -static

[hjl.tools at gmail dot com]

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

--- Comment #5 from H.J. Lu  2011-02-05 15:11:04 
UTC ---
Revision 169847 also works for me on Fedora 14.

[Bug tree-optimization/47615] [4.6 Regression] ICE: too deep recursion in phi_translate/phi_translate_1 with -ftree-pre -fno-tree-fre -fno-tree-sra

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.02.05 14:58:11
 CC||rguenth at gcc dot gnu.org
   Target Milestone|--- |4.6.0
 Ever Confirmed|0   |1

--- Comment #1 from H.J. Lu  2011-02-05 14:58:11 
UTC ---
It is caused by revision 169089:

http://gcc.gnu.org/ml/gcc-cvs/2011-01/msg00711.html

[Bug fortran/47613] [4.6 Regression] namelist read with -static

[hjl.tools at gmail dot com]

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

--- Comment #4 from H.J. Lu  2011-02-05 14:48:07 
UTC ---
On Fedora 14/x86-64, I got

[hjl@gnu-34 rrs]$ /usr/gcc-4.6/bin/gfortran pr47613.f90 -static
[hjl@gnu-34 rrs]$ ./a.out
  -1 T
[hjl@gnu-34 rrs]$ /usr/gcc-4.6/bin/gfortran -v
Using built-in specs.
COLLECT_GCC=/usr/gcc-4.6/bin/gfortran
COLLECT_LTO_WRAPPER=/usr/gcc-4.6/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /net/gnu-13/export/gnu/src/gcc/gcc/configure
--enable-clocale=gnu --with-system-zlib --enable-checking=assert
--with-demangler-in-ld --prefix=/usr/gcc-4.6 --with-local-prefix=/usr/local
--enable-cloog-backend=isl --enable-stage1-languages=c++
--with-ppl-include=/opt/gnu/include --with-ppl-lib=/opt/gnu/lib64
--with-cloog-include=/opt/gnu/include --with-cloog-lib=/opt/gnu/lib64
--with-fpmath=sse
Thread model: posix
gcc version 4.6.0 20110202 (experimental) [trunk revision 169766] (GCC) 
[hjl@gnu-34 rrs]$

[Bug lto/47528] liblto_plugin.so not found should not to be an fatal error

[ktietz at gcc dot gnu.org]

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

Kai Tietz  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2011.02.05 13:42:49
 CC||ktietz at gcc dot gnu.org
 Ever Confirmed|0   |1

--- Comment #4 from Kai Tietz  2011-02-05 13:42:49 
UTC ---
Does it help on cross-compile to do after 'make all-gcc && make install-gcc' to
do additionally 'make install-lto-plugin'?

The fatal error in gcc.c is correct, but indeed it seems that the plugin
doesn't get installed by doing 'make install-gcc'.

[Bug libfortran/47567] Wrong output for small absolute values with F editing

[jvdelisle at gcc dot gnu.org]

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

--- Comment #9 from Jerry DeLisle  2011-02-05 
13:15:08 UTC ---
I completely understand your position on '*' vs '0'

At the time we first implemented showing that special case with zero, we had a
bit of discussion on it. It was clear that the standard does not explicitly say
that one part of its wording over rules some other part of its wording in this
case.

.001 rounds to zero on display but it is not zero and it would be misleading to
call it zero.

0. or .0 on the other hand, is truly zero and we have an opportunity to display
that information. We thought '0' was more useful than '*'. So we wanted to
treat this as a special case. There is room for interpretation in the Standard.
 It is not so definite as one might prefer it to be and I think it is standard
compliant to show it either way.

Does anyone else have a comment?

[Bug fortran/47613] [4.6 Regression] namelist read with -static

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

 CC||jvdelisle at gcc dot
   ||gnu.org

--- Comment #3 from Jerry DeLisle  2011-02-05 
12:48:23 UTC ---
"And -static should not really make a difference in terms of the returned error
value."

This is true, it should not make a difference and on my system it does not.

I have x86-64-linux-gnu

I think what you are seeing is some sort of library path issue. Really odd.

[Bug target/47558] 163267 breaks exception traceback in xplor-nih

[iains at gcc dot gnu.org]

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

--- Comment #58 from Iain Sandoe  2011-02-05 12:21:51 
UTC ---
The response from Nick indicates that the documentation for -flat_namespace and
two-level namespaces is correct and up to date - so we should proceed with a
fix.

>From a general specs point of view, I don't think we should be including
libSystem in REAL_LIBGCC_SPEC, it kinda defeats the object of separating %G and
%L.  If we don't care about this, then let's just set one of those to "" to
avoid future confusion. 

* We also need to watch out for the fact that fortran and java both hijack *lib
to interpose their library lists.

Here is a patch that should achieve the same thing as
http://gcc.gnu.org/ml/gcc-patches/2011-02/msg00274.html, but using the
LINK_GCC_C_SEQUENCE_SPEC (essentially a slightly more sophisticated version of
comment #17).

It is probably harmless to insert libSystem before libgcc_s on Darwin 9 - since
there are no unwinder symbols in Darwin 9's libSystem -- however, for the sake
of consistency with other tools, I've wrapped it specifically for Darwin >= 10.

(sometime I'd also like to split -no_compact_unwinder into its own macro - and
provide a user way to switch it off - although it's still needed by default, as
things stand).

In addition to the cases already posted; for fortran, I get a link order of:
 -lgfortran -lSystem -lgcc_ext.10.5 -lgcc -lquadmath -lm -lgcc_ext.10.5 -lgcc
-lSystem

(incidentally, the presence of the unfiltered -lm in that spec means an
effective additional -lSystem)

and with -mmacosx-version-min=10.5:
 -lgfortran -lgcc_s.10.5 -lgcc_ext.10.5 -lgcc -lquadmath -lm -lgcc_s.10.5
-lgcc_ext.10.5 -lgcc -lSystem 

for java 

-lSystem -lgcc_ext.10.5 -lgcc -lgcj /usr/lib/libiconv.dylib -lz
-allow_stack_execute -lgcc_ext.10.5 -lgcc -lSystem 

and with -mmacosx-version-min=10.5:
-lgcc_s.10.5 -lgcc_ext.10.5 -lgcc -lgcj /usr/lib/libiconv.dylib -lz
-allow_stack_execute -lgcc_s.10.5 -lgcc_ext.10.5 -lgcc -lSystem



- I can't test the xplor package tho' so Jack might wish to do so.

*** Note that, during looking at this, I discovered that libjava/libltdl has an
acinclude.m4 that uses several obsolete macros, including one that inserts
-flat_namespace in the sequence for undefined symbol handling - on at least
Darwin 9 and 10.  Needs addressing as a separate problem, of course.   A
temporary workaround for that is to set MACOSX_DEPLOYMENT_TARGET before
building java. ***



IMO, we still need to fix things such that (a) we don't need to link against
libgcc.a when doing shared linking (b) we change the name of our export lib
(e.g. to libgcc_ext.1.dylib) and only export the symbols we need. 


Index: gcc/config/darwin10.h
===
--- gcc/config/darwin10.h(revision 169811)
+++ gcc/config/darwin10.h(working copy)
@@ -1,5 +1,5 @@
 /* Target definitions for Darwin (Mac OS X) systems.
-   Copyright (C) 2009, 2010 Free Software Foundation, Inc.
+   Copyright (C) 2009, 2010, 2011 Free Software Foundation, Inc.
Contributed by Jack Howarth .

 This file is part of GCC.
@@ -18,8 +18,16 @@ You should have received a copy of the GNU General
 along with GCC; see the file COPYING3.  If not see
 .  */

+#undef LIB_SPEC
+#define LIB_SPEC "%{!static: -lSystem }"
+
 /* Fix PR41260 by passing -no_compact_unwind on darwin10 and later until
-unwinder in libSystem is fixed to digest new epilog unwinding notes. */
+   unwinder in libSystem is fixed to digest new epilog unwinding notes. */

-#undef LIB_SPEC
-#define LIB_SPEC "%{!static:-no_compact_unwind -lSystem}"
+/* FIXME: Work around PR47558 by linking against libSystem ahead of 
+   libgcc_ext. */
+#undef  LINK_GCC_C_SEQUENCE_SPEC
+#define LINK_GCC_C_SEQUENCE_SPEC \
+"%:version-compare(>= 10.6 mmacosx-version-min= -no_compact_unwind) \
+   %{!static:%{!static-libgcc: \
+  %:version-compare(>= 10.6 mmacosx-version-min= -lSystem) } } %G %L"

[Bug rtl-optimization/42631] [4.5 Regression] "-fcompare-debug failure" with "-O1 -funroll-loops"

[jiez at gcc dot gnu.org]

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

--- Comment #15 from Jie Zhang  2011-02-05 12:06:21 
UTC ---
Author: jiez
Date: Sat Feb  5 12:06:18 2011
New Revision: 169851

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=169851
Log:
PR debug/42631
* web.c (entry_register): Don't clobber the number of the
first uninitialized reference in used[].

testsuite/
PR debug/42631
* gcc.dg/pr42631.c: Update test.
* gcc.dg/pr42631-2.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr42631-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/pr42631.c
trunk/gcc/web.c

[Bug fortran/47574] internal compiler error: in build2_stat, at tree.c:3795

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||tkoenig at gcc dot gnu.org
 Resolution||FIXED

--- Comment #15 from Thomas Koenig  2011-02-05 
10:39:07 UTC ---
Test case committed to trunk, closing.

[Bug fortran/47574] internal compiler error: in build2_stat, at tree.c:3795

[tkoenig at gcc dot gnu.org]

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

--- Comment #14 from Thomas Koenig  2011-02-05 
10:35:28 UTC ---
Author: tkoenig
Date: Sat Feb  5 10:35:24 2011
New Revision: 169850

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=169850
Log:
2001-02-05  Thomas Koenig  

PR fortran/47574
* gfortran.dg/pr47574.f90:  New test.


Added:
trunk/gcc/testsuite/gfortran.dg/pr47574.f90
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug fortran/47613] [4.6 Regression] namelist read with -static

[janus at gcc dot gnu.org]

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

--- Comment #2 from janus at gcc dot gnu.org 2011-02-05 10:32:44 UTC ---
(In reply to comment #1)
> So, this is target specific.  What target are 
> you using?

x86_64-unknown-linux-gnu


> I'll also note that in ios = -1 and 5010 are
> 
>   LIBERROR_END = -1,/* End of file, must be negative.  */
>   LIBERROR_READ_VALUE,
> 
> which are both possible errors for reading from an
> unconnected number.

Well, I won't argue about the specific value that IOSTAT returns, since the
standard specifies that this is processor-dependent. (Therefore also gfortran
could take the freedom to change these values.)

The problem for me really is the change of sign of this value when adding the
-static flag (or moving from 4.5 to 4.6). The F08 standard says explicitly that
IOSTAT_END and IOSTAT_EOR are negative, while all other error values are
positive.

And -static should not really make a difference in terms of the returned error
value.

[Bug fortran/47616] New: ICE with allocate(a,source=(/1/))

[tkoenig at gcc dot gnu.org]

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

   Summary: ICE with allocate(a,source=(/1/))
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: tkoe...@gcc.gnu.org


The following is an ice-on-valid (I think):

ig25@linux-fd1f:~/Krempel/Arr> cat arr-2.f90

program main
  implicit none
  integer, dimension(:), allocatable :: a
  allocate (a, source=(/ 1 /))
end program main
ig25@linux-fd1f:~/Krempel/Arr> gfortran arr-2.f90
f951: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Backtrace:

Program received signal SIGSEGV, Segmentation fault.
__gmpz_set (w=0x7fffd9a0, u=0x78) at set.c:42
42usize = u->_mp_size;
(gdb) bt
#0  __gmpz_set (w=0x7fffd9a0, u=0x78) at set.c:42
#1  0x00519b01 in conformable_arrays (e2=0x14151c0, e1=0x14508e0)
at ../../trunk/gcc/fortran/resolve.c:6588
#2  resolve_allocate_expr (e2=0x14151c0, e1=0x14508e0) at
../../trunk/gcc/fortran/resolve.c:6738
#3  resolve_allocate_deallocate (e2=0x14151c0, e1=0x14508e0) at
../../trunk/gcc/fortran/resolve.c:7094