--- Comment #7 from jakub at gcc dot gnu dot org 2009-10-08 07:43 ---
Created an attachment (id=18748)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18748action=view)
pr41176.i
Smaller testcase for 4.4 branch. ICEs with -m64 -O1 -fschedule-insns -fwrapv.
--
--- Comment #5 from burnus at gcc dot gnu dot org 2009-10-08 07:47 ---
Backtrace (of comment 3) using an older GCC 4.5 (20090526):
#0 0x00549453 in gfc_trans_pointer_assignment (expr1=0x12d8ea0,
expr2=0x12d3b80)
at
The following code results in a gimplication error:
type t1
integer :: comp
end type
type(t1), target :: a
class(t1) :: x
pointer :: x
a%comp = 3
x = a
print *,x%comp
end
The problem here is that 'encapsulate_class_symbol' is called too early (i.e.
before the symbol has acquired
--- Comment #16 from ubizjak at gmail dot com 2009-10-08 08:17 ---
Vlad, is it OK if I backport this patch to 4.4? I have tested it on 4.4 without
problems.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22072
--- Comment #6 from dominiq at lps dot ens dot fr 2009-10-08 08:43 ---
The use of common in the context of this PR badly hurts my understanding of
commons: storage arrays computed at compile time. The standard says (f2008):
5.7.2 COMMON statement
5.7.2.1 General
1 The COMMON
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
Severity|normal |enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41628
--- Comment #1 from redi at gcc dot gnu dot org 2009-10-08 09:42 ---
set::insert never invalidates iterators, so that's not a good example.
set::erase invalidates iterators pointing to erased elements, but debug mode
already catches that.
One problem I see with this request is that
--- Comment #2 from redi at gcc dot gnu dot org 2009-10-08 09:43 ---
(In reply to comment #1)
std::setint::iterator i = s.insert(5);
Oops, that should be
std::setint::iterator i = s.insert(5).first;
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41628
--- Comment #3 from hubicka at gcc dot gnu dot org 2009-10-08 10:07 ---
Subject: Bug 41620
Author: hubicka
Date: Thu Oct 8 10:06:52 2009
New Revision: 152556
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=152556
Log:
PR bootstrap/41620
* ipa.c
--- Comment #2 from kenneth dot hoste at elis dot ugent dot be 2009-10-08
10:47 ---
Created an attachment (id=18749)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18749action=view)
Fortran testcase
Turns out the same error message occurs with SPEC CPU2000's 178.galgel, more
--- Comment #42 from steven at gcc dot gnu dot org 2009-10-08 11:06 ---
Add Matz, following comment #40. Micha, maybe you can open a separate bug
report for the issues you mention in your mail
(http://gcc.gnu.org/ml/fortran/2009-08/msg00200.html) and make that new PR
block this
--- Comment #4 from matz at gcc dot gnu dot org 2009-10-08 11:23 ---
We're (slowly) working on this.
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #43 from matz at gcc dot gnu dot org 2009-10-08 11:24 ---
There already is PR31094 about this enhancement.
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from matz at gcc dot gnu dot org 2009-10-08 11:26 ---
See also my mail http://gcc.gnu.org/ml/fortran/2009-08/msg00200.html
about this issue.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31094
--- Comment #6 from danglin at gcc dot gnu dot org 2009-10-08 13:10 ---
Bootstrap also fails on armv5tejl-unknown-linux-gnueabi:
build/gensupport.o:(.data+0x20): undefined reference to `obstack'
--
danglin at gcc dot gnu dot org changed:
What|Removed
--- Comment #7 from dh458 at oakapple dot net 2009-10-08 13:23 ---
Subject: Re: mixing common and modules elicits seg fault
The use of common in the context of this PR badly hurts my understanding of
commons: storage arrays computed at compile time.
For better or worse, the Sun
--- Comment #8 from jakub at gcc dot gnu dot org 2009-10-08 13:33 ---
This is on (set (reg:DF X) (mem:DF ((plus:DI (reg:DI Y) (const_int 3.
When X is still a pseudo, this is considered valid, as lfd accept any offset,
but when RA chooses to assign X to a GPR register, the address
System.
Fedora 11 - Linux 2.6.30.8-64.fc11.x86_64 #1 SMP
gcc-4.4.1, Release: 2.fc11 (Fedora's package)
Problem in short.
definitions:
typedef uint64_t obj[1];
obj x0, x1, X[2];
then the following code doesn't work:
X[0][0] = x0[0];
X[1][0] = x1[0];
while this works:
*X[0] = *x0;
*X[1]
--- Comment #1 from emanuele dot cesena at gmail dot com 2009-10-08 13:50
---
Created an attachment (id=18750)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18750action=view)
source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41630
--- Comment #2 from emanuele dot cesena at gmail dot com 2009-10-08 13:51
---
Created an attachment (id=18751)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18751action=view)
preprocessed file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41630
--- Comment #3 from paolo dot carlini at oracle dot com 2009-10-08 14:16
---
Whatever it is, doesn't happen in mainline.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41630
--- Comment #7 from hubicka at ucw dot cz 2009-10-08 14:18 ---
Subject: Re: [4.5 Regression] GCC does not bootstrap on powerpc64
Hi,
the following patch should fix the problem. I am
bootstrapping/regtesting it at x86_64-linux, but it would be nice to
know if it actually fixes the
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-10-08 14:52 ---
Simplified testcase, fails at -O1. Likely an aliasing issue, but I didn't
yet fully investigate (nor ruled out a non-conforming testcase - though
TBAA is out of the question here):
typedef unsigned long obj[1];
CLASS IS() is correctly parsed but it has been disabled as the actual
implementation is missing. There are two parsing test cases, which can be
re-enabled when the the feature is implemented:
- gcc/testsuite/gfortran.dg/select_type_2.f03
- gcc/testsuite/gfortran.dg/select_type_1.f03
Cf. also
--- Comment #6 from kayhayen at gmx dot de 2009-10-08 15:02 ---
Hello,
is there anything else we can do to help with this bug?
Yours,
Kay Hayen
--
kayhayen at gmx dot de changed:
What|Removed |Added
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-10-08 15:03 ---
What we can see after inlining is
bb 2:
X[0][0] ={v} 12345;
D.1614_1 = (long unsigned int *) X[1];
*D.1614_1 ={v} 67890;
D.1614_2 = (long unsigned int *) X[1];
X.0_3 = (long unsigned int *) X;
D.1623_5
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-10-08 15:07 ---
With 4.3 and 4.4 it is SRA that does not avoid generating wrong code, with
4.5 SRA optimizes the code correctly and recognizes both forms access the
same memory (and thus we optimize the program to return 0).
--
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=41630
--- Comment #7 from charlet at gcc dot gnu dot org 2009-10-08 15:08 ---
Feel free to submit a patch.
Note that middle-end warnings (such as -Wuninitialized) do not always support
properly all front-end semantics, in particular for high level languages such
as Ada, so I'd recommend
--- Comment #40 from howarth at nitro dot med dot uc dot edu 2009-10-08
15:16 ---
Created an attachment (id=18752)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18752action=view)
Fix PR41313 with dual approach
--
howarth at nitro dot med dot uc dot edu changed:
--- Comment #41 from howarth at nitro dot med dot uc dot edu 2009-10-08
15:17 ---
Posted revised patch from Comment 40 to gcc-patches...
http://gcc.gnu.org/ml/gcc-patches/2009-10/msg00519.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41313
--- Comment #7 from doko at ubuntu dot com 2009-10-08 15:17 ---
With binutils from the 2.20 branch, and gcc from the 4.4 branch, including
Jakub's patch, and excluding the current workaround from Ramana, I get:
$ gcc -c main.c
$ objdump --wide -h main.o | grep ALLOC
0 .text
--- Comment #8 from ramana at gcc dot gnu dot org 2009-10-08 15:36 ---
(In reply to comment #7)
With binutils from the 2.20 branch, and gcc from the 4.4 branch, including
Jakub's patch, and excluding the current workaround from Ramana, I get:
IIUC and to make things explicit, the
--- Comment #1 from burnus at gcc dot gnu dot org 2009-10-08 15:39 ---
Created an attachment (id=18753)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18753action=view)
Patch allocate(class) w/o source=/type-spec; plus PR 41581 interim fix
(completely untested)
Patch also changes
--- Comment #4 from matz at gcc dot gnu dot org 2009-10-08 16:03 ---
Subject: Bug 41573
Author: matz
Date: Thu Oct 8 16:03:11 2009
New Revision: 152563
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=152563
Log:
PR middle-end/41573
* builtins.c
--- Comment #4 from jason at gcc dot gnu dot org 2009-10-08 16:09 ---
Subject: Bug 37177
Author: jason
Date: Thu Oct 8 16:09:22 2009
New Revision: 152564
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=152564
Log:
PR c++/37177
* pt.c (resolve_nondeduced_context):
--- Comment #2 from jason at gcc dot gnu dot org 2009-10-08 16:09 ---
Subject: Bug 36816
Author: jason
Date: Thu Oct 8 16:09:31 2009
New Revision: 152565
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=152565
Log:
PR c++/36816
* pt.c
--- Comment #3 from mrs at gcc dot gnu dot org 2009-10-08 16:36 ---
These two look ok to me. The testsuite should be glanced at by Janis to double
check.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41605
--- Comment #4 from mrs at gcc dot gnu dot org 2009-10-08 16:44 ---
Oh, if one wanted to, one could have libgcc_s forward the EH calls into
/usr/lib/libgcc_s.1.dylib by dlopening it and then doing dlsym on the symbols
and calling them. This would `fix' the programs that linked against
--- Comment #8 from manu at gcc dot gnu dot org 2009-10-08 17:39 ---
The output of -fdump-tree-optimized-all-lineno and -fdump-tree-ssa-all-lineno
with and without -fPIC would be interesting. Also, GCC 4.4 and 4.5 fixed a lot
of false positives in Wuninitialized, so please try with at
--- Comment #3 from jason at gcc dot gnu dot org 2009-10-08 17:48 ---
Fixed for 4.5.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from jason at gcc dot gnu dot org 2009-10-08 17:48 ---
Fixed for 4.5.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
--
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
See http://gcc.gnu.org/ml/gcc/2009-10/msg00071.html
--
Summary: The preprocessor incorrectly reports #ident as being
deprecated
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
--
dodji at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dodji at gcc dot gnu dot org
|dot org
--- Comment #9 from espindola at google dot com 2009-10-08 18:20 ---
(In reply to comment #8)
Raphael, can you look into this?
Sure. Sorry about the delay.
The only thing the compiler should need the plugin-api.h for is the enum
ld_plugin_symbol_resolution. If we split
--- Comment #9 from uweigand at gcc dot gnu dot org 2009-10-08 18:39
---
(In reply to comment #8)
This is on (set (reg:DF X) (mem:DF ((plus:DI (reg:DI Y) (const_int 3.
When X is still a pseudo, this is considered valid, as lfd accept any offset,
but when RA chooses to assign X
gcc should warn when the stack frame for a called varargs function
is in excess of a -Wframe-larger-than=NNN bytes. Such a check could
be done at each call site, to see whether the outgoing arguments
alone already exhaust NNN.
--
Summary: -Wframe-larger-than should warn about
--- Comment #8 from meissner at gcc dot gnu dot org 2009-10-08 18:59
---
Created an attachment (id=18754)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18754action=view)
Patch that fixes the powerpc bootstrap problem.
This is the patch that I checked in that came from Jan
--- Comment #9 from meissner at gcc dot gnu dot org 2009-10-08 19:00
---
Patch checked into mainline, subversion id 152569.
--
meissner at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #16 from rwild at gcc dot gnu dot org 2009-10-08 19:06 ---
Created an attachment (id=18755)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18755action=view)
(hopefully) better patch
Gah. Initial white space isn't stripped from the case argument,
I should've known.
Can
--- Comment #17 from aoliva at gcc dot gnu dot org 2009-10-08 19:20 ---
Subject: Bug 41353
Author: aoliva
Date: Thu Oct 8 19:20:22 2009
New Revision: 152573
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=152573
Log:
PR debug/41353
* regmove.c (regmove_backward_pass): Replace src
--- Comment #18 from aoliva at gcc dot gnu dot org 2009-10-08 19:22 ---
All fixed.
--
aoliva at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #17 from davek at gcc dot gnu dot org 2009-10-08 19:37 ---
(In reply to comment #16)
Created an attachment (id=18755)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18755action=view) [edit]
(hopefully) better patch
Gah. Initial white space isn't stripped from the
--- Comment #5 from jbytheway at gmail dot com 2009-10-08 19:40 ---
Ah well. I'm not surprised. If you do wish to argue the point at Santa Cruz
and I can be any help then let me know.
I have no particular intention to contribute; I'm just working through my
backlog of bug reports
--- Comment #6 from paolo dot carlini at oracle dot com 2009-10-08 19:54
---
(In reply to comment #5)
I have no particular intention to contribute;
Too bad, I hope you want to reconsider this decision. In case, however, please
don't attach patches, because we can't and we don't want
--- Comment #18 from rwild at gcc dot gnu dot org 2009-10-08 19:57 ---
Created an attachment (id=18756)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18756action=view)
ditto, but without the d'oh factor
That's what you get when you name one pr-41418 and the other pr41418.
Sorry
--- Comment #1 from janus at gcc dot gnu dot org 2009-10-08 20:27 ---
Mine (have a patch).
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-10-08 21:26 ---
I installed libelf on a i386-darwin machine at /usr/local so I could build a
cross compiler to spu-elf and test LTO on my laptop. And now a native build of
GCC picks up libelf and we get:
checking for the correct
--- Comment #2 from aoliva at gcc dot gnu dot org 2009-10-08 21:34 ---
Yup, ADDR_EXPRs don't count as dereferences in debug stmts, but if the variable
doesn't get a memory location, we end up dropping the whole expression. We
have to. Finding another location holding the value of b
--- Comment #5 from jsm28 at gcc dot gnu dot org 2009-10-08 21:36 ---
Likewise, -Wabi and -Wpsabi belong on common.opt, and the post_options
processing belongs in common code not in individual front ends.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41554
/home/marcus/projects/gcc.trunk/BIN/bin/gcc -m32 -c -O3 -fno-builtin file.i
file.i: In function 'test_readmode':
file.i:4:6: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
--
--- Comment #1 from marcus at jet dot franken dot de 2009-10-08 21:43
---
Created an attachment (id=18757)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18757action=view)
file.i
/home/marcus/projects/gcc.trunk/BIN/bin/gcc -m32 -c -O3 -fno-builtin file.i
--
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-10-08 21:46 ---
#0 0x00cb8976 in htab_remove_elt_with_hash (htab=0x43b0dd20,
element=0xb2e4, hash=2085838349) at
/Users/apinski/src/change/gcc/libiberty/hashtab.c:706
#1 0x00672a4e in remove_local_expressions_from_table () at
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-10-08 21:49 ---
This appeared between revision 152380 and 152576.
The only patch which touched dom during that time was:
+2009-10-05 Richard Guenther rguent...@suse.de
+
+ PR tree-optimization/23821
+ * tree-vrp.c
As noted in my review of the LTO front end,
resolution = fopen (resolution_file_name, r);
gcc_assert (resolution != NULL);
is not an appropriate use of an assertion because the fopen could
fail through system resource exhaustion even if you know the file
exists and is readable and
The macros in lto-elf.c with diagnostics
fatal_error (elf#BITS_getshdr() failed: %s, elf_errmsg (-1));\
fatal_error (elf#BITS_newehdr() failed: %s, elf_errmsg (-1));\
are not i18n-friendly; only the elf bit gets extracted for translation
to gcc.pot.
The code should explicitly say
--- Comment #7 from dougkwan at gcc dot gnu dot org 2009-10-08 22:17
---
Subject: Bug 41574
Author: dougkwan
Date: Thu Oct 8 22:16:58 2009
New Revision: 152580
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=152580
Log:
2009-10-08 Doug Kwan dougk...@google.com
PR
--- Comment #8 from dougkwan at google dot com 2009-10-08 22:20 ---
This is fixed in trunk but at least gcc-4.4.0, where this bug was found, is
still broken.
--
dougkwan at google dot com changed:
What|Removed |Added
--- Comment #2 from nelhage at mit dot edu 2009-10-08 22:20 ---
For an example of real code that wanted to use toplevel inline ASM, see the
following recent Linux commit:
http://git.kernel.org/linus/796216a57fe45c04adc35bda1f0782efec78a713
Lack of this feature necessitated a fairly
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-10-08 22:28 ---
So they want a way to turn off progbits instead?
That seems better than doing extended inline-asm at the top level.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41045
--- Comment #4 from pinskia at gcc dot gnu dot org 2009-10-08 22:32 ---
(In reply to comment #3)
So they want a way to turn off progbits instead?
That seems better than doing extended inline-asm at the top level.
And is less messy really since then the syntax would be something like:
--- Comment #6 from pinskia at gcc dot gnu dot org 2009-10-08 23:06 ---
I ran into this again, this time on powerpc-linux-gnu when I forgot to include
-maltivec on the link line.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41565
--- Comment #7 from pinskia at gcc dot gnu dot org 2009-10-08 23:08 ---
Oh -maltivec is even weirder than -m32 as it does not change the ABI (well it
does but not with respect non vector arguments and such) but I should be able
to compile some files with -maltivec and some without.
Just looking into /tmp after a testsuite runs there are a lot of files there.
cc0FIKlt.errccceY3TE.err
cciZMsdN.o.063t.alias ccqFjO6o.errccy5TZdA.out
cc0hiz3p.wpa.o ccCFYtDM.wpa.o.063t.alias ccj4ba9L.out
lto_get_builtin_tree uses built_in_decls but that is only for the
built_in_class of BUILT_IN_NORMAL. The back-ends have their own array with the
builtins in them for the class of BUILT_IN_MD.
So currently we translate all of the back-end builtins into normal builtins.
This is why
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-10-08 23:48 ---
Note the back-end builtin arrays don't have the same name so it is not as
simple as using that array. I think we need to add either a target hook or
have a standard name for them.
Also the assert there for
77 matches
Mail list logo
