--- Comment #1 from hp at gcc dot gnu dot org 2008-06-22 08:39 ---
These tests have also regressed for mmix-knuth-mmixware 132182 -> 136827, so if
it's a target-specific thing that went wrong (assuming it's the same reason;
there are two more regressions in that range but that's it FWIW)
Multiple regressions have appeared at revision 136976 (last known working
136953), see:
http://gcc.gnu.org/ml/gcc-testresults/2008-06/msg01644.html
http://gcc.gnu.org/ml/gcc-testresults/2008-06/msg01650.html
A typical failure is:
[karma] f90/bug% /opt/gcc/gcc4.4w/bin/gcc
/opt/gcc/_gcc_clean/gcc/
--- Comment #3 from jsm28 at gcc dot gnu dot org 2008-06-22 11:03 ---
Setting to P4 as an Ada bug, please restore to P3 if a C or C++ testcase is
found.
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
--
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36584
>From revision 136960 (not in 136942) I see multiple warnings during bootstrap:
...
../../gcc-4.4-work/gcc/objc/objc-act.c:6693: warning: request for implicit
conversion from 'void *' to 'const char *' not permitted in C++
../../gcc-4.4-work/gcc/collect2.c:849: warning: request for implicit conver
--- Comment #1 from dominiq at lps dot ens dot fr 2008-06-22 11:18 ---
If I revert revision 136959, the test in comment#0 passes.
--
dominiq at lps dot ens dot fr changed:
What|Removed |Added
--- Comment #2 from ubizjak at gmail dot com 2008-06-22 12:00 ---
Author: hubicka
Date: Thu Jun 19 18:00:12 2008
New Revision: 136959
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=136959
Log:
* builtins.c (expand_builtin_nonlocal_goto): Stabilize r_sp before
clob
only since some days I get a segfault with this backtrace:
gdb cc1
r -fpreprocessed agfa_cl20.i -dumpbase agfa_cl20.i -mtune=generic -auxbase
agfa_cl20 -g -O2 -Wall -Wmissing-declarations -version -fstack-protector -fPIC
-o /tmp/ccqJyq0F.sQuit
Program received signal SIGSEGV, Segmentation fau
--- Comment #1 from marcus at jet dot franken dot de 2008-06-22 12:11
---
Created an attachment (id=15800)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15800&action=view)
agfa_cl20.i
/home/marcus/projects/gcc.trunk/BIN/bin/gcc -Wall -g -fstack-protector
-Wmissing-declarations
http://www.openmp.org/mp-documents/spec30.pdf "Version 3.0 May 2008"
"2.2 Conditional Compilation"
"In implementations that support a preprocessor, the _OPENMP macro name is
defined to have the decimal value mm where and mm are the year and
month designations of the version of the OpenMP
--- Comment #1 from jakub at gcc dot gnu dot org 2008-06-22 12:27 ---
Not sure where you are looking?
http://gcc.gnu.org/viewcvs/trunk/gcc/c-cppbuiltin.c?r1=136425&r2=136433
is the latest revision of c-cppbuiltin.c and that has:
if (flag_openmp)
--- Comment #5 from burnus at gcc dot gnu dot org 2008-06-22 12:28 ---
The error only occurs for logical(1), kind=2,4,8,16 all work.
The program also works if one removes the .not.
interface Near0
function Near0_dp (TestNumber) result (NumberNear0)
real :: TestNumber(2
--- Comment #2 from burnus at gcc dot gnu dot org 2008-06-22 12:31 ---
(In reply to comment #1)
> Not sure where you are looking?
I'm a Fortran guy thus I looked here:
fortran/cpp.c:cpp_define (pfile, "_OPENMP=200505");
--
burnus at gcc dot gnu dot org changed:
What
Testcase gcc.dg/memcpy-1.c fails on AVR target.
Failure occurs because the return value is not simplified to avoid memcpy. This
test works on i686 and I can't see why same optimization should not apply to
AVR
Test is:
/* { dg-do compile } */
/* { dg-options "-O2 -fdump-tree-optimized" } */
/* {
--- Comment #1 from joseph at codesourcery dot com 2008-06-22 13:32 ---
Subject: Re: New: Failed optimisation of return of struct
argment in memcpy-1.c
On Sun, 22 Jun 2008, hutchinsonandy at gcc dot gnu dot org wrote:
> Testcase gcc.dg/memcpy-1.c fails on AVR target.
Have you looke
--- Comment #2 from hutchinsonandy at gcc dot gnu dot org 2008-06-22 14:33
---
Thanks for information
--param sra-max-structure-size=32 does indeed remove test failure and produces
optimal code.
But changing the testcase does not remove the optimization problem - unless
sra-max-struct
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Component|c |middle-end
Keywords||ice-on-val
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-06-22 14:46 ---
I belive this was fixed by
2008-06-21 Bernhard Fischer <[EMAIL PROTECTED]>
* tree-ssa-pre.c (fini_antic): Bitmap_sets have to be freed before
the grand_bitmap_obstack.
--
rguenth at gcc dot gn
--- Comment #3 from lauras at gcc dot gnu dot org 2008-06-22 14:49 ---
Closing since valgrind errors are unreproducible now
--
lauras at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #3 from danglin at gcc dot gnu dot org 2008-06-22 14:49 ---
This was fixed by a library rebuild. There's probably a make file
dependency that is not quite right but I am closing as invalid.
--
danglin at gcc dot gnu dot org changed:
What|Removed
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-06-22 14:50 ---
This is really not a task for SRA but for struct copy propagation (which we
do not do). See PR14295.
As this testcase was for SRA you can either XFAIL it for avr or see if the
cost metrics need adjustment.
--
r
--- Comment #8 from rguenth at gcc dot gnu dot org 2008-06-22 15:05 ---
If we would disallow struct copies in the gimple IL and instead require a
register temporary that we would re-write into SSA form like
struct s temp_struct3;
struct s temp_struct2;
struct s temp_struct1;
str
--- Comment #9 from rguenth at gcc dot gnu dot org 2008-06-22 15:07 ---
Created an attachment (id=15801)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15801&action=view)
aggregate temporary registers
Like this simple, untested patch. Breaks tree-sra.
--
http://gcc.gnu.org/bu
--- Comment #1 from lauras at gcc dot gnu dot org 2008-06-22 15:23 ---
Confirmed with r137000.
To set unsignedp value, lex_charconst calls cpp_interpret_charconst. Here it
quits early with an error, leaving unsignedp uninitialized. I will post a patch
to fix.
--
lauras at gcc dot gn
--- Comment #3 from lauras at gcc dot gnu dot org 2008-06-22 15:28 ---
Subject: Bug 34906
Author: lauras
Date: Sun Jun 22 15:28:04 2008
New Revision: 137020
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=137020
Log:
2008-06-22 Laurynas Biveinis <[EMAIL PROTECTED]>
PR
--- Comment #4 from lauras at gcc dot gnu dot org 2008-06-22 15:30 ---
Fixed on trunk.
--
lauras at gcc dot gnu dot org changed:
What|Removed |Added
Status|UN
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-06-22 15:43 ---
I certainly belive this was uncovered by my patch for PR36345. But I also
believe newlib is at fault here ;) The fix simply makes strict-aliasing rules
followed even more (thus, if you build newlib with -fno-strict
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34906
--- Comment #4 from hutchinsonandy at gcc dot gnu dot org 2008-06-22 16:11
---
Quite possibly due to cost metrics. They are far from ideal.
Will mark test XFAIL until we can investigate and fix.
--
hutchinsonandy at gcc dot gnu dot org changed:
What|Removed
--- Comment #6 from burnus at gcc dot gnu dot org 2008-06-22 16:26 ---
Patch. The problem was that gfortran failed to find a conversion routine for
logical(1) to logical(1), now it simply does nothing and reports success.
I'm not sure whether BT_VOID needs some special care or not. (Cf.
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-06-22 16:56 ---
> I think you're mad. I won't be reporting any bugs to gcc until I see signs
> of intelligence coming from you people.
Huh? Also the linker is not part of GCC anyways. It comes from the
binutils project. You
There is a 20% execution regression on the polyhedron induct.f90 benchmark when
compiled with gfortran in gcc 4.3.1 compared to gcc 4.2.4. This reduction
appears
to be triggered by the -fassociative-math (which appears to require
-fno-signed-zeros -fno-trapping-math to actually be used by gfortran)
--- Comment #1 from howarth at nitro dot med dot uc dot edu 2008-06-22
16:58 ---
Created an attachment (id=15802)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15802&action=view)
assembly file generate with -fno-signed-zeros -fno-trapping-math
--
http://gcc.gnu.org/bugzilla/s
--- Comment #114 from pepalogik at seznam dot cz 2008-06-22 16:59 ---
(In reply to comment #113)
> It is available when storing a result to memory.
Yes, but this requires quite a complicated workaround (solution (4) in my
comment #109). So you could say that the IEEE754 double precision
--- Comment #2 from howarth at nitro dot med dot uc dot edu 2008-06-22
17:00 ---
Created an attachment (id=15803)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15803&action=view)
assembly file generate with -fassociative-math -fno-signed-zeros
-fno-trapping-math
--
http://gcc
--- Comment #115 from pepalogik at seznam dot cz 2008-06-22 17:28 ---
That ® should be (R).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323
--- Comment #3 from burnus at gcc dot gnu dot org 2008-06-22 17:54 ---
Fortran requires that parenthesis are always honoured. All other associative
maths operations are allowed in Fortran, but as IEEE is also allowed, this
gives problems e.g. INF is involved or signed zeros. Therefore, g
I ran into this on NetBSD 4.0; the crash said to report it to NetBSD.
When I did so, they said "Why don't you let _them_ know, then?", "them"
referring to you people. However, gcc 4.0 does not have either the
bugs.html or the BUGS referred to by bugreport.texi, as far as I can
see. When I looked
--- Comment #4 from howarth at nitro dot med dot uc dot edu 2008-06-22
18:30 ---
If the problem is due to the honoring of parenthesis in fortran, why doesn't
this issue manifest itself on powerpc-apple-darwin as well?
http://gcc.gnu.org/ml/fortran/2008-06/msg00249.html
--
http://g
Nico R. <[EMAIL PROTECTED]> reports that building e2fsprogs with gcc-4.3.1 and
-fipa-pta triggers an ICE ... observed on both x86 and x86_64
gcc-4.2.4 seems to work fine
CC tdb.c
cc -I../../lib -I../../lib -DLOCALEDIR=\"/usr/share/locale\"
-DROOT_SYSCONFDIR=\"/etc\" -DPACKAGE_NAME=\"\" -
--- Comment #1 from vapier at gentoo dot org 2008-06-22 19:48 ---
Created an attachment (id=15804)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15804&action=view)
e2fsprogs-fipa-pta.i
reduced test case by Nico R.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36600
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-06-22 19:48 ---
-fipa-pta was never did anything anyways .
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #10 from danglin at gcc dot gnu dot org 2008-06-22 20:02
---
The same change gcc.c-torture/execute/20040709-2.c on all hppa targets
(both 32 and 64 bit). On hppa64-hp-hpux11.11, testK is the first test
to fail. In this case, it appears retmeK is miscompiled.
--
http:/
--- Comment #11 from dave at hiauly1 dot hia dot nrc dot ca 2008-06-22
20:04 ---
Subject: Re: [4.4 Regression] FAIL:
gcc.c-torture/execute/20040709-1.c execution at -O2 and above
> to fail. In this case, it appears retmeK is miscompiled.
Simplified test attached.
Dave
---
This:
template class Foo { friend class F; };
gets you this:
~/ootbc/asm$ g++ foo.cc
foo.cc:2: error: using template type parameter F after class
foo.cc:2: error: friend declaration does not name a class or function
--
Summary: Can't be friended by template class argu
--- Comment #5 from pinskia at gcc dot gnu dot org 2008-06-22 20:13 ---
*** Bug 36601 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-06-22 20:13 ---
Because the C++ standard says you cannot. See PR 24629.
*** This bug has been marked as a duplicate of 24629 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Adde
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-06-22 20:27 ---
Not really a regression as the warning was just enabled in the first place
recently.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from dominiq at lps dot ens dot fr 2008-06-22 20:43 ---
I think the problem is that the vector cost model is not tune for the Intel
Core family.
My understanding of the problem is that without the relevant suboption of
-ffast-math
the inner implicit loops in induct are not
--- Comment #13 from danglin at gcc dot gnu dot org 2008-06-22 20:44
---
retmeK (struct K x)
{
SR.14;
SR.13;
SR.12;
SR.11;
SR.10;
x$i;
x$j;
x$B0F7;
struct K D.1258;
:
x$B0F7_1 = 0;
x$j_2 = 0;
x$i_3 = 0;
SR.13_4 = x.i;
x$i_5 = SR.13_4;
SR.14_6 = x.j
I noticed this while looking into tree-ssa-sccvn.c sources (though I doubt it
helps in general really). But anyways we should optimize the following code
into just a "return 0;":
struct f
{
int t, k;
int g[1024];
};
int g(void)
{
struct f a;
__builtin_memset(&a, 0, sizeof(a));
return a
--- Comment #14 from rguenther at suse dot de 2008-06-22 21:13 ---
Subject: Re: [4.4 Regression] FAIL:
gcc.c-torture/execute/20040709-1.c execution at -O2 and above
On Sun, 22 Jun 2008, danglin at gcc dot gnu dot org wrote:
> --- Comment #13 from danglin at gcc dot gnu dot org 2
--- Comment #116 from vincent at vinc17 dot org 2008-06-22 21:14 ---
(In reply to comment #114)
> Yes, but this requires quite a complicated workaround (solution (4) in my
> comment #109).
The problem is on the compiler side, which could store every result of a cast
or an assignment to
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-06-22 21:26 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #15 from dave at hiauly1 dot hia dot nrc dot ca 2008-06-22
21:34 ---
Subject: Re: [4.4 Regression] FAIL: gcc.c-torture/execute/20040709-1.c
execution at -O2 and above
> > x$B0F7_8 = BIT_FIELD_REF ;
> > D.1258.i ={v} x$i_5;
> > D.1258.j ={v} x$j_7;
> > SR.12_9 = x$B
To quote James van Buskirk on comp.lang.fortran:
> Is there any possibility for gfortran's output
> text files to receive line termination appropriate to the host OS?
(he can't display *.s files properly on Windows without
converting them first)
--
Summary: Use \r\n for generated *.
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-06-22 21:48 ---
> (he can't display *.s files properly on Windows without
> converting them first)
What text editor is he using? I know NotePad does not support UNIX style line
endings but WordPad supports it which is what I use
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-06-22 21:54 ---
Related to bug 36602.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16427
--- Comment #16 from rguenther at suse dot de 2008-06-22 22:23 ---
Subject: Re: [4.4 Regression] FAIL:
gcc.c-torture/execute/20040709-1.c execution at -O2 and above
On Sun, 22 Jun 2008, dave at hiauly1 dot hia dot nrc dot ca wrote:
>
>
> --- Comment #15 from dave at hiauly1 dot
--- Comment #6 from howarth at nitro dot med dot uc dot edu 2008-06-22
22:30 ---
IMHO when a new optimization technique is enabled by default in -O3
and degrades common benchmark performance, it qualifies as a
performance regression for that release.
--
http://gcc.gnu.org/bugzilla
--- Comment #17 from dave at hiauly1 dot hia dot nrc dot ca 2008-06-22
22:43 ---
Subject: Re: [4.4 Regression] FAIL: gcc.c-torture/execute/20040709-1.c
execution at -O2 and above
> > --- Comment #15 from dave at hiauly1 dot hia dot nrc dot ca 2008-06-22
> > 21:34 ---
> > Sub
--- Comment #3 from dje at gcc dot gnu dot org 2008-06-22 23:42 ---
Yes, similarly multiple regressions on AIX. Reverting Honza's patch fixes it.
The failure on AIX is:
gcc/testsuite/gcc.c-torture/compile/20050122-2.c:11: internal
compiler error: in copy_rtx, at rtl.c:314
rs6000.md
--- Comment #7 from howarth at nitro dot med dot uc dot edu 2008-06-23
00:07 ---
Looking at the polyhedron benchmark data from
http://physik.fu-berlin.de/~tburnus/gcc-trunk/benchmark/, there appears to be a
big jump in performance in the induct runtime with -ffast-math and -O3 between
2
--- Comment #8 from howarth at nitro dot med dot uc dot edu 2008-06-23
00:46 ---
Looking at the SuSe polyhedron benchmark servers, the induct regression in
trunk was eliminated between 2008-04-27 and 2008-04-28. My guess is this was
fixed with...
r134730 | rguenth | 2008-04-27 12:27:08
--- Comment #2 from dannysmith at users dot sourceforge dot net 2008-06-23
02:54 ---
Using \r\n will cause problems with pch files.
This is why I made this change
2004-06-05 Danny Smith <[EMAIL PROTECTED]>
* toplev.c (init_asm_output): Add explicit 'b' to mode when
o
--- Comment #26 from russiane39 at gmail dot com 2008-06-23 04:34 ---
This bug also affects OpenSolaris.
# gcc -v
Using built-in specs.
Target: i386-pc-solaris2.11
Configured with: ../gcc-4.2.4/configure --prefix=/usr/gnu --libdir=/usr/gnu/lib
--libexecdir=/usr/gnu/lib --mandir=/usr/gnu/
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P2 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36533
--- Comment #2 from jakub at gcc dot gnu dot org 2008-06-23 06:47 ---
Fixed on the trunk.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|
68 matches
Mail list logo
