[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
#include
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 .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=14151&action=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 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 # SMT.9_77 = VDEF D.2529_3->a = D.2584_38; # VUSE 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 # SMT.9_79 = VDEF 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 D.2606_35 = this_2(D)->D.2527.a; ... # tab_77 = VDEF # SMT.11_78 = VDEF 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 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 # SMT.9_93 = VDEF # SMT.11_78 = VDEF 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 # SMT.9_94 = VDEF # SMT.11_80 = VDEF 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=14152&action=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=14153&action=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=gcc&view=rev&rev=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=gcc&view=rev&rev=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=gcc&view=rev&rev=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=gcc&view=rev&rev=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=gcc&view=rev&rev=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 '�')
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)
constant invariant 32>
unit size
constant invariant 4>
align 32 symtab 0 alias set -1 canonical type 0x2e2d0340
fields unit size
align 32 symtab 0 alias set -1 canonical type 0x2e00a5b0
precision 32
pointer_to_this >
SF file c.f90 line 1 size unit size
align 32 offset_align 128
offset
bit offset context
>
chain >
--
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=gcc&view=rev&rev=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=gcc&view=rev&rev=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 poi
[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
[Bug target/33256] internal compiler error: in print_operand_reloc, at config/mips/mips.c:5579
--- Comment #8 from daney at gcc dot gnu dot org 2007-09-04 06:01 --- Created an attachment (id=14154) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14154&action=view) Reduced testcase. -- daney at gcc dot gnu dot org changed: What|Removed |Added Attachment #14149|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33256
[Bug tree-optimization/32975] [4.3 Regression] ICE segfault (verify_cgraph failure after ipa-cp) with -finline-functions -fipa-cp
--- Comment #3 from jakub at gcc dot gnu dot org 2007-09-04 06:14 --- Can't reproduce this, neither on x86_64-linux, nor on ppc-linux, on the former I tried cc1's I had laying around back through to 2007-08-21 and all of them worked. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32975
[Bug fortran/33281] gfortran crt2.o not found under Vista
--- Comment #2 from dannysmith at users dot sourceforge dot net 2007-09-04
06:17 ---
The solution is to build gcc/gfortran wiith -D__USE_MINGW_ACCESS in CFLAGS;
>From mingw/include/io.h
/* Some defines for _access nAccessMode (MS doesn't define them, but
* it doesn't seem to hurt to add them). */
#define F_OK0 /* Check for file existence */
/* Well maybe it does hurt. On newer versions of MSVCRT, an access mode
of 1 causes invalid parameter error. */
#define X_OK1 /* MS access() doesn't check for execute permission. */
#define W_OK2 /* Check for write permission */
#define R_OK4 /* Check for read permission */
and later:
#ifdef __USE_MINGW_ACCESS
/* Old versions of MSVCRT access() just ignored X_OK, while the version
shipped with Vista, returns an error code. This will restore the
old behaviour */
static inline int __mingw_access (const char* __fname, int __mode)
{ return _access (__fname, __mode & ~X_OK); }
#define access(__f,__m) __mingw_access (__f, __m)
#endif
Danny
--
dannysmith at users dot sourceforge dot net changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2007-09-04 06:17:29
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33281
[Bug target/33256] internal compiler error: in print_operand_reloc, at config/mips/mips.c:5579
--- Comment #9 from daney at gcc dot gnu dot org 2007-09-04 06:32 --- Fixing things up when we are calculating relocations does not seem like it will work. We cannot go adding an offest to a %lo() relocation and expect it not to overflow on occasion. Probably we need to load the value into a register and handle the casting there, as is done at -O0. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33256
[Bug tree-optimization/32772] [4.3 Regression] error: found real variable when subvariables should have appeared
--- Comment #12 from jakub at gcc dot gnu dot org 2007-09-04 06:48 --- Which testcase is not fixed? ./xgcc -B ./ -Wall -Wundef -m32 -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -Werror-implicit-function-declaration -Werror-implicit-function-declaration -Os -msoft-float -mregparm=3 -freg-struct-return -mpreferred-stack-boundary=2 -march=athlon -ffreestanding -maccumulate-outgoing-args -fno-omit-frame-pointer -fno-optimize-sibling-calls -fasynchronous-unwind-tables -fno-stack-protector pr32772-1.i -S In file included from include/asm/thread_info.h:17, from include/linux/thread_info.h:22, from include/linux/preempt.h:10, from include/linux/spinlock.h:50, from include/linux/mmzone.h:8, from include/linux/gfp.h:5, from include/linux/mm.h:9, from mm/page_alloc.c:19: include/asm/processor.h: In function `cpuid_count': include/asm/processor.h:622: warning: pointer targets in passing argument 1 of `__cpuid' differ in signedness include/asm/processor.h:622: warning: pointer targets in passing argument 2 of `__cpuid' differ in signedness include/asm/processor.h:622: warning: pointer targets in passing argument 3 of `__cpuid' differ in signedness include/asm/processor.h:622: warning: pointer targets in passing argument 4 of `__cpuid' differ in signedness succeeds on the http://gcc.gnu.org/bugzilla/attachment.cgi?id=13918&action=view testcase, and the http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32772#c6 testcase as well. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32772
