--- Comment #2 from schwab at linux-m68k dot org 2010-04-03 09:16 ---
§6.4.4.1 Integer constants:
If an integer constant cannot be represented by any type in its list, it may
have an extended integer type, if the extended integer type can represent its
value. If all of the types in the
--- Comment #22 from developer at sandoe-acoustics dot co dot uk
2010-04-03 11:00 ---
Created an attachment (id=20299)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20299&action=view)
finalize emutls control vars before varpool_assemble_ending_decls()
This provides a traverse of
/usr/lib/gcc/s390-suse-linux/4.5/cc1 -fpreprocessed sqlite3.i -quiet -dumpbase
sqlite3.c -march=z900 -mtune=z9-109 -m31 -mesa -auxbase-strip .libs/sqlite3.o
-g -O2 -Wall -version -fmessage-length=0 -fstack-protector -funwind-tables
-fasynchronous-unwind-tables -fPIC -o sqlite3.s
sqlite3.c: In funct
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-04-03 14:07 ---
Created an attachment (id=20300)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20300&action=view)
preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43635
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||krebbel at gcc dot gnu dot
|
/usr/lib/gcc/s390-suse-linux/4.5/cc1 -fpreprocessed gengtype-yacc.i -quiet
-dumpbase gengtype-yacc.c -march=z900 -mtune=z9-109 -m31 -mesa -auxbase-strip
gengtype-yacc.o -g -W -Wall -Wwrite-strings -Wstrict-prototypes
-Wmissing-prototypes -pedantic -Wno-long-long -version -o gengtype-yacc.s
GNU C (S
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-04-03 14:12 ---
Created an attachment (id=20301)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20301&action=view)
preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43636
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43636
I have here a testcase where -fstrict-aliasing seems to miscompiles the code.
$ gcc-4.4 tc.c -o tc && ./tc
$ gcc-4.4 tc.c -o tc -O1 && ./tc
$ gcc-4.4 tc.c -o tc -O1 -fstrict-aliasing && ./tc
Segmentation fault
$ gcc-4.4 tc.c -o tc -O1 -fstrict-aliasing -DOK && ./tc
0xaf8bea20
This also happens wi
--- Comment #1 from jengelh at medozas dot de 2010-04-03 15:13 ---
Created an attachment (id=20302)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20302&action=view)
testcase
Hopefully short enough to be a testcase. Left unprocessed to not prematurely
clutter it.
--
http://gcc
--- Comment #10 from tschwinge at gcc dot gnu dot org 2010-04-03 15:18
---
Confirmed.
--
tschwinge at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-04-03 15:39 ---
You are accessing {lh,clh}.{next,prev} through a pointer to type
struct item.
Testcase can be fixed with givin clh and lh type struct item.
--
rguenth at gcc dot gnu dot org changed:
What|Removed
--- Comment #3 from howarth at nitro dot med dot uc dot edu 2010-04-03
16:32 ---
Created an attachment (id=20303)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20303&action=view)
objc.log with exact failing objc.dg-struct-layout-encoding-1 tests listed
This is from r157950...
T
--- Comment #4 from howarth at nitro dot med dot uc dot edu 2010-04-03
16:34 ---
These failures...
FAIL: objc.dg-struct-layout-encoding-1/t001_main.m execution test
FAIL: objc.dg-struct-layout-encoding-1/t005_main.m execution test
FAIL: objc.dg-struct-layout-encoding-1/t009_main.m exec
--- Comment #3 from dfranke at gcc dot gnu dot org 2010-04-03 16:36 ---
No reply in three months. Closing.
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from howarth at nitro dot med dot uc dot edu 2010-04-03
16:37 ---
powerpc64-unknown-linux-gnu doesn't exhibit this problem at either -m32 or
-m64...
http://gcc.gnu.org/ml/gcc-testresults/2010-04/msg00232.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25359
--- Comment #6 from developer at sandoe-acoustics dot co dot uk 2010-04-03
16:40 ---
(In reply to comment #4)
> These failures...
> FAIL: objc.dg-struct-layout-encoding-1/t024_main.m execution test
>
> still exist in current gcc trunk on powerpc-apple-darwin9.
these discrepancies in
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-04-03 17:11 ---
Looking at the testcase the issue is obvious. We have marked the
instantiations as extern, and indeed the cgraph code dealing with
-fkeep-inline-functions honors this and does not preserve extern
inline bodies while
--- Comment #26 from rguenth at gcc dot gnu dot org 2010-04-03 17:14
---
The bootstrap issue is fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #27 from rguenth at gcc dot gnu dot org 2010-04-03 17:15
---
Subject: Bug 42509
Author: rguenth
Date: Sat Apr 3 17:14:44 2010
New Revision: 157954
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157954
Log:
2010-04-03 Richard Guenther
PR middle-end/42509
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43572
--- Comment #9 from vz-gcc at zeitlins dot org 2010-04-03 17:15 ---
Just to bring some more hard numbers into this discussion, I've installed both
4.4 and 4.5 (in addition to 3.4.5 which I'll use as a kind of baseline) on my
own machine (4/8 physical/logical CPUs, 8GB of RAM, Windows 7 6
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-04-03 17:16 ---
Patch looks a bit big for 4.5.0.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43621
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43627
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43630
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43632
--- Comment #10 from pinskia at gcc dot gnu dot org 2010-04-03 17:25
---
>And while the compilation time change alone
How did you configure 4.5? Did you use --enable-checking=release ? If not
then the compile time numbers are not comparable at all.
--
http://gcc.gnu.org/bugzilla
--- Comment #5 from siarhei dot siamashka at gmail dot com 2010-04-03
17:39 ---
Got exactly the same ICE on ARM, bootstrapping gcc:
/var/tmp/portage/sys-devel/gcc-4.5.0_alpha20100401/work/gcc-4.5-20100401/gcc/sched-deps.c:
In function get_dep_weak_1:
/var/tmp/portage/sys-devel/gcc-4.
--- Comment #11 from vz-gcc at zeitlins dot org 2010-04-03 17:46 ---
(In reply to comment #10)
> >And while the compilation time change alone
>
> How did you configure 4.5? Did you use --enable-checking=release ? If not
> then the compile time numbers are not comparable at all.
Ok, m
--- Comment #7 from mrs at gcc dot gnu dot org 2010-04-03 18:06 ---
The Apple gcc-4.2 tree had a few fixes that improved these tests as I recall.
I think if we pull the code from darwin_rs6000_special_round_type_align it will
fix this.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- Comment #8 from pinskia at gcc dot gnu dot org 2010-04-03 18:15 ---
This is just a library side issue. I have a fix on a branch which rewrites the
library not to use the back-end header files. But I have not had time to work
on it recently.
--
http://gcc.gnu.org/bugzilla/show_
--- Comment #12 from vz-gcc at zeitlins dot org 2010-04-03 18:17 ---
Actually I don't think --enable-checking=release changes anything. I've just
tried Cesar Strauss's suggestion to not use __attribute__((dllexport)) in the
code at all but use --enable-auto-import linker option. And mira
--- Comment #50 from tg at mirbsd dot org 2010-04-03 18:18 ---
For the archives: I have a backport of this for gcc 3.4.6 (actually, two
commits 100490D02CD2CE90D8F and 10049E3533B275F48CB in MirBSD) because it
affects being unable to build LLVM, too. Mail me if interested.
--
http:/
--- Comment #7 from rguenth at gcc dot gnu dot org 2010-04-03 18:40 ---
But g++.dg/opt/inline8.C then fails. Why's foo DECL_EXTERNAL?
>
QI
size
unit size
align 8 symtab 0 alias set -1 canonical type 0xb77428a0
arg-types >>
nothrow public s
--- Comment #9 from mikpe at it dot uu dot se 2010-04-03 19:38 ---
For 4.4 the test cases (both the original struct-using one and the later
integer-only one) are fixed by backporting r145184 (PR38180 fix) and then
r157944. Either of them alone fixes neither test case. Bootstrapped and
--- Comment #10 from rguenth at gcc dot gnu dot org 2010-04-03 19:53
---
(In reply to comment #9)
> For 4.4 the test cases (both the original struct-using one and the later
> integer-only one) are fixed by backporting r145184 (PR38180 fix) and then
> r157944. Either of them alone fixes
--- Comment #8 from paolo dot carlini at oracle dot com 2010-04-03 20:01
---
That @n is definitely a pasto: there is no n among the parameters. And the
semantics definitely boils down to taking the whole C string. Understand that
often the documentation is not written by the same people
--- Comment #23 from dominiq at lps dot ens dot fr 2010-04-03 20:03 ---
The patch in comment #22 works as advertised without new regression (see
http://gcc.gnu.org/ml/gcc-testresults/2010-04/msg00243.html).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43553
--- Comment #8 from rguenth at gcc dot gnu dot org 2010-04-03 20:12 ---
Both work with
Index: gcc/cp/semantics.c
===
--- gcc/cp/semantics.c (revision 157953)
+++ gcc/cp/semantics.c (working copy)
@@ -3449,7 +3449,9 @@ exp
--- Comment #9 from rguenth at gcc dot gnu dot org 2010-04-03 20:14 ---
(In reply to comment #8)
> That @n is definitely a pasto: there is no n among the parameters. And the
> semantics definitely boils down to taking the whole C string. Understand that
> often the documentation is not w
--- Comment #10 from paolo dot carlini at oracle dot com 2010-04-03 20:19
---
Thanks Richard for reminding me. I'll do it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43634
--- Comment #9 from hubicka at ucw dot cz 2010-04-03 20:52 ---
Subject: Re: [4.5 Regression] ICE: SIGSEGV
with -fipa-cp-clone -fkeep-inline-functions
> The patch probably only papers over the problem. Honza, can you have a look
> here?
Hi,
I am away for Easter till Monday, but
--- Comment #10 from jason at gcc dot gnu dot org 2010-04-03 21:02 ---
If we're going to mess with that code at all, I'd prefer your initial patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43611
--- Comment #23 from hubicka at ucw dot cz 2010-04-03 21:02 ---
Subject: Re: [4.5 regression] 0.5% code size
regression caused by r147852
> 1) overall_size is reduced twice for the same function, once in
>cgraph_clone_inlined_nodes, once in cgraph_mark_inline_edge (which ca
--- Comment #11 from rguenther at suse dot de 2010-04-03 21:10 ---
Subject: Re: [4.5 Regression] ICE: SIGSEGV with
-fipa-cp-clone -fkeep-inline-functions
On Sat, 3 Apr 2010, jason at gcc dot gnu dot org wrote:
> --- Comment #10 from jason at gcc dot gnu dot org 2010-04-03 21:02
--- Comment #12 from jason at redhat dot com 2010-04-03 21:12 ---
Subject: Re: [4.5 Regression] ICE: SIGSEGV with
-fipa-cp-clone -fkeep-inline-functions
On 04/03/2010 05:10 PM, rguenther at suse dot de wrote:
> But the initial patch also regresses g++.dg/opt/inline8.C, as for
> the in
--- Comment #24 from rguenther at suse dot de 2010-04-03 21:13 ---
Subject: Re: [4.5 regression] 0.5% code size
regression caused by r147852
On Sat, 3 Apr 2010, hubicka at ucw dot cz wrote:
> --- Comment #23 from hubicka at ucw dot cz 2010-04-03 21:02 ---
> Subject: Re: [4.
--- Comment #25 from hubicka at ucw dot cz 2010-04-03 21:19 ---
Subject: Re: [4.5 regression] 0.5% code size
regression caused by r147852
> But the the code as-is allows unlimited growth of a function (well,
> by PARAM_LARGE_FUNCTION_GROWTH for each inlining; the limit is
> bas
--- Comment #26 from hubicka at ucw dot cz 2010-04-03 21:20 ---
Subject: Re: [4.5 regression] 0.5% code size
regression caused by r147852
As for history, I oriignally had only the perentage limits at place, but then
found that they behave really erratically on small units and s
--- Comment #27 from hubicka at ucw dot cz 2010-04-03 21:39 ---
Subject: Re: [4.5 regression] 0.5% code size
regression caused by r147852
And after checking the code, I think it is correct. I.e. limit is computed on
size before inlining of caller or callee (this is to allow lar
--- Comment #6 from siarhei dot siamashka at gmail dot com 2010-04-03
21:53 ---
(In reply to comment #5)
> But preprocessed source feeded to gcc-4.5-20100401 crosscompiler does not
> result in ICE. I'm going to try bootstrapping again with the patch from
> PR42509
> and report back.
T
--- Comment #1 from wilson at gcc dot gnu dot org 2010-04-04 01:34 ---
This is failing due to invalid rtl unsharing. The asm has two dests. We end
up with a parallel with two sets, and the ASM_OPERAND_INPUT_VEC in each SET_SRC
is supposed to be the same rtl pointer. This is checked by
--- Comment #6 from kevin at koconnor dot net 2010-04-04 03:50 ---
I've confirmed this fix (r157942) works (both for the test case and for the
underlying program - SeaBIOS). SeaBIOS ( http://seabios.org/ ) does run into
pr39959, but using --enable-checking=release gets around that probl
This (slightly nonsensical) reduced test case crashes with an internal compiler
error:
void foo(void)
{
int x;
asm volatile("mov $0,%e0\n" :"=r" (x));
}
$ gcc-4.5 tgcc.c -c -o tgcc.o
tgcc.c: In function 'foo':
tgcc.c:6:1: internal compiler error: in reverse_condition, at jump.c:4
gcc 4.4 compiles the following:
_Complex long double foo(long double p1, long double p2)
{
return p1 + (__extension__ 1.0iF) * p2;
}
gcc-4.4 -O3 tgcc.c -c -o tgcc.o
into
0x <+0>: fldt 0x8(%rsp)
0x0004 <+4>: fldt 0x18(%rsp)
0x0
Sent from my iPhone
On Apr 3, 2010, at 11:21 PM, "svfuerst at gmail dot com" > wrote:
gcc 4.4 compiles the following:
_Complex long double foo(long double p1, long double p2)
{
return p1 + (__extension__ 1.0iF) * p2;
}
gcc-4.4 -O3 tgcc.c -c -o tgcc.o
into
0x <+0>
--- Comment #1 from pinskia at gmail dot com 2010-04-04 06:28 ---
Subject: Re: New: Missed optimization with complex long double
Sent from my iPhone
On Apr 3, 2010, at 11:21 PM, "svfuerst at gmail dot com"
wrote:
> gcc 4.4 compiles the following:
>
> _Complex long double foo(long
struct u1
{
float x;
float y;
};
float foo(struct u1 u)
{
return u.x + u.y;
}
compiles into
gcc-4.5 -O3 tgcc.c -c -o tgcc.o
0x <+0>: movq %xmm0,-0x20(%rsp)
0x0006 <+6>: mov-0x20(%rsp),%rax
0x000b <+11>:mov
59 matches
Mail list logo
