[Bug bootstrap/30727] Argument list to long when compiling gcc
--- Comment #3 from schwab at suse dot de 2007-02-15 09:40 --- > It is not a small command line passed to gcc but one enormous command line > passed to /bin/bash. This is wrong. The executed command is gcc, and it only needs 500 bytes of argument space. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30727
[Bug fortran/30793] Segfault on calling a function returning a pointer
--- Comment #8 from burnus at gcc dot gnu dot org 2007-02-15 09:45 --- The link to c.l.fortran is: http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/23aa68ecce460e50 Richard Main: "The pointer assignment is ok. I [...] don't have time to adequately peruse the rest of the code. [...] I do note that you've got generics that have specifics of the same name as the generic. The standard does allow that, but it wouldn't shock me if some compilers get as confused by it as I do." Both the initial and the reduced program compile and run (seemingly) correctly with NAG f95 5.1, ifort 9.1 and 10, and sunf95 8.3. I played around with my reduced testcase (attachment 13050). The crash only occurs with: type mesh integer,allocatable :: area(:) end type mesh if I replace it by "pointer :: area(:)" it does not crash. The extra lines in msh_ and get_scalar_field_msh are: __result_msh_->area.data = 0B; and __result_get_scalar_field_msh->area.data = 0B; Actually, the program does not crash if one replaces the third line of: function msh_(fld) type(mesh), pointer :: msh_ type(field), intent(in) :: fld msh_ => fld%msh end function msh_ by type(field), TARGET, intent(in) :: fld I have still to re-read the test case to check whether TARGET is required by the standard in this case or not. Adding "target" to msh_ is however not enough to prevent the original test case (attachment 13049) from crashing in get_scalar_field_msh; here the dump-tree-original looks like: struct mesh * __result_get_scalar_field_msh; __result_get_scalar_field_msh->area.data = 0B; __result_get_scalar_field_msh->dist.data = 0B; __result_get_scalar_field_msh->interp.data = 0B; I don't know whether something happens behind the scenes, but accessing a component of a (non-allocated and non-associated) pointer sounds bad. Especially, even if it worked, setting them to values and then overwriting them by __result_get_scalar_field_msh = msh_ (&fld->base); seems to be strange. I therefore think there are two bugs: a) In the program a TARGET is missing b) In gfortran one should not initialize array components of pointers before the pointer is allocated (if it is associated it is not needed). If the gfortran bug is fixed, (a) is probably not needed to prevent the crash. (Next step: check whether the standard mandates TARGET and where the bug in gfortran is located, must be somewhere in trans-*.c.) -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||burnus at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC build triplet|i686-pc-linux-gnu | GCC host triplet|i686-pc-linux-gnu | GCC target triplet|i686-pc-linux-gnu | Keywords||wrong-code Last reconfirmed|-00-00 00:00:00 |2007-02-15 09:45:54 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30793
[Bug fortran/30793] Segfault on calling a function returning a pointer
--- Comment #9 from sfilippone at uniroma2 dot it 2007-02-15 09:55 --- (In reply to comment #8) > The link to c.l.fortran is: > http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/23aa68ecce460e50 > > Richard Main: "The pointer assignment is ok. I [...] don't have > time to adequately peruse the rest of the code. [...] > I do note that you've got generics that have specifics of the same name > as the generic. The standard does allow that, but it wouldn't shock me > if some compilers get as confused by it as I do." > > Both the initial and the reduced program compile and run (seemingly) correctly > with NAG f95 5.1, ifort 9.1 and 10, and sunf95 8.3. > > . > > I have still to re-read the test case to check whether TARGET is required by > the standard in this case or not. Adding "target" to msh_ is however not > enough > to prevent the original test case (attachment 13049 [edit]) from crashing in > get_scalar_field_msh; here the dump-tree-original looks like: > However the accessed component is a POINTER to a derived type, I was under the impression that a POINTER component is implicitly available as a TARGET even if its parent is not. Maybe I'm just wrong. Ah, yes, M&R Fortran 95/2003, page 50: "Note that it is sufficient for there to be a pointer at any level of component selection type(entry) :: node ! this has a pointer component next node%next%value is a permitted target" Seems it's legal even without the TARGET attribute. At least one version of XLF is complaining. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30793
[Bug tree-optimization/30795] [4.3 Regression] ice for legal code with -ftree-vectorize -O2
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-02-15 09:56 ---
Confirmed:
#1 0x00cffee3 in vect_get_vec_def_for_stmt_copy (
dt=vect_induction_def, vec_oprnd=0x2abeb1648480)
at /space/rguenther/src/svn/trunk/gcc/tree-vect-transform.c:901
901 gcc_assert (TREE_CODE (vec_stmt_for_operand) == PHI_NODE);
(gdb) call debug_generic_expr (vec_oprnd)
vect_vec_iv_.651_2519
we're trying to vectorize
#2 0x00d0a06d in vectorizable_store (stmt=0x2abeb1570a50,
bsi=0x7a0cc910, vec_stmt=0x7a0cc7e0)
at /space/rguenther/src/svn/trunk/gcc/tree-vect-transform.c:3229
3229 vec_oprnd = vect_get_vec_def_for_stmt_copy (dt,
(gdb) call debug_generic_expr (stmt)
# runningOrder_2294 = VDEF { runningOrder }
runningOrder[i_2611] = i_2611
in
(gdb) call debug_bb (bb_for_stmt (stmt))
;; basic block 36, loop depth 1, count 0
;; prev block 391, next block 37
;; pred: 391 [100.0%] (fallthru) 37 [100.0%] (fallthru,exec)
;; succ: 37 [99.0%] (true,exec) 38 [1.0%] (loop_exit,false,exec)
# ivtmp.658_2514 = PHI
# vect_vec_iv_.651_2522 = PHI
# ivtmp.645_2529 = PHI
# ivtmp.635_2540 = PHI <256(391), ivtmp.635_2539(37)>
# bigDone_2602 = PHI
# runningOrder_2603 = PHI
# i_2611 = PHI <0(391), i_336(37)>
:;
# bigDone_2293 = VDEF { bigDone }
*ivtmp.645_2529 = vect_cst_.639_2532;
vect_vec_iv_.651_2521 = vect_vec_iv_.651_2522 + vect_cst_.650_2523;
vect_vec_iv_.651_2519 = vect_vec_iv_.651_2522 + vect_cst_.652_2520;
vect_vec_iv_.651_2518 = vect_vec_iv_.651_2519 + vect_cst_.652_2520;
vect_vec_iv_.651_2517 = vect_vec_iv_.651_2518 + vect_cst_.652_2520;
# runningOrder_2294 = VDEF { runningOrder }
*ivtmp.658_2514 = vect_vec_iv_.651_2522;
ivtmp.658_2512 = ivtmp.658_2514 + 16B;
# runningOrder_2511 = VDEF { runningOrder }
*ivtmp.658_2512 = vect_vec_iv_.651_2519;
# runningOrder_2294 = VDEF { runningOrder }
runningOrder[i_2611] = i_2611;
i_336 = i_2611 + 1;
ivtmp.635_2539 = ivtmp.635_2540 - 1;
ivtmp.645_2528 = ivtmp.645_2529 + 16B;
ivtmp.658_2513 = ivtmp.658_2512 + 16B;
if (ivtmp.635_2539 != 0) goto ; else goto ;
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||dorit at il dot ibm dot com
Keywords||ice-on-valid-code
Summary|ice for legal code with - |[4.3 Regression] ice for
|ftree-vectorize -O2 |legal code with -ftree-
||vectorize -O2
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30795
[Bug ada/30803] warning: index for "X" may assume lower bound of 1
--- Comment #2 from krischik at users dot sourceforge dot net 2007-02-15 10:07 --- << and you should use a GNAT version older than the version you are building indeed. >> For Linux that would be OK - just use the compiler from the distribution. But for "pentium4-pc-mingw32msv" it is not that easy. I fight this situation for a year now: Either the bootstrap compiler is to old (missing some new feature) or to new (having a new warning) but it never quite right. Anyway, the compiler at question is: GNAT GPL 2006 (20060522-34) Copyright 1996-2006, Free Software Foundation, Inc. Now 20060522-34 sounds distinctive older then 20070207-42 does it? And yes I know about all those private patches AdaCore added for GNAT GPL 2006. So please no lectures. Those private patches got us into a mess where only AdaCore is now able to create mingw Ada compiler. Martin -- krischik at users dot sourceforge dot net changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30803
[Bug ada/30804] index for "Buffer" may assume lower bound of 1
--- Comment #2 from krischik at users dot sourceforge dot net 2007-02-15 10:09 --- And exactly which older, working mingw version would you suggest if GNAT GPL 2006 (20060522-34) Copyright 1996-2006, Free Software Foundation, Inc. is not old enough. Martin -- krischik at users dot sourceforge dot net changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30804
[Bug ada/30804] index for "Buffer" may assume lower bound of 1
--- Comment #3 from charlet at gcc dot gnu dot org 2007-02-15 10:16 --- Any version from the FSF sources than the version you're trying to build should do (e.g. GCC 3.4, 4.0, 4.1). Anyway, you do not need to be a maintainer do submit and commit patches, so if this issue is blocking you, I'd suggest submitting a patch, and once you get approval, commit it. Arno -- charlet at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30804
[Bug ada/30803] warning: index for "X" may assume lower bound of 1
--- Comment #3 from charlet at gcc dot gnu dot org 2007-02-15 10:19 --- If you want to act like a maintainer, then I'd suggest you submit patches, and once you get approval, commit them, it's trivial after all, as you said. The issue here is that you're trying to mix compilers from different origins, and it's true that under mingw, things are complex, because of incompatibilities between mingw version. Otherwise, using FSF GCC 3.4, 4.0 or 4.1 will work just fine to bootstrap GCC 4.2. -- charlet at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30803
[Bug tree-optimization/30795] [4.3 Regression] ice for legal code with -ftree-vectorize -O2
--- Comment #3 from dorit at il dot ibm dot com 2007-02-15 10:21 --- I'll look into it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30795
[Bug fortran/30793] Segfault on calling a function returning a pointer
--- Comment #10 from burnus at gcc dot gnu dot org 2007-02-15 10:32 --- > > I have still to re-read the test case to check whether TARGET is required > > However the accessed component is a POINTER to a derived type [...] Ok, I somehow didn't realize type field type(mesh), pointer :: msh => null() when I read msh_ => fld%msh One does not assign msh_ the variable fld%msh as target, but one assignes the target of the pointer fld%msh to the pointer msh_. But I don't understand why xlf does not like the TARGET attribute. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30793
[Bug fortran/30793] Segfault on calling a function returning a pointer
--- Comment #11 from sfilippone at uniroma2 dot it 2007-02-15 10:42 --- (In reply to comment #10) > > > I have still to re-read the test case to check whether TARGET is required > > > > However the accessed component is a POINTER to a derived type [...] > > Ok, I somehow didn't realize > type field > type(mesh), pointer :: msh => null() > when I read > msh_ => fld%msh > One does not assign msh_ the variable fld%msh as target, but one assignes the > target of the pointer fld%msh to the pointer msh_. Yes, exactly: that's an object that has an independent life, is pointed to from the field object, and I want to get access to it. > > But I don't understand why xlf does not like the TARGET attribute. > Beats me. But I guess I'd be happy enough to have gfortran working, for the time being. Actually I already have a workaround: instead of a function, put a subroutine call get_mesh(mshp,fld) which internally does mshp => fld%msh works perfectly. Why? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30793
[Bug c/16274] Memory allocation error for arrays on stack
--- Comment #3 from med04hrt at studserv dot uni-leipzig dot de 2007-02-15
12:17 ---
(In reply to comment #0)
> The following simple c code gives segmentation fault on a GNU-Linux system
> (Redhat-9.0) running on a Pentium 4 machine with 512 MB RAM.
>
>
> Source file : test.c
>
> -
> #include
>
> int main()
> {
> int a[1024][1024];
> int b[1024][1024];
>
> b[0][0]=13;
>
> return 0;
> }
I had the same error with declaring some
double[10001][13] arrays. the program crashes right at the declaration (no
printf at the beginning is executed).
It seems to me that this happens because the static memory is just to small.
I didn't find out how to define its size, but you can solve the problem if you
allocate the memory dynamically.
#include
int **a=(int**)malloc(sizeof(int)*1024*1024);
int **bb=(int**)malloc(sizeof(int)*1024*1024);
Unfourtunately i couldn't figure out how to do the correct cast, so this
produces a warning on indexation, because the pointer types aren't identicall.
Regards
Petre
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16274
[Bug middle-end/30768] [4.3 regression]: ICE in ext/pb_ds/regression/list_update_data_map_rand.cc
--- Comment #18 from rguenth at gcc dot gnu dot org 2007-02-15 12:41 --- It triggers on the c++tester (x86_64) for boost and tramp3d as well. Can we please fix this asap? Thanks. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |critical Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30768
[Bug preprocessor/30805] New: Internal compiler error when using "x##,##__VA_ARGS__" in macro
The 2-line source that triggers the error: #define A(x,...) x##,##__VA_ARGS__ A(1) Error message: a.c:6: internal compiler error: Geannuleerd Please submit a full bug report The source file is from: http://www.kernel.org/git/?p=linux/kernel/git/josh/sparse.git;a=blob;f=validation/preprocessor13.c;hb=0.2 My system: Linux Knoppix 2.6.19 #7 SMP PREEMPT Sun Dec 17 22:01:07 CET 2006 i686 GNU/Linux The bug is triggerd by al 4 compilers on my system. gcc-3.3 (GCC) 3.3.6 (Debian 1:3.3.6-13) gcc-3.4 (GCC) 3.4.6 (Debian 3.4.6-4) gcc-4.0 (GCC) 4.0.4 20060904 (prerelease) (Debian 4.0.3-7) gcc-4.1 (GCC) 4.1.2 20061028 (prerelease) (Debian 4.1.1-19) -- Summary: Internal compiler error when using "x##,##__VA_ARGS__" in macro Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: preprocessor AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: johandefries at gmail dot com GCC host triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30805
[Bug ada/30806] New: execvp: gcc: Argument list too long
Hello, When trying to build compiler on mingw I get the following error message: - gcc -c -g -fkeep-inline-functions -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -fno-common -DHAVE_CONFIG_H -I. -Iada -I../../gcc-4.2-20070207/gcc -I../../gcc-4.2-20070207/gcc/ada -I../../gcc-4.2-20070207/gcc/../include -I./../intl -I../../gcc-4.2-20070207/gcc/../libcpp/include -I../../gcc-4.2-20070207/gcc/../libdecnumber -I../libdecnumber ../../gcc-4.2-20070207/gcc/ada/env.c -o ada/env.o gcc -g -fkeep-inline-functions -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute -fno-common -DHAVE_CONFIG_H -o gnat1.exe ada/b_gnat1.o ada/adadecode.o ada/adaint.o ada/cstreams.o ada/cio.o ada/targtyps.o ada/decl.o ada/misc.o ada/utils.o ada/utils2.o ada/trans.o ada/cuintp.o ada/argv.o ada/raise.o ada/init.o ada/tracebak.o ada/initialize.o ada/env.o ada/ada.o ada/a-charac.o ada/a-chlat1.o ada/a-except.o ada/a-elchha.o ada/a-ioexce.o ada/s-memory.o ada/s-carun8.o ada/s-casuti.o ada/s-strcom.o ada/s-purexc.o ada/s-htable.o ada/s-traceb.o ada/s-mastop.o ada/ali.o ada/alloc.o ada/atree.o ada/butil.o ada/casing.o ada/checks.o ada/comperr.o ada/csets.o ada/cstand.o ada/debug.o ada/debug_a.o ada/einfo.o ada/elists.o ada/errout.o ada/erroutc.o ada/err_vars.o ada/eval_fat.o ada/exp_attr.o ada/exp_ch11.o ada/exp_ch12.o ada/exp_ch13.o ada/exp_ch2.o ada/exp_ch3.o ada/exp_ch4.o ada/exp_ch5.o ada/exp_ch6.o ada/exp_ch7.o ada/exp_ch8.o ada/exp_ch9.o ada/exp_code.o ada/exp_dbug.o ada/exp_disp.o ada/exp_dist.o ada/exp_fixd.o ada/exp_aggr.o ada/exp_imgv.o ada/exp_intr.o ada/exp_pakd.o ada/exp_prag.o ada/exp_sel.o ada/exp_smem.o ada/exp_strm.o ada/exp_tss.o ada/exp_util.o ada/exp_vfpt.o ada/expander.o ada/fname.o ada/fname-uf.o ada/fmap.o ada/freeze.o ada/frontend.o ada/gnat.o ada/g-hesora.o ada/g-htable.o ada/g-os_lib.o ada/g-speche.o ada/g-string.o ada/g-utf_32.o ada/s-crc32.o ada/get_targ.o ada/gnatvsn.o ada/hlo.o ada/hostparm.o ada/impunit.o ada/interfac.o ada/itypes.o ada/inline.o ada/krunch.o ada/lib.o ada/layout.o ada/lib-load.o ada/lib-util.o ada/lib-xref.o ada/lib-writ.o ada/live.o ada/namet.o ada/nlists.o ada/nmake.o ada/opt.o ada/osint.o ada/osint-c.o ada/output.o ada/par.o ada/prep.o ada/prepcomp.o ada/repinfo.o ada/restrict.o ada/rident.o ada/rtsfind.o ada/s-addope.o ada/s-assert.o ada/s-parame.o ada/s-stache.o ada/s-stalib.o ada/s-imgenu.o ada/s-stoele.o ada/s-soflin.o ada/s-exctab.o ada/s-secsta.o ada/s-traent.o ada/s-wchcnv.o ada/s-wchcon.o ada/s-wchjis.o ada/s-unstyp.o ada/scans.o ada/scng.o ada/scn.o ada/sdefault.o ada/sem.o ada/sem_aggr.o ada/sem_attr.o ada/sem_cat.o ada/sem_ch10.o ada/sem_ch11.o ada/sem_ch12.o ada/sem_ch13.o ada/sem_ch2.o ada/sem_ch3.o ada/sem_ch4.o ada/sem_ch5.o ada/sem_ch6.o ada/sem_ch7.o ada/sem_ch8.o ada/sem_ch9.o ada/sem_case.o ada/sem_disp.o ada/sem_dist.o ada/sem_elab.o ada/sem_elim.o ada/sem_eval.o ada/sem_intr.o ada/sem_maps.o ada/sem_mech.o ada/sem_prag.o ada/sem_res.o ada/sem_smem.o ada/sem_type.o ada/sem_util.o ada/sem_vfpt.o ada/sem_warn.o ada/sinfo-cn.o ada/sinfo.o ada/sinput.o ada/sinput-d.o ada/sinput-l.o ada/snames.o ada/sprint.o ada/stand.o ada/stringt.o ada/style.o ada/styleg.o ada/styleg-c.o ada/switch.o ada/switch-c.o ada/stylesw.o ada/validsw.o ada/system.o ada/table.o ada/targparm.o ada/tbuild.o ada/tree_gen.o ada/tree_io.o ada/treepr.o ada/treeprs.o ada/ttypef.o ada/ttypes.o ada/types.o ada/uintp.o ada/uname.o ada/urealp.o ada/usage.o ada/widechar.o ada/s-crtl.o ada/seh_init.o ada/targext.o ada/back_end.o ada/gnat1drv.o prefix.o main.o tree-browser.o libbackend.a ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a attribs.o ../libcpp/libcpp.a ./../intl/libintl.a -liconv ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a \ make[4]: execvp: gcc: Argument list too long make[4]: *** [gnat1.exe] Fehler 127 make[4]: Leaving directory `/work/gnuada/rpm/BUILD/gnat-mingw-gcc/pentium4-pc-mingw32msv/gcc' make[3]: *** [all-stage1-gcc] Fehler 2 make[3]: Leaving directory `/work/gnuada/rpm/BUILD/gnat-mingw-gcc/pentium4-pc-mingw32msv' make[2]: *** [stage1-bubble] Fehler 2 make[2]: Leaving directory `/work/gnuada/rpm/BUILD/gnat-mingw-gcc/pentium4-pc-mingw32msv' make[1]: *** [all] Fehler 2 make[1]: Leaving directory `/work/gnuada/rpm/BUILD/gnat-mingw-gcc/pentium4-pc-mingw32msv' Fehler: Bad exit status from /var/tmp/rpm-tmp.75542 (%build) - I wonder if there is relay no better way to call the linker on unix and unix-like systems. Martin -- Summary: execvp: gcc: Argument list too long Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: blocker Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: krischik at users dot sourceforge dot net GCC build triplet: pentium4-pc-mingw32msv GCC host triplet: pe
[Bug tree-optimization/30334] Request for -Wundefined
--- Comment #13 from manu at gcc dot gnu dot org 2007-02-15 14:24 --- Another candidate to warn for undefined behaviour PR 968 ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30334
[Bug tree-optimization/30334] Request for -Wundefined
--- Comment #14 from manu at gcc dot gnu dot org 2007-02-15 14:25 --- (In reply to comment #13) > Another candidate to warn for undefined behaviour PR 968 ? > Argh, I meant PR 986. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30334
[Bug middle-end/30807] New: sh postreload bug (might be generic in trunk)
I can only reproduce this problem on the sh target with a gcc version 3.4.3.
However my analysis makes me believe the problem still exists on the trunk.
After greg I have the following sequence :
(insn:HI 11 10 12 0 (set (reg/v/f:SI 2 r2 [orig:160 PrivateData_p ] [160])
(const_int 128 [0x80])) 122 {movsi_i} (nil)
(nil))
(insn:HI 12 11 134 0 (set (reg/v/f:SI 2 r2 [orig:160 PrivateData_p ] [160])
(plus:SI (reg/v/f:SI 2 r2 [orig:160 PrivateData_p ] [160])
(reg:SI 3 r3 [orig:162 Device_p ] [162]))) 23 {*addsi3_compact}
(insn_list 10 (insn_list 11 (nil)))
(expr_list:REG_EQUAL (plus:SI (reg:SI 3 r3 [orig:162 Device_p ] [162])
(const_int 128 [0x80]))
(nil)))
...
(insn:HI 16 135 17 0 (set (reg:SI 1 r1 [166])
(const_int 188 [0xbc])) 122 {movsi_i} (nil)
(nil))
(insn:HI 17 16 18 0 (set (reg:SI 1 r1 [166])
(plus:SI (reg:SI 1 r1 [166])
(reg/v/f:SI 2 r2 [orig:160 PrivateData_p ] [160]))) 23
{*addsi3_compact} (insn_list 16 (nil))
(expr_list:REG_EQUAL (plus:SI (reg:SI 3 r3 [orig:162 Device_p ] [162])
(const_int 316 [0x13c]))
(nil)))
'reload_combine' decides to optimize insns 16/17. After the optimisation, there
is a 'continue' and reload_combines tries other pattern.
The problem is that with this 'continue' reg_state[regno] was is updated with
the other uses (here r2).
later on insn 11/12 are optimized away, believing that r2 is dead because not
makrked in the reg_state use list, leaving it undefined.
The problem is very difficult to isolate (didn't succeed on trunk with i686)
but by reading the postreload code the bug seems latent.
--
Summary: sh postreload bug (might be generic in trunk)
Product: gcc
Version: 3.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: christian dot bruel at st dot com
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnugcc
GCC target triplet: sh-superh-elf-gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30807
[Bug preprocessor/30808] New: It would probably make sense to abort immediately after a file-not-found.
One of the most common problems I face in compiling programs with many
dependancies is that, if a dependency is missing, the resulting error messages
almost invariably scroll off the screen instantly, and even apart from the
scrolling, the single relevant error ("Cannot open : No such file or
directory" or whatever) is buried under hundreds upon hundreds of lines of
errors about variables not declared in scope, syntax errors in declarations,
and so on.
In general, error cascades are virtually impossible to prevent.
However, it seems clear that, any time an include file is missing, we *know*
that the build is doomed to failure. I think it would be a nice option (and
possibly a very good default) for gcc to simply abort immediately after any
file-not-found message, on the grounds that, if you are missing a header file,
there is simply no point in telling you that, without that header, your program
doesn't work.
--
Summary: It would probably make sense to abort immediately after
a file-not-found.
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: preprocessor
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gcc-bugzilla at seebs dot net
GCC build triplet: N/A
GCC host triplet: N/A
GCC target triplet: N/A
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30808
[Bug bootstrap/30727] Argument list to long when compiling gcc
--- Comment #4 from krischik at users dot sourceforge dot net 2007-02-15 15:00 --- Hello Andreas, If you say so I believe you. And it is not that important: I tried with gcc-4.2-20070207 and the problem did not appear again. Only now Ada fails with "Argument list to long" see bug#30806 :-(. Martin -- krischik at users dot sourceforge dot net changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30727
[Bug ada/30806] execvp: gcc: Argument list too long
--- Comment #1 from charlet at gcc dot gnu dot org 2007-02-15 15:03 --- Looks like a mingw/environment issue to me. Never seen such thing myself. -- charlet at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30806
[Bug other/30809] New: make install fails due to erroneous nesting of echo commands
During installation of gcc-4.1.2 ("gmake MAKE=gmake install") the following
error occurred on our Solaris systems:
echo 'SYSTEM_HEADER_DIR="'"`echo /usr/include | sed -e :a -e "s,[^/]*/\.\.\/,,"
-e ta`"'"' \
>
/slt/devel/toolsbase/gcc/4.1.2/sparc-sun-solaris2.10/lib/gcc/sparc-sun-solaris2.10/4.1.2/install-tools/mkheaders.conf
sed: command garbled: s,[
/bin/sh: : cannot execute
/bin/sh: /]*/../,, -e ta: not found
gmake[2]: *** [install-mkheaders] Error 1
gmake[2]: Leaving directory
`/var/tmp/gcc_powell_sparc-sun-solaris2.10_23537/objdir/gcc'
gmake[1]: *** [install-gcc] Error 2
gmake[1]: Leaving directory
`/var/tmp/gcc_powell_sparc-sun-solaris2.10_23537/objdir'
gmake: *** [install] Error 2
I've checked the command:
echo 'SYSTEM_HEADER_DIR="'"`echo /usr/include | sed -e :a -e "s,[^/]*/\.\.\/,,"
-e ta`"'"'
It can be changed to:
echo 'SYSTEM_HEADER_DIR="'`echo /usr/include | sed -e :a -e "s,[^/]*/\.\.\/,,"
-e ta`'"'
I've just omitted the double quotes around the command substitution with
backquotes. That way gcc 4.1.2 would install successfully on my machines.
The command most probably originates from gcc/Makefile.in on line 3786 of 4616,
but I haven't retried compilation with that change.
--
Summary: make install fails due to erroneous nesting of echo
commands
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gabriel dot kaelin at visonys dot com
GCC build triplet: i386-pc-solaris2.10, sparc-sun-solaris2.10
GCC host triplet: i386-pc-solaris2.10, sparc-sun-solaris2.10
GCC target triplet: i386-pc-solaris2.10, sparc-sun-solaris2.10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30809
[Bug middle-end/30807] sh postreload bug (might be generic in trunk)
--- Comment #1 from christian dot bruel at st dot com 2007-02-15 15:37 --- The bug might be clearer to explain like this we have 16: (set reg:r1) (const_int 188) 17: (set reg:r1) (plus (reg:r1 reg:r2) 18: (set reg:r1) (mem (plus (reg:r1) (const_int 4)) is transformed into 16: (set reg:r0) (const_int 192) 18: (set reg:r1) (mem (plus (reg:r0) (reg:r2)) since insn 18 is not reg_state[2].reg_use[i].insn, r2 might be seen as dead by another similar combine transformation on previous insns -- christian dot bruel at st dot com changed: What|Removed |Added CC||christian dot bruel at st ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30807
[Bug middle-end/30807] sh postreload bug (might be generic in trunk)
--- Comment #2 from christian dot bruel at st dot com 2007-02-15 15:55 --- Created an attachment (id=13052) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13052&action=view) Proposed fix for postreload combine the following patch fixes the problem in the sh 3.4.3 compiler. Since I didn't see a similar fix in the trunk, I suspect it is also needed (even if I was not able an isns similar sequence to reproduce the problem). -c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30807
[Bug middle-end/30768] [4.3 regression]: ICE in ext/pb_ds/regression/list_update_data_map_rand.cc
--- Comment #19 from pcarlini at suse dot de 2007-02-15 16:06 --- Also, I don't think the XFAIL-ing has been implemented in the correct way. We are now seeing logs like: http://gcc.gnu.org/ml/gcc-testresults/2007-02/msg00570.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30768
[Bug fortran/30478] FAIL: gfortran.dg/enum_2.f90 -O (internal compiler error)
--- Comment #31 from tobi at gcc dot gnu dot org 2007-02-15 16:20 --- Subject: Bug 30478 Author: tobi Date: Thu Feb 15 16:20:46 2007 New Revision: 122002 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122002 Log: PR fortran/30478 fortran/ * decl.c (create_enum_history, gfc_free_enum_history): Formatting fixes. (add_init_expr_to_sym): Remove ENUM-specific code-path. (variable_decl): Likewise. Formatting fix. (match_attr_spec): Remove ENUM-specific codepath. (gfc_match_enum): Fix typo in error message. (enumerator_decl): New. (gfc_match_enumerator_def): Strip down to code necessary for ENUMs, use enumerator_decl. testsuite/ * gfortran.dg/enum_4.f90: Update expected error message. Modified: branches/gcc-4_1-branch/gcc/fortran/ChangeLog branches/gcc-4_1-branch/gcc/fortran/decl.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/enum_4.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30478
[Bug fortran/30478] FAIL: gfortran.dg/enum_2.f90 -O (internal compiler error)
--- Comment #32 from tobi at gcc dot gnu dot org 2007-02-15 16:22 --- Fixed. -- tobi at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.1.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30478
[Bug c/30794] -Wreturn-type acts differently at -O3
--- Comment #2 from manu at gcc dot gnu dot org 2007-02-15 17:23 --- Why DECL_INLINE is tested? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30794
[Bug fortran/30793] Segfault on calling a function returning a pointer
--- Comment #12 from patchapp at dberlin dot org 2007-02-15 17:25 --- Subject: Bug number PR30793 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-02/msg01366.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30793
[Bug ada/30806] execvp: gcc: Argument list too long
--- Comment #2 from krischik at users dot sourceforge dot net 2007-02-15 17:40 --- Hello Arno, I reported a few similar bugs to the PolyORB team long ago and we found the reason as well: Windows: --- gnat-mingw-gcc-4.2.0.log:checking the maximum length of command line arguments... (cached) 8192 gnat-mingw-gcc-4.2.0.log:finding the maximum length of command line arguments... (cached) 8192 --- SuSE Linux: --- gnat-pro-6.0.0w.log:finding the maximum length of command line arguments... 49153 gnat-pro-6.0.0w.log:finding the maximum length of command line arguments... (cached) 49153 --- ./configure allways makes that check but no one cares. Or better: can care - as I don't know another way to pass the files to the linker. Sitenote: Linux increased from 32k to 48k since I last checked. But personaly I think that ever increasing command lines can't be the answer. You say "WORKSFORME" - So how do you make it work? A shorter path then "gcc-4.2-20070207" to save a few precious bytes? A custom made bash shell (if that is at all possible)? Did you test Windows at all? It is not my aim to upset you with bug reports. Martin -- krischik at users dot sourceforge dot net changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|WORKSFORME | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30806
[Bug ada/30806] execvp: gcc: Argument list too long
--- Comment #3 from charlet at gcc dot gnu dot org 2007-02-15 17:50 --- The command line you quoted is much less than 8192 characters (I count 3744 characters), so I guess your build environment is somehow creating additional limitations, and/or some shell artefact or a bug in make is causing this failure. As I said, not a gcc issue, but a set up issue. Arno -- charlet at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30806
[Bug debug/29558] [4.2/4.3 Regression] ICE in set_variable_part, at var-tracking.c:2140
-- rth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2006-10-23 16:06:32 |2007-02-15 17:50:41 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29558
[Bug preprocessor/15638] gcc should have option to treat missing headers as fatal
--- Comment #9 from pinskia at gcc dot gnu dot org 2007-02-15 17:51 --- *** Bug 30808 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||gcc-bugzilla at seebs dot ||net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15638
[Bug preprocessor/30808] It would probably make sense to abort immediately after a file-not-found.
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-02-15 17:51 --- *** This bug has been marked as a duplicate of 15638 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30808
[Bug fortran/30793] Segfault on calling a function returning a pointer
-- burnus at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |burnus at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2007-02-15 09:45:54 |2007-02-15 18:22:14 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30793
[Bug libstdc++/30449] Missing overloads (specializations) in stl_algobase.h
-- pcarlini at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-02-15 18:43:47 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30449
[Bug c/12603] No return statement warning on function that never returns with -O3
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-02-15 19:30 --- *** Bug 30794 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||ian at airs dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12603
[Bug c/30794] -Wreturn-type acts differently at -O3
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-02-15 19:30 --- *** This bug has been marked as a duplicate of 12603 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30794
[Bug fortran/30799] Inconsistent handling of bad (invalid) LOGICAL kinds
--- Comment #4 from kargl at gcc dot gnu dot org 2007-02-15 19:33 --- Subject: Bug 30799 Author: kargl Date: Thu Feb 15 19:33:13 2007 New Revision: 122012 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122012 Log: 2007-02-15 Steven G. Kargl <[EMAIL PROTECTED]> PR fortran/30799 * primary.c (match_logical_constant): Return MATCH_ERROR on invalid kind. * gfortran.dg/logical_2.f90: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/logical_2.f90 Modified: branches/gcc-4_1-branch/gcc/fortran/ChangeLog branches/gcc-4_1-branch/gcc/fortran/primary.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30799
[Bug fortran/30799] Inconsistent handling of bad (invalid) LOGICAL kinds
--- Comment #5 from kargl at gcc dot gnu dot org 2007-02-15 19:47 --- Fixed on 4.1, 4.2, and trunk. -- kargl at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.1.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30799
[Bug bootstrap/30810] New: top-level BOOT_CFLAGS not being used for bootstrapping
When I pass BOOT_STRAP="-march=athlon -O2" on the command line of make to bootstrap gcc then they are not being used. The flags for bootstrapping always default to "-g -O2". I believe this is due to BOOT_CFLAGS missing in the top-level's Makefile lists for variables to pass on to sub-level Makefiles. Atleast that list does not contain BOOT_CFLAGS so how should this variable get there? This is not specific to 4.1.2. I think I saw this already in 4.1.1. The reason why I need it is because I want to create a profiled bootstrap with a few more optimizations so that an optimised executable will be installed when running "make install". -- Summary: top-level BOOT_CFLAGS not being used for bootstrapping Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: trivial Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sdack at gmx dot de GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30810
[Bug target/19087] Overflowed address in dwarf debug line information
--- Comment #30 from aesok at gcc dot gnu dot org 2007-02-15 20:02 --- Subject: Bug 19087 Author: aesok Date: Thu Feb 15 20:01:59 2007 New Revision: 122013 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122013 Log: PR target/19087 * config/avr/avr.c (DWARF2_ADDR_SIZE): Define. Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/config/avr/avr.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19087
[Bug pending/30773] Spec cpu2k6/h264ref and sphinx3 miscompare regression
--- Comment #3 from steven at gcc dot gnu dot org 2007-02-15 20:06 ---
The third hunk of the patch changes something:
Index: local-alloc.c
===
--- local-alloc.c (revision 121794)
+++ local-alloc.c (working copy)
@@ -1061,9 +1064,8 @@ update_equiv_regs (void)
if (validate_equiv_mem (init_insn, src, dest)
&& ! memref_used_between_p (dest, init_insn, insn))
{
- REG_NOTES (init_insn)
- = gen_rtx_EXPR_LIST (REG_EQUIV, copy_rtx (dest),
-REG_NOTES (init_insn));
+ set_unique_reg_note (init_insn, REG_EQUIV, copy_rtx (dest));
+
/* This insn makes the equivalence, not the one initializing
the register. */
reg_equiv_init[regno]
With this change, we refuse to put a REG_EQUIV note on an insn with more than
one set:
diff -U 12 good/utt.i.157r.lreg broken/utt.i.157r.lreg
--- good/utt.i.157r.lreg2007-02-15 21:07:13.0 +0100
+++ broken/utt.i.157r.lreg 2007-02-15 21:07:42.0 +0100
@@ -938,30 +938,28 @@
(insn:HI 136 135 137 16 (parallel [
(set (reg:SI 100)
(div:SI (reg:SI 98)
(mem/s:SI (plus:SI (reg/v/f:SI 85 [ kb ])
(const_int 8 [0x8])) [9 .nfr+0 S4
A32])))
(set (reg:SI 101)
(mod:SI (reg:SI 98)
(mem/s:SI (plus:SI (reg/v/f:SI 85 [ kb ])
(const_int 8 [0x8])) [9 .nfr+0 S4
A32])))
(clobber (reg:CC 17 flags))
]) 279 {*divmodsi4_nocltd} (insn_list:REG_DEP_TRUE 135 (nil))
-(expr_list:REG_EQUIV (mem:SI (plus:SI (reg/f:SI 7 sp)
-(const_int 12 [0xc])) [0 S4 A32])
-(expr_list:REG_DEAD (reg:SI 98)
-(expr_list:REG_UNUSED (reg:CC 17 flags)
-(expr_list:REG_UNUSED (reg:SI 101)
-(nil))
+(expr_list:REG_DEAD (reg:SI 98)
+(expr_list:REG_UNUSED (reg:CC 17 flags)
+(expr_list:REG_UNUSED (reg:SI 101)
+(nil)
(insn:HI 137 136 138 16 (set (mem:SI (plus:SI (reg/f:SI 7 sp)
(const_int 12 [0xc])) [0 S4 A32])
(reg:SI 100)) 40 {*movsi_1} (insn_list:REG_DEP_TRUE 136 (nil))
(expr_list:REG_DEAD (reg:SI 100)
(nil)))
(insn:HI 138 137 139 16 (set (mem:SI (plus:SI (reg/f:SI 7 sp)
(const_int 8 [0x8])) [0 S4 A32])
(reg:SI 80 [ D.1724 ])) 40 {*movsi_1} (nil)
(expr_list:REG_DEAD (reg:SI 80 [ D.1724 ])
(nil)))
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30773
[Bug target/19087] Overflowed address in dwarf debug line information
--- Comment #31 from aesok at gcc dot gnu dot org 2007-02-15 20:13 --- Fixed in 4.1.3, 4.2.0 and 4.3.0. -- aesok at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19087
[Bug pending/30773] Spec cpu2k6/h264ref and sphinx3 miscompare regression
--- Comment #4 from steven at gcc dot gnu dot org 2007-02-15 20:15 --- NB we don't add the REG_EQUIV note because insn 136 has multiple sets. Such insns can't have REG_EQ* notes according to set_unique_reg_note. But that, I think, is not the bug. More likely is that I exposed a latent bug somewhere... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30773
[Bug c++/30811] New: __FUNCTION__ allowed in function declaration
The manual says __FUNCTION__ is just another name for __func__ but the two
behave slightly differently (the former is not allowed in function declarations
while the latter is). __PRETTY_FUNCTION__ is also allowed but with slightly
different (and, IMO, rather unusual) effects.
I propose that __FUNCTION__ and __PRETTY_FUNCTION__ either be disallowed in
function declarations (just as __func__ is), or that they have the same meaning
as when used in the body of the function.
$ cat z.cpp && g++ z.cpp && ./a.out
extern "C" int puts (const char*);
// void foo (const char *s = __func__) { puts (s); }
void bar (const char *s = __FUNCTION__) { puts (s); }
void baz (const char *s = __PRETTY_FUNCTION__) { puts (s); }
int main () {
// foo ();
bar ();
baz ();
}
top level
--
Summary: __FUNCTION__ allowed in function declaration
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30811
[Bug fortran/25252] ICE on invalid code
--- Comment #5 from kargl at gcc dot gnu dot org 2007-02-15 20:50 --- Does this still fail for others? I can't get the ICE to occur. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25252
[Bug c++/30812] New: enhancement: exception specification in __PRETTY_FUNCTION__
Even though a function's exception specification isn't part of its type (neither is the fact that the function is virtual) it would be useful to include it in __PRETTY_FUNCTION__ (just as virtual is). This is a request for such an enhancement. -- Summary: enhancement: exception specification in __PRETTY_FUNCTION__ Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sebor at roguewave dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30812
[Bug c/30813] New: Numerical error--#define value differs from declared variable value
I've used a #define to set a value, I've set a declared variable to the same
text value and I've set a second declared variable to the #define value. The
declared values are the same, the #define value differs.
If this were a simple round off error, all three values should be the same. As
they are not the same, the #define has a different value. I think the #define
might have access to all of the guard bits in the FPU whereas the declared
values are truncated.
Also, please note, this problem does not happen with gcc 2.9.2 and I'm running
on Red Hat Linux
==
cat prec.c
==
#include
#define VALUE 1e-4
int
main()
{
double v = 1.0;
double a = 1e-4;
double b = VALUE;
printf("a = %e\n", a);
printf("def/var - 1 = %e, var/def - 1 = %e\n", (VALUE*VALUE)/(a*a) - v,
(a*a)/(VALUE*VALUE) - v);
printf("def/var2 - 1 = %e, var2/def - 1 = %e\n", (VALUE*VALUE)/(b*b) - v,
(b*b)/(VALUE*VALUE) - v);
printf("var/var - 1 = %e, def/def - 1 = %e\n", (a*a)/(a*a) - v,
(VALUE*VALUE)/(VALUE*VALUE) - v);
printf("var2/var1 - 1 = %e, var2/var2 - 1 = %e\n", (b*b)/(a*a) - v,
(b*b)/(b*b) - v);
}
$ gcc prec.c
$ ./a.out
a = 1.00e-04
def/var - 1 = -7.486416e-17, var/def - 1 = 7.491837e-17
def/var2 - 1 = -7.486416e-17, var2/def - 1 = 7.491837e-17
var/var - 1 = 0.00e+00, def/def - 1 = 0.00e+00
var2/var1 - 1 = 0.00e+00, var2/var2 - 1 = 0.00e+00
$
--
Summary: Numerical error--#define value differs from declared
variable value
Product: gcc
Version: 3.4.5
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kevin dot glass at pnl dot gov
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30813
[Bug c++/30811] __FUNCTION__ allowed in function declaration
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-02-15 21:17 --- Do you know the status of the C++0x paper about this C99 "extension"? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30811
[Bug target/30813] Numerical error--#define value differs from declared variable value
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-02-15 21:23 --- This works correctly on powerpc-linux-gnu. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30813
[Bug target/30813] Numerical error--#define value differs from declared variable value
--- Comment #2 from kevin dot glass at pnl dot gov 2007-02-15 21:26 --- Subject: RE: Numerical error--#define value differs from declared variable value I ran on a 64-bit Itanium running Red Hat linux, I'm not sure which version. -Original Message- From: pinskia at gcc dot gnu dot org [mailto:[EMAIL PROTECTED] Sent: Thursday, February 15, 2007 1:24 PM To: Glass, Kevin A Subject: [Bug target/30813] Numerical error--#define value differs from declared variable value --- Comment #1 from pinskia at gcc dot gnu dot org 2007-02-15 21:23 --- This works correctly on powerpc-linux-gnu. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30813
[Bug bootstrap/30810] top-level BOOT_CFLAGS not being used for bootstrapping
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-02-15 21:28 --- You mentioned BOOT_STRAP in your comment is that correct? Also did you use "make bootstrap" and not just a plain make? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30810
[Bug c++/30811] __FUNCTION__ allowed in function declaration
--- Comment #2 from sebor at roguewave dot com 2007-02-15 21:29 --- No, I'm not aware of any such paper. AFAIK, neither __FUNCTION__ nor __PRETTY_FUNCTION__ is specified by either C or C++, or proposed for inclusion either of them (I could be wrong). They're gcc extensions, aren't they? I'm suggesting that __FUNCTION__ either behave the way it's documented (i.e., just as C99 __func__ does) or, since it is an extension, that it be extended further. Similarly for __PRETTY_FUNCTION__. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30811
[Bug middle-end/30768] [4.3 regression]: ICE in ext/pb_ds/regression/list_update_data_map_rand.cc
--- Comment #20 from hp at gcc dot gnu dot org 2007-02-15 21:43 ---
In reply to comment #19, it's because the dg-bogus test trigs for that target;
it hits the ICE. As Mark didn't see the fail when testing, and noone else
complained, I originally thought only cris-*-* and perhaps one or two other
targets were affected, but it seems rather universal. The dg-bogus lines
aren't target-specific; there'd have to be both a "target" and "xfail" for that
to work, and you can only have either one of them.
If you insist that you want to see just the single "original" FAIL for "excess
errors" (with has no further explanation or the note of an open PR it has now),
I can change the test to just be skipped for cris-*-* and you'll see no change
for other targets compared to when the ICE first appeared, as in this PR's
"Description". Alternatives would be to add targets to the xfail list or
remove it (defaulting to *-*-*) or change to { target { ! } }, but that
can quickly get messy.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30768
[Bug fortran/25252] ICE on invalid code
--- Comment #6 from dominiq at lps dot ens dot fr 2007-02-15 21:43 --- I have the ICE pr25252.f90:6.46: MODULE PROCEDURE sreal, schar, sint => sreal 1 Error: Syntax error in MODULE PROCEDURE statement at (1) pr25252.f90:0: 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. with Using built-in specs. Target: i386-pc-linux-gnu Configured with: /home/fxcoudert/gfortran_nightbuild/trunk/configure --prefix=/home/fxcoudert/gfortran_nightbuild/irun-20070209 --enable-languages=c,fortran --host=i386-pc-linux-gnu --enable-checking=release --with-gmp=/home/fxcoudert/gfortran_nightbuild/software Thread model: posix gcc version 4.3.0 20070209 (experimental) but not with Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ../gcc/configure --prefix=/var/tmp/gfortran-20061231/irun --enable-languages=c,fortran --with-gmp=/var/tmp/gfortran-20061231/gfortran_libs Thread model: posix gcc version 4.3.0 20061231 (experimental) nor with Using built-in specs. Target: powerpc-apple-darwin7 Configured with: ../gcc-4.3-20070210/configure --prefix=/sw --prefix=/sw/lib/gcc4 --disable-multilib --enable-languages=c,c++,fortran,objc,java --infodir=/sw/lib/gcc4/share/info --with-gmp=/sw --with-included-gettext --build=powerpc-apple-darwin7 --host=powerpc-apple-darwin7 --with-as=/sw/lib/odcctools/bin/as --with-ld=/sw/lib/odcctools/bin/ld --with-nm=/sw/lib/odcctools/bin/nm --with-ar=/sw/lib/odcctools/bin/ar --with-strip=/sw/lib/odcctools/bin/strip --with-ranlib=/sw/lib/odcctools/bin/ranlib Thread model: posix gcc version 4.3.0 20070209 (experimental) and Using built-in specs. Target: powerpc-apple-darwin8 Configured with: ../gcc-4.2-20070124/configure --prefix=/sw --prefix=/sw/lib/gcc4.2 --mandir=/sw/share/man --infodir=/sw/share/info --enable-languages=c,c++,fortran,objc,java --host=powerpc-apple-darwin8 --with-as=/sw/lib/odcctools/bin/as --with-ld=/sw/lib/odcctools/bin/ld --with-nm=/sw/lib/odcctools/bin/nm --with-gmp=/sw --with-libiconv-prefix=/sw --with-system-zlib --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib Thread model: posix gcc version 4.2.0 20070124 (prerelease) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25252
[Bug ada/30806] execvp: gcc: Argument list too long
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-02-15 21:48 --- Just a quick note here, the argument list is way below the max of 8k. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30806
[Bug c++/28943] Unusable error message when using a conditional-expression with multiple type arguments
--- Comment #8 from manu at gcc dot gnu dot org 2007-02-15 22:15 --- Subject: Bug 28943 Author: manu Date: Thu Feb 15 22:15:20 2007 New Revision: 122016 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122016 Log: 2007-02-15 Manuel Lopez-Ibanez <[EMAIL PROTECTED]> PR c++/28943 cp/ * call.c (build_conditional_expr): Improve error message. testsuite/ * g++.dg/warn/pr28943.C: New. Added: trunk/gcc/testsuite/g++.dg/warn/pr28943.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28943
[Bug c/26494] -pedantic-errors can be overridden by -W*
--- Comment #9 from manu at gcc dot gnu dot org 2007-02-15 22:31 --- Subject: Bug 26494 Author: manu Date: Thu Feb 15 22:31:17 2007 New Revision: 122017 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122017 Log: 2007-02-15 Manuel Lopez-Ibanez <[EMAIL PROTECTED]> PR c/26494 * doc/invoke.texi (Warning Options): Remove -Werror-implicit-function-declaration. (Wimplicit-function-declaration): Update description. * opts.c (common_handle_option): Move handling of -Werror=* to... (enable_warning_as_error): ...here. * opts.h (enable_warning_as_error): Declare. * c-decl.c (implicit_decl_warning): Unless -Wno-implicit-function-declaration is given, emit a pedwarn if -std=c99 or emit a warning if -Wimplicit-function-declaration. * c.opt (Wimplicit-function-declaration): Replace mesg_implicit_function_declaration with warn_implicit_function_declaration. * c-opts.c (c_common_handle_option): -Werror-implicit-function-declaration is exactly equal as -Werror=implicit-function-declaration. (set_Wimplicit): Replace mesg_implicit_function_declaration with warn_implicit_function_declaration. (c_common_post_options): -Wimplict-function-declaration is enabled by default by -std=c99, otherwise is disabled by default. * c-objc-common.c (c_objc_common_init): Remove flawed logic. testsuite/ * gcc.dg/Wimplicit-function-declaration-c89.c: New. * gcc.dg/Wimplicit-function-declaration-c89-default.c: New. * gcc.dg/Wimplicit-function-declaration-c89-pedantic.c: New. * gcc.dg/Wimplicit-function-declaration-c99.c: New. * gcc.dg/Wimplicit-function-declaration-c99-pedantic.c: New. * gcc.dg/Werror-implicit-function-declaration.c: New. Added: trunk/gcc/testsuite/gcc.dg/Werror-implicit-function-declaration.c trunk/gcc/testsuite/gcc.dg/Wimplicit-function-declaration-c89-default.c trunk/gcc/testsuite/gcc.dg/Wimplicit-function-declaration-c89-pedantic.c trunk/gcc/testsuite/gcc.dg/Wimplicit-function-declaration-c89.c trunk/gcc/testsuite/gcc.dg/Wimplicit-function-declaration-c99-pedantic.c trunk/gcc/testsuite/gcc.dg/Wimplicit-function-declaration-c99.c Modified: trunk/gcc/ChangeLog trunk/gcc/c-decl.c trunk/gcc/c-objc-common.c trunk/gcc/c-opts.c trunk/gcc/c.opt trunk/gcc/doc/invoke.texi trunk/gcc/opts.c trunk/gcc/opts.h trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26494
[Bug c/26494] -pedantic-errors can be overridden by -W*
--- Comment #10 from manu at gcc dot gnu dot org 2007-02-15 22:33 --- Fixed in GCC 4.3 -- manu at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26494
[Bug c++/28943] Unusable error message when using a conditional-expression with multiple type arguments
--- Comment #9 from manu at gcc dot gnu dot org 2007-02-15 22:35 --- Fixed in GCC 4.3 -- manu at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28943
[Bug c++/30811] __FUNCTION__ allowed in function declaration
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-02-15 22:54 --- IIRC __FUNCTION__ is really __func__ defined by the C99 standard. So is __func__ allowed as a default argument in the C++0x? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30811
[Bug c++/30811] __FUNCTION__ allowed in function declaration
--- Comment #4 from sebor at roguewave dot com 2007-02-15 23:06 --- The wording proposed in N1970 for the C++ __func__ indentifier reads: -1- The identifier __func__ shall be implicitly declared by the translator as if, immediately following the opening brace of each function definition, the declaration static const char __func__[] = "function-name"; appeared, where function-name is the unqualified name of the lexically enclosing function. See http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1970.htm. Based on this __func__ would not be defined in a function declaration (except as an extension). Since the gcc __FUNCTION__ extension does not behave the same way as the C99 __func__ indentifier (i.e., it is defined in a function declaration, albeit to the empty string), it might be possible to extend it and make it defined "earlier," i.e., even before the opening curly brace. Another option, of course, is to undefine it and make it exactly the same as __func__. I see more value in doing the former than the latter. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30811
[Bug tree-optimization/30735] 50% slow down due to mem-ssa merge
--- Comment #5 from pthaugen at us dot ibm dot com 2007-02-15 23:36 --- Seeing similar behavior on PPC for CPU2000. Comparing revisions 119759 and 119760, 179.art degrades 24% and 200.sixtrack degrades 50%. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30735
[Bug fortran/30814] New: non-conforming array sizes in assignment using pack not caught
Hi All Using the command line: gfortran -fbounds-check test.f95, I compiled this: program test integer :: it, neighbrs(var) neighbrs = pack( (/ ( it, it=1, 30 ) /), (/ ( it, it=1, 30 ) /) < 3, (/ ( 0, it=1, 30 ) /) ) end program test substituting different values for var to get different results. When var is not chosen well, the non-conforming sizes of the array asignment are not caught as errors. Sometimes at running glibc catches errors. Examples - all of these should fail with incorrect array sizes, but they don't: if var=18 *** glibc detected *** ./a.out: free(): invalid next size (fast): 0x00508460 *** (plus a whole lot of other guff. let me know if you want to see that) if var=19 *** glibc detected *** ./a.out: double free or corruption (out): 0x00508460 *** if var = 27 it compiles and runs without error Thanks, Gareth -- Summary: non-conforming array sizes in assignment using pack not caught Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: glv at maths dot otago dot ac dot nz GCC build triplet: x86_64-redhat-linux GCC host triplet: x86_64-redhat-linux GCC target triplet: x86_64-redhat-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30814
[Bug rtl-optimization/30815] New: [4.3 Regression] pr29965.c fails on the mainline, switches and __builtin_trap
Reduced testcase without OpenMP:
int f(unsigned section1)
{
switch (section1)
{
case 1: for(;;);
default : __builtin_trap ();
}
}
--
Summary: [4.3 Regression] pr29965.c fails on the mainline,
switches and __builtin_trap
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
GCC target triplet: powerpc*-*-*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30815
[Bug rtl-optimization/30815] [4.3 Regression] pr29965.c fails on the mainline, switches and __builtin_trap
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-02-16 00:37 --- Oh, the ICE I get is: t.c:8: error: fallthru edge after unconditional jump 2 t.c:8: error: wrong amount of branch edges after unconditional jump 2 t.c:8: error: verify_flow_info: Incorrect fallthru 2->3 t.c:8: error: wrong insn in the fallthru edge (barrier 42 41 12) t.c:8: internal compiler error: in rtl_verify_flow_info, at cfgrtl.c:2005 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30815
[Bug pending/30773] Spec cpu2k6/h264ref and sphinx3 miscompare regression
--- Comment #5 from ian at airs dot com 2007-02-16 00:38 ---
I believe this is also related to the failure of gcc.c-torture/execute/simd-1.c
on i686-pc-linux-gnu at -O1 and above.
I think the problem is that we fail to add a REG_EQUIV note here in
local-alloc.c:
if (REG_N_SETS (regno) == 1
&& note && ! rtx_varies_p (XEXP (note, 0), 0))
{
rtx note_value = XEXP (note, 0);
remove_note (insn, note);
set_unique_reg_note (insn, REG_EQUIV, note_value);
}
because the insn looks like this:
(insn 213 211 214 2
/home/iant/gcc/trunk/gcc/testsuite/gcc.c-torture/execute/simd-1.c:44 (parallel
[
(set (reg:SI 195)
(div:SI (reg:SI 174 [ i+8 ])
(mem/j/c/i:SI (plus:SI (reg/f:SI 20 frame)
(const_int -232 [0xff18])) [0 j.64+8 S4 A32])))
(set (reg:SI 196)
(mod:SI (reg:SI 174 [ i+8 ])
(mem/j/c/i:SI (plus:SI (reg/f:SI 20 frame)
(const_int -232 [0xff18])) [0 j.64+8 S4 A32])))
(clobber (reg:CC 17 flags))
]) 193 {*divmodsi4_nocltd} (nil)
(expr_list:REG_DEAD (reg:SI 174 [ i+8 ])
(expr_list:REG_UNUSED (reg:CC 17 flags)
(expr_list:REG_UNUSED (reg:SI 196)
(nil)
(i.e., has two SETs).
That means that in this code:
if (MEM_P (dest) && REG_P (src)
&& (regno = REGNO (src)) >= FIRST_PSEUDO_REGISTER
&& REG_BASIC_BLOCK (regno) >= 0
&& REG_N_SETS (regno) == 1
&& reg_equiv[regno].init_insns != 0
&& reg_equiv[regno].init_insns != const0_rtx
&& ! find_reg_note (XEXP (reg_equiv[regno].init_insns, 0),
REG_EQUIV, NULL_RTX)
&& ! contains_replace_regs (XEXP (dest, 0)))
the ! find_reg_note test fails where it used to succeed. That causes us to set
reg_equiv_init to an inappropriate insn, which we later delete during reload.
--
ian at airs dot com changed:
What|Removed |Added
CC||ian at airs dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30773
[Bug middle-end/30729] [4.1/4.2/4.3 Regression] value computed is not used warning with unused result of va_arg
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-02-16 01:19 --- Subject: Bug 30729 Author: pinskia Date: Fri Feb 16 01:19:23 2007 New Revision: 122027 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122027 Log: 2007-02-15 Andrew Pinski <[EMAIL PROTECTED]> PR middle-end/30729 * stmt.c (warn_if_unused_value): VA_ARG_EXPR has side effects unknown to this function, return early. 2007-02-15 Andrew Pinski <[EMAIL PROTECTED]> PR middle-end/30729 * gcc.dg/Wunused-value-2.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/Wunused-value-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/stmt.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30729
[Bug middle-end/30729] [4.1/4.2 Regression] value computed is not used warning with unused result of va_arg
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-02-16 01:20 --- Fixed on the trunk, will apply to the other branches later. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.1/4.2/4.3 Regression]|[4.1/4.2 Regression] value |value computed is not used |computed is not used warning |warning with unused result |with unused result of va_arg |of va_arg | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30729
[Bug middle-end/30816] New: gfortran.dg/g77/intrinsic-unix-erf.f tests fail with optimization
The testcase started to fail recently, I'm not sure if this points to a bug in gcc or mpfr. CCing Kaveh, as it's probably one of his mpfr patches that caused this. Here's a debug run: tobias-schluters-computer:~/src/dev tobi$ uname -a Darwin tobias-schluters-computer.local 8.8.3 Darwin Kernel Version 8.8.3: Wed Oct 18 21:57:10 PDT 2006; root:xnu-792.15.4.obj~4/RELEASE_I386 i386 i386 tobias-schluters-computer:~/src/dev tobi$ gdb ../pristine/build/gcc/f951 GNU gdb 6.3.50-20050815 (Apple version gdb-563) (Wed Jul 19 05:10:58 GMT 2006) Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-apple-darwin"...Reading symbols for shared lib aries . done (gdb) run intrinsic-unix-erf.f -O Starting program: /Users/tobi/src/pristine/build/gcc/f951 intrinsic-unix-erf.f O Reading symbols for shared libraries ..+++ done MAIN__ failure c_r c_d Analyzing compilation unit Performing interprocedural optimizations init2.c:51: assertion failed: p >= 2 && p = ((mpfr_prec_t)((mpfr_prec_t)(~(mpfr_prec_t)0)>>1)) Program received signal SIGABRT, Aborted. 0x9003d1dc in kill () (gdb) bt #0 0x9003d1dc in kill () #1 0x9010f2af in raise () #2 0x9010de02 in abort () #3 0x4233eb70 in mpfr_assert_fail (filename=0x42348c60 "init2.c", linenum=51, xpr=0x42348a9c "p >= 2 && p <= ((mpfr_prec_t)((mpfr_prec_t)(~(mpfr_prec_t)0)>>1 )") at mpfr-gmp.c:305 #4 0x42337d75 in mpfr_init2 (x=0xb1f0, p=2147483685) at init2.c:51 #5 0x4233d218 in mpfr_erf (y=0xb25c, x=0xb25c, rnd_mode=GMP_RNDN) at e f.c:130 (gdb) -- Summary: gfortran.dg/g77/intrinsic-unix-erf.f tests fail with optimization Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tobi at gcc dot gnu dot org GCC host triplet: darwin-i386 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30816
[Bug c++/30158] [4.0/4.1/4.2/4.3 regression] ICE with invalid statement-expressions
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-02-16 01:23 --- Subject: Bug 30158 Author: pinskia Date: Fri Feb 16 01:23:35 2007 New Revision: 122028 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122028 Log: 2007-02-15 Andrew Pinski <[EMAIL PROTECTED]> PR C++/30158 * semantics.c (finish_stmt_expr_expr): Set TREE_TYPE of the statement expression if we had an error mark node. 2007-02-15 Andrew Pinski <[EMAIL PROTECTED]> PR C++/30158 * g++.dg/ext/stmtexpr10.C: New testcase. Added: trunk/gcc/testsuite/g++.dg/ext/stmtexpr10.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/semantics.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30158
[Bug c++/30158] [4.0/4.1/4.2 regression] ICE with invalid statement-expressions
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-02-16 01:24 --- Fixed on the trunk, might apply later next week to the other branches. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Known to work|3.4.0 |3.4.0 4.3.0 Summary|[4.0/4.1/4.2/4.3 regression]|[4.0/4.1/4.2 regression] ICE |ICE with invalid statement- |with invalid statement- |expressions |expressions http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30158
[Bug middle-end/30816] gfortran.dg/g77/intrinsic-unix-erf.f tests fail with optimization
--- Comment #1 from tobi at gcc dot gnu dot org 2007-02-16 01:25 --- My mpfr is version 2.2.1 as distributed by fink. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30816
[Bug middle-end/30433] [4.1/4.2/4.3 Regression] no longer folding __complex__(0.0, 1.0) == __complex__(1.0, 0.0)
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-02-16 01:27 --- Subject: Bug 30433 Author: pinskia Date: Fri Feb 16 01:27:42 2007 New Revision: 122029 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122029 Log: 2007-02-15 Andrew Pinski <[EMAIL PROTECTED]> PR middle-end/30433 * fold-const.c (fold_comparison): Add back the folding of constant complex comparisions. 2007-02-15 Andrew Pinski <[EMAIL PROTECTED]> PR middle-end/30433 * gcc.c-torture/compile/pr30433.c: New testcase to check that complex constants comparisions are foldded. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr30433.c Modified: trunk/gcc/ChangeLog trunk/gcc/fold-const.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30433
[Bug middle-end/30433] [4.1/4.2 Regression] no longer folding __complex__(0.0, 1.0) == __complex__(1.0, 0.0)
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-02-16 01:28 --- Fixed on the trunk will apply to the branches next week. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Known to work|4.0.4 |4.0.4 4.3.0 Summary|[4.1/4.2/4.3 Regression] no |[4.1/4.2 Regression] no |longer folding |longer folding |__complex__(0.0, 1.0) ==|__complex__(0.0, 1.0) == |__complex__(1.0, 0.0) |__complex__(1.0, 0.0) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30433
[Bug rtl-optimization/30773] [4.3 Regression] Spec cpu2k6/h264ref and sphinx3 miscompare regression
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|pending |rtl-optimization Summary|Spec cpu2k6/h264ref and |[4.3 Regression] Spec |sphinx3 miscompare |cpu2k6/h264ref and sphinx3 |regression |miscompare regression Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30773
[Bug middle-end/30816] gfortran.dg/g77/intrinsic-unix-erf.f tests fail with optimization
--- Comment #2 from tobi at gcc dot gnu dot org 2007-02-16 01:30 --- One more thing: I'm fairly sure the bug didn't appear with r118042 where erf handling via mpfr was introduced. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30816
[Bug preprocessor/30805] [4.1/4.2/4.3 Regression] Internal compiler error when using "x##,##__VA_ARGS__" in macro
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-02-16 01:34 --- 3.0.4 and 2.95.3 did not ICE on this. Confirmed a regression. I don't know if this is valid or not. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Known to fail||3.3.3 4.1.2 4.2.0 4.0.4 Known to work||3.0.4 2.95.3 Last reconfirmed|-00-00 00:00:00 |2007-02-16 01:34:25 date|| Summary|Internal compiler error when|[4.1/4.2/4.3 Regression] |using "x##,##__VA_ARGS__" in|Internal compiler error when |macro |using "x##,##__VA_ARGS__" in ||macro Target Milestone|--- |4.1.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30805
[Bug other/30809] make install fails due to erroneous nesting of echo commands
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-02-16 01:36 --- Usually you set CONFIG_SHELL to a different shell as /bin/sh on solaris is not a POSIX compatiable shell. See http://gcc.gnu.org/install/specific.html#x-x-solaris2 . -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30809
[Bug bootstrap/30810] top-level BOOT_CFLAGS not being used for bootstrapping
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-02-16 01:48 --- >I believe this is due to BOOT_CFLAGS missing in the top-level's Makefile lists They are passed down, see EXTRA_GCC_FLAGS. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|trivial |normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30810
[Bug middle-end/30768] [4.3 regression]: ICE in ext/pb_ds/regression/list_update_data_map_rand.cc
--- Comment #21 from pinskia at gcc dot gnu dot org 2007-02-16 01:49 --- I am still reducing this source. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30768
[Bug c/30762] [4.2/4.3 Regression] IMA messes up with inlining
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|major |normal Summary|[4.2/4.3 Regression]|[4.2/4.3 Regression] IMA |inlining destroys type |messes up with inlining |information | Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30762
[Bug tree-optimization/30771] [4.3 Regression] ice for legal code with -O2 -ftree-vectorize
--- Comment #7 from pinskia at gcc dot gnu dot org 2007-02-16 01:58 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Summary|ice for legal code with -O2 |[4.3 Regression] ice for |-ftree-vectorize|legal code with -O2 -ftree- ||vectorize Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30771
[Bug testsuite/30777] testsuite/gcc.target/i386/abi-1.c failure on openSolaris
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-02-16 02:00 --- If it fails, then the ABI for x86 solaris is different from almost all other x86 targets. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30777
[Bug target/30770] [4.3 regression] BOOT_CFLAGS="-O2 -g -mtune=nocona" miscompiled the stage 3 compiler
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.3 regression]: |[4.3 regression] |BOOT_CFLAGS="-O2 -g - |BOOT_CFLAGS="-O2 -g - |mtune=nocona" miscompiled |mtune=nocona" miscompiled |the stage 3 compiler|the stage 3 compiler Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30770
[Bug target/30778] [4.3 Regression] invalid code generation for memset() with -mtune=k8
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |critical http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30778
[Bug preprocessor/30786] [4.1/4.2/4.3 Regression] ICE on _Pragma at end of file
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Keywords||ice-on-invalid-code Known to fail||3.4.0 4.0.3 4.1.0 4.2.0 Known to work||3.3.3 Summary|ICE on _Pragma at end of|[4.1/4.2/4.3 Regression] ICE |file|on _Pragma at end of file Target Milestone|--- |4.1.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30786
[Bug bootstrap/30790] [4.3 regression] Bootstrap comparison failure i386:
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||30770, 30778 Keywords||build Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30790
[Bug tree-optimization/30791] Need to run may-alias early in IPA
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-02-16 02:06 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||missed-optimization Last reconfirmed|-00-00 00:00:00 |2007-02-16 02:06:58 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30791
[Bug c++/30797] Failure to build Cinelerra 2.1
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-02-16 02:32 --- You might want to start thinking to update the prerelease of the compiler, it is a couple months old now. THis works for me on the trunk and in 4.1.1. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30797
[Bug fortran/29975] [meta-bugs] ICEs with CP2K
--- Comment #64 from jvdelisle at gcc dot gnu dot org 2007-02-16 02:50 --- I now have a machine at home here running i686-pc-gnu-linux that I plan to set up daily compile test on. Joost, does that link in coment #63 get updated daily? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29975
[Bug middle-end/30391] [4.3 regression] ICE at -O1 with conditional expressions and GIMPLE_MODIFY_STMT
--- Comment #10 from sayle at gcc dot gnu dot org 2007-02-16 03:38 --- Subject: Bug 30391 Author: sayle Date: Fri Feb 16 03:38:22 2007 New Revision: 122030 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122030 Log: PR middle-end/30391 * tree.c (expr_align): Handle MODIFY_EXPR. GIMPLE_MODIFY_STMT should be unreachable. (build2_stat): Allow construction of MODIFY_EXPR at any time. For the time being redirect GIMPLE_MODIFY_STMT to the new (renamed) build_gimple_modify_stmt_stat. (build2_gimple_stat): Rename to... (build_gimple_modify_stmt_stat): Now longer take a CODE argument. Always build a GIMPLE_MODIFY_STMT node. * tree.h (build2_gimple, build2_gimple_stat): Delete. (build_gimple_modify_stmt, build_gimple_modify_stmt_stat): New declarations. * tree-cfg.c (factor_computed_gotos, tree_merge_blocks, gimplify_val): Use build_gimple_modify_stmt instead of build2_gimple. * tree-complex.c (set_component_ssa_name, expand_complex_move, expand_complex_div_wide): Likewise. * tree-ssa-dom.c (record_equivalences_from_stmt): Likewise. * tree-ssa-loop-im.c (schedule_sm): Likewise. * tree-ssa-loop-ivopts.c (rewrite_use_nonlinear_expr): Likewise. * tree-ssa-loop-manip.c (create_iv): Likewise. * tree-ssa-phiopt.c (conditional_replacement, minmax_replacement, abs_replacement): Likewise. * tree-ssa-pre.c (create_expression_by_pieces, poolify_modify_stmt, realify_fake_stores): Likewise. * builtins.c (std_expand_builtin_va_start): Build a MODIFY_EXPR node rather than a GIMPLE_MODIFY_STMT node. (std_gimpify_va_arg_expr, expand_builtin_va_copy, fold_builtin_memset, fold_builtin_memory_op, do_mpfr_sincos): Likewise. (integer_valued_real_p): Handle MODIFY_EXPR, not GIMPLE_MODIFY_STMT. * expr.c (expand_expr_real_1): Handle both MODIFY_EXPR and GIMPLE_MODIFY_STMT. * gfortran.dg/pr30391-1.f90: New test case. Added: trunk/gcc/testsuite/gfortran.dg/pr30391-1.f90 Modified: trunk/gcc/ChangeLog trunk/gcc/builtins.c trunk/gcc/expr.c trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-cfg.c trunk/gcc/tree-complex.c trunk/gcc/tree-ssa-dom.c trunk/gcc/tree-ssa-loop-im.c trunk/gcc/tree-ssa-loop-ivopts.c trunk/gcc/tree-ssa-loop-manip.c trunk/gcc/tree-ssa-phiopt.c trunk/gcc/tree-ssa-pre.c trunk/gcc/tree.c trunk/gcc/tree.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30391
[Bug middle-end/30816] gfortran.dg/g77/intrinsic-unix-erf.f tests fail with optimization
--- Comment #3 from ghazi at gcc dot gnu dot org 2007-02-16 03:44 --- I'll try to help but I don't think this has anything to do with my patches. Fortran was using mpfr for evaluating intrinsics way before I touched anything, and I believe it uses it's own historical mechanism from it's frontend for accessing mpfr, unrelated to the middle-end builtins which I added. Some thoughts: 1. I don't see the error on sparc-sun-solaris2.10 (as of yesterday), and I can't find any other recent testresults that have the problem besides ppc-darwin. It may be darwin-specific. 2. Please include a longer backtrace. This will help answer whether mpfr_erf is called from the middle end (my stuff) or from the fortran frontend. 3. I'm suspicious about the mpfr you grabbed. Try building mpfr yourself from source and run it's testsuite to make sure it's healthy. Then link gcc with that and retry. I seem to recall Geoff had some problems on the darwin regression tester and had to build mpfr using cpu type "none". My memory of this is kind of foggy from many months ago. So I'm not sure really, but a miscompiled mpfr would be my first guess. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30816
[Bug middle-end/30816] gfortran.dg/g77/intrinsic-unix-erf.f tests fail with optimization
--- Comment #4 from kargl at gcc dot gnu dot org 2007-02-16 03:53 ---
(In reply to comment #3)
> I'll try to help but I don't think this has anything to do with my patches.
> Fortran was using mpfr for evaluating intrinsics way before I touched
> anything,
> and I believe it uses it's own historical mechanism from it's frontend for
> accessing mpfr, unrelated to the middle-end builtins which I added.
gfortran doesn't constant fold erf. This is due to your patch and
the fact that Tobi is using darwin.
> 1. I don't see the error on sparc-sun-solaris2.10 (as of yesterday), and I
> can't find any other recent testresults that have the problem besides
> ppc-darwin. It may be darwin-specific.
This is my best guess. Consider
program j
x = erf(1.5)
end program j
With a 4.2 gfortran prior to your patches, -fdump-tree-original gives
MAIN__ ()
{
real4 x;
_gfortran_set_std (70, 127, 0);
x = __builtin_erff (1.5e+0);
}
With a fairly up to date trunk with your patch, I get
MAIN__ ()
{
real4 x;
_gfortran_set_std (70, 127, 0, 0);
x = 9.66105163097381591796875e-1;
}
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
CC||kargl at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30816
[Bug middle-end/30816] gfortran.dg/g77/intrinsic-unix-erf.f tests fail with optimization
--- Comment #5 from ghazi at gcc dot gnu dot org 2007-02-16 05:08 --- (In reply to comment #3) > 3. I'm suspicious about the mpfr you grabbed. Try building mpfr yourself > from > source and run it's testsuite to make sure it's healthy. Then link gcc with > that and retry. I seem to recall Geoff had some problems on the darwin > regression tester and had to build mpfr using cpu type "none". My memory of > this is kind of foggy from many months ago. So I'm not sure really, but a > miscompiled mpfr would be my first guess. Here's the old message I recalled: http://gcc.gnu.org/ml/gcc/2006-10/msg00640.html it says you have to configure GMP with --host=none-apple-darwin I assume you should do the same configure flag with MPFR. What version of GMP are you using and where did you get it? You may have a buggy GMP or MPFR, not sure which. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30816
[Bug middle-end/30816] gfortran.dg/g77/intrinsic-unix-erf.f tests fail with optimization
--- Comment #6 from ghazi at gcc dot gnu dot org 2007-02-16 05:16 ---
(In reply to comment #4)
> [...] It may be darwin-specific.
> This is my best guess. Consider
> program j
> x = erf(1.5)
> end program j
> With a 4.2 gfortran prior to your patches, -fdump-tree-original gives
> MAIN__ ()
> {
> real4 x;
> _gfortran_set_std (70, 127, 0);
> x = __builtin_erff (1.5e+0);
> }
> With a fairly up to date trunk with your patch, I get
> MAIN__ ()
> {
> real4 x;
> _gfortran_set_std (70, 127, 0, 0);
> x = 9.66105163097381591796875e-1;
> }
Okay, actually I'm pleased to know that fortran uses the generic middle-end
builtins infrastructure. Anyway, looks like it works for you (and me) so I
agree it's likely darwin specific and I'm still of the opinion it's not a
darwin GCC bug, but rather a buggy build of GMP and/or MPFR on Tobi's darwin
box. What say you Tobi, can you confirm either way?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30816
[Bug rtl-optimization/30773] [4.3 Regression] Spec cpu2k6/h264ref and sphinx3 miscompare regression
--- Comment #6 from steven at gcc dot gnu dot org 2007-02-16 05:26 ---
What Ian said is probably right, and the patch below should fix it. I haven't
tried it yet, though...
Index: local-alloc.c
===
--- local-alloc.c (revision 122011)
+++ local-alloc.c (working copy)
@@ -1064,12 +1064,16 @@ update_equiv_regs (void)
if (validate_equiv_mem (init_insn, src, dest)
&& ! memref_used_between_p (dest, init_insn, insn))
{
- set_unique_reg_note (init_insn, REG_EQUIV, copy_rtx (dest));
-
- /* This insn makes the equivalence, not the one initializing
-the register. */
- reg_equiv_init[regno]
- = gen_rtx_INSN_LIST (VOIDmode, insn, NULL_RTX);
+ /* Try to set a REG_EQUIV note. This may fail if init_insn
+has multiple sets. */
+ if (set_unique_reg_note (init_insn, REG_EQUIV,
+ copy_rtx (dest)))
+ {
+ /* This insn makes the equivalence, not the one initializing
+the register. */
+ reg_equiv_init[regno]
+ = gen_rtx_INSN_LIST (VOIDmode, insn, NULL_RTX);
+ }
}
}
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30773
[Bug fortran/29975] [meta-bugs] ICEs with CP2K
--- Comment #65 from jv244 at cam dot ac dot uk 2007-02-16 05:57 --- (In reply to comment #64) > I now have a machine at home here running i686-pc-gnu-linux that I plan to set > up daily compile test on. Joost, does that link in coment #63 get updated > daily? > No, the idea is that you want to do the testing on a fixed version of CP2K, i.e. that it is sure that any failure you might observe is due to a change in the compiler, and not because we messed up CP2K (which also happens). You'll certainly get the majority of regressions wrt CP2K this way. I also suggest that this tarbal is kept available elsewhere, since it is on a tmp part of the webserver. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29975
[Bug target/30769] compile error / segmentation fault / 64bit compiler
--- Comment #10 from ebotcazou at gcc dot gnu dot org 2007-02-16 06:12 --- Fixed in 4.1.2 and later. Note that you don't need -fno-strict-aliasing with -O, it's the default. You don't need -mcpu=v9 -m64 -Wa,-xarch=v9 either, it's also the default. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30769
