--- Comment #16 from bonzini at gnu dot org 2009-08-08 07:57 ---
Can you try running the testsuite on a non-bootstrapped hppa-hpux compiler?
However, I have an idea and will provide a patch soon.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40952
--- Comment #2 from laurent at guerby dot net 2009-08-08 08:15 ---
I've seen it hang on x86_64-linux with this week trunk.
--
laurent at guerby dot net changed:
What|Removed |Added
---
--- Comment #17 from bonzini at gnu dot org 2009-08-08 08:18 ---
Try squashing this in:
Index: pa/pa.c
===
--- pa/pa.c (revision 150359)
+++ pa/pa.c (working copy)
@@ -9199,7 +9199,7 @@ pa_promote_function_mode (con
--- Comment #3 from laurent at guerby dot net 2009-08-08 08:29 ---
I will try to tweak constants too.
--
laurent at guerby dot net changed:
What|Removed |Added
--- Comment #5 from ktietz at gcc dot gnu dot org 2009-08-08 08:43 ---
(In reply to comment #4)
> -fno-builtin means more or less exactly that the compiler *should not*
> assume anything special about a function from its name (unless the name
> starts __builtin or some similar reserved
--- Comment #2 from steven at gcc dot gnu dot org 2009-08-08 09:07 ---
Why does the basic block reordering pass also not handle this?
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
>From Wine:
/home/marcus/projects/gcc.trunk/BIN/bin/gcc -m32 -c -fno-strict-aliasing -O3
-o mswsock.o mswsock.i
mswsock.i: In function 'get_fn_pointers':
mswsock.i:17:1: error: non-trivial conversion at assignment
int (*LPFN_ACCEPTEX) (void *)
long int (*FARPROC) (void)
# .MEM_6 = VDEF <.MEM_5>
--- Comment #1 from marcus at jet dot franken dot de 2009-08-08 09:41
---
Created an attachment (id=18327)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18327&action=view)
mswsock.i
/home/marcus/projects/gcc.trunk/BIN/bin/gcc -m32 -c -fno-strict-aliasing -O3
-o mswsock.o mswso
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |steven at gcc dot gnu dot
|dot org
// test.c
#include
int main() {
unsigned long long x = 3264;
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-08-08 10:31 ---
The special_function thing is to make us not miss special side-effects of those
functions even when we didn't recognize them as builtins. alloca doesn't have
one apart from the likeliness to blow up the stack if we
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-08-08 10:36 ---
I would suggest to closely look at SSA expansion as well. There is I think
still the regression from pre-SSA expand that it doesn't expand PHI nodes
optimally at -Os (pre-SSA expand split common PHI args into extra
--- Comment #7 from joseph at codesourcery dot com 2009-08-08 10:37 ---
Subject: Re: alloca broken for -fno-builtin
On Sat, 8 Aug 2009, ktietz at gcc dot gnu dot org wrote:
> Well, IMHO it is the same for alloca, as for setjmp, or longjmp. Even some
> code
> for detecting alloca sema
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-08-08 10:38 ---
Shifting by more than the bitsize of the value invokes undefined behavior
(GCC implements shift count truncation for targets that would do this in
hardware which is why you see 5 as result).
--
rguenth at gcc dot
--- Comment #21 from mikulas at artax dot karlin dot mff dot cuni dot cz
2009-08-08 10:41 ---
Hmm, it still generates the stack frame (and the alignment itself) when there
are structures containing long long and with -malign-double.
Example, compile with -O2 -fomit-frame-pointer -mpref
The attached code generates an ICE on valid code with the following command
line parameters:
p...@dogbert> gcc -O1 -ftree-vectorize -c hcmap.cpp
hcmap.cpp: In function void map_do():
hcmap.cpp:5:6: internal compiler error: tree check: expected class
expression, have exceptional (ssa_name) in
--- Comment #1 from p dot vanhoof at oma dot be 2009-08-08 10:46 ---
Created an attachment (id=18328)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18328&action=view)
the code that fails.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41008
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-08-08 10:55 ---
Investigating.
Related testcase, same bug:
typedef int *FARPROC;
static int * __restrict__ acceptex_fn;
int xWSAIoctl(void*);
static void get_fn(FARPROC* fn)
{
FARPROC func;
if (!xWSAIoctl( &func))
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||irar at il dot ibm dot com
Summary|ICE in
--- Comment #22 from hjl dot tools at gmail dot com 2009-08-08 11:45
---
(In reply to comment #21)
> Hmm, it still generates the stack frame (and the alignment itself) when there
> are structures containing long long and with -malign-double.
>
> Example, compile with -O2 -fomit-frame-p
Executing on host: /mnt/gnu/gcc/objdir/gcc/xgcc -B/mnt/gnu/gcc/objdir/gcc/
/mnt/
gnu/gcc/gcc/gcc/testsuite/gcc.c-torture/execute/20070614-1.c -w -O0
-fno-show
-column -lm -o /mnt/gnu/gcc/objdir/gcc/testsuite/gcc/20070614-1.x0
(timeou
t = 300)
PASS: gcc.c-torture/execute/20070614-1.c compil
Executing on host: /mnt/gnu/gcc/objdir/gcc/xgcc -B/mnt/gnu/gcc/objdir/gcc/
/mnt/
gnu/gcc/gcc/gcc/testsuite/gcc.c-torture/execute/complex-5.c -w -O0
-fno-show-
column -lm -o /mnt/gnu/gcc/objdir/gcc/testsuite/gcc/complex-5.x0(timeout
= 300)
PASS: gcc.c-torture/execute/complex-5.c compilati
--- Comment #18 from t dot artem at mailcity dot com 2009-08-08 14:14
---
(In reply to comment #16)
>
> This is not a simple testcase. A simple testcase is a sufficiently small
> self-contained compilable code that shows the problem in a way that can be
> reliably and consistently repr
--- Comment #23 from mikulas at artax dot karlin dot mff dot cuni dot cz
2009-08-08 14:15 ---
(In reply to comment #22)
> It is because -malign-double will align long long to 8 byte.
Yes, it aligns it in the structures ... but why on the stack? Those people who
were writing it really d
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-08-08 15:32 ---
Subject: Bug 40991
Author: rguenth
Date: Sat Aug 8 15:32:36 2009
New Revision: 150580
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150580
Log:
2009-08-08 Richard Guenther
PR tree-optimization/
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-08-08 15:54 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #10 from manu at gcc dot gnu dot org 2009-08-08 16:05 ---
Created an attachment (id=18329)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18329&action=view)
XML diagnostics
A prototype of XML mode for diagnostics. The output looks like:
inicializaci�n de un miembro de
--- Comment #19 from rguenth at gcc dot gnu dot org 2009-08-08 16:21
---
Note that after a GCC version is released fixes for runtime regressions are
usually not considered because of their impact on stability (which is the
most important point). Instead if you care for performance of a
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |janus at gcc dot gnu dot org
|dot org
--- Comment #11 from joseph at codesourcery dot com 2009-08-08 16:33
---
Subject: Re: (Natural) language independent error / warning
classification
On Sat, 8 Aug 2009, manu at gcc dot gnu dot org wrote:
> I am not planning to work on this further. This patch shows that it can be
> d
--- Comment #3 from astrange at ithinksw dot com 2009-08-08 16:44 ---
Maybe the C version will be usable after everyone is using 4.4+, earlier
versions tend to make a mess.
Anyway, counting newlines for size estimation wouldn't pessimize anything.
--
http://gcc.gnu.org/bugzilla/sho
--- Comment #12 from manu at gcc dot gnu dot org 2009-08-08 17:05 ---
(In reply to comment #11)
> XML output), but I think in practice it's only useful if driven by
> cooperation from IDE people who will help establish what the XML should
> look like and commit to making an IDE use the
--- Comment #23 from mikulas at artax dot karlin dot mff dot cuni dot cz
2009-08-08 17:30 ---
(In reply to comment #21)
Unfortunatelly, that patch is wrong. It aligns when there is some vector type
in the function but it doesn't align if the autovectorizer creates SSE
instructions. Try
--- Comment #2 from jv244 at cam dot ac dot uk 2009-08-08 18:01 ---
doesn't compile with trunk?
gcc -DNDEBUG -D_PTHREADS -D_THREAD_SAFE -D_REENTRANT -D_POSIX_SOURCE -O
-Wfatal-errors -g -c t.ii
In file included from /usr/include/c++/4.2/bits/stl_algobase.h:72:0,
from /
--- Comment #4 from laurent at guerby dot net 2009-08-08 20:36 ---
I'm lauching a binary search.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40788
at -O3 -fwhole-file
CALL UVSET(NX,NY,NZ,HVAR,ZET,NP,DZ,DKM,UM,VM,UG,VG,TM,DCDX,
*ITY,ISH,NSMT,F)
CALL DCTDX(NX,NY,NX1,NFILT,C(MLAG),DCDX(MLAG),HELP,HELPA,
* HELP,HELPA,FY,FYC,SAVEY)
END
SUBROUTINE PADEC(DKS,DKDS,HVAR,WM,WG,FN,NS,AN,BN,CN,IT)
COMPLEX*16
--
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=41011
--- Comment #8 from steven at gcc dot gnu dot org 2009-08-08 22:24 ---
This bug is as dead as SCO.
With the difference, of course, that all issues in this meta-bug appear to be
fixed, whereas SCO is still damaged goods :-)
--
steven at gcc dot gnu dot org changed:
What
--- Comment #3 from steven at gcc dot gnu dot org 2009-08-08 22:26 ---
No progress for >6 years. Concerns a very old, no longer supported GCC version.
-> WONTFIX
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #7 from steven at gcc dot gnu dot org 2009-08-08 22:35 ---
I believe this should be closed as WONTFIX. Warnings exist to indicate things
in the program that are almost certainly wrong. In this case, the only way to
really avoid false positives is to look at the context of t
--- Comment #2 from steven at gcc dot gnu dot org 2009-08-08 22:37 ---
Would anyone object if this gets closed as WONTFIX?
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #2 from steven at gcc dot gnu dot org 2009-08-08 22:38 ---
Any news on this one?
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Sta
--- Comment #10 from steven at gcc dot gnu dot org 2009-08-08 22:42 ---
Let's be realistic about this one: It will not be fixed, ever.
-> WONTFIX
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from steven at gcc dot gnu dot org 2009-08-08 22:47 ---
Looks OK in r150579. Fixed somewhere along the road. Going through really old
bug reports can be so rewarding...
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #6 from steven at gcc dot gnu dot org 2009-08-08 22:52 ---
Obviously something experienced by more than one user, on more than one
platform.
Tom, can you make a guess about what is wrong based on the suggested
work-around of comment #5?
--
steven at gcc dot gnu dot org
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfir
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfir
--- Comment #7 from tromey at gcc dot gnu dot org 2009-08-09 00:09 ---
The earlier comments should probably first be investigated by looking
in config.log. (Except the original comment which sounds like a missing
feature in depcomp -- that should go upstream to Automake.)
Comment #5 so
Compiling the following test case with FDO, virtual call base->Foo(id) is
promoted/specialized in valueProf transformation. However the resulting direct
call is not inlined due to type mismatch.
The problem is that the 2nd ARG_TYPE associated with the indirect call is a
record type, but the actua
49 matches
Mail list logo
