--- Comment #2 from amylaar at gcc dot gnu dot org 2010-05-12 06:54 ---
A patch is here:
http://gcc.gnu.org/ml/gcc-patches/2010-05/msg00788.html
--
amylaar at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from jakub at gcc dot gnu dot org 2010-05-12 06:33 ---
Yeah, this is fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #2 from christian dot eggers at kathrein dot de 2010-05-12
06:29 ---
(In reply to comment #1)
> I think this is related to PR 12448
>
Yes, it's a similar. PR 12448 says that "-MT " produces a wrong result,
but it seems that this has already been fixed. Can the behavior of "
--- Comment #7 from jakub at gcc dot gnu dot org 2010-05-12 06:25 ---
I can't reproduce the problem either, neither in 4.6 nor in 4.4. 4.5.0 (rather
than current 4.5 snapshots) had a bug with nonnull attribute if a function is
IPA optimized and some arguments are optimized out, but I do
--- Comment #6 from pmoulder at mail dot csse dot monash dot edu dot au
2010-05-12 05:29 ---
Part of the problem is a documentation bug: the nonnull attribute's parameter
is named "arg-index", suggesting that the first parameter is 0, while the
example strongly suggests that the first p
--- Comment #2 from astrange at ithinksw dot com 2010-05-12 05:27 ---
Created an attachment (id=20639)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20639&action=view)
test file 2
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44090
--- Comment #1 from astrange at ithinksw dot com 2010-05-12 05:27 ---
Created an attachment (id=20638)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20638&action=view)
test file 1
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44090
rch=native --with-tune=native --disable-nls --enable-lto
--disable-bootstrap LDFLAGS=-L/sw/lib CPPFLAGS=-I/sw/include
--enable-languages=c,c++,objc,obj-c++,lto
Thread model: posix
gcc version 4.6.0 20100511 (experimental) (GCC)
The attached files have two different definitions of MpegEncContext. -f
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org
|dot org
On vect256 branch, I got
[...@gnu-34 gcc]$ ./xgcc -B./ -mavx -O3
/export/gnu/import/git/gcc-avx256/gcc/testsuite/gfortran.dg/vect/pr33301.f -S
/export/gnu/import/git/gcc-avx256/gcc/testsuite/gfortran.dg/vect/pr33301.f: In
function \u2018zgelsx\u2019:
/export/gnu/import/git/gcc-avx256/gcc/testsuite
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2010-05-12 03:28
---
With all due respect for Cowan, I think that the program should be revised to
use standard code, or at least not use this particular feature. The last
revision of the program was in 2004. I agree we should close
--- Comment #1 from carrot at google dot com 2010-05-12 02:22 ---
It turns out that my original test case matches a conditional move pattern. It
shows another opportunity.
The following code demonstrates a simple compare and branch case
void foo1();
void bar5(int x)
{
if (x == -1)
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
GCC target trip
--- Comment #1 from hjl dot tools at gmail dot com 2010-05-12 00:48 ---
A patch is posted at
http://gcc.gnu.org/ml/gcc-patches/2010-05/msg00807.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
---
[...@gnu-6 gcc]$ cat
/export/gnu/import/git/gcc/gcc/testsuite/gcc.target/i386/avx-cmpsd-2.c
/* { dg-do compile } */
/* { dg-options "-O2 -mavx" } */
#include
__m128d
foo (__m128d x, __m128d y)
{
return _mm_cmpeq_sd (x, y);
}
/* { dg-final { scan-assembler "vcmpeqsd" } } */
[...@gnu-6 gcc]$ g
--- Comment #2 from paolo dot carlini at oracle dot com 2010-05-11 23:50
---
Looking into it.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-05-11 23:14 ---
I think this is related to PR 12448
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44076
--- Comment #5 from pinskia at gcc dot gnu dot org 2010-05-11 22:59 ---
Works for me with:
.ident "GCC: (GNU) 4.6.0 20100427 (experimental) [trunk revision
158795]"
on x86_64 with -m32 -O2 -fno-inline.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #14 from pluto at agmk dot net 2010-05-11 22:50 ---
few hours of git-bisecting and i have first bad commit:
3bfe8549d7fd3c67c90f64e76cbf60daae1e211c is the first bad commit
commit 3bfe8549d7fd3c67c90f64e76cbf60daae1e211c
Author: bkoz
Date: Tue Jan 13 01:49:30 2009 +
--- Comment #2 from kargl at gcc dot gnu dot org 2010-05-11 22:20 ---
The dates for the "Known to work" versions are
gcc version 4.6.0 20100503 (experimental) (GCC)
gcc version 4.5.1 20100420 (prerelease) (GCC)
gcc version 4.4.5 20100504 (prerelease) (GCC)
This is most likely fixed on
--- Comment #1 from dfranke at gcc dot gnu dot org 2010-05-11 22:14 ---
gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5)
$> gfortran-4.4 -fopenmp pr44085.f90 &&./a.out
FAIL - Negative test should not compile
gcc version 4.5.1 20100509 (prerelease)
$> gfortran-4.5 -fopenmp pr44085.f90 &&./a.o
--- Comment #1 from dfranke at gcc dot gnu dot org 2010-05-11 22:10 ---
(In reply to comment #0)
> [Expected output is no output, e.g. from Intel compiler.]
There's no output with 4.5 (gcc version 4.5.1 20100509) or current trunk (gcc
version 4.6.0 20100510); my system compiler, gcc ver
--- Comment #12 from hp at gcc dot gnu dot org 2010-05-11 21:33 ---
The committed patch fixed the build issue (thanks), so closing.
If some of the issues in the follow-up comments remains, please clone.
--
hp at gcc dot gnu dot org changed:
What|Removed
--- Comment #7 from paolo dot carlini at oracle dot com 2010-05-11 20:56
---
Fixed for 4.6.0.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #6 from paolo dot carlini at oracle dot com 2010-05-11 20:55
---
Fixed for 4.6.0.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #3 from paolo dot carlini at oracle dot com 2010-05-11 20:54
---
Fixed for 4.6.0.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #6 from paolo at gcc dot gnu dot org 2010-05-11 20:53 ---
Subject: Bug 34491
Author: paolo
Date: Tue May 11 20:53:36 2010
New Revision: 159295
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159295
Log:
/cp
2010-05-11 Paolo Carlini
PR c++/34272
PR
--- Comment #5 from paolo at gcc dot gnu dot org 2010-05-11 20:53 ---
Subject: Bug 34272
Author: paolo
Date: Tue May 11 20:53:36 2010
New Revision: 159295
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159295
Log:
/cp
2010-05-11 Paolo Carlini
PR c++/34272
PR
--- Comment #2 from paolo at gcc dot gnu dot org 2010-05-11 20:53 ---
Subject: Bug 43630
Author: paolo
Date: Tue May 11 20:53:36 2010
New Revision: 159295
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159295
Log:
/cp
2010-05-11 Paolo Carlini
PR c++/34272
PR
On Linux/ia32, revision 159280 gave:
FAIL: gcc.dg/lto/20081204-2 c_lto_20081204-2_0.o-c_lto_20081204-2_0.o link,
(internal compiler error)
FAIL: gfortran.dg/lto/20091015-1 f_lto_20091015-1_0.o-f_lto_20091015-1_2.o link
FAIL: gfortran.dg/lto/20091015-1 f_lto_20091015-1_0.o-f_lto_20091015-1_2.o lin
--- Comment #1 from fabien dot chene at gmail dot com 2010-05-11 18:50
---
(mine)
--
fabien dot chene at gmail dot com changed:
What|Removed |Added
Known to fail|
struct A
{
int const i : 2;
};
void f()
{
A a; // <- should fail
new A; // <- should fail
}
--
Summary: undiagnosed invalid default initialization of bit field
members
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
--- Comment #6 from jakub at gcc dot gnu dot org 2010-05-11 18:29 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #9 from jakub at gcc dot gnu dot org 2010-05-11 18:28 ---
Fixed on the trunk so far, will backport to 4.5 after a while if there aren't
any issues with it on the trunk.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #13 from jakub at gcc dot gnu dot org 2010-05-11 18:25 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #12 from jakub at gcc dot gnu dot org 2010-05-11 18:23 ---
Subject: Bug 44071
Author: jakub
Date: Tue May 11 18:22:52 2010
New Revision: 159289
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159289
Log:
PR middle-end/44071
* cfglayout.c (fixup_reorder
Test Case:
! derived from OpenMP test omp3f/NF03_2_9_2_2a.f90
! REFERENCES : OpenMP 3.0, p. 83, line 30
program NF03_2_9_2_2a
implicit none
integer, save :: threadprivate_var
!$omp threadprivate(threadprivate_var)
!$omp parallel
!$omp task untied
threadprivate_var = 1
!$omp end task
!$
--- Comment #11 from jakub at gcc dot gnu dot org 2010-05-11 18:18 ---
Subject: Bug 44071
Author: jakub
Date: Tue May 11 18:17:43 2010
New Revision: 159288
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159288
Log:
PR middle-end/44071
* cfglayout.c (fixup_reorder
--- Comment #8 from jakub at gcc dot gnu dot org 2010-05-11 18:14 ---
Subject: Bug 44059
Author: jakub
Date: Tue May 11 18:14:19 2010
New Revision: 159287
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159287
Log:
PR c++/44059
* config/elfos.h (ASM_DECLARE_OBJECT
--- Comment #5 from jakub at gcc dot gnu dot org 2010-05-11 18:12 ---
Subject: Bug 44062
Author: jakub
Date: Tue May 11 18:12:28 2010
New Revision: 159286
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159286
Log:
PR c++/44062
* c-parser.c (c_parser_expression):
Test Case:
! derived from OpenMP test omp3f/F03_2_9_1_1_4a.f90
! REFERENCES : OpenMP 3.0, p. 79, lines 11-14
program F03_2_9_1_1_4a
use omp_lib
implicit none
integer, parameter :: NT = 4
integer, parameter :: EXPECTED_i = -1 ! expected value of i at end
integer, parameter :: EXPEC
--- Comment #3 from jingyu at google dot com 2010-05-11 17:56 ---
I configure gcc with --with-arch=armv5te. The default multilib will be compiled
in ARM mode.
The error happens when I build the armv7-a/thumb multilib.
I checked the config.log for armv7-a/thumb/libgcc, libgcc was indeed c
--- Comment #11 from hp at gcc dot gnu dot org 2010-05-11 17:17 ---
Changing back target milestone to reflect the earliest release known to have
the fix.
--
hp at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from hp at gcc dot gnu dot org 2010-05-11 17:06 ---
(In reply to comment #6)
> Causes PR40414 on GCC 4.4.x, reopening to make the other PR depend on this.
Looks like the above statement is wrong: the committed patch for this PR is
just (one of the two) required for PR404
--- Comment #3 from danglin at gcc dot gnu dot org 2010-05-11 16:58 ---
Fixed.
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
Status|WAITING
--- Comment #10 from jakub at gcc dot gnu dot org 2010-05-11 16:50 ---
Yeah.
BTW: you don't necessarily need to use the %l[f_yes] syntax, when there are no
input operands of the asm goto you can just as well use %l0 resp. %l1.
--
jakub at gcc dot gnu dot org changed:
What
--- Comment #9 from hp at gcc dot gnu dot org 2010-05-11 16:48 ---
(In reply to comment #8)
> In this case, I guess the way to go would be to apply *both* my patch
> and Hans-Peter's patch to the 4.4 branch ...
I'm sorry I missed that the committed patch was fingered as a regressor (sp?
--- Comment #5 from dfranke at gcc dot gnu dot org 2010-05-11 16:46 ---
(In reply to comment #4)
> Fixed in trunk. Closing.
...
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #4 from dfranke at gcc dot gnu dot org 2010-05-11 16:46 ---
Fixed in trunk. Closing.
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
Target M
--- Comment #3 from dfranke at gcc dot gnu dot org 2010-05-11 16:45 ---
Subject: Bug 43711
Author: dfranke
Date: Tue May 11 16:45:17 2010
New Revision: 159282
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159282
Log:
gcc/fortran/:
2010-05-11 Daniel Franke
PR fortran
--- Comment #14 from fabien dot chene at gmail dot com 2010-05-11 16:43
---
Fixed (committed by Jason).
--
fabien dot chene at gmail dot com changed:
What|Removed |Added
--- Comment #6 from fabien dot chene at gmail dot com 2010-05-11 16:41
---
Fixed in rev 158918, committed by Jason.
--
fabien dot chene at gmail dot com changed:
What|Removed |Added
-
--- Comment #2 from dfranke at gcc dot gnu dot org 2010-05-11 16:38 ---
(In reply to comment #1)
> Just for completeness: This is a regression with regards to g77.
The standards are a mouthful already. Do we need every extension that there
ever was? Besides this PR, demand was non-exist
--- Comment #9 from hpa at zytor dot com 2010-05-11 16:15 ---
Thanks everyone for jumping (groan) on this.
>From the looks of it, changing the asm goto statement itself to:
asm goto ("# Either %l[f_yes] or %l[f_no]\n\t"
"jmp %l[f_yes]"
: : : : f_yes, f_no);
.
--- Comment #5 from h dot m dot brand at xs4all dot nl 2010-05-11 15:54
---
Subject: Re: Impossible to build any version beyond 4.2.4
On 5 May 2010 20:54:53 -, "sje at cup dot hp dot com"
wrote:
> --- Comment #4 from sje at cup dot hp dot com 2010-05-05 20:54 ---
> I ha
--- Comment #8 from dfranke at gcc dot gnu dot org 2010-05-11 15:46 ---
Fixed in trunk. Closing.
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from dfranke at gcc dot gnu dot org 2010-05-11 15:43 ---
Subject: Bug 31820
Author: dfranke
Date: Tue May 11 15:43:16 2010
New Revision: 159278
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159278
Log:
gcc/fortran/:
2010-05-11 Daniel Franke
PR fortran
--- Comment #4 from hv at crypt dot org 2010-05-11 15:38 ---
(In reply to comment #3)
> That's a user bug. You shouldn't pass NULL to arguments declared nonnull.
> To quote gcc documentation:
> "The compiler may also choose to make optimizations based
> on the knowledge that certain fun
--- Comment #11 from hubicka at gcc dot gnu dot org 2010-05-11 15:16
---
Subject: Bug 44063
Author: hubicka
Date: Tue May 11 15:15:48 2010
New Revision: 159273
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159273
Log:
PR tree-optimize/44063
* ipa-inline.c (cgr
--- Comment #5 from rogier dot wester at asml dot com 2010-05-11 14:55
---
Created an attachment (id=20637)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20637&action=view)
a second include including the first include file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44083
--- Comment #4 from rogier dot wester at asml dot com 2010-05-11 14:55
---
Created an attachment (id=20636)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20636&action=view)
an include file including the first include file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44083
--- Comment #3 from rogier dot wester at asml dot com 2010-05-11 14:54
---
Created an attachment (id=20635)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20635&action=view)
the precompiled include file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44083
--- Comment #2 from rogier dot wester at asml dot com 2010-05-11 14:54
---
Created an attachment (id=20634)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20634&action=view)
the original include file (not precompiled)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44083
--- Comment #1 from rogier dot wester at asml dot com 2010-05-11 14:53
---
Created an attachment (id=20633)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20633&action=view)
source file including 2 include files
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44083
--- Comment #3 from jakub at gcc dot gnu dot org 2010-05-11 14:51 ---
That's a user bug. You shouldn't pass NULL to arguments declared nonnull.
To quote gcc documentation:
"The compiler may also choose to make optimizations based
on the knowledge that certain function arguments will not
below you find the information on my host system and the used gcc command.
I tried to use a pre-compiled header file. There is one file that includes two
include files which both include another (the same) header file. I wanted to
see whether the pre-compiled header file was taken from both includ
--- Comment #2 from jakub at gcc dot gnu dot org 2010-05-11 14:43 ---
Created an attachment (id=20632)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20632&action=view)
gcc46-pr42278.patch
Untested patch. I'll need to see whether we don't generate too many
__unknown__ names with i
--- Comment #2 from hv at crypt dot org 2010-05-11 14:41 ---
Created an attachment (id=20631)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20631&action=view)
Generated assembly code, with annotation
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44081
--- Comment #1 from hv at crypt dot org 2010-05-11 14:41 ---
Created an attachment (id=20630)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20630&action=view)
C source code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44081
After watchdog reset (for example, to enter reprogramming), the AVR core
restarts with watchdog enabled, contrary to a cold start after power on.
The C program is not given an opportunity to disable or reset the watchdog
before "main" ; and when the data and/or bss section is large enough, the
watc
zen% /opt/gcc-4.5.0/bin/gcc -v
Using built-in specs.
COLLECT_GCC=/opt/gcc-4.5.0/bin/gcc
COLLECT_LTO_WRAPPER=/opt/gcc-4.5.0/libexec/gcc/i686-pc-linux-gnu/4.5.0/lto-wrapper
Target: i686-pc-linux-gnu
Configured with: /src/package/lang/other/gcc-4.5.0/configure
--prefix=/opt/gcc-4.5.0 --with-gmp=/opt/g
When gcc is called with -O3, it could add -O1 to the options it passes to the
linker, when it knows that it is GNU ld. For now this is only useful with
-shared, but I don't see any reason not to also pass it without -shared.
Reference:
http://gcc.gnu.org/ml/gcc/2010-05/msg00193.html
--
Configure Script does not detect elf_getshdrstrndx
But still tries to use it in stage 2 bootstrap and gives error,
../../trunk/gcc/lto/lto-elf.c: In function 'validate_file' :
../../trunk/gcc/lto/lto-elf.c:539:3:error: implicit declaration of
function 'elf_getshdrstrndx' [-Werror=implicit-funct
--- Comment #2 from borntraeger at de dot ibm dot com 2010-05-11 13:57
---
Created an attachment (id=20629)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20629&action=view)
Testfix for the prefetch-7.c testcase
There always was
fprintf (dump_file, "Marked reference %p as a no
--- Comment #8 from uweigand at gcc dot gnu dot org 2010-05-11 13:57
---
(In reply to comment #7)
> Not sure what's the state here. Is 4.4 broken now?
Here's the status as far as I know. I had checked in a patch:
http://gcc.gnu.org/ml/gcc-patches/2009-08/msg00254.html
to fix the prob
--- Comment #6 from danglin at gcc dot gnu dot org 2010-05-11 13:46 ---
I have rechecked 4.4 and 4.5 and the test is no longer failing.
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #1 from borntraeger at de dot ibm dot com 2010-05-11 13:43
---
>From a first look this looks like that the test case scans for
"nontemporal store" which is also emitted by the new debug messages:
-return false;
+{
+ if (dump_file && (dump_flags & TDF_DETAILS))
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38591
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43416
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43190
--- Comment #7 from rguenth at gcc dot gnu dot org 2010-05-11 13:38 ---
Not sure what's the state here. Is 4.4 broken now?
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
-
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43810
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44063
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44018
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43820
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43689
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Summary|[4.4, 4.5, 4.6 regression] |[4.4/4.5/4.6 regression]
|incorrect dwarf data gcc-
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44078
On Linux/ia32, revision 159262 gave:
FAIL: gcc.dg/tree-ssa/prefetch-7.c scan-tree-dump-times aprefetch "nontemporal
store" 2
Revision 159255 is OK. It may be caused by revisions 159256/159257:
http://gcc.gnu.org/ml/gcc-cvs/2010-05/msg00307.html
http://gcc.gnu.org/ml/gcc-cvs/2010-05/msg00308.html
--- Comment #4 from jakub at gcc dot gnu dot org 2010-05-11 12:48 ---
Created an attachment (id=20628)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20628&action=view)
gcc46-pr44062-c++.patch
C++ change that fixes this.
It treats all (void) / static_cast conversions and the impli
--- Comment #8 from jakub at gcc dot gnu dot org 2010-05-11 12:18 ---
Created an attachment (id=20627)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20627&action=view)
gcc46-pr44071.patch
Updated patch that fixes the rest of the issues. The reason why testcase
without __builtin_u
--- Comment #2 from dave at hiauly1 dot hia dot nrc dot ca 2010-05-11
12:05 ---
Subject: Re: genautomata: undeclared unit or reservation `cortex_a9_}ult'
> Is this still an issue ? My armv5te box was bootstrapping without the issue
> you
> mention in cortex-a9.md and there is a test
--- Comment #10 from joel at gcc dot gnu dot org 2010-05-11 11:50 ---
FWIW also seen on sparc-rtems, powerpc-rtems, and i386-rtems.
This did not happen building mips-rtems.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44063
For the small testcase below gcc-4.4.3 neither warns about the initialization
of var1 nor about the comparison against an integer. Nevertheless the
comparison
is optimized away.
// gcc -O2 -Wtype-limits
_Bool var1 = 3;
int test(void)
{
if (var1 == 3)
return 1;
return 0;
}
This maybe relat
--- Comment #25 from dougmencken at gmail dot com 2010-05-11 11:31 ---
(In reply to comment #24)
Okay, I'm ready to bisect. I know it would take weeks. I cloned gcc repo using
git clone git://git.infradead.org/toolchain/gcc.git gcc-git , but this repo
doesn't use tags (i.e. I can't speci
--- Comment #3 from astrange at ithinksw dot com 2010-05-11 10:36 ---
It's propagated by vrp1, and then nothing removes it again. tree-uncprop
doesn't change it - it looks like it doesn't have anything to handle this,
actually.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44073
--- Comment #2 from steven at gcc dot gnu dot org 2010-05-11 10:24 ---
There is a GIMPLE uncprop pass for this. Could you verify that after this pass
there is just one assignment of the constant to an SSA_NAME? If so, the problem
is in the RTL CPROP pass, otherwise we have to look at the
--- Comment #26 from paolo at gcc dot gnu dot org 2010-05-11 10:23 ---
Subject: Bug 43259
Author: paolo
Date: Tue May 11 10:23:20 2010
New Revision: 159269
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159269
Log:
2010-05-11 Silvius Rus
PR libstdc++/43259
*
--- Comment #25 from paolo at gcc dot gnu dot org 2010-05-11 10:22 ---
Subject: Bug 43259
Author: paolo
Date: Tue May 11 10:22:18 2010
New Revision: 159268
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159268
Log:
2010-05-11 Silvius Rus
PR libstdc++/43259
*
--- Comment #7 from jakub at gcc dot gnu dot org 2010-05-11 10:20 ---
Created an attachment (id=20626)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20626&action=view)
gcc46-pr44071.patch
Untested fix for the ICE part (and, with __builtin_unreachable the generated
code is even cor
1 - 100 of 131 matches
Mail list logo
