--- 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
Status|ASSIG
--
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
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 differs
--- 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?
///
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
CC||jason at gcc dot gnu dot org
Status|UNCONFIRMED
--- 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
--- 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 ver
--- 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=21233&action=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: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:
pc-linux-gnu/4.6.0/lto-wrapper
Target: i686-pc-linux-gnu
Configured with: ../gcc.git/configure --enable-languages=c,c++
--program-suffix=-trunk --prefix=/home/prak/Dev/gcc-install --disable-bootstrap
Thread model: posix
gcc version 4.6.0 20100716 (experimental) (GCC)
COLLECT_GCC_OPTIONS='-v'
--- 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?
--
http://gcc.gnu.
--- 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=21232&action=view)
plugin output
in particular, look at the series of RECORD_TYPES beginning with #511.
Interestingly, their definit
--- 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=21231&action=view)
test code (sqlite3)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44968
--- 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=21230&action=view)
plugin
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44968
--- 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.
--
http://gcc.
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
PLUGIN_FINISH_
--- 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=21229&action=view)
Testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44967
inux-gnu
Configured with: ../gcc.git/configure --enable-languages=c,c++
--program-suffix=-trunk --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&
--- 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=gcc&view=rev&rev=162270
Log:
PR target/42235
* postreload.c (reload_cse_move
--- 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=21228&action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44966
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
prevailin
--- 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=gcc&view=rev&rev=158835
Log:
predicate aware uninitialized a
--- 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
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:
392
--- 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 it
--- 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=gcc&view=rev&rev=162269
Log:
PR c++/32505
* pt.c (process_partial_specializati
--- 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.
--
http://gcc
--- 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 g
--- 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
avr-gcc-4.5.0-2.f
--- 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 externa
--- 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=21227&action=view)
final __forced_unwind patch and fixes applied in 2007, for historical reference
--
http://gcc.gnu.org/bugzil
--- 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:
:
ivtmp.10_12 = (long unsigned int) &a[-1];
ivtmp.16_15 = (long unsigned int) &c
--- 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 #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 t
--- 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
>
--- 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 a
--- 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!-)
--
http://gcc.gnu.org
--- 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 dot
--- 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 #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
* config/i386/i386.c (ix86_vectorize_builtin_vec_perm): Silence
bogus uninitialized warning.
--
howarth
--- 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 #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 definin
--
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 #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 struct A { };
A a;
template struct A { }; // { dg-error "A" }
--
jason at gcc dot gnu dot
--- 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=21226&action=view)
3rd file to reproduce - compiling this one generates the error
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?i
--- 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=21225&action=view)
2nd of 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 n
--- 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=21224&action=view)
three f90 files that reproduce the bug
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44957
--- 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 #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 #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 fo
--- 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 or
--- 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=gcc&view=rev&rev=125025
> Log:
> 2007-05-24 H.J. Lu
> PR
--- 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=gcc&view=rev&rev=162261
Log:
2010-07-16 Jerry DeLisle
PR libfortran/37077
--- 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 #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=gcc&view=rev&rev=162260
Log:
2010-07-16 Jerry DeLisle
PR libfortran/37077
--- 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
gcc.dg/compat/vect
--- 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
Kno
--- 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=21223&action=view)
A patch with psABI warning
This patch changes and warns psABI:
[...@gnu-6 case3]$ make
/export/build/gnu/gcc
--- 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=21222&action=view)
reduced testcase (from ffmpeg sources)
Command line:
$ gcc -fkeep-inline-functions -O1 pr44964.c
--
http://gcc.gn
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: gimple_defa
--- 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_abor
--- 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 oracle
--- Comment #3 from paolo dot carlini at oracle dot com 2010-07-16 13:22
---
Wait a minute, however, what about vector? We can ignore the super-legacy
rope, but is the vector version of the problem known to LWG?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44963
--- 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=21221&action=view)
Fix for the PR
Please note that this patch contains part of Janus' clean-up of vtabs diff.
This came about becau
--- 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 back_insert_
--- 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 #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 #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 #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 #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 rope : public _Rope_base<_CharT, _Alloc>
{
public:
typedef _CharT value_type;
--- 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)
--
c
--- 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
--
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
#include
using namespace std;
int main(int argc, char **argv)
{
--- 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
--- 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 #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 #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=gcc&view=rev&rev=162255
Log:
PR target/44942
* config/i386/i386-protos.h (ix86
--- 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: g
--- 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
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 #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=gcc&view=rev&rev=162254
Log:
2010-07-16 Jack Howarth
PR testsuite/42843
--- 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
---
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 ".deps/an
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Summary|[4.5 Regression] bootstrap |[4.5 Regression] bootstrap
|failed at Comparing sta
--- 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 }
k.0
--- 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 cor
--- 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 #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 #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 thr
90 matches
Mail list logo
