--- Comment #2 from pinskia at gcc dot gnu dot org 2009-12-20 05:11 ---
can you attach the preprocessed sources that were used to create the .o's?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-12-20 03:41 ---
So we have:
extern wint_t __btowc_alias (int __c) __asm ("btowc");
extern __inline wint_t
__attribute__ ((__nothrow__)) btowc (int __c)
{ return (__builtin_constant_p (__c) && __c >= '\0' && __c <= '\x7f'
? (wint_
--- Comment #1 from andi-gcc at firstfloor dot org 2009-12-20 02:26 ---
Created an attachment (id=19353)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19353&action=view)
object files for lto
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42441
a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
lto-wrapper: /usr/local/bin/gcc45 returned 1 exit status
collect2: lto-wrapper returned 1 exit status
Seems error itself is broken?
gcc version 4.5.0 20091219 (ex
--- Comment #5 from paolo dot carlini at oracle dot com 2009-12-20 01:33
---
Maybe I should not have set the milestone ;) Seriously, normally I have no idea
if somebody wants to backport the fix, and simply unassign myself... up to you.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?i
--- Comment #2 from joseph at codesourcery dot com 2009-12-20 01:16 ---
Subject: Re: New: Linux kernel BUILD_BUG_ON() broke
This is a different sort of not-an-integer-constant-expression from the
previous cases the kernel was found to use with invalid unevaluated
operands (I asked i
--- Comment #19 from matz at gcc dot gnu dot org 2009-12-20 01:16 ---
Subject: Bug 42027
Author: matz
Date: Sun Dec 20 01:15:46 2009
New Revision: 155367
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155367
Log:
PR tree-optimization/42027
* cfgexpand.c (expand_g
--- Comment #1 from andi-gcc at firstfloor dot org 2009-12-20 00:54 ---
Created an attachment (id=19352)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19352&action=view)
preprocessed file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42439
The linux kernel uses a special macro BUILD_BUG_ON() that uses
some tricks using bitfields to evaluate constant expressions at compile time
and error out if they are violated.
One of the BUILD_BUG_ON()s in a recent kernel now fail with gcc 4.5 snapshot
(gcc version 4.5.0 20091219 (experimental
--- Comment #15 from js-gcc at webkeks dot org 2009-12-20 00:31 ---
After looking some more at the code, I might have an idea what's causing the
issue:
__objc_gnu_init calls __objc_exec_class on _OBJC_MODULES. Is it possible that
this call is not made for some reason if you link your lib
--- Comment #4 from dodji at gcc dot gnu dot org 2009-12-19 23:02 ---
Shouldn't this bug be closed as it has been fixed in trunk for 4.5 and the
target milestone is set to 4.5.0 ?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42058
--- Comment #19 from dodji at gcc dot gnu dot org 2009-12-19 22:43 ---
This should now be fixed in trunk for 4.5
--
dodji at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #18 from dodji at gcc dot gnu dot org 2009-12-19 22:40 ---
Subject: Bug 42225
Author: dodji
Date: Sat Dec 19 22:40:37 2009
New Revision: 155363
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155363
Log:
Fix PR c++/42225, take 2
gcc/cp/ChangeLog:
PR c++/42225
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-12-19 21:28 ---
You need the may_alias attribute on int64_t, not on v4si.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #45 from rguenth at gcc dot gnu dot org 2009-12-19 21:10
---
(In reply to comment #41)
> Indeed. The PRE issue could be fixed by fixing PR38819 not in the way it is
> done now but "properly" detect the invalid situations during ANTIC computation
> and simply never mark trap
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-12-19 21:09 ---
Mine.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-12-19 21:09 ---
Created an attachment (id=19351)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19351&action=view)
unoptimized prototype
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42438
See PR42108. Basically we still can PRE a possibly trapping division in
if (b)
tmp = a/b;
tmp = a/b;
because there is no invisible exit along the paths to the insertion point.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42108#c41
hints at what we should instead do.
--
Sum
Very simple source, but total mess in generated code !
Or, am I doing something wrong ?
Source a.c:
typedef int v4si __attribute__((__vector_size__(16), __may_alias__));
typedef long long int64_t;
int64_t xor128fold (v4si s) {
int64_t *p = (int64_t*)&s;
return p[0] ^ p[1];
}
-
--- Comment #15 from paolo dot carlini at oracle dot com 2009-12-19 20:29
---
Good ;)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42352
--- Comment #2 from janus at gcc dot gnu dot org 2009-12-19 20:27 ---
(In reply to comment #1)
> The following program is also rejected, unless the marked line is
> removed/comment out. At a glance, it looks OK - and ifort, NAG f95 and g95
> accept it. The error message is:
>
>
>pr
--- Comment #17 from kargl at gcc dot gnu dot org 2009-12-19 19:45 ---
Closing as won't fix. Currently, gfortran produces nan + i nan for
finite-complex / 0 or finite-complex / (0,0) with its FE constanting
folding and when the middle-end generates code. The Fortran standard
does not p
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-12-19 19:42 ---
I'll take care of this during 4.6 development.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #44 from rguenth at gcc dot gnu dot org 2009-12-19 19:41
---
PR42436 now tracks the possible VRP and middle-end improvement. Only the
PRE fixing possibility would count as a regression fix IMHO.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42108
In PR42108 a division is found to be non-trapping by VRP but neither PRE nor
LIM can make use of that information (well, because VRP doesn't mark the
divisions in any meaningful way).
--
Summary: VRP should mark non-trapping integer divisions
Product: gcc
Version
--- Comment #43 from rguenth at gcc dot gnu dot org 2009-12-19 19:29
---
Btw, with the patch from comment #33 LIM will now hoist the division
properly and the performance regression would be fixed(?). The patch
will though likely cause verification issues with -fnon-call-exceptions
for
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-12-19 19:06 ---
Re-open. Not fixed on the trunk.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from rguenth at gcc dot gnu dot org 2009-12-19 19:05 ---
Re-open. It's still broken on the trunk.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #7 from rguenth at gcc dot gnu dot org 2009-12-19 19:05 ---
*** Bug 42435 has been marked as a duplicate of this bug. ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-12-19 19:05 ---
Huh, it only fails from the testsuite harness, not when executing outside of
that environment?! When I decrease the outside stack size limit it no longer
fails in either case (decrease from 8MB to 1MB).
Valgrind sh
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-12-19 18:56 ---
I didn't see it with multilib testing on x86_64 either. Trying native i?86.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42435
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Summary|[4.5 regression]|[4.5 Regression]
|gfortran.dg/graphite/pr42285|gfor
On Linux/ia32, revision 155361 gave
Executing on host:
/export/gnu/import/svn/gcc-test/bld/gcc/testsuite/gfortran/../../gfortran
-B/export/gnu/import/svn/gcc-test/bld/gcc/testsuite/gfortran/../../
/export/gnu/import/svn/gcc-test/src-trunk/gcc/testsuite/gfortran.dg/graphite/pr42285.f90
-O -O2 -f
--- Comment #4 from jakub at gcc dot gnu dot org 2009-12-19 18:40 ---
After sched1 we have:
(insn 6094 6056 6069 83 u4.c:511 (set (reg:QI 5621)
(mem/s/u/j:QI (plus:SI (reg/f:SI 5441)
(reg:SI 5619)) [0 q1 S1 A8])) 73 {*movqi} (expr_list:REG_DEAD
(reg:SI 5619)
--- Comment #1 from pault at gcc dot gnu dot org 2009-12-19 18:02 ---
Goran,
What you say is manifestly so. However, as a native English speaker I have no
need of translation. Have CC'd Tobias in the hope that it is as irritating to
a German as a Swede :-)
Thanks for the report.
Con
--- Comment #1 from pault at gcc dot gnu dot org 2009-12-19 17:58 ---
This is going to be big trouble to fix.
I do not know how we can easily distinguish between two symbols with the same
name and different flavours.
Maybe derived types should not be in the symtree but in one of their
--- Comment #4 from jason at gcc dot gnu dot org 2009-12-19 16:37 ---
Fixed for 4.5.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIG
--- Comment #3 from jakub at gcc dot gnu dot org 2009-12-19 16:06 ---
Created an attachment (id=19350)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19350&action=view)
2fish.c
Updated testcase with lots of asm scheduling barriers inserted, still failing
(and with no- added to opti
--- Comment #18 from armand dot potter at free dot fr 2009-12-19 15:44
---
Configure is as follow:
/tmp/gcc-4.4.2/configure --enable-shared --enable-clocale=gnu
--enable-__cxa_atexit --libexecdir=/usr/lib --enable-threads=posix
--enable-languages=c,c++ --build=i686-pc-linux-gnu --host=
--- Comment #14 from rwgk at yahoo dot com 2009-12-19 15:09 ---
(In reply to comment #13)
> That said, this specific issue has been moved yesterday to [Tentatively Ready]
> and it's safe enough to simply re-add for now the C++03 set of overloads (we
> don't implement yet the C++0x alloca
--- Comment #8 from dvilleneuve at kronos dot com 2009-12-19 14:41 ---
(In reply to comment #7)
> *** Bug 42432 has been marked as a duplicate of this bug. ***
>
Sorry for the duplicate. Seems I did not search enough...
The resolution I've found for DR 257 is that there are no defect
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-12-19 12:15 ---
We free too many DECL and TYPE contexts which confuses dwarf2out.c. Now in the
end the contexts shouldn't drag in too many extra trees though
1) we'd need support for streaming NAMESPACE_DECLs
2) we should be able
--- Comment #8 from rguenth at gcc dot gnu dot org 2009-12-19 11:41 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #7 from rguenth at gcc dot gnu dot org 2009-12-19 11:41 ---
Subject: Bug 42401
Author: rguenth
Date: Sat Dec 19 11:41:14 2009
New Revision: 155361
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155361
Log:
2009-12-19 Richard Guenther
PR lto/42401
--- Comment #14 from dfranke at gcc dot gnu dot org 2009-12-19 11:38
---
(In reply to comment #7)
> Support for this type of format has now been added to xgettext. The support
> will be contained in gettext 0.18.
I got as far as recreating the .pot for testing. Tried to compile the upd
--- Comment #42 from rguenth at gcc dot gnu dot org 2009-12-19 11:25
---
Subject: Bug 42108
Author: rguenth
Date: Sat Dec 19 11:24:49 2009
New Revision: 155360
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155360
Log:
2009-12-19 Richard Guenther
PR tree-optimizatio
--- Comment #6 from jb at gcc dot gnu dot org 2009-12-19 11:03 ---
(In reply to comment #5)
> (In reply to comment #4)
> > (In reply to comment #3)
>
> Gentlemen,
>
> What is the word on this? A WONTFIX?
Certainly this should be fixed, eventually. Whether it will be fixed for 4.5 or
s
--- Comment #2 from congruwer at yahoo dot co dot uk 2009-12-19 10:57
---
(In reply to comment #1)
> First can you try a newer GCC since 3.4.x is no longer supported.
I do apologize - the updater never notified me so I just assumed I was using
the latest stable release. I have updated a
The gfortran documentation should advise the user about the clock resolutions
she/he might expect when calling the various clock intrinsics DATE_AND_TIME,
SYSTEM_CLOCK, and CPU_TIME.
--
Summary: Documentation should provide advise about clock
resolutions
--- Comment #12 from jb at gcc dot gnu dot org 2009-12-19 10:50 ---
Since the actual implementation of system_clock has no use for non-integer
count rates, this should be implemented by creating an integer temporary in the
frontend and then calling the existing functions.
Also, note tha
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-12-19 09:30 ---
First can you try a newer GCC since 3.4.x is no longer supported. 4.3.4 is the
latest release.
Second sicne this is a modified version of GCC, you should report the bug to
the place where you got the binary/
--
The bug occurs when I compile the following code:
===
__attribute__((stdcall)) int (*P)(int A, int B, int C) = 0;
__attribute__((stdcall)) int X(int A, int B, int C)
{
if(A) return P(A, B, C);
return P(42, B, C);
}
===
52 matches
Mail list logo
