[Bug target/46080] New: incorrect precision of sqrtf builtin for x87 arithmetic (-mfpmath=387)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46080
Summary: incorrect precision of sqrtf builtin for x87
arithmetic (-mfpmath=387)
Product: gcc
Version: 4.4.5
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: vinc...@vinc17.org
With -mfpmath=387 (tested on a x86_64 platform), the first sqrtf is computed in
double precision instead of single. On
#include stdio.h
#include math.h
float x = (float) M_PI;
int main(void)
{
printf (%.60f\n, sqrtf(x));
printf (%.60f\n, sqrtf(x));
printf (%.60f\n, sqrtf(x));
return 0;
}
I get with various gcc versions (including gcc version 4.6.0 20101009
(experimental) [trunk revision 165234] (Debian 20101009-1)):
$ gcc -Wall -mfpmath=387 bug.c -o bug -lm -O0; ./bug
1.7724538755670267153874419818748719990253448486328125
1.772453904151916503906250
1.772453904151916503906250
The bug is also present with -O1 when the sqrtf calls are grouped in a single
printf and disappears if the builtin is disabled with -fno-builtin-sqrtf.
For the first sqrtf, the asm code shows a fsqrt followed by a call sqrtf
under some condition, but the condition is not satisfied. The other occurrences
just have a call sqrtf, which is correct.
log10(6.2442) returning nan0x8000 — some kind of good old fp stack alignment problem?
Hello, After being pointed to a thread about unexpected NaNs (http://gcc.gnu.org/ml/gcc-bugs/1999-10/msg00410.html), I decided to try here to see if the ghost I have in my code rings a bell with anyone... In short, I have a trigger series of events that I can set off in my code (an X11 data manipulation app) that will cause the log10() function to return a NaN for a perfectly valid input. This happens once per trigger event: preceding and subsequent calls to log10() will return the expected result for the same (exactly the same!) input value. The NaN is returned also when I call log10() (or log()) from gdb, after the trigger event. Some additional details: this happens on Mac OS X 10.6.4 running on a mid 2010 MPB with a 2.4Ghz Core2, compiling with gcc-4.0 or llvm-gcc-4.2.1 (but apparently not with the regular gcc-4.2.1), and also on a Pentium-M laptop running WinXP and Cygwin. The trigger event involves a function with variable arguments. More details and the results of some ongoing investigations on Ars Technica: http://arstechnica.com/civis/viewtopic.php?p=20913595#p20913595 I've found the way to avoid this from happening (and to deal with it when it happens at the spot where it happens at the moment), but I'd prefer to understand the issue. For now, I have the impression I just chased a ghost to a different hiding place... thanks in advance, René Bertin
[Bug tree-optimization/46081] New: [4.6 Regression] FAIL: gcc.dg/ipa/ipa-pta-10.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46081
Summary: [4.6 Regression] FAIL: gcc.dg/ipa/ipa-pta-10.c
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hjl.to...@gmail.com
CC: rgue...@gcc.gnu.org
On Linux/x86-64, revision 165643 gave
FAIL: gcc.dg/ipa/ipa-pta-10.c scan-ipa-dump pta ESCAPED = { ESCAPED NONLOCAL
}
Revision 165636 is OK. It may be caused by revision 165641:
http://gcc.gnu.org/ml/gcc-cvs/2010-10/msg00826.html
[Bug target/46080] [4.4/4.5/4.6 Regression] incorrect precision of sqrtf builtin for x87 arithmetic (-mfpmath=387)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46080 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target||i?86-*-* Status|UNCONFIRMED |NEW Known to work||4.3.4 Keywords||wrong-code Last reconfirmed||2010.10.19 10:49:12 Ever Confirmed|0 |1 Summary|incorrect precision of |[4.4/4.5/4.6 Regression] |sqrtf builtin for x87 |incorrect precision of |arithmetic (-mfpmath=387) |sqrtf builtin for x87 ||arithmetic (-mfpmath=387) Target Milestone|--- |4.4.6 Known to fail||4.4.3, 4.5.1, 4.6.0 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2010-10-19 10:49:12 UTC --- Confirmed.
[Bug c++/46078] [4.6 regression] new valgrind warnings when compiling an optimization test case
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46078 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.6.0
[Bug tree-optimization/46077] [4.6 regression] ICE in tree vectorization when compiling towns_audio.cpp from scummvm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46077 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.6.0
[Bug tree-optimization/46081] [4.6 Regression] FAIL: gcc.dg/ipa/ipa-pta-10.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46081
--- Comment #1 from H.J. Lu hjl.tools at gmail dot com 2010-10-19 10:50:54
UTC ---
Executing on host: /export/gnu/import/svn/gcc-test/bld/gcc/xgcc
-B/export/gnu/import/svn/gcc-test/bld/gcc/
/export/gnu/import/svn/gcc-test/src-trunk/gcc/testsuite/gcc.dg/ipa/ipa-pta-10.c
-O2 -fipa-pta -fdump-ipa-pta-details -lm -m32 -o ./ipa-pta-10.exe
(timeout = 300)
PASS: gcc.dg/ipa/ipa-pta-10.c (test for excess errors)
Setting LD_LIBRARY_PATH to
:/export/gnu/import/svn/gcc-test/bld/gcc:/export/gnu/import/svn/gcc-test/bld/gcc/32::/export/gnu/import/svn/gcc-test/bld/gcc:/export/gnu/import/svn/gcc-test/bld/gcc/32:/export/gnu/import/svn/gcc-test/bld/x86_64-unknown-linux-gnu/libstdc++-v3/.libs:/export/gnu/import/svn/gcc-test/bld/x86_64-unknown-linux-gnu/libmudflap/.libs:/export/gnu/import/svn/gcc-test/bld/x86_64-unknown-linux-gnu/libssp/.libs:/export/gnu/import/svn/gcc-test/bld/x86_64-unknown-linux-gnu/libgomp/.libs:/export/gnu/import/svn/gcc-test/bld/./gcc:/export/gnu/import/svn/gcc-test/bld/./prev-gcc
PASS: gcc.dg/ipa/ipa-pta-10.c execution test
FAIL: gcc.dg/ipa/ipa-pta-10.c scan-ipa-dump pta ESCAPED = { ESCAPED NONLOCAL
}
[Bug middle-end/46076] [4.6 regression] constant propagation and compile-time math no longer happening versus 4.4 and 4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46076 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.6.0
[Bug fortran/42169] [4.4/4.5/4.6 Regression] gfortran.dg/pr41928.f90:47: internal compiler error: in store_can_be_removed_p, at ira-emit.c:371
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42169 --- Comment #21 from Richard Guenther rguenth at gcc dot gnu.org 2010-10-19 10:55:08 UTC --- (In reply to comment #20) Not really, there are about 300 lines of new code (mostly in a new routine). It might be that only the change in can_reassociate_p is needed to fix this bug. That would be a pretty easy backport and I verified that it fixes the testcase, I haven't done a complete run with the change though. Just backporting that change will cause quite some regressions. Note that I think it can't be a real fix for the ICE - it'll only paper over it.
[Bug tree-optimization/46081] [4.6 Regression] FAIL: gcc.dg/ipa/ipa-pta-10.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46081 --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2010-10-19 11:06:33 UTC --- Author: rguenth Date: Tue Oct 19 11:06:29 2010 New Revision: 165697 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=165697 Log: 2010-10-19 Richard Guenther rguent...@suse.de PR testsuite/46081 * gcc.dg/ipa/ipa-pta-10.c: Adjust. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/ipa/ipa-pta-10.c
[Bug tree-optimization/46081] [4.6 Regression] FAIL: gcc.dg/ipa/ipa-pta-10.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46081 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.6.0 --- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2010-10-19 11:06:53 UTC --- Fixed.
[Bug fortran/46079] [4.6 Regression] ABI for empty stop statement broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46079 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org Target Milestone|--- |4.6.0 Summary|ABI for empty stop |[4.6 Regression] ABI for |statement broken|empty stop statement broken
[Bug tree-optimization/46077] [4.6 regression] ICE in tree vectorization when compiling towns_audio.cpp from scummvm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46077 Ira Rosen irar at il dot ibm.com changed: What|Removed |Added CC||irar at il dot ibm.com --- Comment #1 from Ira Rosen irar at il dot ibm.com 2010-10-19 11:54:34 UTC --- Maybe related to PR 45971?
[Bug fortran/43414] DWARF4: Use DW_AT_main_subprogram for MAIN__
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43414 --- Comment #3 from Francois-Xavier Coudert fxcoudert at gcc dot gnu.org 2010-10-19 12:30:43 UTC --- Author: fxcoudert Date: Tue Oct 19 12:30:35 2010 New Revision: 165699 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=165699 Log: PR fortran/43414 * dwarf2out.c (add_calling_convention_attribute): Flag main Fortran subroutine with DW_AT_main_subprogram. Modified: trunk/gcc/ChangeLog trunk/gcc/dwarf2out.c
[Bug fortran/43414] DWARF4: Use DW_AT_main_subprogram for MAIN__
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43414 Francois-Xavier Coudert fxcoudert at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.6.0 --- Comment #4 from Francois-Xavier Coudert fxcoudert at gcc dot gnu.org 2010-10-19 12:32:06 UTC --- Fixed on trunk.
[Bug c++/46024] g++.dg/warn/miss-format-1.C FAILs on Solaris 8 and 9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46024 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED URL||http://gcc.gnu.org/ml/gcc-p ||atches/2010-10/msg01626.htm ||l Last reconfirmed||2010.10.19 12:54:39 Ever Confirmed|0 |1 --- Comment #1 from Rainer Orth ro at gcc dot gnu.org 2010-10-19 12:54:39 UTC --- Mine.
[Bug fortran/46079] [4.6 Regression] ABI for empty stop statement broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46079 Jerry DeLisle jvdelisle at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2010.10.19 13:06:42 AssignedTo|unassigned at gcc dot |jvdelisle at gcc dot |gnu.org |gnu.org Ever Confirmed|0 |1
[Bug rtl-optimization/37360] [4.4 Regression] ICE in haifa-sched.c when compiling __popcountsi2 from libgcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37360 Jie Zhang jiez at gcc dot gnu.org changed: What|Removed |Added CC||jiez at gcc dot gnu.org --- Comment #20 from Jie Zhang jiez at gcc dot gnu.org 2010-10-19 14:03:07 UTC --- Just for record, ./cc1 -march=sb1 -O3 j.i -fPIC can reproduce this issue on latest trunk if r140151 is reversed.
[Bug libgcj/46082] New: libgcj fails to build in current 4.5 branch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46082 Summary: libgcj fails to build in current 4.5 branch Product: gcc Version: 4.5.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcj AssignedTo: unassig...@gcc.gnu.org ReportedBy: b...@arklinux.org Building current 4.5 branch aborts when it hits check_jni_methods.sh: /bin/sh ../../scripts/check_jni_methods.sh Found a problem with the JNI methods declared and implemented. () missing in implementation, () missing in header files Java_gnu_java_awt_dnd_peer_gtk_GtkDragSourceContextPeer_create Java_gnu_java_awt_peer_gtk_CairoGraphics2D_cairoResetClip Java_gnu_java_awt_peer_gtk_CairoSurface_copyAreaNative2 Java_gnu_java_awt_peer_gtk_GdkGraphicsEnvironment_getMouseCoordinates Java_gnu_java_awt_peer_gtk_GdkPixbufDecoder_initState Java_gnu_java_awt_peer_gtk_GtkCheckboxPeer_gtkButtonSetLabel Java_gnu_java_awt_peer_gtk_GtkChoicePeer_nativeRemoveAll Java_gnu_java_awt_peer_gtk_GtkComponentPeer_gtkWidgetDispatchKeyEvent Java_gnu_java_awt_peer_gtk_GtkComponentPeer_gtkWidgetGetLocationOnScreen Java_gnu_java_awt_peer_gtk_GtkComponentPeer_gtkWidgetGetLocationOnScreenUnlocked Java_gnu_java_awt_peer_gtk_GtkComponentPeer_gtkWidgetRequestFocus Java_gnu_java_awt_peer_gtk_GtkComponentPeer_gtkWidgetSetBackground Java_gnu_java_awt_peer_gtk_GtkComponentPeer_gtkWidgetSetForeground Java_gnu_java_awt_peer_gtk_GtkFramePeer_gtkFixedSetVisible Java_gnu_java_awt_peer_gtk_GtkLabelPeer_create Java_gnu_java_awt_peer_gtk_GtkListPeer_add Java_gnu_java_awt_peer_gtk_GtkTextAreaPeer_create Java_gnu_java_awt_peer_gtk_GtkTextFieldPeer_getText Java_gnu_java_awt_peer_gtk_GtkToolkit_getScreenResolution Java_gnu_java_awt_peer_gtk_GtkToolkit_gtkInit Java_gnu_java_awt_peer_gtk_GtkWindowPeer_nativeSetLocation Java_gnu_java_awt_peer_qt_QtComponentPeer_getSizeNative Java_gnu_java_awt_peer_qt_QtImage_clear Java_gnu_java_awt_peer_qt_QtImage_drawPixelsScaled Java_gnu_java_awt_peer_qt_QtMenuPeer_delItem Java_gnu_java_awt_peer_qt_QtTextAreaPeer_setCaretPosition Java_gnu_java_math_GMP_natAndNot Java_gnu_java_math_GMP_natGCD Java_gnu_java_net_local_LocalSocketImpl_close Java_gnu_java_net_VMPlainSocketImpl_bind6 Java_gnu_java_nio_VMPipe_pipe0 Java_gnu_java_util_prefs_gconf_GConfNativePeer_gconf_1escape_1key Java_gnu_javax_sound_midi_dssi_DSSIMidiDeviceProvider_getDSSICopyright_1 Java_gnu_javax_sound_sampled_gstreamer_io_GstAudioFileReaderNativePeer_gstreamer_1get_1audio_1format_1file Java_gnu_javax_sound_sampled_gstreamer_io_GstAudioFileReaderNativePeer_init_1id_1cache Java_gnu_javax_sound_sampled_gstreamer_lines_GstPipeline_available Java_gnu_javax_sound_sampled_gstreamer_lines_GstPipeline_detect_1pipe_1size Java_gnu_xml_libxmlj_dom_GnomeDocument_getElementsByTagNameNS Java_gnu_xml_libxmlj_dom_GnomeNamedNodeMap_getLength Java_gnu_xml_libxmlj_dom_GnomeNode_getFirstChild Java_gnu_xml_libxmlj_dom_GnomeNode_hasChildNodes Java_gnu_xml_libxmlj_dom_GnomeNodeList_getLength Java_gnu_xml_libxmlj_transform_GnomeTransformer_transformDocToDoc Java_java_io_VMFile_delete Java_java_lang_VMFloat_floatToRawIntBits Java_java_nio_VMDirectByteBuffer_shiftDown make[6]: *** [all-local] Error 1
[Bug middle-end/45962] [4.6 Regression]: many c/c++ failures on cris-elf, in r165236:165242
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45962 Richard Henderson rth at gcc dot gnu.org changed: What|Removed |Added Status|REOPENED|NEW --- Comment #16 from Richard Henderson rth at gcc dot gnu.org 2010-10-19 15:49:02 UTC --- (In reply to comment #15) ... though the vector alignment is neither explicit nor mandatory. It's implicit in the DImode mode of the type. If you'd like to reduce the alignment of local variables, use the MINIMUM_ALIGNMENT macro; see the i386 port for an example. No such dynamic allocation at r165239. Yes, that's the whole point of the patch, to honor alignment as given. When doing so, it feels it needs to save the stack-pointer. That's redundant; it's already saved when a frame-pointer is needed. The cris port fails to define EXIT_IGNORE_STACK to indicate this. Without that, the middle-end thinks it must save/restore sp around the function. Frankly, there's nothing otherwise unusual about this new alloca from any other. I guess you've just never noticed this extra save previously? It so emits move.d $sp,[$r8-8] ... Where it gets the -8 from, I don't know, I'll look further. I assume that's a stack slot for a spilled pseudo?
[Bug bootstrap/44970] [4.6 regression] Revision 162270 failed to bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44970 --- Comment #87 from Steve Ellcey sje at cup dot hp.com 2010-10-19 16:09:57 UTC --- My testing on 32 bit and 64 bit PA boxes went fine. The patch looks good to me.
[Bug lto/46083] New: gcc.dg/initpri1.c FAILs with -flto/-fwhopr (attribute constructor/destructor doesn't work)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46083 Summary: gcc.dg/initpri1.c FAILs with -flto/-fwhopr (attribute constructor/destructor doesn't work) Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassig...@gcc.gnu.org ReportedBy: zso...@seznam.cz Output: $ gcc gcc.dg/initpri1.c ./a.out $ gcc gcc.dg/initpri1.c -flto ./a.out Aborted $ gcc gcc.dg/initpri1.c -fwhopr ./a.out Aborted With another testcase, -flto worked fine, but -fwhopr failed. Constructors and destructors are executed, but not in expected order. Tested revisions: r165699 - fail
[Bug rtl-optimization/37360] [4.4 Regression] ICE in haifa-sched.c when compiling __popcountsi2 from libgcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37360 --- Comment #21 from Jie Zhang jiez at gcc dot gnu.org 2010-10-19 16:58:58 UTC --- Another way to fix this bug: http://gcc.gnu.org/ml/gcc/2010-10/msg00281.html David, are you still interested to try this patch on sb1?
[Bug rtl-optimization/37360] [4.4 Regression] ICE in haifa-sched.c when compiling __popcountsi2 from libgcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37360 --- Comment #22 from David Daney daney at gcc dot gnu.org 2010-10-19 17:38:32 UTC --- I no longer have access to an SB1. But you should be able to run the test case on a cross compiler to see how it is affected by any patch.
[Bug c++/46056] [C++0x] range-based for loop inside lambda crashes if _GLIBCXX_DEBUG is defined
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46056 --- Comment #2 from Alexander Klimov alserkli at inbox dot ru 2010-10-19 18:22:11 UTC --- Created attachment 22086 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22086 simple testcase
[Bug c++/46056] [C++0x] range-based for loop does not destruct iterators
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46056 Alexander Klimov alserkli at inbox dot ru changed: What|Removed |Added Summary|[C++0x] range-based for |[C++0x] range-based for |loop inside lambda crashes |loop does not destruct |if _GLIBCXX_DEBUG is|iterators |defined | --- Comment #3 from Alexander Klimov alserkli at inbox dot ru 2010-10-19 18:24:27 UTC --- Apparently it has nothing to do with _GLIBCXX_DEBUG or lambda. Turns out range-based for loop does not call destructor for iterator and thus v._M_iterators is not null. See attachment for a direct testcase.
[Bug target/46084] New: gcc.dg/split-4.c failed with -mavx -m32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46084 Summary: gcc.dg/split-4.c failed with -mavx -m32 Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: hjl.to...@gmail.com CC: i...@google.com On Linux/ia32, gcc.dg/split-4.c failed with -mavx -m32: [...@gnu-18 gcc]$ ./xgcc -B./ /export/gnu/import/git/gcc-avx/gcc/testsuite/gcc.dg/split-4.c -fsplit-stack -m32 -mavx [...@gnu-18 gcc]$ ./a.out Segmentation fault [...@gnu-18 gcc]$ You can download AVX emulator from http://software.intel.com/en-us/avx/
[Bug tree-optimization/46085] New: [4..6 Regression] gcc.dg/vect/fast-math-vect-reduc-[57].c failed with -mavx -ffast-math -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46085 Summary: [4..6 Regression] gcc.dg/vect/fast-math-vect-reduc-[57].c failed with -mavx -ffast-math -O3 Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: hjl.to...@gmail.com [...@gnu-18 gcc]$ ./xgcc -B./ /export/gnu/import/git/gcc-avx/gcc/testsuite/gcc.dg/vect/fast-math-vect-reduc-5.c -mavx -ffast-math -o3[...@gnu-18 gcc]$ ./a.out Aborted [...@gnu-18 gcc]$ ./xgcc -B./ /export/gnu/import/git/gcc-avx/gcc/testsuite/gcc.dg/vect/fast-math-vect-reduc-7.c -mavx -ffast-math -O3 [...@gnu-18 gcc]$ ./a.out Aborted [...@gnu-18 gcc]$ They failed due to 256bit vectorizer.
[Bug tree-optimization/46085] [4..6 Regression] gcc.dg/vect/fast-math-vect-reduc-[57].c failed with -mavx -ffast-math -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46085 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added CC||rguenth at gcc dot gnu.org Target Milestone|--- |4.6.0
[Bug tree-optimization/46085] [4..6 Regression] gcc.dg/vect/fast-math-vect-reduc-[57].c failed with -mavx -ffast-math -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46085
--- Comment #1 from H.J. Lu hjl.tools at gmail dot com 2010-10-19 19:48:35
UTC ---
[...@gnu-18 gcc]$ cat x.c
extern void abort ();
float b[16] = {0,3,6,9,12,15,18,21,24,27,30,33,36,39,42,45};
float c[16] = {0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15};
int main ()
{
int i;
float diff = 2;
for (i = 0; i 16; i++) {
diff += (b[i] - c[i]);
}
if (diff != 242)
abort ();
return 0;
}
[...@gnu-18 gcc]$ ./xgcc -B./ x.c -ftree-vectorize -g -mavx -O -ffast-math
[...@gnu-18 gcc]$ ./a.out
Aborted
[...@gnu-18 gcc]$ ./xgcc -B./ x.c -ftree-vectorize -g -mavx -O -ffast-math
-mno-avx -msse4
[...@gnu-18 gcc]$ ./a.out
[...@gnu-18 gcc]$
[Bug plugins/41757] Add PLUGIN_FINISH_DECL
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41757 Diego Novillo dnovillo at gcc dot gnu.org changed: What|Removed |Added CC||dnovillo at gcc dot gnu.org --- Comment #3 from Diego Novillo dnovillo at gcc dot gnu.org 2010-10-19 20:02:45 UTC --- We still have not received copyright assignment paperwork from Brian, so we are not able to accept the patch unfortunately.
[Bug c++/46056] [C++0x] range-based for loop does not destruct iterators
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46056 --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com 2010-10-19 20:35:01 UTC --- Many thanks Alexander.
[Bug c++/46056] [C++0x] range-based for loop does not destruct iterators
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46056 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||rodrigorivascosta at gmail ||dot com --- Comment #5 from Paolo Carlini paolo.carlini at oracle dot com 2010-10-19 20:48:59 UTC --- Let's add Rodrigo in CC.
[Bug c/46086] New: fail to build gcc 4.5.2 on sparc64-portbld-freebsd9.0 - configure: error: cannot compute suffix of object files: cannot compile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46086 Summary: fail to build gcc 4.5.2 on sparc64-portbld-freebsd9.0 - configure: error: cannot compute suffix of object files: cannot compile Product: gcc Version: 4.5.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: me...@bristol.ac.uk Created attachment 22087 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22087 /usr/ports/lang/gcc45/work/build/sparc64-portbld-freebsd9.0/libgcc/config.log running make gives this error: *skip* gmake[3]: Entering directory `/usr/ports/lang/gcc45/work/build/libcpp' gmake[3]: Nothing to be done for `all'. gmake[3]: Leaving directory `/usr/ports/lang/gcc45/work/build/libcpp' gmake[3]: Entering directory `/usr/ports/lang/gcc45/work/build/libdecnumber' gmake[3]: Nothing to be done for `all'. gmake[3]: Leaving directory `/usr/ports/lang/gcc45/work/build/libdecnumber' gmake[3]: Entering directory `/usr/ports/lang/gcc45/work/build/gcc' gmake[3]: Leaving directory `/usr/ports/lang/gcc45/work/build/gcc' Checking multilib configuration for libgcc... Configuring stage 2 in sparc64-portbld-freebsd9.0/libgcc configure: loading cache ./config.cache checking for --enable-version-specific-runtime-libs... no checking for a BSD-compatible install... /usr/bin/install -c -o root -g wheel checking for gawk... nawk checking build system type... sparc64-portbld-freebsd9.0 checking host system type... sparc64-portbld-freebsd9.0 checking for sparc64-portbld-freebsd9.0-ar... /usr/local/sparc64-portbld-freebsd9.0/bin/ar checking for sparc64-portbld-freebsd9.0-lipo... lipo checking for sparc64-portbld-freebsd9.0-nm... /usr/ports/lang/gcc45/work/build/./gcc/nm checking for sparc64-portbld-freebsd9.0-ranlib... /usr/local/sparc64-portbld-freebsd9.0/bin/ranlib checking for sparc64-portbld-freebsd9.0-strip... /usr/local/sparc64-portbld-freebsd9.0/bin/strip checking whether ln -s works... yes checking for sparc64-portbld-freebsd9.0-gcc... /usr/ports/lang/gcc45/work/build/./gcc/xgcc -B/usr/ports/lang/gcc45/work/build/./gcc/ -B/usr/local/sparc64-portbld-freebsd9.0/bin/ -B/usr/local/sparc64-portbld-freebsd9.0/lib/ -isystem /usr/local/sparc64-portbld-freebsd9.0/include -isystem /usr/local/sparc64-portbld-freebsd9.0/sys-include checking for suffix of object files... configure: error: in `/usr/ports/lang/gcc45/work/build/sparc64-portbld-freebsd9.0/libgcc': configure: error: cannot compute suffix of object files: cannot compile See `config.log' for more details. gmake[2]: *** [configure-stage2-target-libgcc] Error 1 gmake[2]: Leaving directory `/usr/ports/lang/gcc45/work/build' gmake[1]: *** [stage2-bubble] Error 2 gmake[1]: Leaving directory `/usr/ports/lang/gcc45/work/build' gmake: *** [bootstrap-lean] Error 2 *** Error code 1 Stop in /usr/ports/lang/gcc45. *** Error code 1 The config.log file is attached. many thanks anton
[Bug c/46086] fail to build gcc 4.5.2 on sparc64-portbld-freebsd9.0 - configure: error: cannot compute suffix of object files: cannot compile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46086 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2010-10-19 21:06:26 UTC --- cc1: internal compiler error: Segmentation fault: 11 Does this happen every time?
[Bug bootstrap/46086] fail to build gcc 4.5.2 on sparc64-portbld-freebsd9.0 - configure: error: cannot compute suffix of object files: cannot compile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46086 --- Comment #2 from Anton Shterenlikht mexas at bristol dot ac.uk 2010-10-19 21:10:00 UTC --- yes I've repeated it maybe 5-10 times over the last several weeks. I don't know if this is a regression. I think lapack dependency in freebsd ports recently moved from gcc44 to gcc45, so probably I haven't tried to build gcc45 until a few weeks ago.
[Bug bootstrap/46086] fail to build gcc 4.5.2 on sparc64-portbld-freebsd9.0 - configure: error: cannot compute suffix of object files: cannot compile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46086 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added CC||ebotcazou at gcc dot ||gnu.org --- Comment #3 from Eric Botcazou ebotcazou at gcc dot gnu.org 2010-10-19 21:20:44 UTC --- See http://gcc.gnu.org/install/specific.html#sparc-x-x
[Bug tree-optimization/43657] [4.3/4.4/4.5/4.6 Regression] -ftree-loop-linear causes FAIL: gcc.dg/vect/vect-cond-5.c execution test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43657
--- Comment #4 from Changpeng Fang changpeng.fang at amd dot com 2010-10-19
21:27:46 UTC ---
for (k = 0; k 32; k++)
{
res = 0;
for (j = 0; j 32; j++)
for (i = 0; i 32; i++)
{
next = a[i][j];
res = c cond_array[i+k][j] ? next : res;
}
out[k] = res;
}
gcc interchanges i and j loops, which is not legal in this case.
Apparently, res takes the last value of a[i][j] that satisfies the
condition c cond_array[i+k][j]. As a result, change in the
reference order will get a different value for res.
Anyone knows where to do this legality check?
What about the interchange in Graphite for this case?
[Bug tree-optimization/46085] [4..6 Regression] gcc.dg/vect/fast-math-vect-reduc-[57].c failed with -mavx -ffast-math -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46085
--- Comment #2 from H.J. Lu hjl.tools at gmail dot com 2010-10-19 21:32:05
UTC ---
(define_expand reduc_splus_v8sf
[(match_operand:V8SF 0 register_operand )
(match_operand:V8SF 1 register_operand )]
TARGET_AVX
{
rtx tmp = gen_reg_rtx (V8SFmode);
rtx tmp2 = gen_reg_rtx (V8SFmode);
emit_insn (gen_avx_haddv8sf3 (tmp, operands[1], operands[1]));
emit_insn (gen_avx_haddv8sf3 (tmp2, operands[1], operands[1]));
emit_insn (gen_avx_haddv8sf3 (operands[0], tmp2, tmp2));
DONE;
})
and
(define_expand reduc_splus_v4df
[(match_operand:V4DF 0 register_operand )
(match_operand:V4DF 1 register_operand )]
TARGET_AVX
{
rtx tmp = gen_reg_rtx (V4DFmode);
emit_insn (gen_avx_haddv4df3 (tmp, operands[1], operands[1]));
emit_insn (gen_avx_haddv4df3 (operands[0], tmp, tmp));
DONE;
})
are incorrect.
[Bug target/46072] AIX linker chokes on debug info for uninitialized static variables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46072 --- Comment #1 from Daniel Richard G. skunk at iskunk dot org 2010-10-19 21:51:44 UTC --- I'd like to add: We've been able to work around this issue in our C codebase simply by ensuring that every static variable is initialized with a value. The bug behavior makes the uninitialized ones easy to track down as a matter of course. However, we can't do the same for our C++ codebase. There is at least one static declaration (std::__ioinit) in the C++ header files that we can't touch, so unless we turn off debug information altogether, there's not much of a way to avoid the linker error.
[Bug tree-optimization/44503] control flow in the middle of basic block with -fprefetch-loop-arrays
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44503 Changpeng Fang changpeng.fang at amd dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #5 from Changpeng Fang changpeng.fang at amd dot com 2010-10-19 21:54:27 UTC --- This bug is no longer valid for the current gcc trunk. It is possibly fixed by Honza's CFG work related to leaf attribute. Anyway, I close this bug.
[Bug bootstrap/46086] fail to build gcc 4.5.2 on sparc64-portbld-freebsd9.0 - configure: error: cannot compute suffix of object files: cannot compile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46086 --- Comment #4 from Anton Shterenlikht mexas at bristol dot ac.uk 2010-10-19 22:07:54 UTC --- what specifically? The versions of the libraries mentioned on my box are above the minimum recommended: mpfr-3.0.0 gmp-5.0.1 binutils-2.20.1_3 or did I miss something else?
[Bug fortran/23280] gfortran does not emit DW_AT_entry_point (dwarf-2) debugging info
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23280 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #4 from Tobias Burnus burnus at gcc dot gnu.org 2010-10-19 22:10:14 UTC --- Can this PR be closed given that PR 43414 is fixed? If not, could you point out what is missing?
[Bug tree-optimization/46085] [4..6 Regression] gcc.dg/vect/fast-math-vect-reduc-[57].c failed with -mavx -ffast-math -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46085 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc-p ||atches/2010-10/msg01681.htm ||l --- Comment #3 from H.J. Lu hjl.tools at gmail dot com 2010-10-19 22:15:07 UTC --- A patch is posted at http://gcc.gnu.org/ml/gcc-patches/2010-10/msg01681.html
[Bug middle-end/45962] [4.6 Regression]: many c/c++ failures on cris-elf, in r165236:165242
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45962 --- Comment #17 from Hans-Peter Nilsson hp at gcc dot gnu.org 2010-10-19 22:21:43 UTC --- (In reply to comment #10) MAX_STACK_ALIGNMENT should be MAX_OFILE_ALIGNMENT if you support the full stack re-alignment scheme. Is there a particular reason it should be MAX_OFILE_ALIGNMENT? The object file features shouldn't matter for stack objects. I'd think it should be something like the minimum supported value for the equivalent of (ulimit -s) / 2, not an easy value to get hold of though. (In reply to comment #16) (In reply to comment #15) ... though the vector alignment is neither explicit nor mandatory. It's implicit in the DImode mode of the type. If you'd like to reduce the alignment of local variables, use the MINIMUM_ALIGNMENT macro; see the i386 port for an example. Hm, the default should fall back to effectively BIGGEST_ALIGNMENT unless there's a specific __attribute__ ((__aligned__ (N))) in there. That it apparently doesn't is a bug; the defaults of the *_ALIGNMENT macros shouldn't second-guess the basic alignment macros, increasing alignment. (BTW, shouldn't MINIMUM_ALIGNMENT default to STACK_ALIGNMENT? And be named DYNAMIC_STACK_ALIGNMENT?) Are you open to having that fixed? No such dynamic allocation at r165239. Yes, that's the whole point of the patch, to honor alignment as given. Right, it apparently correctly uses macros which have the wrong values. Your cleanups had (at least) fallouts, business as usual... When doing so, it feels it needs to save the stack-pointer. That's redundant; it's already saved when a frame-pointer is needed. The cris port fails to define EXIT_IGNORE_STACK to indicate this. IIRC I tried to define that macro some (long) time ago, but that had fallouts. Too much water under the bridges, so it might be a good idea to try that again. (Defining it would not be a proper fix though, it'd just be covering up the bug.) Without that, the middle-end thinks it must save/restore sp around the function. Frankly, there's nothing otherwise unusual about this new alloca from any other. I guess you've just never noticed this extra save previously? I have inspected alloca-using code some time or other and have IIRC noticed it being slightly suboptimal, but then again, not unexpected from alloca. I've never seen such a save/restore using an _invalid_ location, just being redundant. It so emits move.d $sp,[$r8-8] ... Where it gets the -8 from, I don't know, I'll look further. I assume that's a stack slot for a spilled pseudo? Not a spilled pseudo, rather the stack-saving code going wrong. Stack-saving/restoring seems explicit and a bit intertwined; earlier well-placed do_pending_stack_adjust() calls playing a part, then effected by explow.c:emit_stack_save. Not a big surprise if it goes wrong due to or uncovered by r165240. To be investigated; I'll do my part. It might not be wrong in the long run to completely replace EXIT_IGNORE_STACK with 1 and apply dead-code-elimination. At a glance, no weird-stack targets define it to 0 AFAICT and those future ones that would, would IMHO be better off doing a port-specific save and restore in their prologues/epilogues.
[Bug target/46084] gcc.dg/split-4.c failed with -mavx -m32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46084 --- Comment #1 from H.J. Lu hjl.tools at gmail dot com 2010-10-19 22:42:20 UTC --- This one fails without AVX instructions: [...@gnu-18 gcc]$ ./xgcc -B./ /export/gnu/import/git/gcc-avx/gcc/testsuite/gcc.dg/split-4.c -mavx -m32 -fsplit-stack -S [...@gnu-18 gcc]$ ./xgcc -B./ -m32 split-4.s [...@gnu-18 gcc]$ ./a.out Segmentation fault [...@gnu-18 gcc]$
[Bug c++/46046] internal compiler error with SFINAE expression in a template inside a template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46046 --- Comment #3 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org 2010-10-19 22:58:14 UTC --- Author: paolo Date: Tue Oct 19 22:58:11 2010 New Revision: 165708 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=165708 Log: /cp 2010-10-19 Paolo Carlini paolo.carl...@oracle.com PR c++/46046 * pt.c (add_to_template_args): Check extra_args for error_mark_node. (coerce_template_parms): Likewise for args. /testsuite 2010-10-19 Paolo Carlini paolo.carl...@oracle.com PR c++/46046 * g++.dg/template/crash104.C: New. Added: trunk/gcc/testsuite/g++.dg/template/crash104.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog
[Bug c++/46046] internal compiler error with SFINAE expression in a template inside a template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46046 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.6.0 --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com 2010-10-19 22:59:49 UTC --- Fixed.
[Bug tree-optimization/44776] FAIL: gcc.dg/matrix/transpose-3.c execution, -fprofile-use -fipa-matrix-reorg -fdump-ipa-matrix-reorg -O3 -fwhole-program
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44776 Zdenek Sojka zsojka at seznam dot cz changed: What|Removed |Added CC||zsojka at seznam dot cz --- Comment #11 from Zdenek Sojka zsojka at seznam dot cz 2010-10-19 23:00:48 UTC --- I am able to reproduce this at x86_64-pc-linux-gnu. Crashes with -fprofile-use with r165699 and r163636. However, valgrind reports invalid operations even without -fprofile-*: (-g is not needed to reproduce) $ gcc -O -fipa-matrix-reorg -fwhole-program transpose-3.i -g $ valgrind -q ./a.out /dev/null ==28612== Invalid free() / delete / delete[] ==28612==at 0x4C25A2D: free (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==28612==by 0x40098D: main (transpose-3.c:45) ==28612== Address 0x5185100 is 0 bytes inside a block of size 16 free'd ==28612==at 0x4C25A2D: free (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==28612==by 0x40098D: main (transpose-3.c:45) ==28612== Removing any of these flags (except -g) makes the problem disappear.
[Bug fortran/46087] New: Double precision values, when read in from data file, include random trailing numbers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46087 Summary: Double precision values, when read in from data file, include random trailing numbers Product: gcc Version: 4.5.1 Status: UNCONFIRMED Severity: major Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: kyle.s.wil...@gmail.com Example code: program test_dble real(8) :: a,b integer :: x,y open(unit=11,file='testdble.dat',status='old') read(11,*) a read(11,*) x read(11,*) b read(11,*) y write(*,'(f22.20)') a write(*,'(f22.20)') b print*, a print*, b print *, x print *, y close(11) end program test_dble testdble.dat: 2.18 5 4.2 55 I am converting from using Absoft f77 compiler to the lastest version of gfortran and when comparing the results, gfortran adds random trailing numbers onto the end of the double precision numbers. The number SHOULD have all trailing zeros and no other numbers. Results using gfortran 4.5.1: 2.18015987 4.20017764 2.1802 4.2002 5 55 Results using f77: 2.1800 4.2000 2.18 4.20 5 55 The program was not compiiled using any compiler flags. Thanks.
[Bug fortran/46087] Double precision values, when read in from data file, include random trailing numbers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46087 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2010-10-19 23:12:58 UTC --- Please read http://www.validlab.com/goldberg/paper.pdf . The issue is that 2.18 is not exactly representable.
[Bug middle-end/45962] [4.6 Regression]: many c/c++ failures on cris-elf, in r165236:165242
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45962 --- Comment #18 from Richard Henderson rth at gcc dot gnu.org 2010-10-19 23:21:31 UTC --- (In reply to comment #17) Is there a particular reason it should be MAX_OFILE_ALIGNMENT? No. For ELF, that just means arbitrarily large. Hm, the default should fall back to effectively BIGGEST_ALIGNMENT unless there's a specific __attribute__ ((__aligned__ (N))) in there. That it apparently doesn't is a bug Hum. I hadn't noticed previously that your BIGGEST_ALIGNMENT is *also* set to BITS_PER_UNIT. (BTW, shouldn't MINIMUM_ALIGNMENT default to STACK_ALIGNMENT? And be named DYNAMIC_STACK_ALIGNMENT?) I dunno about dynamic. That sounds like stack re-alignment. The current MINIMUM_ALIGNMENT leaves the alignment unchanged. Are you open to having that fixed? Well, it appears as if get_mode_alignment is already correct, but TYPE_ALIGN and thus DECL_ALIGN don't honor BIGGEST_ALIGNMENT. I can see that if we adjust TYPE_ALIGN we'll alter the layout of all structures, which can't be a good thing. I'm not sure what the fallout would be from changing if (code != FIELD_DECL) /* For non-fields, update the alignment from the type. */ do_type_align (type, decl); to also take BIGGEST_ALIGNMENT into account. Certainly we can't change do_type_align because that's also used for FIELD_DECLs. Not a spilled pseudo, rather the stack-saving code going wrong. Stack-saving/restoring seems explicit and a bit intertwined; earlier well-placed do_pending_stack_adjust() calls playing a part, then effected by explow.c:emit_stack_save. Not a big surprise if it goes wrong due to or uncovered by r165240. To be investigated; I'll do my part. Ug. It might not be wrong in the long run to completely replace EXIT_IGNORE_STACK with 1 and apply dead-code-elimination. That would be really nice. There are several ports that explicitly set it to 0: arc, h8300, m68hc11, spu, mcore, m32c. Those probably need a simple update to their epilogues to restore from frame pointer.
[Bug rtl-optimization/46088] New: [4.6 Regression] ICE: SIGSEGV in ix86_binary_operator_ok (i386.c:15025) with -Os -fnon-call-exceptions -fpeel-loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46088 Summary: [4.6 Regression] ICE: SIGSEGV in ix86_binary_operator_ok (i386.c:15025) with -Os -fnon-call-exceptions -fpeel-loops Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: zso...@seznam.cz Created attachment 22088 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22088 reduced testcase Command line: $ gcc -Os -fnon-call-exceptions -fpeel-loops pr46088.c Related valgrind output: $ valgrind -q --trace-children=yes gcc -Os -fnon-call-exceptions -fpeel-loops pr46088.c ==14275== Invalid read of size 2 ==14275==at 0xA7C8EC: ix86_binary_operator_ok (i386.c:15025) ==14275==by 0xDF3063: recog (i386.md:10038) ==14275==by 0xEE9313: recog_for_combine (combine.c:10480) ==14275==by 0xF16107: try_combine (combine.c:3220) ==14275==by 0xF2141D: rest_of_handle_combine (combine.c:1187) ==14275==by 0x79613E: execute_one_pass (passes.c:1562) ==14275==by 0x7963D4: execute_pass_list (passes.c:1617) ==14275==by 0x7963E6: execute_pass_list (passes.c:1618) ==14275==by 0x8E30F5: tree_rest_of_compilation (tree-optimize.c:419) ==14275==by 0xAAC341: cgraph_expand_function (cgraphunit.c:1494) ==14275==by 0xAAE909: cgraph_optimize (cgraphunit.c:1553) ==14275==by 0xAAEE69: cgraph_finalize_compilation_unit (cgraphunit.c:1016) ==14275== Address 0xabababababababab is not stack'd, malloc'd or (recently) free'd ==14275== pr46088.c: In function 'foo': pr46088.c:7:1: 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. Tested revisions: r165699 - crash r159696 - crash r158095 - OK 4.5 r163761 - OK
[Bug target/46089] New: ICE: in gen_reg_rtx, at emit-rtl.c:861 with -mcmodel=large -fsplit-stack
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46089
Summary: ICE: in gen_reg_rtx, at emit-rtl.c:861 with
-mcmodel=large -fsplit-stack
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zso...@seznam.cz
Even simple testcase such as:
testcase.c
void foo(void) {}
Causes this ICE:
$ gcc -mcmodel=large -fsplit-stack testcase.c
testcase.c: In function 'foo':
testcase.c:1:1: internal compiler error: in gen_reg_rtx, at emit-rtl.c:861
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
Tested revisions:
r165699 - crash
r163636 - doesn't know -fsplit-stack
[Bug target/46080] [4.4/4.5/4.6 Regression] incorrect precision of sqrtf builtin for x87 arithmetic (-mfpmath=387)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46080 --- Comment #2 from Vincent Lefèvre vincent at vinc17 dot org 2010-10-20 01:51:56 UTC --- Created attachment 22089 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22089 sh script to test sqrtf Similar problems can also be found with: printf (%.60f\n%.60f\n%.60f\n, sqrtf(x), sqrtf(x), sqrtf(x)); I've found that every GCC version I could test was showing some incorrect behavior (but GCC 4.2.4 was the most consistent one). With the attached script, I get: -DSEP -O0 -O1 -O2 GCC 3.4.6 SSS SSS SDD SDD GCC 4.1.3 SSS SSS DSS DDS GCC 4.2.4 SSS SSS DDD DDD (x86) GCC 4.3.5 SSS SSS DSS DDD (ditto with GCC 4.3.2 on x86) GCC 4.4.5 DSS SSD DSS DDD where S means that one gets the result in single precision (as expected) and D means that one gets the result in double precision.
[Bug fortran/42169] [4.4/4.5/4.6 Regression] gfortran.dg/pr41928.f90:47: internal compiler error: in store_can_be_removed_p, at ira-emit.c:371
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42169 Vladimir Makarov vmakarov at redhat dot com changed: What|Removed |Added CC||vmakarov at redhat dot com --- Comment #22 from Vladimir Makarov vmakarov at redhat dot com 2010-10-20 03:03:53 UTC --- Function store_can_be_removed_p was written in assumption that the store is on a loop exit. Apparently it is not true. In this case, it was actually a loop entry from 4 to 5 in loop tree: 0-1-2-3-4-5 | --6-7 There should be some rare combinations of conditions (one is that pseudo is not changed in whole program) to achieve gcc_unreachable for the loop entry. Therefore it is hard to reproduce. There is a very simple solution which is to return false (preventing this optimization) instead of gcc_unreachable (that is a loop entry case). I'll send a patch soon.
[Bug rtl-optimization/46088] [4.6 Regression] ICE: SIGSEGV in ix86_binary_operator_ok (i386.c:15025) with -Os -fnon-call-exceptions -fpeel-loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46088 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2010.10.20 03:22:14 CC||bernds at codesourcery dot ||com, hjl.tools at gmail dot ||com Target Milestone|--- |4.6.0 Ever Confirmed|0 |1 --- Comment #1 from H.J. Lu hjl.tools at gmail dot com 2010-10-20 03:22:14 UTC --- It is caused by revision 158187: http://gcc.gnu.org/ml/gcc-cvs/2010-04/msg00291.html
[Bug c/46090] New: 16 bit uint16_t puts non-zero in highest bits when shifting
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46090
Summary: 16 bit uint16_t puts non-zero in highest bits when
shifting
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: kshak...@gmail.com
This problem occurred on 64-bit Linux platform.
Here is an example of code for reproducing problem.
#include stdint.h
uint16_t In16(uint16_t input)
{
uint16_t len = (input * 0x0101) 8;
return len;
}
int len = In16(0x808);
When passing input=0x808, expected result:
1. len = (input * 0x0101) 8;
2. len = (0x808 * 0x0101) 8;
3. len = (0x808 + 0x0800) 8;
4. len = 0x1008 8;
5. len = 0x10;
Instead of 0x10, result is 0x810
3. len = (0x808 + 0x80800) 8;
Here higher than 16 bit is not truncated.
4. len = 0x81008 8;
5. len = 0x810;
[Bug c/46090] 16 bit uint16_t puts non-zero in highest bits when shifting
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46090 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2010-10-20 04:52:48 UTC --- input * 0x0101 is really ((int)input) * 0x0101. So this behavior is correct.
[Bug target/46091] New: missed optimization: x86 bt/btc/bts instructions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46091
Summary: missed optimization: x86 bt/btc/bts instructions
Product: gcc
Version: 4.3.5
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jay.kr...@cornell.edu
The following code, at least when optimizing for space, should use x86
bt/btc/bts instructions.
#include limits.h
#include stddef.h
void set_bit(size_t* a, size_t b)
{
const unsigned c = sizeof(size_t) * CHAR_BIT;
a[b / c] |= (((size_t)1) (b % c));
}
void clear_bit(size_t* a, size_t b)
{
const unsigned c = sizeof(size_t) * CHAR_BIT;
a[b / c] = ~(((size_t)1) (b % c));
}
int get_bit(size_t* a, size_t b)
{
const unsigned c = sizeof(size_t) * CHAR_BIT;
return !!(a[b / c] (((size_t)1) (b % c)));
}
