Wrong-code bug in execute_update_addresses_taken?
Hello,
the following program seems to be miscompiled at -O or higher:
int
main (void)
{
int data = 1;
struct ptr
{
int val;
} *ptr = (struct ptr *) data;
ptr-val = 0;
return data;
}
This program should return 0, but actually returns 1.
[ As far as I can tell, this program does not violate the aliasing
rules; all memory accesses refer to an object of effective (because
declared) type int, and use lvalue references of type int.
The pointer cast might depend on implementation-defined behaviour,
but is not undefined. In any case, there are no warnings, and use
of -fno-strict-aliasing does not fix the problem. ]
In 024t.forwprop1, we still have (correctly):
# .MEMD.3455_4 = VDEF .MEMD.3455_3(D)
dataD.1975 = 1;
# .MEMD.3455_5 = VDEF .MEMD.3455_4
MEM[(struct ptr *)dataD.1975].valD.1977 = 0;
# VUSE .MEMD.3455_5
D.3453_2 = dataD.1975;
return D.3453_2;
but then in 025t.ealias, we get:
dataD.1975_4 = 1;
# .MEMD.3455_5 = VDEF .MEMD.3455_3(D)
MEM[(struct ptr *)dataD.1975].valD.1977 = 0;
D.3453_2 = dataD.1975_4;
return D.3453_2;
This is apparently caused by the addresses taken pass,
which results in those messages:
No longer having address taken: data
Registering new PHI nodes in block #0
Registering new PHI nodes in block #2
Updating SSA information for statement data = 1;
Updating SSA information for statement D.3453_2 = data;
It seems that for some reason, the pass claims to be able to
eliminate all statements that take the address of data,
but then leaves the MEM reference unchanged ...
Any suggestions on what might cause this problem?
Thanks,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
ulrich.weig...@de.ibm.com
Re: Wrong-code bug in execute_update_addresses_taken?
On Sat, Feb 5, 2011 at 7:55 AM, Ulrich Weigand uweig...@de.ibm.com wrote:
Hello,
the following program seems to be miscompiled at -O or higher:
int
main (void)
{
int data = 1;
struct ptr
{
int val;
} *ptr = (struct ptr *) data;
ptr-val = 0;
return data;
}
This program should return 0, but actually returns 1.
[ As far as I can tell, this program does not violate the aliasing
rules; all memory accesses refer to an object of effective (because
declared) type int, and use lvalue references of type int.
The pointer cast might depend on implementation-defined behaviour,
but is not undefined. In any case, there are no warnings, and use
of -fno-strict-aliasing does not fix the problem. ]
In 024t.forwprop1, we still have (correctly):
# .MEMD.3455_4 = VDEF .MEMD.3455_3(D)
dataD.1975 = 1;
# .MEMD.3455_5 = VDEF .MEMD.3455_4
MEM[(struct ptr *)dataD.1975].valD.1977 = 0;
# VUSE .MEMD.3455_5
D.3453_2 = dataD.1975;
return D.3453_2;
but then in 025t.ealias, we get:
dataD.1975_4 = 1;
# .MEMD.3455_5 = VDEF .MEMD.3455_3(D)
MEM[(struct ptr *)dataD.1975].valD.1977 = 0;
D.3453_2 = dataD.1975_4;
return D.3453_2;
This is apparently caused by the addresses taken pass,
which results in those messages:
No longer having address taken: data
Registering new PHI nodes in block #0
Registering new PHI nodes in block #2
Updating SSA information for statement data = 1;
Updating SSA information for statement D.3453_2 = data;
It seems that for some reason, the pass claims to be able to
eliminate all statements that take the address of data,
but then leaves the MEM reference unchanged ...
Any suggestions on what might cause this problem?
This behavior change of -fno-strict-aliasing is caused by
http://gcc.gnu.org/ml/gcc-patches/2010-10/msg00788.html
--
H.J.
New libquadmath maintainers: Jakub and Tobias
Jakub, Tobias -- The GCC SC has appointed you as maintainers of libquadmath within GCC. Please update the MAINTAINERS file to reflect your new positions. Congratulations! -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
gcc-4.6-20110205 is now available
Snapshot gcc-4.6-20110205 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.6-20110205/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.6 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 169855 You'll find: gcc-4.6-20110205.tar.bz2 Complete GCC (includes all of below) MD5=640f0f3248522735f7b361df52c95a14 SHA1=f318596cea001e189990eeb5ac0fa5d606c0ed2b gcc-core-4.6-20110205.tar.bz2C front end and core compiler MD5=98109df1e4ac9a800484cee801dc3078 SHA1=b66e799bc00338e4ab7dd4d1a59abc44a5f12b15 gcc-ada-4.6-20110205.tar.bz2 Ada front end and runtime MD5=98580ae23b42b48e0f321e1754dbae3c SHA1=3b94e640e5534f1ce85d8f8e8c8144405332de4f gcc-fortran-4.6-20110205.tar.bz2 Fortran front end and runtime MD5=8a86ad6d9ea9670a1613c8c69f54cbd7 SHA1=92a39c6f3fd3c0d8bff7847a41d0499da248e931 gcc-g++-4.6-20110205.tar.bz2 C++ front end and runtime MD5=58f2c791707d005ab991e5aae36d87cc SHA1=3af28e211d12b25c845f1d721e5c7004eed50bc7 gcc-go-4.6-20110205.tar.bz2 Go front end and runtime MD5=b3f18427c5a885a7b0f171b516092f92 SHA1=09becf579072e27a160972790efce6547d223aa8 gcc-java-4.6-20110205.tar.bz2Java front end and runtime MD5=966b1088f2ad7f2c03ee2bc0ba53f08f SHA1=a587bb71b88da675107c200f0514d030540f715e gcc-objc-4.6-20110205.tar.bz2Objective-C front end and runtime MD5=f2b156a7951b786ecbca649c504c7c02 SHA1=7037424d5fd5fa98d9438431c906f7a98f42e182 gcc-testsuite-4.6-20110205.tar.bz2 The GCC testsuite MD5=48996e1dd9f69d73a55da96f9e7041d3 SHA1=94abe42f961bd71705c74c173e3f54480e4fd107 Diffs from 4.6-20110129 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.6 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
[Bug fortran/47616] New: ICE with allocate(a,source=(/1/))
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 http://gcc.gnu.org/bugs.html 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
[Bug fortran/47613] [4.6 Regression] namelist read with -static
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/47574] internal compiler error: in build2_stat, at tree.c:3795
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47574 --- Comment #14 from Thomas Koenig tkoenig at gcc dot gnu.org 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=gccview=revrev=169850 Log: 2001-02-05 Thomas Koenig tkoe...@gcc.gnu.org PR fortran/47574 * gfortran.dg/pr47574.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/pr47574.f90 Modified: trunk/gcc/testsuite/ChangeLog
[Bug fortran/47574] internal compiler error: in build2_stat, at tree.c:3795
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47574 Thomas Koenig tkoenig at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||tkoenig at gcc dot gnu.org Resolution||FIXED --- Comment #15 from Thomas Koenig tkoenig at gcc dot gnu.org 2011-02-05 10:39:07 UTC --- Test case committed to trunk, closing.
[Bug rtl-optimization/42631] [4.5 Regression] -fcompare-debug failure with -O1 -funroll-loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42631 --- Comment #15 from Jie Zhang jiez at gcc dot gnu.org 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=gccview=revrev=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 target/47558] 163267 breaks exception traceback in xplor-nih
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558
--- Comment #58 from Iain Sandoe iains at gcc dot gnu.org 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 howa...@bromo.med.uc.edu.
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
http://www.gnu.org/licenses/. */
+#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 fortran/47613] [4.6 Regression] namelist read with -static
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47613 Jerry DeLisle jvdelisle at gcc dot gnu.org changed: What|Removed |Added CC||jvdelisle at gcc dot ||gnu.org --- Comment #3 from Jerry DeLisle jvdelisle at gcc dot gnu.org 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 libfortran/47567] Wrong output for small absolute values with F editing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47567 --- Comment #9 from Jerry DeLisle jvdelisle at gcc dot gnu.org 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 lto/47528] liblto_plugin.so not found should not to be an fatal error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47528 Kai Tietz ktietz at gcc dot gnu.org 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 ktietz at gcc dot gnu.org 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 fortran/47613] [4.6 Regression] namelist read with -static
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47613 --- Comment #4 from H.J. Lu hjl.tools at gmail dot com 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 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47615 H.J. Lu hjl.tools at gmail dot com 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 hjl.tools at gmail dot com 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47613 --- Comment #5 from H.J. Lu hjl.tools at gmail dot com 2011-02-05 15:11:04 UTC --- Revision 169847 also works for me on Fedora 14.
[Bug tree-optimization/46188] [4.5 regression] -fipa-cp removes destructor call
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46188 Mikael Pettersson mikpe at it dot uu.se changed: What|Removed |Added CC||hubicka at gcc dot gnu.org, ||mikpe at it dot uu.se --- Comment #10 from Mikael Pettersson mikpe at it dot uu.se 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=gccview=revrev=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 middle-end/47610] [4.6 Regression] cp-demangle.c:1970:1: error: cplus_demangle_builtin_types causes a section type conflict
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47610
--- Comment #6 from John David Anglin danglin at gcc dot gnu.org 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 target/46779] wrong code generation for array access
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46779 Georg Lay avr at gjlay dot de changed: What|Removed |Added CC||avr at gjlay dot de --- Comment #5 from Georg Lay avr at gjlay dot de 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 fortran/47571] [4.6 Regression] undefined reference to clock_gettime in Linux build of 02/01/2011
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571 --- Comment #22 from Janne Blomqvist jb at gcc dot gnu.org 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=gccview=revrev=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 middle-end/47610] [4.6 Regression] cp-demangle.c:1970:1: error: cplus_demangle_builtin_types causes a section type conflict
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47610 --- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org 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/47613] [4.6 Regression] namelist read with -static
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
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/47616] ICE with allocate(a,source=(/1/))
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47616 --- Comment #1 from Thomas Koenig tkoenig at gcc dot gnu.org 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 http://gcc.gnu.org/bugs.html 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 fortran/47613] [4.6 Regression] namelist read with -static
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47613 --- Comment #7 from H.J. Lu hjl.tools at gmail dot com 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/47613] [4.6 Regression] namelist read with -static
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47613 --- Comment #8 from Jerry DeLisle jvdelisle at gcc dot gnu.org 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 libfortran/47567] Wrong output for small absolute values with F editing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47567 --- Comment #10 from Jerry DeLisle jvdelisle at gcc dot gnu.org 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=gccview=revrev=169853 Log: 2011-02-05 Jerry DeLisle jvdeli...@gcc.gnu.org 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
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 fortran/47613] [4.6 Regression] namelist read with -static
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47613
--- Comment #10 from Steve Kargl sgk at troutmask dot apl.washington.edu
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47613
--- Comment #11 from H.J. Lu hjl.tools at gmail dot com 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 target/47558] 163267 breaks exception traceback in xplor-nih
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558 --- Comment #59 from Jack Howarth howarth at nitro dot med.uc.edu 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 rdar://problem/7457013, ___divdc3 slightly wrong, fixed in Lion.
[Bug target/47558] 163267 breaks exception traceback in xplor-nih
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558 --- Comment #60 from Iain Sandoe iains at gcc dot gnu.org 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 rdar://problem/7457013, ___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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558 --- Comment #61 from Jack Howarth howarth at nitro dot med.uc.edu 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558 --- Comment #62 from Dominique d'Humieres dominiq at lps dot ens.fr 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 fortran/42434] Documentation should provide advice about clock resolutions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42434 Janne Blomqvist jb at gcc dot gnu.org 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 jb at gcc dot gnu.org 2011-02-05 20:06:48 UTC --- Patch: http://gcc.gnu.org/ml/gcc-patches/2011-02/msg00331.html
[Bug fortran/42434] Documentation should provide advice about clock resolutions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42434 --- Comment #2 from Janne Blomqvist jb at gcc dot gnu.org 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=gccview=revrev=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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42434 Janne Blomqvist jb at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #3 from Janne Blomqvist jb at gcc dot gnu.org 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 middle-end/47610] [4.6 Regression] cp-demangle.c:1970:1: error: cplus_demangle_builtin_types causes a section type conflict
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47610 --- Comment #9 from Jakub Jelinek jakub at gcc dot gnu.org 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=gccview=revrev=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 rtl-optimization/47612] RTL crash when cc0 setter moved away from cc0 user
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47612 Mikael Pettersson mikpe at it dot uu.se changed: What|Removed |Added CC||bernds at gcc dot gnu.org, ||mikpe at it dot uu.se --- Comment #4 from Mikael Pettersson mikpe at it dot uu.se 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=gccview=revrev=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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47610 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #10 from Jakub Jelinek jakub at gcc dot gnu.org 2011-02-05 21:04:54 UTC --- Fixed.
[Bug other/42333] complex division failure on darwin10 with -lm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42333 --- Comment #51 from Jack Howarth howarth at nitro dot med.uc.edu 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 other/42333] complex division failure on darwin10 with -lm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42333 --- Comment #52 from Jack Howarth howarth at nitro dot med.uc.edu 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 fortran/47613] [4.6 Regression] namelist read with -static
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 c/47617] New: SSE rounding mode works -g, not -O3
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 other/42333] complex division failure on darwin10 with -lm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42333 m...@gcc.gnu.org mrs at gcc dot 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 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 lto/45375] [meta-bug] Issues with building Mozilla with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375 --- Comment #38 from Jan Hubicka hubicka at gcc dot gnu.org 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 gcov-profile/47618] New: Collecting multiple profiles and using all for PGO
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 target/47269] DSYMUTIL_SPEC doesn't handle -gtoggle
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47269
--- Comment #2 from Mike Stump mikestump at comcast dot net 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 target/47269] DSYMUTIL_SPEC doesn't handle -gtoggle
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47269
--- Comment #3 from Mike Stump mikestump at comcast dot net 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 c/47617] SSE rounding mode works -g, not -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47617 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47269
--- Comment #4 from Jack Howarth howarth at nitro dot med.uc.edu 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 preprocessor/47047] Support for path translation in __FILE__
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47047 --- Comment #4 from Joerg Sonnenberger joerg at netbsd dot org 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 bootstrap/43073] libiberty fails to build when using gcc-core
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43073 Luke A. Guest laguest at archeia dot com changed: What|Removed |Added CC||laguest at archeia dot com --- Comment #6 from Luke A. Guest laguest at archeia dot com 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.
