Re: RFC: Hack to make restrict more useful
On 9/3/07, Daniel Berlin [EMAIL PROTECTED] wrote: On 9/2/07, Paul Brook [EMAIL PROTECTED] wrote: That said, second, my understanding of restrict, from reading the c99 standard, is that it is perfectly valid for restrict pointers to alias each other during *loads*.. IE you can guarantee any restricted pointer that is stored into can't alias the other restricted pointers. Those only used for loads can alias each other. How does it make a difference? If for two pointers that are only loaded from we say they don't alias I cannot imagine a transformation that would get anything wrong. Easy answer: Dependence testing and then loop transforms. Given p[i] = a[i] + b[i], if you claim a and b can't alias, you will now claim that a[i] and b[i] don't access the same memory on the same iteration. We could easily use this and some profit estimation to decide to say, change the iteration space of a but not b,which will break since they really do alias, and breaking this is bad because they are allowed to. Eh? Maybe I'm blind, but how can a change in iteration space that is valid for the non-aliasing case be invalid for the aliasing case _if we do not modify any data_? Ok, Marks example is the only one we could get wrong. But we simply can not derive value ranges from restrict qualification. Richard.
RE: DFA Scheduler - unable to pipeline loads
Matt, I just started working on pipeline description and I'm confused one thing in your description. For integer, your cpu have a 1-cycle latency, but with 3 units stages issue,iu,wb. What does that mean? My understanding is that the number of units seperated by , should be equal to latency. Am I right? Thanks - Joey -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matt Lee Sent: 2007年9月1日 5:58 To: gcc@gcc.gnu.org Subject: DFA Scheduler - unable to pipeline loads Hi, I am working with GCC-4.1.1 on a simple 5-pipe stage simple scalar RISC processors with the following description for loads and stores, (define_insn_reservation integer 1 (eq_attr type branch,jump,call,arith,darith,icmp,nop) issue,iu,wb) (define_insn_reservation load 3 (eq_attr type load) issue,iu,wb) (define_insn_reservation store 1 (eq_attr type store) issue,iu,wb) I am seeing poor scheduling in Dhrystone where a memcpy call is expanded inline. memcpy (dst, src, 16) == load 1, rA + 4 store 1, rB + 4 load 2, rA + 8 store 2, rB + 8 ... Basically, instead of pipelining the loads, the current schedule stalls the processor for two cycles on every dependent store. Here is a dump from the .35.sched1 file. ;; == ;; -- basic block 0 from 6 to 36 -- before reload ;; == ;;0-- 6r84=r5 :issue,iu,wb ;;1-- 13 r86=[`Ptr_Glob'] :issue,iu,wb ;;2-- 25 r92=0x5:issue,iu,wb ;;3-- 12 r85=[r84] :issue,iu,wb ;;4-- 14 r87=[r86] :issue,iu,wb ;;7-- 15 [r85]=r87 :issue,iu,wb ;;8-- 16 r88=[r86+0x4] :issue,iu,wb ;; 11-- 17 [r85+0x4]=r88 :issue,iu,wb ;; 12-- 18 r89=[r86+0x8] :issue,iu,wb ;; 15-- 19 [r85+0x8]=r89 :issue,iu,wb ;; 16-- 20 r90=[r86+0xc] :issue,iu,wb ;; 19-- 21 [r85+0xc]=r90 :issue,iu,wb ;; 20-- 22 r91=[r86+0x10] :issue,iu,wb ;; 23-- 23 [r85+0x10]=r91 :issue,iu,wb ;; 24-- 26 [r84+0xc]=r92 :issue,iu,wb ;; 25-- 31 clobber r3 :nothing ;; 25-- 36 use r3 :nothing ;; Ready list (final): ;; total time = 25 ;; new head = 7 ;; new tail = 36 There is an obvious better schedule to be obtained. Here is one such (hand-modified) schedule which just pipelines two of the loads to obtain a shorter critical path length to the whole function (function has only bb 0) ;;0-- 6r84=r5 :issue,iu,wb ;;1-- 13 r86=[`Ptr_Glob'] :issue,iu,wb ;;2-- 25 r92=0x5:issue,iu,wb ;;3-- 12 r85=[r84] :issue,iu,wb ;;4-- 14 r87=[r86] :issue,iu,wb ;;7-- 15 [r85]=r87 :issue,iu,wb ;;8-- 16 r88=[r86+0x4] :issue,iu,wb ;;9-- 18 r89=[r86+0x8] :issue,iu,wb ;; 10-- 20 r90=[r86+0xc] :issue,iu,wb ;; 11-- 17 [r85+0x4]=r88 :issue,iu,wb ;; 12-- 19 [r85+0x8]=r89 :issue,iu,wb ;; 13-- 21 [r85+0xc]=r90 :issue,iu,wb ;; 14-- 22 r91=[r86+0x10] :issue,iu,wb ;; 17-- 23 [r85+0x10]=r91 :issue,iu,wb ;; 18-- 26 [r84+0xc]=r92 :issue,iu,mb_wb ;; 19-- 31 clobber r3 :nothing ;; 20-- 36 use r3 :nothing ;; Ready list (final): ;; total time = 20 ;; new head = 7 ;; new tail = 36 This schedule is 5 cycles faster. I have read and re-read the material surrounding the DFA scheduler. I understand that the heuristics optimize critical path length and not stalls or other metrics. But in this case it is precisely the critical path length that is shortened by the better schedule. I have been examining various hooks available and for a while it seemed like TARGET_SCHED_FIRST_CYCLE_MULTIPASS_DFA_LOOKAHEAD must be set to a larger window to look for better candidates to schedule into the ready queue. For instance, this discussion seems to say so. http://gcc.gnu.org/ml/gcc/2002-05/msg01132.html But a post that follows soon after seems to imply otherwise. http://gcc.gnu.org/ml/gcc/2002-05/msg01388.html Both posts are from Vladimir. In any case the final conclusion seems to be that the lookahead is useful only for multi-issue processors. So what is wrong in my description? How do I
Re: RFC: Hack to make restrict more useful
On Sun, 2 Sep 2007, Mark Mitchell wrote: Daniel Berlin wrote: Again, I'd love to just ignore this and say we don't care. Ugh. I think you're right that the standard says that we only get to assume non-aliasing when the pointed-to memory is modified, so all-parameters-restrict is actually weaker than -fargument-noalias. How unfortunate. I've CC'd Joseph in the hopes that his C standards knowledge will suggest a different answer. The rules that unmodified memory may alias were a deliberate change in the FDIS relative to the previous public draft; see http://www.open-std.org/jtc1/sc22/wg14/www/docs/n866.htm: 24 1. The FCD specification of restrict forbids aliasing of 25 unmodified objects. Doing so does not promote optimization, 26 and has other disadvantages, which are discussed in examples 27 A-E below. It is also contrary to the prior art in Fortran. -- Joseph S. Myers [EMAIL PROTECTED]
Re: DFA Scheduler - unable to pipeline loads
Matt Lee wrote: Hi, I am working with GCC-4.1.1 on a simple 5-pipe stage simple scalar RISC processors with the following description for loads and stores, (define_insn_reservation integer 1 (eq_attr type branch,jump,call,arith,darith,icmp,nop) issue,iu,wb) (define_insn_reservation load 3 (eq_attr type load) issue,iu,wb) (define_insn_reservation store 1 (eq_attr type store) issue,iu,wb) I am seeing poor scheduling in Dhrystone where a memcpy call is expanded inline. memcpy (dst, src, 16) == load 1, rA + 4 store 1, rB + 4 load 2, rA + 8 store 2, rB + 8 ... I agree with Adam, that this is most probably an aliasing issue. Take a look at the dependency map (you can get it with -fsched-verbose=6 flag in your command line). -- Maxim
Re: question about rtl loop-iv analysis
Zdenek's patch here - http://gcc.gnu.org/ml/gcc-patches/2007-08/msg02291.html - solved the problem. Kenny, Zdenek - many thanks for solving this issue! dorit Seongbae Park (박성배, 朴成培) [EMAIL PROTECTED] wrote on 29/08/2007 01:01:42: On 8/28/07, Zdenek Dvorak [EMAIL PROTECTED] wrote: ... that obviously is not the case here, though. Do you (or someone else responsible for df) have time to have a look at this problem? Otherwise, we may discuss it forever, but we will not get anywhere. Zdenek Open a PR and assign it to me, if you're not in a hurry - I should be able to look at it next week. Thanks! This is PR33224 dorit -- #pragma ident Seongbae Park, compiler, http://seongbae.blogspot.com;
has_volatile_ops and early optimization w/o alias information
We set has_volatile_ops on all(?) memory references during early
optimization because we don't have alias information. But we
do it inconsistently for loads. For example I see
D.2574_23 = *D.2573_22;
(no volatile) and
D.2565_28 ={v} tab[D.2560_27].__delta;
(volatile). Because for indirect references we also check
/* Aliasing information is missing; mark statement as
volatile so we won't optimize it out too actively. */
else if (!gimple_aliases_computed_p (cfun)
(flags opf_def))
s_ann-has_volatile_ops = true;
so only add has_volatile_ops if we would create a DEF. Now the
other place is in the generic add_virtual_operand like
if (aliases == NULL)
{
if (!gimple_aliases_computed_p (cfun))
s_ann-has_volatile_ops = true;
and so also marks load. Which one is safe? I suppose it is safe
to DCE loads even without alias information? So I'd add the check
for a DEF also in the generic add_virtual_operand code.
Thanks for clarification.
Richard.
About allocating registers for instrumentation
Hi, I am working on gcc-4.1.1 and Itanium architecture. Current now I have finished instrumenting ld and st instructions before the second scheduling pass by reserving two global registers at backend. However, in order to enhance the performance (e.g. make the scheduling better), I choose to allocate two registers for each instrumentation instead of using the reserved ones. To identify which registers I can use for each ld and st instruction, I follow the following idea: For each insn, I compute its live-in and live-out by starting from the basic-block: as we can get the live-in of the basic-block, then, for INSN(N) in the basic-block, (1) live-in[ INSN(N) ] = live-out [ INSN(N-1) ] (2) live-out[ INSN(N) ] = (live-in [ INSN(N) ] U set) -(REG_DEAD U REG_UNUSED) where set is the set of registers set by the insn, and REG_DEAD, REG_UNUSED can be got from the insn notes. Then, R-( live-in[INSN(N)] U live-out[INSN(N)] ) is the set of registers I can use to instrument INSN(N). (here R is a set of registers I specified, for example, all the caller-save global general registers) Am I right? or is there any thing I mis-understand, if any, please point out, thanks! Further, how to identify SET in (1) ? I have found many of the insns just before the second scheduling have only one set in it. If this is hold for all insns, I think I can use the single_set to get SET. Is there any exception for that? thanks again Wu
Re: RFC: Hack to make restrict more useful
Joseph S. Myers wrote: The rules that unmodified memory may alias were a deliberate change in the FDIS relative to the previous public draft; see http://www.open-std.org/jtc1/sc22/wg14/www/docs/n866.htm: That explains why I had no memory of this, despite having researched restrict pretty carefully in earlier drafts. That also explains why other compilers in the field implements restrict as meaning does not alias, independent of what's modified. Danny, does your more comprehensive treatment of restrict still optimize test cases like the one in the PR I filed? In any case, I guess we should consider my patch withdrawn. Although, if the new meaning of restrict matches standard Fortran semantics, then our Fortran handling must be wrong, since all my patch did was make us match our current Fortran semantics. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: RFC: Hack to make restrict more useful
In any case, I guess we should consider my patch withdrawn. Although, if the new meaning of restrict matches standard Fortran semantics, then our Fortran handling must be wrong, since all my patch did was make us match our current Fortran semantics. In Fortran the pointers are not exposed at the language level, so it's probably much harder to construct a cases where this matters. Paul
Re: RFC: Hack to make restrict more useful
Mark Mitchell wrote: Joseph S. Myers wrote: The rules that unmodified memory may alias were a deliberate change in the FDIS relative to the previous public draft; see http://www.open-std.org/jtc1/sc22/wg14/www/docs/n866.htm: That explains why I had no memory of this, despite having researched restrict pretty carefully in earlier drafts. That also explains why other compilers in the field implements restrict as meaning does not alias, independent of what's modified. Danny, does your more comprehensive treatment of restrict still optimize test cases like the one in the PR I filed? Test cases of mine, which fail to optimize, involve a scalar argument, performing arithmetic between a scalar and an array. In the C case, -fargument-noalias brings optimization, which is not promoted by restrict keyword. Using an explicit local copy of the argument should work as well. Could that be a reason for avoiding the optimization? I think the likely use of restrict by various compilers comes into play only when a possibly aliased variable is modified, as pointed out previously. Such optimization could result in broken results anyway, wwhen array bounds violations occur, so I guess there's no way to check, other than by extending bounds checking.
Re: RFC: Hack to make restrict more useful
On 9/3/07, Richard Guenther [EMAIL PROTECTED] wrote: On 9/3/07, Daniel Berlin [EMAIL PROTECTED] wrote: On 9/2/07, Paul Brook [EMAIL PROTECTED] wrote: That said, second, my understanding of restrict, from reading the c99 standard, is that it is perfectly valid for restrict pointers to alias each other during *loads*.. IE you can guarantee any restricted pointer that is stored into can't alias the other restricted pointers. Those only used for loads can alias each other. How does it make a difference? If for two pointers that are only loaded from we say they don't alias I cannot imagine a transformation that would get anything wrong. Easy answer: Dependence testing and then loop transforms. Given p[i] = a[i] + b[i], if you claim a and b can't alias, you will now claim that a[i] and b[i] don't access the same memory on the same iteration. We could easily use this and some profit estimation to decide to say, change the iteration space of a but not b,which will break since they really do alias, and breaking this is bad because they are allowed to. Eh? Maybe I'm blind, but how can a change in iteration space that is valid for the non-aliasing case be invalid for the aliasing case _if we do not modify any data_? You may be right, but it just means we have to be very careful where we use the data if there are no modifications. I'm not sure the best way to go about this. Right now, i attached restrict info to SSA_NAME's, and we use it in access_can_touch_variable, may_alias_p, and the dataref version of this. Sadly though, it also means we can't use restricted pointers to say anything about non-restricted pointers unless their is modification either. IE int foo(int *a, restrict *b), doesn't guarantee a and b don't alias unless there is a modification of one of them. --Dan
Re: RFC: Hack to make restrict more useful
On 9/3/07, Daniel Berlin [EMAIL PROTECTED] wrote: On 9/3/07, Richard Guenther [EMAIL PROTECTED] wrote: On 9/3/07, Daniel Berlin [EMAIL PROTECTED] wrote: On 9/2/07, Paul Brook [EMAIL PROTECTED] wrote: That said, second, my understanding of restrict, from reading the c99 standard, is that it is perfectly valid for restrict pointers to alias each other during *loads*.. IE you can guarantee any restricted pointer that is stored into can't alias the other restricted pointers. Those only used for loads can alias each other. How does it make a difference? If for two pointers that are only loaded from we say they don't alias I cannot imagine a transformation that would get anything wrong. Easy answer: Dependence testing and then loop transforms. Given p[i] = a[i] + b[i], if you claim a and b can't alias, you will now claim that a[i] and b[i] don't access the same memory on the same iteration. We could easily use this and some profit estimation to decide to say, change the iteration space of a but not b,which will break since they really do alias, and breaking this is bad because they are allowed to. Eh? Maybe I'm blind, but how can a change in iteration space that is valid for the non-aliasing case be invalid for the aliasing case _if we do not modify any data_? You may be right, but it just means we have to be very careful where we use the data if there are no modifications. I'm not sure the best way to go about this. Right now, i attached restrict info to SSA_NAME's, and we use it in access_can_touch_variable, may_alias_p, and the dataref version of this. I think this should be ok. Sadly though, it also means we can't use restricted pointers to say anything about non-restricted pointers unless their is modification either. IE int foo(int *a, restrict *b), doesn't guarantee a and b don't alias unless there is a modification of one of them. Well, that is probably to make handling of contrieved derivations of a restrict pointer conservatively correct. That is, for example restrict int *p; int pi = (int)p; *(int *)p = 1; just assuming that there are derivations that PTA cannot deal with. The way the standard is written it's just for a safe default. Richard.
gcc-4.1-20070903 is now available
Snapshot gcc-4.1-20070903 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20070903/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.1 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_1-branch revision 128061 You'll find: gcc-4.1-20070903.tar.bz2 Complete GCC (includes all of below) gcc-core-4.1-20070903.tar.bz2 C front end and core compiler gcc-ada-4.1-20070903.tar.bz2 Ada front end and runtime gcc-fortran-4.1-20070903.tar.bz2 Fortran front end and runtime gcc-g++-4.1-20070903.tar.bz2 C++ front end and runtime gcc-java-4.1-20070903.tar.bz2 Java front end and runtime gcc-objc-4.1-20070903.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.1-20070903.tar.bz2The GCC testsuite Diffs from 4.1-20070827 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.1 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
[Bug fortran/33288] New: ICE (segfault) in mpfr_cmp2 when evaluating array initializers containing addition
gfortran 4.1.2/4.2.0/4.3.0 segfaults when compiling the following program: program initbug integer,parameter :: n0 = 3, n = 5 real(kind=8),parameter :: x0(n0) = (/ 0.0d0, 0.0d0, 0.0d0 /) real(kind=8),parameter :: x(n) = (/ -x0, x0(n0-1:1:-1) /) + 1.0d0 end program initbug Valgrind output: $ valgrind /home/r6144/apps/gcc-4.3.0-070903-bin/bin/../libexec/gcc/i386-pc-linux-gnu/4.3.0/f951 initbug.f90 -quiet -dumpbase initbug.f90 -march=pentium4 -mfpmath=sse -auxbase-strip initbug.o -g -O2 -Wall -W -Wno-unused -Wimplicit-interface -Wtabs -version -ffree-form -ffree-line-length-none -fimplicit-none -ffpe-trap=invalid,zero,overflow -fintrinsic-modules-path /home/r6144/apps/gcc-4.3.0-070903-bin/bin/../lib/gcc/i386-pc-linux-gnu/4.3.0/finclude -o /tmp/ccZfWmpd.s ==5331== Memcheck, a memory error detector. ==5331== Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et al. ==5331== Using LibVEX rev 1658, a library for dynamic binary translation. ==5331== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP. ==5331== Using valgrind-3.2.1, a dynamic binary instrumentation framework. ==5331== Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et al. ==5331== For more details, rerun with: -v ==5331== GNU F95 (GCC) version 4.3.0 20070902 (experimental) [trunk revision 128023] (i386-pc-linux-gnu) compiled by GNU C version 4.3.0 20070902 (experimental) [trunk revision 128023], GMP version 4.2.1, MPFR version 2.2.1. GGC heuristics: --param ggc-min-expand=63 --param ggc-min-heapsize=63256 ==5331== Invalid read of size 4 ==5331==at 0x84CCEDB: mpfr_cmp2 (in /home/r6144/apps/gcc-4.3.0-070903-bin/libexec/gcc/i386-pc-linux-gnu/4.3.0/f951) ==5331==by 0x84C6D35: mpfr_sub1 (in /home/r6144/apps/gcc-4.3.0-070903-bin/libexec/gcc/i386-pc-linux-gnu/4.3.0/f951) ==5331==by 0x84B9AB2: mpfr_add (in /home/r6144/apps/gcc-4.3.0-070903-bin/libexec/gcc/i386-pc-linux-gnu/4.3.0/f951) ==5331==by 0x804CB56: gfc_arith_plus (arith.c:657) ==5331== Address 0x812488 is not stack'd, malloc'd or (recently) free'd initbug.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. -- Summary: ICE (segfault) in mpfr_cmp2 when evaluating array initializers containing addition Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rainy6144 at gmail dot com GCC build triplet: i386-pc-linux-gnu GCC host triplet: i386-pc-linux-gnu GCC target triplet: i386-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33288
[Bug fortran/33288] ICE (segfault) in mpfr_cmp2 when evaluating array initializers containing addition
--- Comment #1 from dominiq at lps dot ens dot fr 2007-09-03 07:39 --- I don't see the ICE on PPC Darwin8, revision 128037, but the following modifed code gives a wrong answer: program initbug integer,parameter :: n0 = 3, n = 5 real(kind=8),parameter :: x0(n0) = (/ 2.0d0, 2.0d0, 2.0d0 /) real(kind=8),parameter :: x(n) = (/ -x0, x0(n0-1:1:-1) /) + 1.0d0 print *, x end program initbug gives -1.00 -1.00 -1.00 1.000.00 xlf and g95 gives: -1.0 -1.0 -1.0 3.0 3.0 or -1. -1. -1. 3. 3. as I expect. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33288
[Bug c++/33289] New: [4.2/4.3 Regression] __sprintf_chk etc. not DECL_ANTICIPATED
typedef __SIZE_TYPE__ size_t; extern C int __sprintf_chk (char *__restrict, int, size_t, const char *, ...) throw (); extern C int __sprintf_chk (char *__restrict, int, size_t, const char *, ...) throw (); fails to compile with: /tmp/4.C:3: error: declaration of 'int __sprintf_chk(char*, int, size_t, const char*, ...) throw ()' throws different exceptions /tmp/4.C:2: error: from previous declaration 'int __sprintf_chk(char*, int, long unsigned int, const char*, ...)' (but compiles with -fno-builtin-__sprintf_chk). Surprisingly, similar testcase with say __memcpy_chk compiles just fine. The problem is that when we create builtins, 1) ATTR_NOTHROW among builtin attributes causes just TREE_NOTHROW being set, but doesn't create any kind of exception specification 2) the C++ FE sets DECL_ANTICIPATED only on builtins that don't start with two underscores. I wonder why the limitation on DECL_ANTICIPATED, I can understand that for __builtin_* or __sync_*, but __*_chk when not __builtin___*_chk should be IMHO DECL_ANTICIPATED. Also, at least for Linux NOTHROW on printf, fprintf etc. is wrong, only sprintf/snprintf can't throw, printf/fprintf/scanf etc. are (optional) cancellation points and during pthread_cancel can cause forced unwinding. -- Summary: [4.2/4.3 Regression] __sprintf_chk etc. not DECL_ANTICIPATED Product: gcc Version: 4.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ 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=33289
[Bug fortran/33288] ICE (segfault) in mpfr_cmp2 when evaluating array initializers containing addition
--- Comment #2 from burnus at gcc dot gnu dot org 2007-09-03 09:34 --- I don't see the ICE on PPC Darwin8, revision 128037, but the following modifed code gives a wrong answer: For me (4.3.0 20070903, r128037, x86_64-unknown-linux-gnu) both examples cause a segmentation fault in mpfr_cmp2. Interestingly, I don't get any failure if I run the program through valgrind. -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||burnus at gcc dot gnu dot ||org OtherBugsDependingO||32834 nThis|| Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC build triplet|i386-pc-linux-gnu | GCC host triplet|i386-pc-linux-gnu | GCC target triplet|i386-pc-linux-gnu | Keywords||ice-on-valid-code Known to fail||4.1.3 4.2.2 4.3.0 Last reconfirmed|-00-00 00:00:00 |2007-09-03 09:34:53 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33288
[Bug fortran/33288] ICE (segfault) in mpfr_cmp2 when evaluating array initializers containing addition
--- Comment #3 from dominiq at lps dot ens dot fr 2007-09-03 09:43 --- If I try to regtestify the code (uncomment the commented line): program initbug integer,parameter :: n0 = 3, n = 5 real(kind=8),parameter :: x0(n0) = (/ 2.0d0, 2.0d0, 2.0d0 /) real(kind=8),parameter :: x(n) = (/ -x0, x0(n0-1:1:-1) /) + 1.0d0 print *, x ! if (any(x /= (/ -1.0d0, -1.0d0, -1.0d0, 3.0d0, 3.0d0 /))) call abort() end program initbug I get: [karma] f90/bug% gfc pr33288.f90 pr33288.f90:4.37: real(kind=8),parameter :: x(n) = (/ -x0, x0(n0-1:1:-1) /) + 1.0d0 1 Error: Array operands are incommensurate at (1) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33288
[Bug fortran/33271] nint_2.f90 abort compiled with -O0
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2007-09-03 10:04
---
(In reply to comment #3)
A) I see that you and others put a number of patches and regenerations. Do you
want me to rebootstrap and then do it?
I don't think we've touched anything who should affect this since you filed the
PR, so no real need to update.
It starts to sound like a library problem... could you compile and run the
following C source:
#include stdio.h
#include stdlib.h
int main (void)
{
double a;
float b;
int j1, j2;
long long int i1, i2;
printf (%lu %lu %lu\n, sizeof(int), sizeof(long int), sizeof(long long
int));
a = 4.99944488848768742172978818416595459e-1L;
i2 = 0;
i1 = (long long int) __builtin_lround (a);
if (i1 != 0 || i2 != 0)
puts (Abort 1);
a = 5.0e-1L;
i2 = 1;
i1 = (long long int) __builtin_lround (a);
if (i1 != 1 || i2 != 1)
puts (Abort 2);
a = 5.00111022302462515654042363166809082e-1L;
i2 = 1;
i1 = (long long int) __builtin_lround (a);
if (i1 != 1 || i2 != 1)
puts (Abort 3);
b = 4.99701976776123046875e-1;
j2 = 0;
j1 = (int) __builtin_lroundf (b);
if (j1 != 0 || j2 != 0)
puts (Abort 4);
b = 5.0e-1;
j2 = 1;
j1 = (int) __builtin_lroundf (b);
if (j1 != 1 || j2 != 1)
puts (Abort 5);
b = 5.0059604644775390625e-1;
j2 = 1;
j1 = (int) __builtin_lroundf (b);
if (j1 != 1 || j2 != 1)
puts (Abort 6);
a = 4.503599627370497e+15L;
i1 = __builtin_llround (a);
i2 = 4503599627370497;
if (i1 != i2 || i1 != 4503599627370497)
puts (Abort 7);
a = -4.503599627370497e+15L;
i1 = __builtin_llround (a);
i2 = -4503599627370497;
if (i1 != i2 || i1 != -4503599627370497)
puts (Abort 8);
return 0;
}
(gcc a.c -lm -W -Wall; try with -O0 and -O1, I expect it will fail only at
-O0).
One last question: in your build tree, you should have a file named
${builddir}/${target_triplet}/libgfortran/config.h. How does it define the
macros HAVE_LLROUND, HAVE_LLROUNDF, HAVE_LLROUNDL, HAVE_LROUND, HAVE_LROUNDF
and HAVE_LROUNDL?
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Keywords||wrong-code
Last reconfirmed|-00-00 00:00:00 |2007-09-03 10:04:32
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33271
[Bug fortran/33261] gfortran 4.3.0 doesn't work on Windows Vista.
--- Comment #5 from joerg dot richter at gedas dot de 2007-09-03 10:05 --- Subject: AW: [SPAM Verdacht] - gfortran 4.3.0 doesn't work on Windows Vista. - Bayesian Filter detected spam Dear Sir, I am sending You the output generated by gfortran 4.3.0 (Version 20070813)using the command gfortran -v lax3kern.f 2 430-output-20070813.txt Best regards and many thanks in advance, Joerg Richter -Ursprüngliche Nachricht- Von: fxcoudert at gcc dot gnu dot org [mailto:[EMAIL PROTECTED] Gesendet: Freitag, 31. August 2007 12:32 An: [EMAIL PROTECTED] Betreff: [SPAM Verdacht] - [Bug fortran/33261] gfortran 4.3.0 doesn't work on Windows Vista. - Bayesian Filter detected spam --- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-08-31 10:32 --- Can you paste (or attach as a file) the output of gfortran -v name.f? In the error message you get: unrecognized command line option -fintrinsic-modules path what exactly is the character between -fintrinsic-modules and path? (There should be a - here, the option name is -fintrinsic-modules-path) Is that a regular space, another character? (if you can't tell, please redirect output to a file, zip it and attach it here; I'm afraid copy-pasting into bugzilla might play games with special characters) -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org Severity|blocker |normal GCC build triplet||i386-pc-mingw32 GCC host triplet||i386-pc-mingw32 GCC target triplet||i386-pc-mingw32 Summary|gfortran 4.3.0 did not start|gfortran 4.3.0 doesn't work |compiling on Windows Vista. |on Windows Vista. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33261 --- You are receiving this mail because: --- You reported the bug, or are watching the reporter. --- Comment #6 from joerg dot richter at gedas dot de 2007-09-03 10:05 --- Created an attachment (id=14151) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14151action=view) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33261
[Bug fortran/33288] ICE (segfault) in mpfr_cmp2 when evaluating array initializers containing addition
--- Comment #4 from burnus at gcc dot gnu dot org 2007-09-03 10:12 --- The following does not ICE for me and produces the right result (note the extra +0.0): real,parameter :: x(n) = (/ -x0, x0(n0-1:1:-1) + 0.0 /) +1.0 analogously for (note extra (...)): real,parameter :: x(n) = (/ -x0, ( x0(n0-1:1:-1) ) /) +1.0 Seemingly, the array range x0(n0-1:1:-1) does not get properly simplified and thus -value.real points to the nirvana. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Keywords||wrong-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33288
[Bug fortran/33261] gfortran 4.3.0 doesn't work on Windows Vista.
--- Comment #7 from fxcoudert at gcc dot gnu dot org 2007-09-03 10:25 --- The output you posted shows that you have gfortran-4.3.0 in your path but you also have a f951 binary coming from a G95 installation (it says: G95 Fortran 95 version 4.0.3 (g95 0.90!) Jul 27 2006). What happens is that gfortran calls the f951 executable (it's the compiler itself, the gfortran binary is just a driver program setting the environment up and calling compiler, assembler and linker) from g95 instead of its own. Please either uninstall that old g95 or at least remove its directories from your PATH environment variable when compiling with gfortran. I'm closing this bug as INVALID, but please feel free to post further comments if you were to need more help (or open a new bug report if you have another unrelated issue). -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33261
[Bug fortran/33281] gfortran crt2.o not found under Vista
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-09-03 10:40 --- (In reply to comment #0) I'm trying to run gfortran under Windows Vista. Do you compile yourself or use pre-made binaries (and which binaries)? What version of gfortran do you use? If you build the compiler yourself, do you use cygwin or mingw? I ran into ld: crt2.o: No such file. I've found several reports on this, but no solution... What does the compiler say when you add the -v flag? (gfortran -v myfile.f90) What is the value of your PATH environment variable? -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33281
[Bug fortran/33282] [4.2] ICE in find_array_section when using vector subscripts
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-09-03 10:42 --- Unless this is a regression, won't be fixed. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED GCC build triplet|i686-pc-linux-gnu | GCC host triplet|i686-pc-linux-gnu | GCC target triplet|i686-pc-linux-gnu | Resolution||WONTFIX Summary|ICE in find_array_section |[4.2] ICE in |when using vector subscripts|find_array_section when ||using vector subscripts http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33282
[Bug fortran/33252] GCC-4.3.0 Bootstrap testsuite error increase
--- Comment #16 from fxcoudert at gcc dot gnu dot org 2007-09-03 10:44 --- The Fortran part has its PR, I saw a PR for some C problem also, so I'm closing this. If other you experience other powerpc regressions, please open new PRs. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33252
[Bug fortran/33288] ICE (segfault) in mpfr_cmp2 when evaluating array initializers containing addition
--- Comment #5 from dominiq at lps dot ens dot fr 2007-09-03 11:01 --- I confirm that program initbug integer,parameter :: n0 = 3, n = 5 real(kind=8),parameter :: x0(n0) = (/ 2.0d0, 2.0d0, 2.0d0 /) real(kind=8),parameter :: x(n) = (/ -x0, x0(n0-1:1:-1) + 0.0d0 /) + 1.0d0 print *, x if (any(x /= (/ -1.0d0, -1.0d0, -1.0d0, 3.0d0, 3.0d0 /))) call abort() end program initbug works as expected. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33288
[Bug middle-end/33290] New: [4.3 Regression] gcc.c-torture/execute/930921-1.c fails at -O1 and above now
+++ This bug was initially created as a clone of Bug #33283 +++ [18:22] apinski /home/apinski/src/local/gcc/gcc/testsuite/gcc.c-torture/execute/930921-1.c:5: error: could not split insn^M [18:22] apinski new failure [18:23] apinski on ppc-linux-gnu [18:23] apinski between 127935 and 128000 [18:32] Rhyolite I guess it could be due to my predicate change [18:33] apinski this was after that [18:33] Rhyolite okay, phew [18:33] apinski paired support was inbetween that though [18:33] Rhyolite sigh [18:34] Rhyolite Revital said that she regression tested [18:34] apinski but also Sandra's regclass changes [18:34] apinski and some optabs changes [18:34] apinski so it could be either of those three And then from PR 33277 #3: Fromp http://gcc.gnu.org/ml/gcc-testresults/, looking at the results from regress, it can be narrowed between 127961 (working) and 127997 (non working). Note that the last change of final.c is 127941 (outside the range). From an uneducated guess, I'l say 127989, but I may be completely wrong. And from #4: From looking closer to the changes, the scheduler changes is not likely because this happens at -O1 :) I am more thinking it was: 2007-08-31 Richard Sandiford [EMAIL PROTECTED] Which changed optabs which is part of the expansion. The IV change could not have cause this issue as there is no loop in that function so the last change would be the optabs change. Note I am going to start cloning this bug until all the offtopic stuff stops being added. -- Summary: [4.3 Regression] gcc.c-torture/execute/930921-1.c fails at -O1 and above now 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: pinskia at gcc dot gnu dot org GCC target triplet: powerpc-*-* (32bits) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33290
[Bug middle-end/33290] [4.3 Regression] gcc.c-torture/execute/930921-1.c fails at -O1 and above now
-- 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=33290
[Bug middle-end/33283] [4.3 Regression] gcc.c-torture/execute/930921-1.c fails at -O1 and above now
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-09-03 11:17 --- Closing as offtopic stuff was added again. Maybe I should mention something about 4.2.x, gentoo also decided to use it :). And it is not a bad release, 4.2.1 is much better. If glibc does not build with 4.2.1, that does not mean GCC is at fault really. I think people should blaming GCC all the time when it comes to building code. Kernel folks have the same issue. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33283
[Bug tree-optimization/33291] New: a+=2; a+=2 not simplified to a+=4; with -O3 (ok with gcc-4.2.1)
I triggered this is the inner loop of the CPU emulation code of openMSX
(http://openmsx.sf.net/). I tried to reduce the code. Below is the smallest
code I could come with up that still shows the problem:
---
struct Clock {
void f();
void add(unsigned n) { a += n; }
int a;
};
struct CPU : Clock {
virtual ~CPU();
unsigned char readSlow();
void execute();
void delay() { add(2); }
unsigned char readFast() {
if (unsigned char* p = ptrs[addr 8]) {
// fast-path
delay(); // ### 1
delay(); // ### 2
return p[addr 255];
} else {
// slow-path
return readSlow();
}
}
typedef void (CPU::*FuncPtr)();
static FuncPtr tab[256];
unsigned char* ptrs[256];
unsigned addr;
};
void CPU::execute() {
f();
while (true) {
unsigned char b = readFast();
delay(); // # 3
(this-*tab[b])();
}
}
When compiled with SVN revision 128037 on a linux x86_64 machine:
g++ -O3 -S CPU.ii
cat -n CPU.s
1 .file CPU.ii
2 .text
3 .align 2
4 .p2align 4,,15
5 .globl _ZN3CPU7executeEv
6 .type _ZN3CPU7executeEv, @function
7 _ZN3CPU7executeEv:
8 .LFB5:
9 pushq %rbp
10 .LCFI0:
11 leaq8(%rdi), %rbp
12 pushq %rbx
13 .LCFI1:
14 movq%rdi, %rbx
15 movq%rbp, %rdi
16 subq$8, %rsp
17 .LCFI2:
18 call_ZN5Clock1fEv
19 .p2align 4,,10
20 .p2align 3
21 .L6:
22 movl2064(%rbx), %eax
23 shrl$8, %eax
24 mov %eax, %eax
25 movq16(%rbx,%rax,8), %rdx
26 testq %rdx, %rdx
27 je .L2
28 movl8(%rbx), %eax###
29 addl$2, %eax ### 1
30 movl%eax, (%rbp) ###
31 movl8(%rbx), %eax###
32 addl$2, %eax ### 2
33 movl%eax, (%rbp) ###
34 movzbl 2064(%rbx), %eax
35 movzbl (%rdx,%rax), %edx
36 .L3:
37 movl8(%rbx), %eax#
38 addl$2, %eax # 3
39 movl%eax, (%rbp) #
40 movzbl %dl, %eax
41 salq$4, %rax
42 movq_ZN3CPU3tabE(%rax), %rdx
43 testb $1, %dl
44 jne .L4
45 movq%rbx, %rdi
46 addq_ZN3CPU3tabE+8(%rax), %rdi
47 call*%rdx
48 jmp .L6
49 .p2align 4,,10
50 .p2align 3
51 .L4:
52 movq%rbx, %rdi
53 addq_ZN3CPU3tabE+8(%rax), %rdi
54 movq(%rdi), %rax
55 movq-1(%rdx,%rax), %rdx
56 call*%rdx
57 jmp .L6
58 .L2:
59 movq%rbx, %rdi
60 call_ZN3CPU8readSlowEv
61 movl%eax, %edx
62 .p2align 4,,4
63 .p2align 3
64 jmp .L3
[skipped the rest of the output]
The missed optimization is visible in lines 28-33. It's also strange to me why
reading the variable is done via 8(%rbx) while writing is done via (%rbp).
gcc-4.2.1 does a better job on this, it optimizes the two consecutive delay()
functions to just: addl $4, 8(%rbx)
Additionally I would have prefered that all three delay() functions would be
collapsed into a single instruction in the fast code path (and partly
duplicated as a+=4; readSlow(); a+=2; in the slow path). But I understand
this might be more difficult to implement.
--
Summary: a+=2; a+=2 not simplified to a+=4; with -O3 (ok
with gcc-4.2.1)
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: wouter dot vermaelen at scarlet dot be
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33291
[Bug tree-optimization/33291] a+=2; a+=2 not simplified to a+=4; with -O3 (ok with gcc-4.2.1)
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-09-03 11:28 --- # VUSE tab_56, SMT.9_58, SMT.10_60 D.2581_35 = this_2(D)-D.2503.a; D.2582_36 = (unsigned int) D.2581_35; D.2583_37 = D.2582_36 + 2; D.2584_38 = (int) D.2583_37; # tab_76 = VDEF tab_56 # SMT.9_77 = VDEF SMT.9_58 D.2529_3-a = D.2584_38; # VUSE tab_76, SMT.9_77, SMT.10_60 D.2586_40 = this_2(D)-D.2503.a; D.2587_41 = (unsigned int) D.2586_40; D.2588_42 = D.2587_41 + 2; D.2589_43 = (int) D.2588_42; # tab_78 = VDEF tab_76 # SMT.9_79 = VDEF SMT.9_77 D.2529_3-a = D.2589_43; hmmm, aliasing -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|minor |normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33291
[Bug fortran/33288] ICE (segfault) in mpfr_cmp2 when evaluating array initializers containing addition
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2007-09-03 11:31 --- (In reply to comment #4) Seemingly, the array range x0(n0-1:1:-1) does not get properly simplified and thus -value.real points to the nirvana. Nope. I get an ICE for the following testcase: real, parameter :: x0(1) = 0 real, parameter :: x(1) = (/ x0 /) + 1 end The problem is that we come into gfc_arith_plus() with one operand being an EXPR_ARRAY, so looking at its value.real is wrong (if you want to do something with it, it's value.constructor that should be looked at). I guess reduce_binary_ac() should really look deeper: in the loop for (c = head; c; c = c-next), we should see whether c-expr is an EXPR_CONSTANT before calling eval(), and look deeper into it if it's an EXPR_ARRAY. (Though it's the first time I look at this code and array constructors, I might be misunderstanding it all.) -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33288
[Bug fortran/29396] segfault with character pointer association
-- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2007-03-16 15:15:54 |2007-09-03 11:46:39 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29396
[Bug fortran/29606] Internal Error: Derived type I/O should have been handled via the frontend
-- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2007-02-10 21:16:09 |2007-09-03 11:47:31 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29606
[Bug fortran/30625] Array pointers to components of derived type arrays do not work
-- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2007-01-28 20:33:48 |2007-09-03 11:48:03 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30625
[Bug fortran/30871] Pointer to substring rejected with Different character lengths in pointer assignment
-- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2007-04-10 15:14:17 |2007-09-03 11:48:57 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30871
[Bug tree-optimization/33291] a+=2; a+=2 not simplified to a+=4; with -O3 (ok with gcc-4.2.1)
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-09-03 12:01 --- The problem is that forwprop doesn't propagate addr_exprs to memory reference stmts in early optimization anymore (due to the volatile issues) and value numbering cannot deal with the different (but same) load/store addresses: D.2605_34 = this_2(D)-D.2527; # VUSE tab_57, SMT.9_59, SMT.11_63 D.2606_35 = this_2(D)-D.2527.a; ... # tab_77 = VDEF tab_57 # SMT.11_78 = VDEF SMT.11_63 D.2605_34-a = D.2609_38; (also aliasing computes different answers here, for whatever reason). With scheduling an extra forwprop pass before FRE the second _load_ of a is eliminated, but DSE still cannot figure the dead store: # VUSE tab_57, SMT.9_59, SMT.11_63 D.2606_35 = this_2(D)-D.2527.a; D.2607_36 = (unsigned int) D.2606_35; D.2608_37 = D.2607_36 + 2; D.2609_38 = (int) D.2608_37; # tab_77 = VDEF tab_57 # SMT.9_93 = VDEF SMT.9_59 # SMT.11_78 = VDEF SMT.11_63 this_2(D)-D.2527.a = D.2609_38; D.2612_41 = (unsigned int) D.2609_38; D.2613_42 = D.2612_41 + 2; D.2614_43 = (int) D.2613_42; # tab_79 = VDEF tab_77 # SMT.9_94 = VDEF SMT.9_93 # SMT.11_80 = VDEF SMT.11_78 this_2(D)-D.2527.a = D.2614_43; -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||alias, missed-optimization Last reconfirmed|-00-00 00:00:00 |2007-09-03 12:01:47 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33291
[Bug middle-end/33290] [4.3 Regression] gcc.c-torture/execute/930921-1.c fails at -O1 and above now
--- Comment #1 from rsandifo at gcc dot gnu dot org 2007-09-03 12:04 --- Created an attachment (id=14152) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14152action=view) Proposed patch It was indeed my fault, sorry. When doing a 32x32-64 multiplication, CONST_INTs are interpreted in the target mode (DImode). We were forcing such a CONST_INT into an SImode register without sign-extending it first. The attached patch seems to fix the testcase. I'm testing on x86_64-linux-gnu. Could someone with access to PowerPC GNU/Linux or Darwin please test it too? I could do before-and-after tests for powerpc-eabisim, but it'd probably take longer. -- rsandifo at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rsandifo at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33290
[Bug tree-optimization/33291] a+=2; a+=2 not simplified to a+=4; with -O3 (ok with gcc-4.2.1)
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-09-03 12:04 --- That is, rtl level DSE removes the dead store: _ZN3CPU7executeEv: .LFB5: pushq %rbx .LCFI0: movq%rdi, %rbx leaq8(%rdi), %rdi call_ZN5Clock1fEv .p2align 4,,10 .p2align 3 .L6: movl2064(%rbx), %eax shrl$8, %eax mov %eax, %eax movq16(%rbx,%rax,8), %rdx testq %rdx, %rdx je .L2 movzbl 2064(%rbx), %eax addl$4, 8(%rbx) movzbl (%rdx,%rax), %eax .L3: movzbl %al, %eax addl$2, 8(%rbx) salq$4, %rax movq_ZN3CPU3tabE(%rax), %rdx testb $1, %dl jne .L4 movq%rbx, %rdi addq_ZN3CPU3tabE+8(%rax), %rdi call*%rdx jmp .L6 .p2align 4,,10 .p2align 3 .L4: movq%rbx, %rdi addq_ZN3CPU3tabE+8(%rax), %rdi movq(%rdi), %rax movq-1(%rdx,%rax), %rdx call*%rdx jmp .L6 .L2: movq%rbx, %rdi call_ZN3CPU8readSlowEv .p2align 4,,6 .p2align 3 jmp .L3 .LFE5: -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Keywords||TREE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33291
[Bug c++/29731] [4.0/4.1/4.2/4.3 regression] ICE with statement expression as template parameter
--- Comment #7 from pcarlini at suse dot de 2007-09-03 12:09 --- Fixing the second ICE. -- pcarlini at suse dot de changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29731
[Bug c/33292] New: optimizer optimizes out a piece of code
the optimizer skips a function call that should not be skipped. -- Summary: optimizer optimizes out a piece of code Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: nicolas at dyalog dot com GCC build triplet: x86_64-pc-linux-gnu GCC host triplet: x86_64-pc-linux-gnu GCC target triplet: x86_64-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33292
[Bug c/33292] optimizer optimizes out a piece of code
--- Comment #1 from nicolas at dyalog dot com 2007-09-03 12:26 --- Created an attachment (id=14153) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14153action=view) preprocessed source of a repro Sorry guys the repro is a bit complicated but i could NOT narrow it down any further. I can't understand what triggers this optimizer bug. I refer to the optimized version when compiled with : gcc delayopt.i -o delayopt -O3 -ggdb3 -Wall And to the debug version when compiled with : gcc delayopt.i -o delayopt -ggdb3 -Wall The function that the optimizer skips is TimeValToFileTime(). If you look at the optimized disassembly, you will see that asyncSleep() does the follwing routine which is the optimized call to TimeValToFileTime() : 400675: imul $0x989680,%rax,%rax 40067c: lea(%rbx,%rbx,4),%rbx 400680: lea(%rax,%rbx,2),%rbx whereas nt_async_delay() doesn't and therefore uses a bad value for the variable curr. Output of optimized version : Going to sleep 1.00 seconds Slept -1188821606.219786 seconds Output of debug version : Going to sleep 1.00 seconds Slept 1.004632 seconds -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33292
[Bug middle-end/33290] [4.3 Regression] gcc.c-torture/execute/930921-1.c fails at -O1 and above now
--- Comment #2 from andreast at gcc dot gnu dot org 2007-09-03 13:05 --- Looks ok on PowerPC Darwin. 16 passes. I tested on top of 128028. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33290
[Bug middle-end/33290] [4.3 Regression] gcc.c-torture/execute/930921-1.c fails at -O1 and above now
--- Comment #3 from dominiq at lps dot ens dot fr 2007-09-03 13:10 --- The test case works: [karma] gcc/darwin_buildw% ../gcc4.3w/bin/gcc -O ../gcc-4.3-work/gcc/testsuite/gcc.c-torture/execute/930921-1.c ../gcc-4.3-work/gcc/testsuite/gcc.c-torture/execute/930921-1.c: In function 'main': ../gcc-4.3-work/gcc/testsuite/gcc.c-torture/execute/930921-1.c:13: warning: incompatible implicit declaration of built-in function 'abort' ../gcc-4.3-work/gcc/testsuite/gcc.c-torture/execute/930921-1.c:14: warning: incompatible implicit declaration of built-in function 'exit' [karma] gcc/darwin_buildw% a.out [karma] gcc/darwin_buildw% ../gcc4.3w/bin/gcc -O -m64 ../gcc-4.3-work/gcc/testsuite/gcc.c-torture/execute/930921-1.c ../gcc-4.3-work/gcc/testsuite/gcc.c-torture/execute/930921-1.c: In function 'main': ../gcc-4.3-work/gcc/testsuite/gcc.c-torture/execute/930921-1.c:13: warning: incompatible implicit declaration of built-in function 'abort' ../gcc-4.3-work/gcc/testsuite/gcc.c-torture/execute/930921-1.c:14: warning: incompatible implicit declaration of built-in function 'exit' [karma] gcc/darwin_buildw% a.out I am starting the gcc test suite, allow for 2+ hours. Thanks -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33290
[Bug rtl-optimization/15473] Sibcall optimization for libcalls.
--- Comment #3 from chrbr at gcc dot gnu dot org 2007-09-03 13:24 --- this report is quite old, but worth to pop : We found similar problems with implicit memory block copying when using struct copying by value. (frequent in C++ ) Softfloat architectures making a very extensive use of libcalls are also very sensitive to this lost optimisation (it is a performance regression since the optimisation was correctly done with a gcc 3.4.3). The rtl was then emitted both for normal calls and sibling calls and stored in a placeholder. The placeholder was decided to be emitted after all the stmts were expanded. Since gcc 4.0 the placeholders have disapeared so we lost the ability to optimise libcalls in the backend. I will try to make use of the cfg information available in expand to decide if we can pass BLOCK_OP_TAILCALL to emit_block_move. I expect that libcalls can share the same interface. -- chrbr at gcc dot gnu dot org changed: What|Removed |Added CC||chrbr at gcc dot gnu dot org Last reconfirmed|2006-03-01 02:40:48 |2007-09-03 13:24:57 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15473
[Bug middle-end/33216] [4.1/4.2/4.3 Regression] ICE in named_section_real, at varasm.c:419
--- Comment #8 from jakub at gcc dot gnu dot org 2007-09-03 13:43 --- It is not bogus. -fprofile-arcs is one way of introducing .ctors stuff. When building crtstuff, if it is supposed to work, you must avoid all options that generate such stuff, whether it is -fprofile-arcs, -fasynchronous-unwind-tables, -fexceptions, etc. See e.g. config/i386/t-crtstuff for details. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33216
[Bug fortran/33271] nint_2.f90 abort compiled with -O0
--- Comment #5 from michelin60 at gmail dot com 2007-09-03 13:49 ---
(gcc a.c -lm -W -Wall; try with -O0 and -O1, I expect it will fail only at
-O0).
One last question: in your build tree, you should have a file named
${builddir}/${target_triplet}/libgfortran/config.h. How does it define the
macros HAVE_LLROUND, HAVE_LLROUNDF, HAVE_LLROUNDL, HAVE_LROUND, HAVE_LROUNDF
and HAVE_LROUNDL?
Let me start off by saying that today is a holiday and that tomoorow I am back
at work and traveling, I am not allowed to use __any__ business assets for GCC
connected activity.
That last question seems beyond my ken. I am running glibc-2.6.1
(the latest official). The GCC tree is just the fairly current svn without any
changes by myself. I am a chemical engineer and computers, compilers are just
tools as far as I am concerned. I certainly do not use the latest for
production work (I have about a dozen compilers that I can make active at any
given time. This is my home machine and completely disconnected from my
company.
We just had an extensive power outage and we just recovering. I will try and
run that program today? the question is with which C compiler ( the latest
Trunk, gcc-4.3.0? 4.1.current? 3.3.6 ? or 3.4.6? and even the junky 4.2.1) I am
not prepared to give you a choice of glibc as going back to earlier versions is
generally discouraged and rather risky.
Regarding the last question just look in your own current svn tree.
You might also look at PR33271 or PR33277 for my latest fiasco with Pinski. He
appears to owe his job to Dr. Edelsohn and was just hanging around a school
where a relative is a department head for several years. (this is documentable)
Do not try to recruit me as a maintainer because I would __never__ consider
working in an organization as politiized and poorly run as GCC. Mark Mitchel is
just not allowed to act as a real release manager.
The exception is the fortran group (minus Kargl). Where Paul Thomas has been
doing herculean work. I would love to see at least part of that work in 4.1.x
as 4.2.x and 4.3.x are completely messed up with things like decimal float
(major marketing tool of IBM). By the way the latest gcc on AIX is 3.3.1. Thus,
the IBM marketing types are pratically stating that they want to see gcc-4
hobbled.
Now if you do not want to work with me any more, just let me know. I am am
pretty hard boiled from the US corporate world and can spot the gcc
manipulations from a mile away.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33271
[Bug c/33292] optimizer optimizes out a piece of code
--- Comment #2 from nicolas at dyalog dot com 2007-09-03 14:07 --- after a bit more work it seems optimized out because diff64() doesn't observe strict aliasing... that was tricky because it was not the diff64() code that was snipped out but TimeValToFileTime()... I think the compiler should either warn (strict aliasing) in diff64, or not remove TimeValToFileTime()... Or did I miss something ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33292
[Bug fortran/33271] nint_2.f90 abort compiled with -O0
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2007-09-03 14:09
---
(In reply to comment #5)
Let me start off by saying that today is a holiday and that tomoorow I am back
at work and traveling, I am not allowed to use __any__ business assets for GCC
connected activity.
That's fine, I'm certainly not in a hurry. We'll have this fixed before
release, and of course the sooner the better, a few days on a corner case is
not a big deal (this testcase is really a corner case).
We just had an extensive power outage and we just recovering. I will try and
run that program today? the question is with which C compiler ( the latest
Trunk, gcc-4.3.0? 4.1.current? 3.3.6 ? or 3.4.6? and even the junky 4.2.1)
Try with the same compiler that gave you the Fortran failure. Otherwise, take
any other one, what the code I posted is really testing is your glibc.
One last question: in your build tree, you should have a file named
${builddir}/${target_triplet}/libgfortran/config.h. How does it define the
macros HAVE_LLROUND, HAVE_LLROUNDF, HAVE_LLROUNDL, HAVE_LROUND, HAVE_LROUNDF
and HAVE_LROUNDL?
Regarding the last question just look in your own current svn tree.
No, I'm not referring to the source tree but the build tree (the one where your
object build files are stored in). That's the directory where you run the
configure make in. Could you look into that directory, for a file named
powerpc-unknown-linux-gnu/libgfortran/config.h, and paste the lines of that
file which contain the text HAVE_LROUND and the other ones I was quoting?
PS: Please refrain from comments on individuals. There are numerous media to
express your opinion on how open source projects in general (and GCC in
particular) are run, but this Bugzilla isn't one of them. I'm giving you
technical help, and acknowledge the help you're giving the project by having
access to this specific target. Let's keep it constructive.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33271
[Bug fortran/33271] nint_2.f90 abort compiled with -O0
--- Comment #7 from fxcoudert at gcc dot gnu dot org 2007-09-03 14:11 --- And please stop CCing people! I'm taking care of this bug, and there really is no need to bother other people by sending them copies of all comments/investigation we exchange on the issue. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC|dje at watson dot ibm dot | |com, pinskia at gcc dot gnu | |dot org | AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2007-09-03 10:04:32 |2007-09-03 14:11:58 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33271
[Bug fortran/33271] nint_2.f90 abort compiled with -O0
--- Comment #8 from burnus at gcc dot gnu dot org 2007-09-03 14:25 ---
One last question: in your build tree, you should have a file named
${builddir}/${target_triplet}/libgfortran/config.h. How does it define the
macros HAVE_LLROUND, HAVE_LLROUNDF, HAVE_LLROUNDL, HAVE_LROUND, HAVE_LROUNDF
and HAVE_LROUNDL?
That last question seems beyond my ken. I am running glibc-2.6.1
(the latest official).
That file should be in your case in
/var/tmp/43/build-159/powerpc-unknown-linux-gnu/libgfortran/config.h
- this might be different,
depending where you build gcc/gfortran; this was the
directory used in your bug description (comment #0)
The file is generated at configure time and thus specific to the system where
gcc/gfortran is build.
On my system (x86_64-unknown-linux-gnu, but also glibc-2.6), I have in the
equivalent file:
#define HAVE_LLROUND 1
#define HAVE_LLROUNDF 1
#define HAVE_LLROUNDL 1
#define HAVE_LLROUND 1
#define HAVE_LLROUNDF 1
#define HAVE_LLROUNDL 1
I would expect that your config.h has the same entries (as we both use a recent
glibc), but it would be great if you could confirm this.
The question is with which C compiler ( the latest Trunk, gcc-4.3.0?
4.1.current? 3.3.6 ? or 3.4.6? and even the junky 4.2.1)
As FX wants to check whether the C Library (glibc) works correctly, it should
not matter; but if you have the choice I would use gcc 4.3.0.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33271
[Bug tree-optimization/33291] a+=2; a+=2 not simplified to a+=4; with -O3 (ok with gcc-4.2.1)
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-09-03 14:36 --- I have a patch that makes it work apart from the tree level DSE issue. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2007-09-03 12:01:47 |2007-09-03 14:36:17 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33291
[Bug c/21920] aliasing violations
--- Comment #119 from rguenth at gcc dot gnu dot org 2007-09-03 15:20 --- *** Bug 33292 has been marked as a duplicate of this bug. *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||nicolas at dyalog dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21920
[Bug c/33292] optimizer optimizes out a piece of code
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-09-03 15:20 --- The cast to (void *) disables the alias warning. This was done on purpose, so it's unfortunate that this in some cases makes debugging harder. *** This bug has been marked as a duplicate of 21920 *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33292
[Bug tree-optimization/33291] [4.3 Regression] a+=2; a+=2 not simplified to a+=4; with -O3 (ok with gcc-4.2.1)
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Known to fail||4.3.0 Known to work||4.2.1 Summary|a+=2; a+=2 not simplified |[4.3 Regression] a+=2; a+=2 |to a+=4; with -O3 (ok |not simplified to a+=4; |with gcc-4.2.1) |with -O3 (ok with gcc- ||4.2.1) Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33291
[Bug middle-end/33290] [4.3 Regression] gcc.c-torture/execute/930921-1.c fails at -O1 and above now
--- Comment #4 from dominiq at lps dot ens dot fr 2007-09-03 15:32 --- Test Run By dominiq on Mon Sep 3 15:14:54 2007 Native configuration is powerpc-apple-darwin8 === gcc tests === Schedule of variations: unix XPASS: gcc.dg/20020103-1.c scan-assembler-not LC[0-9] FAIL: gcc.dg/builtins-61.c scan-tree-dump return 0.0 FAIL: gcc.dg/initpri1.c execution test FAIL: gcc.dg/memcpy-1.c scan-tree-dump-times nasty_local 0 FAIL: gcc.dg/ssp-2.c (test for excess errors) XPASS: gcc.dg/tree-ssa/update-threading.c scan-tree-dump-times Invalid sum 0 FAIL: gcc.dg/vect/section-anchors-pr27770.c (test for excess errors) FAIL: gcc.dg/vect/section-anchors-vect-69.c (test for excess errors) FAIL: gcc.dg/vect/section-anchors-vect-69.c scan-tree-dump-times Alignment of access forced using peeling 4 FAIL: gcc.target/powerpc/parity-1.c scan-assembler popcntb FAIL: gcc.target/powerpc/popcount-1.c scan-assembler popcntb FAIL: gcc.target/powerpc/stabs-attrib-vect-darwin.c scan-assembler .stabs.*vi:\\(0,[0-9]+\\)[EMAIL PROTECTED] === gcc Summary === # of expected passes46198 # of unexpected failures10 # of unexpected successes 2 # of expected failures 169 # of untested testcases 35 # of unsupported tests 412 /opt/gcc/darwin_buildw/gcc/xgcc version 4.3.0 20070903 (experimental) (GCC) That's the normal unexpected failures/successes on Darwin8. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33290
[Bug middle-end/33290] [4.3 Regression] gcc.c-torture/execute/930921-1.c fails at -O1 and above now
--- Comment #5 from rsandifo at gcc dot gnu dot org 2007-09-03 15:36 --- Subject: Bug 33290 Author: rsandifo Date: Mon Sep 3 15:35:52 2007 New Revision: 128048 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128048 Log: gcc/ PR middle-end/33290 * optabs.c (avoid_expensive_constant): Canonicalize CONST_INTs before forcing them into a register. Modified: trunk/gcc/ChangeLog trunk/gcc/optabs.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33290
[Bug middle-end/33290] [4.3 Regression] gcc.c-torture/execute/930921-1.c fails at -O1 and above now
--- Comment #6 from rsandifo at gcc dot gnu dot org 2007-09-03 15:36 --- Thanks to Andreas and Dominique for the testing. Now applied to 4.3. Sorry to everyone for the breakage. -- rsandifo at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33290
[Bug c++/10541] [DR 354] Is NULL a valid pointer-type template argument?
--- Comment #8 from mec at google dot com 2007-09-03 15:47 --- DR 354 has been in state WP since October 2005. Is that good enough to unsuspend this issue? http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#354 -- mec at google dot com changed: What|Removed |Added CC||mec at google dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10541
[Bug c/33292] optimizer optimizes out a piece of code
--- Comment #4 from nicolas at dyalog dot com 2007-09-03 16:08 --- That's what I feared I have lots of those in my code... Thanks for the quick reply anyway =) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33292
[Bug middle-end/33216] [4.1 Regression] ICE in named_section_real, at varasm.c:419
--- Comment #9 from rguenth at gcc dot gnu dot org 2007-09-03 16:24 --- I see. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.1/4.2/4.3 Regression] ICE|[4.1 Regression] ICE in |in named_section_real, at |named_section_real, at |varasm.c:419|varasm.c:419 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33216
[Bug c++/30302] [4.0/4.1/4.2/4.3 regression] ICE with invalid member in anonymous struct
--- Comment #4 from pcarlini at suse dot de 2007-09-03 16:35 --- On it. -- pcarlini at suse dot de changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30302
[Bug fortran/31675] Fortran front-end and libgfortran should have a common header file
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-09-03 16:44 --- Subject: Bug 31675 Author: fxcoudert Date: Mon Sep 3 16:44:15 2007 New Revision: 128050 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128050 Log: PR fortran/31675 * libgfortran.h: New file. * iso-fortran-env.def: Use macros in the new header instead of hardcoded integer constants. * Make-lang.in (F95_PARSER_OBJS, GFORTRAN_TRANS_DEPS): Add fortran/libgfortran.h. * gfortran.h (GFC_STD_*, GFC_FPE_*, options_convert, ioerror_codes): Remove. * trans.c (ERROR_ALLOCATION): Remove. (gfc_call_malloc, gfc_allocate_with_status, gfc_allocate_array_with_status): Use LIBERROR_ALLOCATION. * trans-types.h (GFC_DTYPE_*): Remove. * trans-decl.c (gfc_generate_function_code): Use GFC_CONVERT_NATIVE instead of CONVERT_NATIVE. * trans-io.c (set_parameter_value, set_parameter_ref): Use LIBERROR_* macros instead of IOERROR_ macros. * trans-intrinsic.c (gfc_conv_intrinsic_function): Use LIBERROR_END and LIBERROR_EOR instead of hardcoded constants. * options.c (gfc_init_options): Use GFC_CONVERT_NATIVE instead of CONVERT_NATIVE. (gfc_handle_option): Use GFC_CONVERT_* macros instead of CONVERT_*. * libgfortran.h: Include gcc/fortran/libgfortran.h. Remove M_PI, GFC_MAX_DIMENSIONS, GFC_DTYPE_*, GFC_NUM_RANK_BITS, error_codes, GFC_STD_*, GFC_FPE_* and unit_convert. * runtime/environ.c (variable_table): Use GFC_*_UNIT_NUMBER instead of hardcoded constants. (do_parse, init_unformatted): Use GFC_CONVERT_* macros instead of CONVERT_*. * runtime/string.c (find_option): Use LIBERROR_BAD_OPTION instead of ERROR_BAD_OPTION. * runtime/error.c (translate_error, generate_error): Use LIBERROR_* macros instead of ERROR_*. * io/file_pos.c (formatted_backspace, unformatted_backspace, st_backspace, st_rewind, st_flush): Rename macros. * io/open.c (convert_opt, edit_modes, new_unit, already_open, st_open): Likewise. * io/close.c (st_close): Likewise. * io/list_read.c (next_char, convert_integer, parse_repeat, read_logical, read_integer, read_character, parse_real, check_type, list_formatted_read_scalar, namelist_read, nml_err_ret): Likewise. * io/read.c (convert_real, read_l, read_decimal, read_radix, read_f): Likewise. * io/inquire.c (inquire_via_unit): Likewise. * io/unit.c (get_internal_unit): Likewise. * io/transfer.c (read_sf, read_block, read_block_direct, write_block, write_buf, unformatted_read, unformatted_write, formatted_transfer_scalar, us_read, us_write, data_transfer_init, skip_record, next_record_r, write_us_marker, next_record_w_unf, next_record_w, finalize_transfer, st_read, st_write_done): Likewise. * io/format.c (format_error): Likewise. Added: trunk/gcc/fortran/libgfortran.h Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/Make-lang.in trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/iso-fortran-env.def trunk/gcc/fortran/options.c trunk/gcc/fortran/trans-decl.c trunk/gcc/fortran/trans-intrinsic.c trunk/gcc/fortran/trans-io.c trunk/gcc/fortran/trans-types.h trunk/gcc/fortran/trans.c trunk/libgfortran/ChangeLog trunk/libgfortran/io/close.c trunk/libgfortran/io/file_pos.c trunk/libgfortran/io/format.c trunk/libgfortran/io/inquire.c trunk/libgfortran/io/list_read.c trunk/libgfortran/io/open.c trunk/libgfortran/io/read.c trunk/libgfortran/io/transfer.c trunk/libgfortran/io/unit.c trunk/libgfortran/libgfortran.h trunk/libgfortran/runtime/environ.c trunk/libgfortran/runtime/error.c trunk/libgfortran/runtime/string.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31675
[Bug fortran/31675] Fortran front-end and libgfortran should have a common header file
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-09-03 16:47 --- Fixed. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31675
[Bug c++/33293] New: inlining std::inner_product()
I use std::inner_product() to do the vector multiplication when performing matrix multiplication. This involves calling std::inner_product() within 2 nested loops (one across all rows, one across all columns). Unfortunately, g++-4.1.2 will not, it seems, inline the call even at -O5. If I provide my own version with an inline hint, it improves the speed of my matrix multiplication by ~15%, which is not to be sniffed at. I suppose my questions would be: (a) erm, do you need proof? (b) should the compiler do the inlining regardless (ie, it's a compiler issue), or should the declaration of std::inner_product give a hint with the inline keyword (and perhaps also other functions)? Simon. -- Summary: inlining std::inner_product() Product: gcc Version: 4.2.1 Status: UNCONFIRMED Severity: minor Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: simon dot marshall at misys dot com GCC host triplet: sparc-sun-solaris2.8 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33293
[Bug c/31955] gcc-4.2.0.tar.bz2 is missing INSTALL html files
--- Comment #2 from simon dot marshall at misys dot com 2007-09-03 16:54 --- This is also true of 4.2.1. Sorry if I have missed something. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31955
[Bug libstdc++/33293] inlining std::inner_product()
--- Comment #1 from pcarlini at suse dot de 2007-09-03 17:20 --- Note, in GCC any -Ox, x 3 is identical to -O3. Anyway, I think we can safely add inline to std::accumulate and std::inner_product. -- pcarlini at suse dot de changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de |dot org | Status|UNCONFIRMED |ASSIGNED Component|c++ |libstdc++ Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-09-03 17:20:12 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33293
[Bug c++/10541] [DR 354] Is NULL a valid pointer-type template argument?
--- Comment #9 from pinskia at gcc dot gnu dot org 2007-09-03 17:29 --- DR 354 has been in state WP since October 2005. Is that good enough to unsuspend this issue? Yes. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|SUSPENDED |NEW Last reconfirmed|2005-12-11 23:08:05 |2007-09-03 17:29:38 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10541
[Bug tree-optimization/33294] New: [4.2/4.3 Regression] -fno-strict-aliasing -ftree-vrp miscompilation
Compile with -O2 -fno-strict-aliasing, fails on amd64 and alpha at least.
Doesn't fail with -fno-tree-vrp. Seems to be related to bug 32575. Breaks
linux kernel in many places (this asm is used with prefetch instruction).
struct T { void *p; } *t;
int main (void)
{
struct T *a;
a = t;
asm volatile ( : : m (*(unsigned long *) a));
if (a)
__builtin_abort ();
return 0;
}
--
Summary: [4.2/4.3 Regression] -fno-strict-aliasing -ftree-vrp
miscompilation
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: belyshev at depni dot sinp dot msu dot ru
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33294
[Bug libstdc++/33293] inlining std::inner_product()
--- Comment #2 from paolo at gcc dot gnu dot org 2007-09-03 17:48 --- Subject: Bug 33293 Author: paolo Date: Mon Sep 3 17:48:31 2007 New Revision: 128053 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128053 Log: 2007-09-03 Paolo Carlini [EMAIL PROTECTED] PR libstdc++/33293 * include/bits/stl_numeric.h (accumulate, inner_product): Add inline function-specifier. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/stl_numeric.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33293
[Bug libstdc++/33293] inlining std::inner_product()
--- Comment #3 from pcarlini at suse dot de 2007-09-03 17:50 --- Fixed for 4.3.0. -- pcarlini at suse dot de changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33293
[Bug fortran/33295] New: ICE in fold_const.c (fold_convert) when reordering USE statements
The following code produces the error internal compiler error: in fold_convert, at fold-const.c:2626 when compiled with GCC trunk rev. 128037: module A type A_type real comp end type end module A module B contains function initA() use A implicit none type(A_type):: initA initA%comp=1.0 end function end module B program C use B use A implicit none type(A_type):: A_var A_var = initA() end program C The crucial part here are the USE statements in program C. The error only pops up when they appear as listed above. Exchanging them to use A use B makes the error vanish. The error is also killed by A_var = initA() It happens for GCC 4.3.0 (trunk) as well as 4.1.3 and 4.2.1. The target system is i686-pc-linux-gnu. -- Summary: ICE in fold_const.c (fold_convert) when reordering USE statements Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jaydub66 at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33295
[Bug c++/33287] namespace hides class definition
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-09-03 18:05 ---
Yes and this correct.
Though the error was wrong.
On the trunk we get:
t.cc:12: error: 'namespace C1 { }' redeclared as different kind of symbol
t.cc:2: error: previous declaration of 'class C1'
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33287
[Bug fortran/33295] ICE in fold_const.c (fold_convert) when reordering USE statements
--- Comment #1 from jaydub66 at gmail dot com 2007-09-03 18:05 --- The error is also killed by A_var = initA() Sorry. The error is killed by *removing* this line. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33295
[Bug c++/33287] namespace hides class definition
--- Comment #2 from fang at csl dot cornell dot edu 2007-09-03 18:11
---
Subject: Re: namespace hides class definition
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-09-03 18:05
---
Yes and this correct.
Though the error was wrong.
On the trunk we get:
t.cc:12: error: 'namespace C1 { }' redeclared as different kind of symbol
t.cc:2: error: previous declaration of 'class C1'
... which was fixed by patch referenced in PR 30734 (PR 2708) on trunk, if
you want to try/request a backport.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33287
[Bug tree-optimization/33294] [4.2/4.3 Regression] -fno-strict-aliasing -ftree-vrp miscompilation
--- Comment #1 from belyshev at depni dot sinp dot msu dot ru 2007-09-03 18:13 --- This bug is invalid because asm() does NULL pointer dereference, thus triggering undefined behavior. -- belyshev at depni dot sinp dot msu dot ru changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33294
[Bug c++/33287] namespace hides class definition
--- Comment #3 from ilgb at livius dot net 2007-09-03 18:15 --- it looks we are talking about different bugs, the error I get is different: ../src/a.cpp:26: error: 'C1' does not name a type where the line 26 is the following: C1 c; -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33287
[Bug c++/33287] namespace hides class definition
--- Comment #4 from fang at csl dot cornell dot edu 2007-09-03 18:19 --- Subject: Re: namespace hides class definition --- Comment #3 from ilgb at livius dot net 2007-09-03 18:15 --- it looks we are talking about different bugs, the error I get is different: ../src/a.cpp:26: error: 'C1' does not name a type where the line 26 is the following: C1 c; Sorry to confuse, I meant that the new error message on the trunk was attributed to that patch I mentioned, not the bug you're currently seeing. David Fang Computer Systems Laboratory Electrical Computer Engineering Cornell University http://www.csl.cornell.edu/~fang/ -- (2400 baud? Netscape 3.0?? lynx??? No problem!) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33287
[Bug libfortran/33253] namelist: reading back a string with apostrophe
--- Comment #4 from patchapp at dberlin dot org 2007-09-03 19:05 --- Subject: Bug number PR33253 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-09/msg00153.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33253
[Bug libfortran/33253] namelist: reading back a string with apostrophe
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2007-09-03 19:27 --- Subject: Bug 33253 Author: jvdelisle Date: Mon Sep 3 19:27:48 2007 New Revision: 128056 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128056 Log: 2007-09-03 Jerry DeLisle [EMAIL PROTECTED] PR fortran/33253 * gfortran.dg/namelist_15.f90: Update test. * gfortran.dg/namelist_24.f90: Update test. * gfortran.dg/namelist_38.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/namelist_38.f90 Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/namelist_15.f90 trunk/gcc/testsuite/gfortran.dg/namelist_24.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33253
[Bug libfortran/33253] namelist: reading back a string with apostrophe
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2007-09-03 19:29 --- Subject: Bug 33253 Author: jvdelisle Date: Mon Sep 3 19:29:17 2007 New Revision: 128057 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128057 Log: 2007-09-03 Jerry DeLisle [EMAIL PROTECTED] PR libfortran/33253 * io/list_read.c (read_character): Use DELIM_APOSTROPHE and DELIM_QUOTE in check of first character in string. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/io/list_read.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33253
[Bug libfortran/33253] namelist: reading back a string with apostrophe
--- Comment #7 from jvdelisle at gcc dot gnu dot org 2007-09-03 19:32 --- Fixed on trunk. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33253
[Bug tree-optimization/33017] [4.3 Regression] tree check fail for legal 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/2007- ||09/msg00155.html Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-09-03 19:35:25 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33017
[Bug fortran/33295] ICE in fold_const.c (fold_convert) when reordering USE statements
--- Comment #2 from ubizjak at gmail dot com 2007-09-03 20:07 ---
Confirmed on x86_64 (-O0), RECORD_TYPE is entering fold_convert() from
gfc_trans_scalar_assign():
(gdb) bt
#0 fancy_abort (file=0xb322f0 ../../gcc-svn/trunk/gcc/fold-const.c,
line=2626,
function=0xb321d2 fold_convert) at
../../gcc-svn/trunk/gcc/diagnostic.c:654
#1 0x005c6eec in fold_convert (type=0x2e2d0340,
arg=0x2dff54b0)
at ../../gcc-svn/trunk/gcc/fold-const.c:2626
#2 0x00492f0e in gfc_trans_scalar_assign (lse=0x7fff3ff81120,
rse=0x7fff3ff810d0, ts=
{type = BT_DERIVED, kind = 0, derived = 0xf97230, cl = 0x0, is_c_interop
= 0, is_iso_c = 0, f90_type = BT_UNKNOWN}, l_is_temp=0 '\0', r_is_var=0 '\0')
at ../../gcc-svn/trunk/gcc/fortran/trans-expr.c:3609
#3 0x00496ca5 in gfc_trans_assignment_1 (expr1=0xf97130,
expr2=0xf97700, init_flag=0 '\0')
at ../../gcc-svn/trunk/gcc/fortran/trans-expr.c:4011
#4 0x00496dbc in gfc_trans_assignment (expr1=0xf97130, expr2=0xf97700,
init_flag=210 '#65533;')
at ../../gcc-svn/trunk/gcc/fortran/trans-expr.c:4152
#5 0x0047b116 in gfc_trans_code (code=0xf986c0) at
../../gcc-svn/trunk/gcc/fortran/trans.c:970
#6 0x0048fc73 in gfc_generate_function_code (ns=0xf960e0)
at ../../gcc-svn/trunk/gcc/fortran/trans-decl.c:3258
(gdb) up
#1 0x005c6eec in fold_convert (type=0x2e2d0340,
arg=0x2dff54b0)
at ../../gcc-svn/trunk/gcc/fold-const.c:2626
2626 gcc_unreachable ();
(gdb) p debug_tree (type)
record_type 0x2e2d0340 a_type SF
size integer_cst 0x2dff1a50 type integer_type 0x2dffe0d0
bit_size_type constant invariant 32
unit size integer_cst 0x2dff16c0 type integer_type 0x2dffe000
constant invariant 4
align 32 symtab 0 alias set -1 canonical type 0x2e2d0340
fields field_decl 0x2e2cbe70 comp
type real_type 0x2e00a5b0 real4 SF size integer_cst
0x2dff1a50 32 unit size integer_cst 0x2dff16c0 4
align 32 symtab 0 alias set -1 canonical type 0x2e00a5b0
precision 32
pointer_to_this pointer_type 0x2e00a820
SF file c.f90 line 1 size integer_cst 0x2dff1a50 32 unit size
integer_cst 0x2dff16c0 4
align 32 offset_align 128
offset integer_cst 0x2dff16f0 constant invariant 0
bit offset integer_cst 0x2dff1f30 constant invariant 0 context
record_type 0x2e2d0340 a_type
chain type_decl 0x2e2d0410 D.1372
--
ubizjak at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2007-09-03 20:07:11
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33295
[Bug target/28902] Fix for alingment of XXX is greater than maximum object alignment on AVR
--- Comment #2 from aesok at gcc dot gnu dot org 2007-09-03 20:35 --- Subject: Bug 28902 Author: aesok Date: Mon Sep 3 20:35:10 2007 New Revision: 128059 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128059 Log: PR target/28902 * config/avr/avr.h (TARGET_VTABLE_ENTRY_ALIGN): Define. Modified: trunk/gcc/ChangeLog trunk/gcc/config/avr/avr.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28902
[Bug target/28902] Fix for alingment of XXX is greater than maximum object alignment on AVR
--- Comment #3 from aesok at gcc dot gnu dot org 2007-09-03 21:04 --- Subject: Bug 28902 Author: aesok Date: Mon Sep 3 21:03:50 2007 New Revision: 128060 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128060 Log: PR target/28902 * config/avr/avr.h (TARGET_VTABLE_ENTRY_ALIGN): Define. Modified: branches/gcc-4_2-branch/gcc/ChangeLog branches/gcc-4_2-branch/gcc/config/avr/avr.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28902
[Bug target/1078] Problems with attributes documentation
--- Comment #6 from eweddington at cso dot atmel dot com 2007-09-04 03:37 --- (In reply to comment #5) Patch to document AVR progmem attribute: http://gcc.gnu.org/ml/gcc-patches/2007-07/msg01832.html Now committed: http://gcc.gnu.org/ml/gcc-patches/2007-09/msg00159.html This bug is fixed for the AVR target. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1078
[Bug target/12017] ICE: in spill_failure, at reload1.c:1862 with builtin_apply/builtin_return
--- Comment #13 from eweddington at cso dot atmel dot com 2007-09-04 03:46 --- Seems to be fixed in 4.2.1, at least. I haven't tried earlier releases. Changing target milestone and closing bug. -- eweddington at cso dot atmel dot com changed: What|Removed |Added Status|NEW |RESOLVED Known to work|4.3.0 |4.3.0 4.2.1 Resolution||FIXED Target Milestone|4.3.0 |4.2.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12017
[Bug c++/33287] namespace hides class definition
--- Comment #5 from eweddington at cso dot atmel dot com 2007-09-04 04:02 --- (In reply to comment #1) Yes and this correct. Andrew, Are you saying that this bug is invalid? If so, then it needs to be closed as such. Thanks -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33287
[Bug target/33256] internal compiler error: in print_operand_reloc, at config/mips/mips.c:5579
--- Comment #5 from daney at gcc dot gnu dot org 2007-09-04 04:20 --- I just tried this on a mipsel-linux compiler: $ /home/ddaney/gccsvn/trunk-build/gcc/xgcc -B/home/ddaney/gccsvn/trunk-build/gcc/ -v -S -mabi=64 -msym32 -mno-abicalls -O2 pr33256.c Reading specs from /home/ddaney/gccsvn/trunk-build/gcc/specs Target: mipsel-linux Configured with: ../trunk/configure --prefix=/home/ddaney/gccsvn/trunk-install --target=mipsel-linux --build=mipsel-linux --host=mipsel-linux --with-gmp=/home/ddaney/mp --with-mpfr=/home/ddaney/mp --with-arch=sb1 --disable-java-awt --without-x --enable-__cxa_atexit --disable-jvmpi Thread model: posix gcc version 4.3.0 20070903 (experimental) [trunk revision 128061] (GCC) COLLECT_GCC_OPTIONS='-B/home/ddaney/gccsvn/trunk-build/gcc/' '-v' '-S' '-mabi=64' '-msym32' '-mno-abicalls' '-O2' '-march=sb1' '-mno-shared' /home/ddaney/gccsvn/trunk-build/gcc/cc1 -quiet -v -iprefix /home/ddaney/gccsvn/trunk-build/gcc/../lib/gcc/mipsel-linux/4.3.0/ -isystem /home/ddaney/gccsvn/trunk-build/gcc/include -isystem /home/ddaney/gccsvn/trunk-build/gcc/include-fixed pr33256.c -quiet -dumpbase pr33256.c -mabi=64 -msym32 -mno-abicalls -march=sb1 -mno-shared -auxbase pr33256 -O2 -version -o pr33256.s ignoring nonexistent directory /home/ddaney/gccsvn/trunk-build/gcc/../lib/gcc/mipsel-linux/4.3.0/include ignoring nonexistent directory /home/ddaney/gccsvn/trunk-build/gcc/../lib/gcc/mipsel-linux/4.3.0/include-fixed ignoring nonexistent directory /home/ddaney/gccsvn/trunk-build/gcc/../lib/gcc/mipsel-linux/4.3.0/../../../../mipsel-linux/include ignoring nonexistent directory /home/ddaney/gccsvn/trunk-build/gcc/../lib/gcc/../../include ignoring nonexistent directory /home/ddaney/gccsvn/trunk-build/gcc/../lib/gcc/../../lib/gcc/mipsel-linux/4.3.0/include ignoring nonexistent directory /home/ddaney/gccsvn/trunk-build/gcc/../lib/gcc/../../lib/gcc/mipsel-linux/4.3.0/include-fixed ignoring nonexistent directory /home/ddaney/gccsvn/trunk-build/gcc/../lib/gcc/../../lib/gcc/mipsel-linux/4.3.0/../../../../mipsel-linux/include #include ... search starts here: #include ... search starts here: /home/ddaney/gccsvn/trunk-build/gcc/include /home/ddaney/gccsvn/trunk-build/gcc/include-fixed /usr/local/include /usr/include End of search list. GNU C (GCC) version 4.3.0 20070903 (experimental) [trunk revision 128061] (mipsel-linux) compiled by GNU C version 4.3.0 20070903 (experimental) [trunk revision 128061], GMP version 4.2.1, MPFR version 2.3.0. GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Compiler executable checksum: e8d0d3f2f67f4d75657f801573ee0cb0 pr33256.c:23: warning: 'struct tcf_proto' declared inside parameter list pr33256.c:23: warning: its scope is only this definition or declaration, which is probably not what you want pr33256.c:24: warning: 'struct tcf_pkt_info' declared inside parameter list pr33256.c:24: warning: 'struct sk_buff' declared inside parameter list pr33256.c:25: warning: 'struct tcf_proto' declared inside parameter list pr33256.c:26: warning: 'struct sk_buff' declared inside parameter list pr33256.c:46: warning: 'struct tcf_pkt_info' declared inside parameter list pr33256.c:46: warning: 'struct sk_buff' declared inside parameter list pr33256.c:53: warning: 'struct tcf_pkt_info' declared inside parameter list pr33256.c:53: warning: 'struct sk_buff' declared inside parameter list pr33256.c:59: warning: initialization from incompatible pointer type pr33256.c:66: warning: 'struct tcf_pkt_info' declared inside parameter list pr33256.c:66: warning: 'struct sk_buff' declared inside parameter list pr33256.c:70: warning: 'struct tcf_pkt_info' declared inside parameter list pr33256.c:70: warning: 'struct sk_buff' declared inside parameter list pr33256.c: In function 'em_meta_match': pr33256.c:74: warning: passing argument 1 of 'meta_get' from incompatible pointer type pr33256.c:74: warning: passing argument 2 of 'meta_get' from incompatible pointer type pr33256.c:75: warning: passing argument 1 of 'meta_get' from incompatible pointer type pr33256.c:75: warning: passing argument 2 of 'meta_get' from incompatible pointer type pr33256.c: At top level: pr33256.c:79: warning: 'struct tcf_proto' declared inside parameter list pr33256.c:82: warning: 'struct tcf_proto' declared inside parameter list pr33256.c:85: warning: 'struct sk_buff' declared inside parameter list pr33256.c:89: warning: initialization from incompatible pointer type pr33256.c:89: warning: initialization from incompatible pointer type pr33256.c:90: warning: initialization from incompatible pointer type pr33256.c:90: warning: initialization from incompatible pointer type pr33256.c:92: warning: excess elements in struct initializer pr33256.c:92: warning: (near initialization for 'em_meta_ops.link') pr33256.c:94: warning: excess elements in struct initializer pr33256.c:94: warning: (near initialization for 'em_meta_ops.link') COMPILER_PATH=/home/ddaney/gccsvn/trunk-build/gcc/ LIBRARY_PATH=/home/ddaney
[Bug target/33256] internal compiler error: in print_operand_reloc, at config/mips/mips.c:5579
--- Comment #6 from daney at gcc dot gnu dot org 2007-09-04 04:27 --- OK I can reproduce with my mips64-linux cross compiler. I wonder if it is big-endian related... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33256
[Bug libfortran/33225] [4.3 regression] Missing last digit is some formatted output (on 32bit targets)
--- Comment #12 from jvdelisle at gcc dot gnu dot org 2007-09-04 04:47 --- Found the problem. I will submit the update patch against this PR -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33225
[Bug libfortran/33225] Missing last digit in some formatted output (on 32bit targets), per kind write_float
--- Comment #13 from jvdelisle at gcc dot gnu dot org 2007-09-04 04:49 --- Changed title to reflect what this is, not really a regression at this point. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.3 regression] Missing|Missing last digit in some |last digit is some formatted|formatted output (on 32bit |output (on 32bit targets) |targets), per kind ||write_float http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33225
[Bug libfortran/33225] Missing last digit in some formatted output (on 32bit targets), per kind write_float
--- Comment #14 from dominiq at lps dot ens dot fr 2007-09-04 04:58 --- Did you also have a look to the other problem: print *, nearest(huge(1.0),1.0), nearest(-huge(1.0),-1.0), nearest(huge(1.0d0) 1 Error: Result of NEAREST overflows its kind at (1) ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33225
[Bug libfortran/33225] Missing last digit in some formatted output (on 32bit targets), per kind write_float
--- Comment #15 from jvdelisle at gcc dot gnu dot org 2007-09-04 05:39 --- Yes, I also checked the huge testcase and its all clean now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33225
[Bug libfortran/33225] Missing last digit in some formatted output (on 32bit targets), per kind write_float
--- Comment #16 from patchapp at dberlin dot org 2007-09-04 05:40 --- Subject: Bug number PR33225 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-09/msg00176.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33225
[Bug fortran/33296] New: nearest(huge(1.0),1.0) gives an error
The following code: real x x = nearest(huge(1.0),1.0) end gives x = nearest(huge(1.0),1.0) 1 Error: Result of NEAREST overflows its kind at (1) instead of setting x to +Inf. This bug is also present in GNU F95 version 4.2.1. -- Summary: nearest(huge(1.0),1.0) gives an error Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dominiq at lps dot ens dot fr GCC target triplet: powerpc-apple-darwin8 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33296
[Bug libfortran/33225] Missing last digit in some formatted output (on 32bit targets), per kind write_float
--- Comment #17 from jvdelisle at gcc dot gnu dot org 2007-09-04 05:44 --- Dominique: The problem in comment 14 is not fixed and I do not think its related. I will check further though. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33225
[Bug target/33256] internal compiler error: in print_operand_reloc, at config/mips/mips.c:5579
--- Comment #7 from daney at gcc dot gnu dot org 2007-09-04 05:46 --- Here is what is happening: The value of avenrun[0] is being passed to a function that takes an 32 bit int parameter. Since avenrun is an array of 64 bit unsigned long, the conversion to int can be done by loading an int from avenrun + 4. In mips_symbolic_constant_p() we call offset_within_block_p(avenrun, 4) which returns false because avenrun is an array of undetermined length. If the length turns out to be zero, then an offset of 4 would fall outside of the array. I don't really know how to fix this. We could get rid of the offset_within_block_p() check all together (which could cause undiagnosed bad code in other circumstances), or we could assume that if symbol is an array, and the offset falls in the first element that it is OK. Perhaps Richard will have some ideas here... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33256
[Bug libfortran/33225] Missing last digit in some formatted output (on 32bit targets), per kind write_float
--- Comment #18 from dominiq at lps dot ens dot fr 2007-09-04 05:47 --- I do not think its related. I just realized that and I filled PR33296. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33225
