[Bug fortran/37821] gfortran is ignoring #includes with the syntax file.h
--- Comment #2 from kargl at gcc dot gnu dot org 2008-10-14 06:26 --- Is there a problem with using the standard conforming INCLUDE statement? You forgot to include a small test case. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37821
[Bug target/37809] [4.2/4.3/4.4 Regression] Incorrect code with MMX right shift __builtin_ia32_psradi
--- Comment #4 from suckfish at ihug dot co dot nz 2008-10-14 07:17 ---
Digging a bit, in combine.c, the ASHIFTRT case of force_to_mode() contains two
calls to simplify_shift_const(). Disabling those for vector modes fixes the
test case here (patch below).
But I suspect this is just the tip of the iceberg; there are probably many
other arithmetic simplifications here that will get incorrectly applied to
vector types, especially when sizeof(vector type) = sizeof (HOST_WIDE_INT).
Do we need to audit the whole compiler for such things, or is there a sensible
place we can insert a don't-optimise-vector-types test with disabling too many
useful optimisations?
Thinking that the test-suite probably contains many more tests for 128 bit
vector types, would it be possible/worth-while to build a compiler run the
test-suite with HOST_WIDE_INT being 128 bits?
diff --git a/gcc/combine.c b/gcc/combine.c
index 5821301..ad24d94 100644
--- a/gcc/combine.c
+++ b/gcc/combine.c
@@ -7635,7 +7635,8 @@
nonzero = INTVAL (XEXP (x, 1));
}
- if ((mask ~nonzero) == 0)
+ if ((mask ~nonzero) == 0
+ !VECTOR_MODE_P (mode) !VECTOR_MODE_P (GET_MODE (x)))
{
x = simplify_shift_const (NULL_RTX, LSHIFTRT, GET_MODE (x),
XEXP (x, 0), INTVAL (XEXP (x, 1)));
@@ -7643,7 +7644,8 @@
return force_to_mode (x, mode, mask, next_select);
}
- else if ((i = exact_log2 (mask)) = 0)
+ else if ((i = exact_log2 (mask)) = 0
+!VECTOR_MODE_P (mode) !VECTOR_MODE_P (GET_MODE (x)))
{
x = simplify_shift_const
(NULL_RTX, LSHIFTRT, GET_MODE (x), XEXP (x, 0),
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37809
[Bug middle-end/37815] [4.4 Regression] ICE in vt_add_function_parameters (bootstrap error)
--- Comment #3 from doko at ubuntu dot com 2008-10-14 07:21 --- reverting r141077 on current trunk lets the bootstrap succeed on sparc-linux -- doko at ubuntu dot com changed: What|Removed |Added CC||rth at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37815
[Bug c/37106] [4.4 Regression] ICE: in mems_in_disjoint_alias_sets_p, at alias.c:278
--- Comment #10 from ghazi at gcc dot gnu dot org 2008-10-14 08:10 --- (In reply to comment #9) Well, I guess then the first thing to ask for is for both the gcc.target/i386/opt-1.c and gcc.target/i386/opt-2.c tests to be extended so that they are run with -fPIC. It would be helpful to know if current gcc trunk on i386 linux fail these test with -fPIC to determine if this issue is darwin specific. I confirm the opt-1/opt-2 failures on i686-linix and x86_64-linux when using -fpic or -fPIC: http://gcc.gnu.org/ml/gcc-testresults/2008-10/msg00958.html http://gcc.gnu.org/ml/gcc-testresults/2008-10/msg00907.html The issue is not darwin-specific. -- ghazi at gcc dot gnu dot org changed: What|Removed |Added CC||ghazi at gcc dot gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-10-14 08:10:59 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37106
[Bug middle-end/37805] [4.3/4.4 Regression] gcc --help=separate
--- Comment #3 from jakub at gcc dot gnu dot org 2008-10-14 12:01 --- Subject: Bug 37805 Author: jakub Date: Tue Oct 14 12:00:19 2008 New Revision: 141106 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=141106 Log: PR middle-end/37805 * opts.c (common_handle_option): Don't ICE on -fhelp=joined and -fhelp=separate. Modified: trunk/gcc/ChangeLog trunk/gcc/opts.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37805
[Bug fortran/37821] [4.4 Regression] gfortran is ignoring #includes with the syntax file.h
--- Comment #3 from burnus at gcc dot gnu dot org 2008-10-14 12:11 --- Confirm. gcc (the C compiler) has using -I test_directory: #include ... search starts here: #include ... search starts here: test_directory /usr/local/include /projects/tob/gcc-trunk/include /projects/tob/gcc-trunk/lib/gcc/x86_64-unknown-linux-gnu/4.4.0/include /projects/tob/gcc-trunk/lib/gcc/x86_64-unknown-linux-gnu/4.4.0/include-fixed /usr/include End of search list. whereas gfortran has the following: #include ... search starts here: test_directory /projects/tob/gcc-trunk/lib/gcc/x86_64-unknown-linux-gnu/4.4.0/finclude . #include ... search starts here: /usr/local/include /projects/tob/gcc-trunk/include /projects/tob/gcc-trunk/lib/gcc/x86_64-unknown-linux-gnu/4.4.0/include /projects/tob/gcc-trunk/lib/gcc/x86_64-unknown-linux-gnu/4.4.0/include-fixed /usr/include End of search list. -- 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 Last reconfirmed|-00-00 00:00:00 |2008-10-14 12:11:19 date|| Summary|gfortran is ignoring|[4.4 Regression] gfortran is |#includes with the syntax |ignoring #includes with the |file.h|syntax file.h http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37821
[Bug bootstrap/37825] New: '--with-abi=aapcs-linux' rejected
When using '--with-abi' to preconfigure the 'aapcs-linux' ABI, the build fails with | Unknown ABI used in --with-abi=aapcs-linux As this ABI is accepted for '-mabi=', it should be accepted for bootstrapping too. -- Summary: '--with-abi=aapcs-linux' rejected Product: gcc Version: 4.3.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: enrico dot scholz at informatik dot tu-chemnitz dot de GCC target triplet: arm-linux-gnueabi http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37825
[Bug fortran/37821] [4.4 Regression] gfortran is ignoring #includes with the syntax file.h
--- Comment #4 from dfranke at gcc dot gnu dot org 2008-10-14 12:23 --- Bugger. How much time do we have left before 4.4? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37821
[Bug middle-end/37815] [4.4 Regression] ICE in vt_add_function_parameters (bootstrap error)
--- Comment #4 from jakub at gcc dot gnu dot org 2008-10-14 11:25 ---
Created an attachment (id=16491)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16491action=view)
libgcc2.i
Indeed, caused by r141077. On the attached preprocessed source reproduceable
with - sparc-linux cross with -g -O{1,2}. The RTL dump with/without r141077
is identical until ira, then a bunch of stack slots are shared differently.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37815
[Bug c/37823] New: Missed optimization - ffs() from strings.h
GCC produces some redundant addl/subl instructions for the following function,
which calls the built-in ffs():
--- snip ---
#include strings.h
int
foo(int i, int j)
{
return i + ffs(j) - 1;
}
--- output of gcc -O3 -m32 -S foo.c ---
foo:
pushl %ebp
xorl%edx, %edx
movl%esp, %ebp
bsfl12(%ebp), %eax
sete%dl
negl%edx
orl %edx, %eax
addl$1, %eax
subl$1, %eax
addl8(%ebp), %eax
popl%ebp
ret
--- output of gcc -O3 -S foo.c ---
foo:
bsfl%esi, %esi
movl$-1, %eax
cmove %eax, %esi
addl$1, %esi
leal-1(%rsi,%rdi), %eax
ret
--
Summary: Missed optimization - ffs() from strings.h
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jjk at acm dot org
GCC host triplet: x86_64-redhat-linux
GCC target triplet: x86_64-redhat-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37823
[Bug target/37381] [4.4 Regression] ICE in ia64_speculate_insn, at config/ia64/ia64.c:6902
--- Comment #10 from amonakov at gcc dot gnu dot org 2008-10-14 13:41 --- Since Andrey has just committed ia64 changes from sel-sched branch to trunk, the underlying problem is fixed and ICEs on original testcase and mentioned regression tests are gone. Closing as fixed. -- amonakov at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37381
[Bug fortran/37826] New: gfortran compiled with -gstabs+ on OSX emits incorrect debug information if compiled with -finit-local-zero
If I compile the following program with -gstabs+ under OSX 10.5.5 with gcc4.4 Using built-in specs. Target: i386-apple-darwin8.10.1 Configured with: /tmp/gfortran-20081006/ibin/../gcc/configure --prefix=/usr/local/gfortran --enable-languages=c,fortran --with-gmp=/tmp/gfortran-20081006/gfortran_libs --enable-bootstrap Thread model: posix gcc version 4.4.0 20081006 (experimental) [trunk revision 140904] (GCC) program hello integer a common /testcommon/a integer pos(3) a = 5 pos(1) = 2 pos(2) = 1 pos(3) = 1 write (*,*) HELLO, A end as follows: gfortran -gstabs+ -o testcase testcase.f Then I can correctly use gdb as shown below: Breakpoint 1, MAIN__ () at testcase.f:1 1 program hello (gdb) next Current language: auto; currently fortran 8 a = 5 (gdb) list 3 integer a 4 common /testcommon/a 5 6 integer pos(3) 7 8 a = 5 9 10pos(1) = 2 11pos(2) = 1 12pos(3) = 1 However, if I compile with -finit-local-zero like this: gfortran -finit-local-zero -gstabs+ -o testcase testcase.f The line numbers don't match the source code as shown below: Breakpoint 1, MAIN__ () at testcase.f:1 1 program hello (gdb) next Current language: auto; currently fortran 6 integer pos(3) (gdb) list 1 program hello 2 3 integer a 4 common /testcommon/a 5 6 integer pos(3) 7 8 a = 5 9 10pos(1) = 2 (gdb) quit The compiler is apparently adding extra code to initizilize the variables but not accounting for it in the line numbers. This problem has existed as long as the -finit-local-zero option has been avaliable in gfortran. I can't test other -g options as they don't generate usuable debug information on OSX. -- Summary: gfortran compiled with -gstabs+ on OSX emits incorrect debug information if compiled with -finit-local-zero Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: chris dot walter at duke dot edu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37826
[Bug rtl-optimization/37782] [4.4 regression] Stage2 ada compiler miscompiled
--- Comment #2 from jakub at gcc dot gnu dot org 2008-10-14 11:50 --- I couldn't reproduce this on powerpc64-linux --with-cpu=default32 --enable-languages=ada, I can only reproduce the var-tracking.c ICE which is already tracked in PR37815. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37782
[Bug middle-end/37805] [4.3/4.4 Regression] gcc --help=separate
--- Comment #4 from jakub at gcc dot gnu dot org 2008-10-14 12:08 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37805
[Bug c++/37553] [4.3/4.4 Regression] ICE in build_c_cast
--- Comment #4 from dgregor at gcc dot gnu dot org 2008-10-14 15:05 --- Subject: Bug 37553 Author: dgregor Date: Tue Oct 14 15:03:51 2008 New Revision: 14 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=14 Log: 2008-10-14 Douglas Gregor [EMAIL PROTECTED] PR c++/37553 * tree.c (build_type_attribute_qual_variant): Hash on the unqualified type, and don't overwrite an existing (type_hash_eq): Make the TYPE_NAME of the types significant, to allow distinguishing between wchar_t and its underlying type. This also means that we'll retain a little more typedef information. 2008-10-14 Douglas Gregor [EMAIL PROTECTED] PR c++/37553 * g++.dg/ext/alias-canon2.C: New. Added: trunk/gcc/testsuite/g++.dg/ext/alias-canon2.C Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37553
[Bug middle-end/37828] [graphite] in expand_scalar_variables_expr, at graphite.c:3421
--- Comment #1 from dwarak dot rajagopal at amd dot com 2008-10-14 15:29 --- Created an attachment (id=16492) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16492action=view) Testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37828
[Bug c++/37553] [4.3/4.4 Regression] ICE in build_c_cast
--- Comment #5 from doug dot gregor at gmail dot com 2008-10-14 16:03 --- Fixed on mainline -- doug dot gregor at gmail dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|4.3.3 |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37553
[Bug fortran/35681] wrong result for vector subscripted array expression in MVBITS
--- Comment #5 from domob at gcc dot gnu dot org 2008-10-14 16:20 --- I will look at this and try to work it out, taking it for now. -- domob at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |domob at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2008-03-24 22:13:04 |2008-10-14 16:20:44 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35681
[Bug c/37822] Code deficiency in function fold
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-10-14 09:25 --- As you say, this is fixed in later versions. GCC 3.4.x has long been out of maintainance. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37822
[Bug c++/35483] GCC on AIX doesn't support dollar in symbols name.
--- Comment #7 from dje at gcc dot gnu dot org 2008-10-14 17:06 --- Created an attachment (id=16493) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16493action=view) patch to convert dollar signs to underscores New patch. This patch intercepts the dollar signs at a lower level and correctly handles garbage collection allocations of strings. -- dje at gcc dot gnu dot org changed: What|Removed |Added Attachment #15273|0 |1 is obsolete|| Attachment #15298|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35483
[Bug middle-end/37828] [graphite] in expand_scalar_variables_expr, at graphite.c:3421
--- Comment #2 from spop at gcc dot gnu dot org 2008-10-14 15:32 --- Mine. It makes no sense to loop block single nested loops. -- spop at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |spop at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-10-14 15:32:16 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37828
[Bug tree-optimization/37449] [4.4 Regression] calculix gets wrong answer for -O1 -ffast-math
--- Comment #13 from jakub at gcc dot gnu dot org 2008-10-14 17:35 ---
The different results between -O1 -f{,no}unsafe-math-optimizations are because
this testcase relies heavily on signed zeros, and with with fast math 0 and -0
aren't considered to make a difference, you get at least different value of tt
depending on it (for cn -1.0 it can be either pi/3 or -pi/3, depending on
whether
sqrt returned -0 or 0). But no matter whether tt is pi/3 or -pi/3, two of the
results should be 0.5 and so the test should succeed. But dom1 when it decides
to duplicate the bb's (once for the passed in cn, once for +-1.0) omits
unexpectedly the first conditional (i.e. set *neig = 2 if fabs (al[0] - al[1])
1.e-5). It does that both when -funsafe-math-optimizations and
-fno-unsafe-math-optimizations, but given that for -funsafe-math-optimizations
tt is -pi/3, al[0] is 0.5 and al[1] is 0.5, so this is fatal, while for
non-fast math al[0] is 0.5 and al[2] is 0.5, so it doesn't care.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37449
[Bug bootstrap/37825] '--with-abi=aapcs-linux' rejected
--- Comment #1 from enrico dot scholz at informatik dot tu-chemnitz dot de 2008-10-14 12:22 --- mmh... fixed in SVN already... closing bug -- enrico dot scholz at informatik dot tu-chemnitz dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37825
[Bug c++/37650] [4.2/4.3/4.4 regression] ICE with broken default template parameter
--- Comment #3 from paolo at gcc dot gnu dot org 2008-10-14 17:53 --- Subject: Bug 37650 Author: paolo Date: Tue Oct 14 17:51:55 2008 New Revision: 141115 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=141115 Log: /cp 2008-10-14 Paolo Carlini [EMAIL PROTECTED] PR c++/37650 * pt.c (push_template_decl_real): Check that current_template_parms is not null. (process_partial_specialization): Assert current_template_parms not null. /testsuite 2008-10-14 Paolo Carlini [EMAIL PROTECTED] PR c++/37650 * g++.dg/template/crash83.C: New. Added: trunk/gcc/testsuite/g++.dg/template/crash83.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37650
[Bug c++/37650] [4.2/4.3 regression] ICE with broken default template parameter
--- Comment #4 from paolo dot carlini at oracle dot com 2008-10-14 17:53 --- Fixed for 4.4.0. -- paolo dot carlini at oracle dot com changed: What|Removed |Added AssignedTo|paolo dot carlini at oracle |unassigned at gcc dot gnu |dot com |dot org Status|ASSIGNED|NEW Summary|[4.2/4.3/4.4 regression] ICE|[4.2/4.3 regression] ICE |with broken default template|with broken default template |parameter |parameter http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37650
[Bug middle-end/37828] [graphite] ICE in expand_scalar_variables_expr, at graphite.c:3421 with -floop-block
--- Comment #3 from grosser at gcc dot gnu dot org 2008-10-14 17:55 ---
(In reply to comment #2)
It makes no sense to loop block single nested loops.
Using -fgraphite-identity (not yet commited) or removing the ifdef at
graphite.c:4915 the Polyhedron also fails with this bug. So it seems not only
to be because of loop blocking.
All compiled with
f951 -O1 -fdump-tree-graphite-all -fgraphite-identity name.f90
[...]
Performing interprocedural optimizations
visibility early_local_cleanups summary generate inline static-var
pure-constAssembling functions:
list ddx ddy sw
bug.f90: In function 'sw':
bug.f90:6: internal compiler error: in expand_scalar_variables_expr, at
graphite.c:3421
[...]
pure-constAssembling functions:
div_care capacitance prod0 vprim ginteg fourir fourir2d preco fourirg
init_solve fourir2dx prod1 mv_prod cgstab
capacita.f90: In function 'cgstab':
capacita.f90:12: internal compiler error: in expand_scalar_variables_expr, at
graphite.c:3421
[...]
pure-constAssembling functions:
list ddx ddy sw
channel.f90: In function 'sw':
channel.f90:6: internal compiler error: in expand_scalar_variables_expr, at
graphite.c:3421
[...]
Performing interprocedural optimizations
visibility early_local_cleanups {GC 5400k - 4387k} {GC 5712k - 5287k}
summary generate inline static-var pure-constAssembling functions:
convert_lower_case computer_time time_now runit check_eof check_number
mutual_ind_cir_cir_coils induct define_wand_coils {GC 6903k - 4965k}
build_vrml_data
induct.f90: In function 'build_vrml_data':
induct.f90:4840: internal compiler error: in expand_scalar_variables_expr, at
graphite.c:3421
[...]
Performing interprocedural optimizations
visibility early_local_cleanups {GC 5362k - 3039k} summary generate
inline static-var pure-constAssembling functions:
dswap genuni idamax trs2a2 minlst cptrf2 dscal extpic lsame xerbla cmpmat
rnflow
rnflow.f90: In function 'rnflow':
rnflow.f90:4478: internal compiler error: in expand_scalar_variables_expr, at
graphite.c:3421
--
grosser at gcc dot gnu dot org changed:
What|Removed |Added
CC||grosser at gcc dot gnu dot
||org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37828
[Bug middle-end/37828] [graphite] ICE in expand_scalar_variables_expr, at graphite.c:3421 with -floop-block
--- Comment #4 from spop at gcc dot gnu dot org 2008-10-14 18:24 --- Subject: Bug 37828 Author: spop Date: Tue Oct 14 18:23:05 2008 New Revision: 141116 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=141116 Log: 2008-10-14 Sebastian Pop [EMAIL PROTECTED] Harsha Jagasia [EMAIL PROTECTED] PR tree-optimization/37828 * testsuite/gcc.dg/graphite/pr37828.c: New. * graphite.c (graphite_trans_loop_block): Do not loop block single nested loops. Added: branches/graphite/gcc/testsuite/gcc.dg/graphite/pr37828.c Modified: branches/graphite/gcc/ChangeLog.graphite branches/graphite/gcc/graphite.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37828
[Bug middle-end/37828] [graphite] ICE in expand_scalar_variables_expr, at graphite.c:3421 with -floop-block
--- Comment #5 from spop at gcc dot gnu dot org 2008-10-14 18:29 --- Fixed on graphite branch. We should open another bug once the -fgraphite-identity is in. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37828
[Bug fortran/37827] New: Fortran IO structure - compiler vs. library (libgfortran) [requires ABI breaking?]
See http://gcc.gnu.org/ml/fortran/2008-10/msg00105.html Steve Ellcey writes there: While examining the failures of some of the f2003 IO tests on my IA64 HP-UX systems I found what I think is a mismatch between the st_parameter_dt in the library and in the compiler. It seems like this would affect f95 as well as f2003 so I am not sure why it hasn't shown up before but I wonder if this is also why some of these tests fail on powerpc too. The first field in st_parameter_dt structure is common and is of type st_parameter_common. This structure, in my ILP32 runtime mode is 28 bytes long (5 ints and 2 pointers). The second field in st_parameter_dt is rec, which is type GFC_IO_INT. Now my ILP32 system does support 8 byte integers (as long long) so GFC_IO_INT is an 8 byte integer and that in turns requires an 8 byte alignment. Since the first field is not a multiple of 8 bytes the compiler puts 4 bytes of padding between common and rec in the st_parameter_dt structure. I do not believe this padding is accounted for in the compilers calculation of offsets as generated from ioparm.def. While investigating this problem I also noticed that there seems to be a descrepency in the type of id in st_parameter_44. In io.h it is GFC_IO_INT *id but in ioparm.def we have: IOPARM (dt, id,1 16, pint4) Shouldn't io.h be GFC_INTEGER4 or perhaps ioparm.def should be pintio? I don't think this problem is related to my problem though since it would be a pointer and 4 bytes long in either case. Is there a way to account for compiler padding in the st_parameter_dt structure? -- Jerry replied: We can not touch that part of st_parameter_dt without breaking ABI. Now for 4.5 we will probably break ABI for other reasons and this will be the opportunity to do some re-constructive surgery. We could at that time make sure we align on 8 byte boundaries and pad if we have to. I do not know a way to magically do this. -- Summary: Fortran IO structure - compiler vs. library (libgfortran) [requires ABI breaking?] Product: gcc Version: 4.4.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37827
[Bug target/37633] [4.4 Regression] wrong register use on sh64
--- Comment #3 from vmakarov at redhat dot com 2008-10-14 19:42 --- I've checked the old RA. It does not assigned partially clobbered hard register because it is done only when non partially clobbered hard regs were tried first. Sh has a lot of such registers therefore the chance to generate wrong code is small. I can simulate the same behaviour for IRA by increasing costs for partially clobbered hard registers. Currently rs6000 and sh define HARD_REGNO_CALL_PART_CLOBBERED. So even the problem is solved for sh in different way, the patch increasing cost would be useful for rs6000. Still, as I wrote, the complete solution (the mentioned cost increase will be still necessary in any case) would be save and restore partially clobbered hard-registers in caller-saves.c. The patch increasing the costs will be sent later today. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37633
[Bug middle-end/37674] [4.4 Regression] Bootstrap failure due to miscompilation of genattrtab
--- Comment #5 from vmakarov at redhat dot com 2008-10-14 19:50 --- Updating of total_conflict_hard_regs in ira-build.c::ira_flattening was completely wrong. So I rewrite the calculation of total_conflict_hard_regs and total_no_stack_reg_p. It is now done from the scratch. The code became more readable and there is no visible slowdown of IRA. I'll send a patch solving the PR later today. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37674
[Bug fortran/37827] Fortran IO structure - compiler vs. library (libgfortran) [requires ABI breaking?]
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-10-14 19:56 --- You cannot touch the library part, but you certainly can align what the compiler does to the library part of the structure definition. Thus, if the behavior is wrong (as in wrong-code) at the moment, changing the ABI only in parts that affect the wrong-code bug certainly is ok. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37827
[Bug c++/37819] [4.4 Regression] ice for bitfield code
-- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | URL||http://gcc.gnu.org/ml/gcc- ||patches/2008- ||10/msg00573.html Status|NEW |ASSIGNED Last reconfirmed|2008-10-13 22:30:57 |2008-10-14 08:54:24 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37819
[Bug fortran/37829] New: ICE in resolve_symbol
module modx use, intrinsic :: iso_c_binding common /spaces/ sp integer (c_long) :: sp bind (c) :: /spaces/ end module modx block data use modx double precision sums common /cblock/ sums (4) data (sums (i), i = 1,4) / 1.0, 2.0, 3.0, 4.0 / end ICEs in resolve_symbol: 9102 /* Make sure that the derived type has been resolved and that the 9103 derived type is visible in the symbol's namespace, if it is a 9104 module function and is not PRIVATE. */ 9105 if (sym-ts.type == BT_DERIVED 9106 sym-ts.derived-attr.use_assoc 9107 sym-ns-proc_name-attr.flavor == FL_MODULE) The first 2 conditions are true, but sym-ns-proc_name is NULL. sym is c_funloc, with sym-module __iso_c_binding. -- Summary: ICE in resolve_symbol Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jakub at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37829
[Bug regression/37824] funroll-loops miscompiles php
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-10-14 13:20 ---
It is indeed an aliasing violation, you store a long and read a long*.
Fix it like
int main()
{
int i;
long a;
long **b = malloc(8 * sizeof(long));
for (i = 0; i 8; i++)
*b++ = a;
b--;
foo(6, (void **)b);
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution||INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37824
[Bug middle-end/37742] [4.4 Regression] ICE in vectorizer with restrict pointer
--- Comment #12 from rguenth at gcc dot gnu dot org 2008-10-14 20:46 --- This is because data-ref uses p1 for DR_BASE_ADDRESS instead of p (which is restrict qualified), for the scalar load we do not do this propagation because we try to retain restrict qualifications. simple_iv () in dr_analyze_innermost computes for the iv base (int * restrict) p1_4(D) + 4 and canonicalize_base_object_address gets passed (int * restrict) p1_4(D) after splitting away the offset. This just strips NOPs, so the restrict qualification gets lost here. I have a patch. So the assert in this case hints at a missed-optimization. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37742
[Bug middle-end/37805] [4.3/4.4 Regression] gcc --help=separate
--- Comment #2 from jakub at gcc dot gnu dot org 2008-10-14 09:16 --- This isn't ice-on-valid-code, but rather ice-on-invalid-option-argument, but we don't have such a category. -- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | URL||http://gcc.gnu.org/ml/gcc- ||patches/2008- ||10/msg00575.html Status|NEW |ASSIGNED Last reconfirmed|2008-10-13 23:01:10 |2008-10-14 09:16:37 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37805
possible bug in 4.1.2 g++ arm compiler -O2 optimization
I already sent this to [EMAIL PROTECTED], but no responses, so posting here
also.
-b
I seem to have found a bug in the ARM 4.1.2 g++ optimization code. This
attached test case demonstrates an apparent optimizer bug in the 4.1.2 ARM g++
compiler.
Compile this code:
arm-linux-g++ -O2 -S optbug.cpp
and look at the assembly for the test() method:
_ZN6OptBug4testEv:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
ldr r0, [r0, #1028]
ldr r3, [r0, #1024]
sub r0, r3, r0
cmp r0, #16384
movlt r0, #0
movge r0, #1
@ lr needed for prologue
mov pc, lr
Notice the two ldr instructions. The first puts a value into r0 but the
second assumes r0 has not been modified. The order of the two lines appears
to be flipped.
I'm hoping there is a patch for this problem and if not, perhaps there is a
work-around you folks can suggest. I'm tied to this tool chain version for the
near term.
Thanks in advance for any assistance you can provide.
Blair
=cut here===
#include stdio.h
// This test case demonstrates an optimizer bug in the 4.1.2 ARM g++ compiler.
// Compile this code:
//
//arm-linux-g++ -O2 -S optbug.cpp
//
// and look at the assembly for the test() method:
//
// _ZN6OptBug4testEv:
//@ args = 0, pretend = 0, frame = 0
//@ frame_needed = 0, uses_anonymous_args = 0
//@ link register save eliminated.
//ldrr0, [r0, #1028]
//ldrr3, [r0, #1024]
//subr0, r3, r0
//cmpr0, #16384
//movlt r0, #0
//movge r0, #1
//@ lr needed for prologue
//movpc, lr
//
// Notice the two ldr instructions. The first puts a value into r0 but the
// second assumes r0 has not been modified. The order of the two lines appears
// to be flipped.
class OptBug
{
public:
OptBug(): v1(200), v2(200) {}
bool test();
protected:
// The presence of this buffer effects the type of assembly that is
// generated. With the buffer around 1024 we get the assembly with the bug.
char data[1024];
int v1;
int v2;
};
bool OptBug::test()
{
if ((v2 - v1) 16*1024)
return false;
return true;
}
int main(int argc, char **argv)
{
OptBug ob;
printf(Should return 0\n);
printf(%d\n, ob.test());
return 0;
}
[Bug fortran/37826] gfortran compiled with -gstabs+ on OSX emits incorrect debug information if compiled with -finit-local-zero
--- Comment #1 from burnus at gcc dot gnu dot org 2008-10-14 21:03 --- I can't test other -g options as they don't generate usuable debug information on OSX. To my knowledge OS X also supports DWARF debugging symbols, cf. http://gcc.gnu.org/ml/gcc-patches/2007-02/msg00745.html However, with DWARF the result is the same. The line numbers don't match the source code as shown below: I might miss something, but the line numbers look OK. The compiler is apparently adding extra code to initizilize the variables but not accounting for it in the line numbers. It does and seemingly the debug location used for this is the line of the last variable declaration. It is actually not quite clear how gfortran should handle this - simply not allowing a break point in line 6? Or ... ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37826
[Bug c/37106] [4.4 Regression] ICE with -fpic or -fPIC: in mems_in_disjoint_alias_sets_p, at alias.c:278
--- Comment #12 from dominiq at lps dot ens dot fr 2008-10-14 10:57 --- Possible candidates revisions 138075, 138089, and 138092. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37106
[Bug fortran/37826] gfortran compiled with -gstabs+ on OSX emits incorrect debug information if compiled with -finit-local-zero
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-10-14 21:10 --- To me the initialization of the variables should be recorded when using -finit-local-zero. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37826
[Bug middle-end/37815] [4.4 Regression] ICE in vt_add_function_parameters (bootstrap error)
--- Comment #5 from jakub at gcc dot gnu dot org 2008-10-14 11:47 --- vt_add_function_parameters asserts that REG_EXPR or MEM_EXPR of DECL_RTL of a PARM decl, if it is non-NULL, is the PARM_DECL itself, but with the r141077 patch when the stack slots may be shared, decl might be actually spill_slot_decl. Not sure how should var-tracking.c figure out where the stack slot is still used for the PARM_DECL and where it starts holding something else. On this libgcc2.i sparc testcase the stack slot in question (fp-176) is used first as c (one of PARM_DECLs) and after a while as c.49 (VAR_DECL). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37815
[Bug fortran/37826] gfortran compiled with -gstabs+ on OSX emits incorrect debug information if compiled with -finit-local-zero
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-10-14 21:12 --- In fact g77 did the same, see PR 15171. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37826
[Bug target/37823] Missed optimization - ffs() from strings.h
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-10-14 09:31 --- Trunk produces: foo: pushl %ebp xorl%eax, %eax movl%esp, %ebp bsfl12(%ebp), %edx sete%al negl%eax orl %eax, %edx movl8(%ebp), %eax addl$1, %edx popl%ebp leal-1(%edx,%eax), %eax ret and foo: .LFB0: .cfi_startproc bsfl%esi, %eax movl$-1, %edx cmove %edx, %eax addl%edi, %eax ret So the 64bit version is fine, the 32bit version is still funny. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement Status|UNCONFIRMED |NEW Component|c |target Ever Confirmed|0 |1 GCC host triplet|x86_64-redhat-linux | GCC target triplet|x86_64-redhat-linux |i?86-*-* Keywords||missed-optimization Last reconfirmed|-00-00 00:00:00 |2008-10-14 09:31:25 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37823
[Bug middle-end/37828] New: [graphite] in expand_scalar_variables_expr, at graphite.c:3421
g++ -c -floop-block -O3 bug_rep.cpp bug_rep.cpp: In function int sort_and_split(foo**, foo**, long int): bug_rep.cpp:9: internal compiler error: in expand_scalar_variables_expr, at graphite.c:3421 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. Testcase attached. - Dwarak -- Summary: [graphite] in expand_scalar_variables_expr, at graphite.c:3421 Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dwarak dot rajagopal at amd dot com GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37828
[Bug fortran/37826] gfortran compiled with -gstabs+ on OSX emits incorrect debug information if compiled with -finit-local-zero
--- Comment #4 from chris dot walter at duke dot edu 2008-10-14 21:33 --- To my knowledge OS X also supports DWARF debugging symbols, cf. http://gcc.gnu.org/ml/gcc-patches/2007-02/msg00745.html Hmm.. Well when I try it I get (using gfortran -gdwarf-2) this when I start gdb: GNU gdb 6.3.50-20050815 (Apple version gdb-960) (Sun May 18 18:38:33 UTC 2008) 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 libraries done warning: Could not find object file /var/folders/7c/7cla3UxyGe0s8EeGsHNlUU+++TI/-Tmp-//cc8EVMgS.o - no debug information available for testcase.f. I might miss something, but the line numbers look OK. The compiler is apparently adding extra code to initizilize the variables but not accounting for it in the line numbers. It does and seemingly the debug location used for this is the line of the last variable declaration. Well... As described in the closed bug report the effect is a lot of jumping around among the declaration statements for more complicated code. It steps in both directions (I mean it will go from line 6 to 2 to 7 etc etc) I assumed this was a problem but it sounds like you are saying these are the lines that correspond to the assembly code. If it is always the case that there is really a one-to-one correspondence between the source line and what is being cleared it makes sense if you understand it. My feeling is that the code that the compiler adds to clear the variables is different than what is in the source code (which are definitions) so it shouldn't be trying to step through that source code. The variable definition isn't really the same as clearing the variable. I don't remember ever seeing this when debugging in g77 on linux but I take your word for it. Perhaps it shouldn't be changed but it is very confusing as it is quite difficult to tell when the subroutine execution ever begins. In anycase, I understand your explanation if you would rather not change it. It might be worth adding a warning to the documentation. Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37826
[Bug regression/37824] funroll-loops miscompiles php
--- Comment #1 from anton at samba dot org 2008-10-14 11:59 --- Alan Modra points out the cast is not required and removing it does fix the issue. BTW -Wstrict-aliasing (or -Wstrict-aliasing=2) doesn't warn about the code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37824
[Bug fortran/37821] [4.4 Regression] gfortran is ignoring #includes with the syntax file.h
--- Comment #6 from chris dot walter at duke dot edu 2008-10-14 13:39 --- Sorry, for leaving out the test case, but I see it is confirmed now. I can't use the conforming INCLUDE since I am dealing with a large legacy code base and ~150 colleagues who are also using the code with various compilers etc. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37821
[Bug target/37381] [4.4 Regression] ICE in ia64_speculate_insn, at config/ia64/ia64.c:6902
--- Comment #11 from hjl dot tools at gmail dot com 2008-10-14 21:50 --- I didn't see the testcase in comment #2 in gcc. -- hjl dot tools at gmail dot com changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37381
[Bug regression/37824] funroll-loops miscompiles php
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-10-14 21:59 --- There are two aliasing violations here. The first is what Richard mentioned and the second is also in foo, there is a load from p via long* and also a store via void*. That is where the issue comes down to here and not the other one but both are undefined code . -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37824
[Bug c++/37819] [4.4 Regression] ice for bitfield code
--- Comment #4 from jakub at gcc dot gnu dot org 2008-10-14 21:59 --- Subject: Bug 37819 Author: jakub Date: Tue Oct 14 21:57:44 2008 New Revision: 141118 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=141118 Log: PR c++/37819 * cp-gimplify.c (cp_genericize_r): Only fold_convert COND_EXPR arguments if they don't already have COND_EXPR's type. * g++.dg/expr/bitfield11.C: New test. Added: trunk/gcc/testsuite/g++.dg/expr/bitfield11.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-gimplify.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37819
[Bug c++/37819] [4.4 Regression] ice for bitfield code
--- Comment #5 from jakub at gcc dot gnu dot org 2008-10-14 21:59 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37819
[Bug fortran/37821] [4.4 Regression] gfortran is ignoring #includes with the syntax file.h
--- Comment #5 from burnus at gcc dot gnu dot org 2008-10-14 12:31 ---
(In reply to comment #3)
#include ... search starts here:
test_directory
/projects/tob/gcc-trunk/lib/gcc/x86_64-unknown-linux-gnu/4.4.0/finclude
.
That . comes last is also wrong; it should come first for However, CPP
automatically takes care.
Draft patch below; it works, except that I get the warning (-v -I tes):
ignoring duplicate directory tes Warning
#include ... search starts here:
#include ... search starts here:
tes
/projects/tob/gcc-trunk/lib/gcc/x86_64-unknown-linux-gnu/4.4.0/finclude
/usr/local/include
/projects/tob/gcc-trunk/include
/projects/tob/gcc-trunk/lib/gcc/x86_64-unknown-linux-gnu/4.4.0/include
/projects/tob/gcc-trunk/lib/gcc/x86_64-unknown-linux-gnu/4.4.0/include-fixed
/usr/include
End of search list.
Index: cpp.c
===
--- cpp.c (Revision 141104)
+++ cpp.c (Arbeitskopie)
@@ -628,10 +628,9 @@ gfc_cpp_add_include_path (char *path, bo
{
/* CHAIN sets cpp_dir-sysp which differs from 0 if PATH is a system
include path. Fortran does not define any system include paths. */
- int chain = 0;
int cxx_aware = 0;
- add_path (path, chain, cxx_aware, user_supplied);
+ add_path (path, BRACKET, cxx_aware, user_supplied);
}
void
Index: options.c
===
--- options.c (Revision 141104)
+++ options.c (Arbeitskopie)
@@ -266,8 +266,6 @@ gfc_post_options (const char **pfilename
source_path[i] = 0;
gfc_add_include_path (source_path, true);
}
- else
-gfc_add_include_path (., true);
if (canon_source_file != gfc_source_file)
gfc_free (CONST_CAST (char *, canon_source_file));
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37821
[Bug c/37106] [4.4 Regression] ICE: in mems_in_disjoint_alias_sets_p, at alias.c:278
--- Comment #11 from dominiq at lps dot ens dot fr 2008-10-14 10:14 --- I confirm the opt-1/opt-2 failures on i686-linix and x86_64-linux when using -fpic or -fPIC: ... The issue is not darwin-specific. Digging the archives the failures on x86_64-linux when using -fpic or -fPIC appeared between: http://gcc.gnu.org/ml/gcc-testresults/2008-07/msg02246.html and http://gcc.gnu.org/ml/gcc-testresults/2008-07/msg02337.html Kaveh do you have a way to know the corresponding revisions? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37106
[Bug regression/37824] New: funroll-loops miscompiles php
A gcc checkout from yesterday (4.4.0 20081013) is miscompiling php when built
with 64bit and funroll-loops. A cut down test case is below but at this stage
im not sure if its a violation of the aliasing rules.
good:
# gcc -m64 -O2 -o /tmp/foo /tmp/foo.c
# /tmp/foo
0xfabef50
0xfabef50
0xfabef50
0xfabef50
0xfabef50
0xfabef50
bad:
# gcc -m64 -funroll-loops -O2 -o /tmp/foo /tmp/foo.c
# /tmp/foo
0xfacef50
0xfacef50
(nil)
(nil)
(nil)
0xfacef50
code:
#include stdio.h
#include stdlib.h
void foo(int count, void **p)
{
while (--count = 0) {
long *q = *(long **)(--p);
*p = 0;
printf(%p\n, q);
}
}
int main()
{
int i;
long a;
long *b = malloc(8 * sizeof(long));
for (i = 0; i 8; i++)
*b++ = (unsigned long)a;
b--;
foo(6, (void **)b);
return 0;
}
--
Summary: funroll-loops miscompiles php
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: regression
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: anton at samba dot org
GCC target triplet: powerpc-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37824
[Bug c++/37830] New: g++ 4.3.1 generates incorrect output when using -O2 (other optimization levels work okay)
The source files in this attachment demonstrate an apparent bug in g++'s -O2 optimizer. To reproduce the bug, do the following: 1) make 2) ./testmessage If the bug is reproduced, you should see output like this: [EMAIL PROTECTED]:~/bug ./testmessage COMPILER BUG! _iterList is 0xbfc371e0, should be NULL at this point! If the bug is not reproduced, the output will be this: [EMAIL PROTECTED]:~/bug ./testmessage Bug not reproduced, hmm. Note that the bug only occurs if I use the -O2 compiler setting... -O0, -O1, and -O3 compile and run with no noticeable problems. I've reproduced this bug in the following environment: Ubuntu Linux 8.04, with the stock g++ 4.3.1 installed, on a MacPro (octocore-Xeon) (under VMWare Fusion). [EMAIL PROTECTED]:~/gcc_optimizer_bug$ g++ --version g++ (Ubuntu 20080404-0ubuntu1) 4.3.1 20080404 (prerelease) [gcc-4_3-branch revision 133917] Copyright (C) 2008 Free Software Foundation, Inc. The bug does not occur under MacOS/X 10.5.5 with g++ 4.0.1. A similar bug occurs under SUSE 10.0 with gcc 4.3.2 installed, but the entry conditions are different such that a different unit test (gcc_optimizer_bug.zip) must be run instead, in order to trigger it there. --- Code details: I've simplified the code in this unit test as much as I can; I would have removed more code since a lot of it never gets executed by the unit test and therefore shouldn't be relevant; however, removing any more code makes the symptom go away(!) The background for the code is this: I have a templated Hashtable class, which can be iterated over using the associated HashtableIterator class. When a HashtableIterator is created, it adds itself to a linked list of registered iterators in its Hashtable (see Hashtable::RegisterIterator()), so that if the Hashtable is modified during the iteration, the associated HashtableIterators can be updated appropriately. When the HashtableIterator is destroyed, its destructor calls Hashtable::UnregisterIterator() so that the iterator will no longer appear in the linked list. My code also has a Message class, which is implemented using a Hashtable object, and there is a an associated MessageFieldNameIterator class that is implemented using a HashtableIterator. The problem is that when -O2 optimization is enabled, the MessageFieldNameIterator's HashtableIterator object (_iter) doesn't unregister itself from the Hashtable's _iterList correctly, and the Hashtable's _iterList pointer is left pointing to an invalid memory location, causing the program to crash shortly thereafter. The invalid pointer seems to point to the stack just after the MessageFieldNameIterator object, for what that's worth. This code has worked fine for years, at least it did until I upgraded to g++ 4.x (where x=1). Sincerely, Jeremy Friesner [EMAIL PROTECTED] 626 487 3194 -- Summary: g++ 4.3.1 generates incorrect output when using -O2 (other optimization levels work okay) Product: gcc Version: 4.3.1 Status: UNCONFIRMED Severity: major Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jaf at meyersound dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37830
[Bug target/37633] [4.4 Regression] wrong register use on sh64
--- Comment #4 from hjl at gcc dot gnu dot org 2008-10-14 22:24 --- Subject: Bug 37633 Author: hjl Date: Tue Oct 14 22:23:23 2008 New Revision: 141120 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=141120 Log: 2008-10-14 Vladimir Makarov [EMAIL PROTECTED] PR target/37633 * ira-costs.c (ira_tune_allocno_costs_and_cover_classes): Check HARD_REGNO_CALL_PART_CLOBBERED. Modified: branches/ira-merge/gcc/ChangeLog.ira branches/ira-merge/gcc/ira-costs.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37633
[Bug c++/37830] g++ 4.3.1 generates incorrect output when using -O2 (other optimization levels work okay)
--- Comment #1 from jaf at meyersound dot com 2008-10-14 22:26 --- Created an attachment (id=16494) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16494action=view) This is the unit test described above; compile and run this to reproduce the bug -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37830
[Bug middle-end/37535] [4.4 Regression] gcc/libgcc2.c:404: internal compiler error: Floating point exception
--- Comment #18 from hjl at gcc dot gnu dot org 2008-10-14 22:26 --- Subject: Bug 37535 Author: hjl Date: Tue Oct 14 22:25:09 2008 New Revision: 141121 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=141121 Log: 2008-10-14 Vladimir Makarov [EMAIL PROTECTED] PR middle-end/37535 * ira-lives.c (mark_early_clobbers): Remove. (make_pseudo_conflict, check_and_make_def_use_conflicts, check_and_make_def_conflicts, make_early_clobber_and_input_conflicts, mark_hard_reg_early_clobbers): New functions. (process_bb_node_lives): Call make_early_clobber_and_input_conflicts and mark_hard_reg_early_clobbers. Make hard register inputs live again. * doc/rtl.texi (clobber): Change descriotion of RA behaviour for early clobbers of pseudo-registers. Modified: branches/ira-merge/gcc/ChangeLog.ira branches/ira-merge/gcc/doc/rtl.texi branches/ira-merge/gcc/ira-lives.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37535
[Bug tree-optimization/37830] g++ 4.3.1 generates incorrect output when using -O2 (other optimization levels work okay)
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-10-14 22:31 --- Works on the trunk. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Severity|major |normal Component|c++ |tree-optimization Known to work||4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37830
[Bug tree-optimization/37830] g++ 4.3.1 generates incorrect output when using -O2 (other optimization levels work okay)
--- Comment #3 from jaf at meyersound dot com 2008-10-14 22:39 --- Created an attachment (id=16495) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16495action=view) This unit test reproduces the bug under g++ 4.3.1, running under SUSE 10.0 (32-bit mode) on my Xeon Mac (w/VMWare Fusion) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37830
[Bug middle-end/37674] [4.4 Regression] Bootstrap failure due to miscompilation of genattrtab
--- Comment #6 from hjl at gcc dot gnu dot org 2008-10-14 22:50 --- Subject: Bug 37674 Author: hjl Date: Tue Oct 14 22:49:36 2008 New Revision: 141122 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=141122 Log: 2008-10-14 Vladimir Makarov [EMAIL PROTECTED] PR middle-end/37674 * ira-build.c (ira_flattening): Recalculate ALLOCNO_TOTAL_NO_STACK_REG_P and ALLOCNO_TOTAL_CONFLICT_HARD_REGS from the scratch instead of the propagation. Modified: branches/ira-merge/gcc/ChangeLog.ira branches/ira-merge/gcc/ira-build.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37674
[Bug testsuite/35677] Intermitent failure FAIL: libgomp.fortran/crayptr2.f90
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-10-14 23:30 --- I still see this, though it was failing a lot more than it was passing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35677
[Bug c++/37831] New: -Wshadow warns about variable names that aren't equal
-Wshadow is silly about this piece of code:
-
class Foo {
int bar_;
public:
void bar(int bar)
{
bar_ = bar;
}
};
-
This is a fairly common style. Note that local and member variable have
names that differ by the underscore. Yet:
g/x c++ -Wshadow -c x.cc
x.cc: In member function 'void Foo::bar(int)':
x.cc:5: warning: declaration of 'bar' shadows a member of 'this'
I think that's being overly pedantic.
W.
--
Summary: -Wshadow warns about variable names that aren't equal
Product: gcc
Version: 4.2.1
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bangerth at dealii dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37831
[Bug c++/37831] -Wshadow warns about variable names that aren't equal
--- Comment #1 from bangerth at dealii dot org 2008-10-15 01:38 --- Note also that the documentation plainly states: @item -Wshadow @opindex Wshadow @opindex Wno-shadow Warn whenever a local variable shadows another local variable, parameter or global variable or whenever a built-in function is shadowed. The current behavior could therefore simply be classified as a bug. W. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37831
[Bug c++/37831] -Wshadow warns about variables inside classes member functions
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-10-15 01:40 --- bar the function shadows bar the variable. I think the warning is correct. The variable _bar is not being taken into account at all. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Summary|-Wshadow warns about|-Wshadow warns about |variable names that aren't |variables inside classes |equal |member functions http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37831
[Bug c++/37831] -Wshadow warns about variables inside classes member functions
--- Comment #3 from bangerth at dealii dot org 2008-10-15 01:51 --- (In reply to comment #2) bar the function shadows bar the variable. I think the warning is correct. The variable _bar is not being taken into account at all. Ah, bummer, I didn't even look close enough to see that the function and its argument are named the same. Silly me, I just saw this piece of code another project was unhappy about and thought I should submit this as a bug. You're right, and I agree that the warning is valid. W. -- bangerth at dealii dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37831
[Bug fortran/37832] New: System_Clock
Resolution of the System_Clock(TICKS,RATE,MAX) intrinsic degraded from about 3.6 MHz to 1,000 Hz when I upgraded from g77 to gfortran (for Windows). There is a computer clock that I have accessed in Visual Basic that represents elapsed time since my computer was turned on, returned as an integer*8 quantity, which operates at the higher frequency. It should be possible for you to offer something similar by re-writing System_Clock(TICKS,RATE,MAX) to operate at the higher frequency (as it was in g77) and return TICKS as an integer*8. -- Summary: System_Clock Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: DavidLNewton at yahoo dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37832
[Bug fortran/37832] System_Clock
--- Comment #1 from kargl at gcc dot gnu dot org 2008-10-15 05:50 --- You can already get an integer(8) result. integer(8) ticks,rate call system_clock(count=ticks,count_rate=rate) print *, ticks, rate end gfc -o z a.f90 ./z 2131173368 1000 count_rate is determined from either /usr/include/sys/time.h or /usr/include/time.h. You need to munge your system header files. For the record, there is very little OS specific code in the library, and I would actively oppose putting more OS specific code in the library. If you want higher resolution try cpu_time, which is one of the few routines that has OS specific code. You can also write your timing routine in C and use ISO C binding to call that routine. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37832
