--- Comment #5 from jvdelisle at gcc dot gnu dot org 2010-07-16 06:44
---
I am attempting a build on a PPC machine to see if I can fix this. I suspect I
am missing a few casts in the right places.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed
--- Comment #10 from burnus at gcc dot gnu dot org 2010-07-16 07:09 ---
(In reply to comment #9)
(In reply to comment #6)
Please don't keep reopening this bug.
The symbols are weak undefs because libgfortran doesn't require (and
shouldn't
require) libpthread, it is thread-safe
--- Comment #16 from burnus at gcc dot gnu dot org 2010-07-16 07:17 ---
(In reply to comment #15)
By now we have proper whole-file checking. Is this PR still relevant?
I think it is - though there should be some PR about it. The correct way is to
construct the dummy argument list from
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2010-07-16 07:31
---
I am able to reproduce this on the PPC machine I have access to. I think I see
the problem and will submit a patch in the next few days when I can squeeze in
some time.
Dominique, can you do me a favor and test
--- Comment #12 from rguenth at gcc dot gnu dot org 2010-07-16 08:22
---
What does the standard say here? What is the type in effect for aliasing
when doing
int i = va_arg (va, int);
? Is type-punning allowed when unpacking args?
Note that we would need to make sure to use the
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-07-16 08:29 ---
IPA-PTA computes the required information (but we do not store sub-field
granular points-to or clobber sets):
h.clobber = { k.8+8 }
h.use = { }
f.clobber = { k.8+8 } same as f.arg0
f.use = { }
f.arg0 = { k.8+8 }
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Summary|[4.5 Regression] bootstrap |[4.5 Regression] bootstrap
|failed at Comparing
In stddef.h, __GNUG__ appears to be undefined while size_t is defined so that
this will fail:
#if !(defined (__GNUG__) defined (size_t))
typedef __SIZE_TYPE__ size_t;
Compiler invocation:
gcc -DHAVE_CONFIG_H -I. -I. -I. -Iinclude-m32 -O2 -Wall -MT
antlr3basetree.lo -MD -MP -MF
--- Comment #9 from rguenth at gcc dot gnu dot org 2010-07-16 08:38 ---
Frontend issue then. Does it work with -fwhole-file?
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #21 from iains at gcc dot gnu dot org 2010-07-16 08:39 ---
Subject: Bug 42843
Author: iains
Date: Fri Jul 16 08:39:37 2010
New Revision: 162254
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162254
Log:
2010-07-16 Jack Howarth howa...@bromo.med.uc.edu
PR
Reported by bd satish at http://gcc.gnu.org/ml/fortran/2010-07/msg00206.html
The following program segfaults. The crucial part is that the argument has is
CLASS and not TYPE - and that it is used in a specification expression.
The ICE occurs when it is written to the .MOD file.
Valgrind shows:
--- Comment #10 from dominiq at lps dot ens dot fr 2010-07-16 08:51 ---
Does it work with -fwhole-file?
Nope, but it works with -fcheck=all at -O2 and not at -O3.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44945
--- Comment #7 from dominiq at lps dot ens dot fr 2010-07-16 09:03 ---
Dominique, can you do me a favor and test the READ patch as well that I
submitted to see if the issue is there as well. I suspect it is.
Yes!-(
FAIL: gfortran.dg/char4_iunit_1.f03 -O0 execution test
FAIL:
--- Comment #4 from jakub at gcc dot gnu dot org 2010-07-16 09:06 ---
Subject: Bug 44942
Author: jakub
Date: Fri Jul 16 09:06:02 2010
New Revision: 162255
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162255
Log:
PR target/44942
* config/i386/i386-protos.h
--- Comment #11 from burnus at gcc dot gnu dot org 2010-07-16 09:11 ---
Seemingly, we currently only recycle DECLs for procedure decls, but not for
module variable decls.
Looking at
gfortran -fdump-tree-optimized-all -O3 char_array_structure_constructor.f90
one finds (grep MOD_c):
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-07-16 09:39 ---
Looks like a bug in antlr3.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44961
--- Comment #12 from jakub at gcc dot gnu dot org 2010-07-16 10:08 ---
As can be seen on:
module mm
contains
function a ()
integer :: a, b, c
common /blk/ b, c
b = 6
c = 7
a = 8
end function
end module mm
function b ()
integer :: b, d, e
common /blk/ d, e
b
The example program below will exhibit the problem when compiled with
-std=c++0x or gnu++0x flag. The problem is particularly unfortunate, as rope is
designed for use with back_inserter style constructs.
Example program:
#include iostream
#include ext/rope
using namespace std;
int main(int
--- Comment #5 from jakub at gcc dot gnu dot org 2010-07-16 10:35 ---
Fixed on the trunk so far, will backport to branches later on.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from chrbr at gcc dot gnu dot org 2010-07-16 11:34 ---
done since http://gcc.gnu.org/ml/gcc-patches/2010-01/msg01147.html
needed ACCUMULATE_OUTGOING_ARG to fix unwinding (can go back to previous
behavior with -mno-accumulate-outgoing-args -fno-omit-frame-pointer)
--
--- Comment #1 from redi at gcc dot gnu dot org 2010-07-16 12:00 ---
confirmed, the ambiguity comes because crope::const_reference is a typedef for
char, not const char
template class _CharT, class _Alloc
class rope : public _Rope_base_CharT, _Alloc
{
public:
--- Comment #13 from burnus at gcc dot gnu dot org 2010-07-16 12:08 ---
Patch for -fwhole-file (not regtested).
Paul, do you know why derived types where excluded?
Index: trans-decl.c
===
--- trans-decl.c(revision
--- Comment #14 from burnus at gcc dot gnu dot org 2010-07-16 12:08 ---
(In reply to comment #13)
Paul, do you know why derived types where excluded?
s/where/were/ - Firefox needs a grammar checker ...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44945
--- Comment #15 from jakub at gcc dot gnu dot org 2010-07-16 12:32 ---
I wonder whether the middle-end will not mind different types (the recycled
decl will use backend_decl and its type from wherever it has been generated,
and the current function will likely have a different type).
--- Comment #4 from hjl dot tools at gmail dot com 2010-07-16 13:02 ---
It is caused by revision 161744:
http://gcc.gnu.org/ml/gcc-cvs/2010-07/msg00097.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #2 from paolo dot carlini at oracle dot com 2010-07-16 13:12
---
Bah, I'm afraid this is going to be a wontfix. Certainly the
back_insert_iterator assignment operators are fine per se in C++0x mode, and I
don't think we really want to, eg, add specializations of
--- Comment #7 from pault at gcc dot gnu dot org 2010-07-16 13:20 ---
Created an attachment (id=21221)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21221action=view)
Fix for the PR
Please note that this patch contains part of Janus' clean-up of vtabs diff.
This came about
--- Comment #3 from paolo dot carlini at oracle dot com 2010-07-16 13:22
---
Wait a minute, however, what about vectorbool? We can ignore the super-legacy
rope, but is the vectorbool version of the problem known to LWG?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44963
--- Comment #4 from paolo dot carlini at oracle dot com 2010-07-16 13:31
---
It is, LWG 1334. I'll try to figure in Rapperswil if there is enough consensus
about the resolution to warrant an early implementation even if the issue isn't
really resolved.
--
paolo dot carlini at
--- Comment #18 from hjl dot tools at gmail dot com 2010-07-16 13:31
---
The problem isn't new:
[...@gnu-6 case3]$ cat x.c
#include x.h
void
foo (long double x, struct A y, long double z)
{
int i;
struct A a = { { 0, 1, 2, 3 } };
if (x != 8.0L || z != 8.0L)
__builtin_abort
Command line:
$ gcc -fkeep-inline-functions -O[123s] testcase.c
Valgrind output:
$ valgrind -q --trace-children=yes
/mnt/svn/gcc-trunk/binary-162056-lto-fortran-checking-yes-rtl-df/bin/gcc
-fkeep-inline-functions -O1 testcase.c
==20756== Invalid read of size 8
==20756==at 0x8CD66D:
--- Comment #1 from zsojka at seznam dot cz 2010-07-16 13:37 ---
Created an attachment (id=21222)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21222action=view)
reduced testcase (from ffmpeg sources)
Command line:
$ gcc -fkeep-inline-functions -O1 pr44964.c
--
--- Comment #19 from hjl dot tools at gmail dot com 2010-07-16 13:41
---
Created an attachment (id=21223)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21223action=view)
A patch with psABI warning
This patch changes and warns psABI:
[...@gnu-6 case3]$ make
--- Comment #1 from ro at gcc dot gnu dot org 2010-07-16 13:52 ---
This is a regression from GCC 3.4.6.
--
ro at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #20 from hjl dot tools at gmail dot com 2010-07-16 13:55
---
The following testcases are affected:
gcc.c-torture/compile/20070522-1.c
gcc.c-torture/compile/pr33617.c
gcc.c-torture/execute/pr38151.c
gcc.dg/compat/struct-align-1
gcc.dg/compat/struct-align-2
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2010-07-16 14:16
---
Subject: Bug 37077
Author: jvdelisle
Date: Fri Jul 16 14:16:04 2010
New Revision: 162260
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162260
Log:
2010-07-16 Jerry DeLisle jvdeli...@gcc.gnu.org
--- Comment #16 from burnus at gcc dot gnu dot org 2010-07-16 14:21 ---
(In reply to comment #15)
I wonder whether the middle-end will not mind different types (the recycled
decl will use backend_decl and its type from wherever it has been generated,
and the current function will
--- Comment #9 from jvdelisle at gcc dot gnu dot org 2010-07-16 14:21
---
Subject: Bug 37077
Author: jvdelisle
Date: Fri Jul 16 14:21:10 2010
New Revision: 162261
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162261
Log:
2010-07-16 Jerry DeLisle jvdeli...@gcc.gnu.org
--- Comment #10 from rob1weld at aol dot com 2010-07-16 14:31 ---
(In reply to comment #7)
Subject: Bug 32062
Author: hjl
Date: Thu May 24 14:12:18 2007
New Revision: 125025
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125025
Log:
2007-05-24 H.J. Lu hongjiu...@intel.com
--- Comment #17 from paul dot richard dot thomas at gmail dot com
2010-07-16 14:38 ---
Subject: Re: [4.6 Regression] Wrong decl for module vars /
FAIL: gfortran.dg/char_array_structure_constructor.f90
Dear Tobias,
On Fri, Jul 16, 2010 at 2:08 PM, burnus at gcc dot gnu dot
--- Comment #18 from burnus at gcc dot gnu dot org 2010-07-16 14:47 ---
Answer: With the patch, one gets:
gfortran -fwhole-file gfortran.dg/default_initialization_4.f90
without the patch (and still -fwhole-file) it works.
The reason is that one does not copy over the backend_decl for
--- Comment #11 from kargl at gcc dot gnu dot org 2010-07-16 14:48 ---
(In reply to comment #10)
(In reply to comment #9)
(In reply to comment #6)
Please don't keep reopening this bug.
The symbols are weak undefs because libgfortran doesn't require (and
shouldn't
--- Comment #2 from hjl dot tools at gmail dot com 2010-07-16 15:31 ---
It is caused by revision 158477:
http://gcc.gnu.org/ml/gcc-cvs/2010-04/msg00583.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #2 from sme at cs dot toronto dot edu 2010-07-16 16:03 ---
Created an attachment (id=21224)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21224action=view)
three f90 files that reproduce the bug
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44957
--- Comment #3 from sme at cs dot toronto dot edu 2010-07-16 16:04 ---
I've investigated further, and can reproduce it, but with one more condition
that I didn't mention in the original bugreport.
Basically, it happens when we have two modules, both defining a subroutine with
the same
--- Comment #4 from sme at cs dot toronto dot edu 2010-07-16 16:05 ---
Created an attachment (id=21225)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21225action=view)
2nd of three F90 files that reproduce the bug
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44957
--- Comment #5 from sme at cs dot toronto dot edu 2010-07-16 16:06 ---
Created an attachment (id=21226)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21226action=view)
3rd file to reproduce - compiling this one generates the error
--
--- Comment #3 from jason at gcc dot gnu dot org 2010-07-16 16:22 ---
Confirmed; no diagnostic is required by the standard, but we really ought to
give one anyway. Simpler testcase:
template class T struct A { };
Aint* a;
template class T struct AT* { }; // { dg-error Aint * }
--
--
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
--- Comment #6 from kargl at gcc dot gnu dot org 2010-07-16 17:18 ---
(In reply to comment #3)
I've investigated further, and can reproduce it, but with one more condition
that I didn't mention in the original bugreport.
Basically, it happens when we have two modules, both defining
--- Comment #6 from pault at gcc dot gnu dot org 2010-07-16 17:35 ---
(In reply to comment #5)
Is this now fixed on trunk? We had to deal with the TBAA problem with the
arrival of mem-ref2.
Paul
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43986
--- Comment #1 from howarth at nitro dot med dot uc dot edu 2010-07-16
17:36 ---
The offending commit here was...
Revision 155759
2010-01-09 Alexandre Oliva aol...@redhat.com
* config/i386/i386.c (ix86_vectorize_builtin_vec_perm): Silence
bogus uninitialized
--- Comment #2 from howarth at nitro dot med dot uc dot edu 2010-07-16
17:38 ---
Note that the proposed patch for the new flag -Wself-assign...
http://gcc.gnu.org/ml/gcc-patches/2010-06/msg02519.html
reverts the offending commit. That change...
Index: gcc/config/i386/i386.c
--- Comment #2 from domob at gcc dot gnu dot org 2010-07-16 17:50 ---
I just hit it, too:
subroutine foo (x)
procedure(intf) :: x
abstract interface
integer function intf ()
end function intf
end interface
print *, x()
end subroutine foo
--
domob at gcc dot gnu
--- Comment #7 from dominiq at lps dot ens dot fr 2010-07-16 18:28 ---
Works for me too on x86_64-apple-darwin10.4 and powerpc-apple-darwin9.
Ah, here the potential problem, Mac OS X is notorious for having
problems that other OS's do not.
urban legend!-)
--
--- Comment #8 from sme at cs dot toronto dot edu 2010-07-16 18:39 ---
Here's my command line, and the results:
% gfortran -c m_dropdead.F90 m_die.F90 m_IndexBin_char.F90
m_IndexBin_char.F90:12.25:
use m_die, only : die
1
Error: Symbol 'die' referenced
--- Comment #9 from kargl at gcc dot gnu dot org 2010-07-16 18:45 ---
(In reply to comment #8)
Here's my command line, and the results:
% gfortran -c m_dropdead.F90 m_die.F90 m_IndexBin_char.F90
m_IndexBin_char.F90:12.25:
use m_die, only : die
1
--- Comment #4 from Kyle dot D dot Moffett at boeing dot com 2010-07-16
18:48 ---
(In reply to comment #0)
I attached two testcase which is stripped down graphicsmagick code.
tc-resize2.c has a few instructions more than tc-resize.c. I belive the bug
is
the same.
I was able to
--- Comment #10 from sme at cs dot toronto dot edu 2010-07-16 19:00 ---
Okay, I just upgraded to 4.4.1 and it compiles fine.
Thanks!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44957
--- Comment #33 from pthaugen at gcc dot gnu dot org 2010-07-16 19:14
---
gcc.dg/tree-ssa/loop-19.c started failing on powerpc with -m64 between 7/5 and
7/7. The tree dump now looks like the following:
bb 2:
ivtmp.10_12 = (long unsigned int) a[-1];
ivtmp.16_15 = (long unsigned
--- Comment #19 from jason at gcc dot gnu dot org 2010-07-16 19:21 ---
Created an attachment (id=21227)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21227action=view)
final __forced_unwind patch and fixes applied in 2007, for historical reference
--
--- Comment #5 from oakad at yahoo dot com 2010-07-16 19:21 ---
Why is rope super-legacy? It had not enough attention to it, true, but it's a
very convenient class in certain cases.
Does the bug resolution means that no more changes/updates are expected for gcc
supplied rope, so
--- Comment #9 from Dr dot diesel at gmail dot com 2010-07-16 19:38 ---
I don't get any different output than Scott, no .ii file, but I have exactly
the same problem on Fedora 13 64bit.
avrdude-5.10-2.fc13.x86_64
avr-gcc-c++-4.5.0-2.fc13.x86_64
avra-1.2.3-4.fc13.x86_64
--- Comment #11 from kargl at gcc dot gnu dot org 2010-07-16 19:46 ---
Closing as WONTFIX. With trunk being for active development
and 4.4 and 4.5 under maintenance commits, I doubt anyone
will find time to investigate this further.
Thanks for the bug report.
--
kargl at gcc dot
--- Comment #6 from redi at gcc dot gnu dot org 2010-07-16 20:33 ---
what resolution? this bug has no resolution, it's been suspended until we know
what the C++ committee decide to do about DR 1334. The proposed resolution to
DR 1334 would solve the problem with rope.
--
--- Comment #4 from jason at gcc dot gnu dot org 2010-07-16 21:05 ---
Subject: Bug 32505
Author: jason
Date: Fri Jul 16 21:05:16 2010
New Revision: 162269
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162269
Log:
PR c++/32505
* pt.c
--- Comment #7 from paolo dot carlini at oracle dot com 2010-07-16 21:37
---
Yes, it's considered super-legacy vs hash_map, for example, which is just
legacy. The criterion is very simple: we are missing active maintainers. Just
for your information, I'm the one who voted for keeping
Had the following problem happen:
Create a LTO build of a program with a gcc git checkout
Update to a slightly newer checkout
The new checkout had one option in fortran more added
Continue compiling the program without make clean with the new compiler
LTO link failed with this assert failing:
--- Comment #1 from andi-gcc at firstfloor dot org 2010-07-16 23:07 ---
One way to solve this would be to use a hash of the option table as a version
number.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44965
--- Comment #3 from howarth at nitro dot med dot uc dot edu 2010-07-16
23:13 ---
According to Le-Chun Wu, the commit...
Author: davidxl
Date: Wed Apr 28 17:41:31 2010
New Revision: 158835
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158835
Log:
predicate aware uninitialized
With the attached test case which tests WHOPR with weak aliases
I get a segfault in lto_symtab_merge_decls_1 line 758
This happens in
if (prevailing-node-same_body_alias)
prevailing-node-same_body-local.used_from_object_file = true;
else
--- Comment #1 from andi-gcc at firstfloor dot org 2010-07-16 23:23 ---
Created an attachment (id=21228)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21228action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44966
--- Comment #5 from bernds at gcc dot gnu dot org 2010-07-16 23:48 ---
Subject: Bug 42235
Author: bernds
Date: Fri Jul 16 23:47:46 2010
New Revision: 162270
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162270
Log:
PR target/42235
* postreload.c
--prefix=/home/prak/Dev/gcc-install --disable-bootstrap
Thread model: posix
gcc version 4.6.0 20100716 (experimental) (GCC)
COLLECT_GCC_OPTIONS='-v' '-std=c++0x' '-shared-libgcc' '-mtune=generic'
'-march=pentiumpro'
/home/prak/Dev/gcc-install/libexec/gcc/i686-pc-linux-gnu/4.6.0/cc1plus -quiet
-v
--- Comment #1 from piotr dot rak at gmail dot com 2010-07-16 23:49 ---
Created an attachment (id=21229)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21229action=view)
Testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44967
For the dehydra plugin, we unfortunately have to delay processing certain types
until after their completion (see
http://hg.mozilla.org/rewriting-and-analysis/dehydra/file/1248fd227e7f/dehydra_plugin.c#l426).
We do this by saving the types in a vector and then processing them during
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-07-16 23:52 ---
Really it is kinda expected that for development versions, lto file format is
going to be unstable. Now crashing is not the right thing to do. Doing a hash
is not going to work either I think.
--
--- Comment #1 from ehren dot m at gmail dot com 2010-07-16 23:53 ---
Created an attachment (id=21230)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21230action=view)
plugin
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44968
--- Comment #2 from ehren dot m at gmail dot com 2010-07-16 23:55 ---
Created an attachment (id=21231)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21231action=view)
test code (sqlite3)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44968
--- Comment #3 from ehren dot m at gmail dot com 2010-07-16 23:57 ---
Created an attachment (id=21232)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21232action=view)
plugin output
in particular, look at the series of RECORD_TYPES beginning with #511.
Interestingly, their
--- Comment #3 from andi-gcc at firstfloor dot org 2010-07-16 23:58 ---
It's not only development versions, options can change between minor releases
Also I don't think LTO_major/minor is always increased anyways.
Why should a hash over the option table not work?
--
: posix
gcc version 4.6.0 20100716 (experimental) (GCC)
COLLECT_GCC_OPTIONS='-v' '-c' '-std=c++0x' '-shared-libgcc' '-mtune=generic'
'-march=pentiumpro'
/home/prak/Dev/gcc-install/libexec/gcc/i686-pc-linux-gnu/4.6.0/cc1plus -quiet
-v -D_GNU_SOURCE is_constructible_bug.cc -quiet -dumpbase
--- Comment #4 from pinskia at gcc dot gnu dot org 2010-07-17 00:03 ---
Could they have been GCed?
Most likely yes. easy way to find out is to configure with valgrind checking
and run valgrind over cc1plus with your plugin loaded.
--
pinskia at gcc dot gnu dot org changed:
--- Comment #1 from piotr dot rak at gmail dot com 2010-07-17 00:03 ---
Created an attachment (id=21233)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21233action=view)
Testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44969
--- Comment #4 from pinskia at gcc dot gnu dot org 2010-07-17 00:04 ---
(In reply to comment #3)
It's not only development versions, options can change between minor releases
Also I don't think LTO_major/minor is always increased anyways.
I think we should just store out the GCC
--- Comment #5 from pinskia at gcc dot gnu dot org 2010-07-17 00:08 ---
Oh one more thing, bugzilla is not the right form for help debugging plugins
really.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44968
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
CC||jason at gcc dot gnu dot org
Status|UNCONFIRMED
--- Comment #2 from paolo dot carlini at oracle dot com 2010-07-17 00:56
---
I don't think this is a library issue, the implementation is straightforward.
The below C++03 snippet already shows the problem, is rejected (ICC likes it).
Jason, can you have a look to this one too?
On Linux/ia32, revision 162270:
http://gcc.gnu.org/ml/gcc-cvs/2010-07/msg00624.html
caused:
make[6]: Leaving directory `/export/gnu/import/svn/gcc-test/bld'
Comparing stages 2 and 3
warning: gcc/cc1obj-checksum.o differs
warning: gcc/cc1plus-checksum.o differs
warning: gcc/cc1-checksum.o
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Target Milestone|--- |4.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44970
--- Comment #5 from jason at gcc dot gnu dot org 2010-07-17 04:13 ---
Fixed for 4.6.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
91 matches
Mail list logo
