The current trunk does require flex.
The build dies pretty quickly unless flex is available.
Was the flex dependency recently reintroduced? It used to be that if
you update trunk with contrib/gcc_update (instead of svn up), it sets
the modifcation time of generated files so that flex
On Sun, 2010-05-23 at 05:11 +0100, Martin Guy wrote:
On 5/11/10, Mark Mitchell m...@codesourcery.com wrote:
Richard Earnshaw wrote:
Speaking of which, we should probably formally deprecate the old arm-elf
derived targets in 4.6 so that we can remove them in 4.7.
Similarly, we
On Sun, 2010-05-23 at 23:15 +0200, Steven Bosscher wrote:
On Sun, May 23, 2010 at 10:27 PM, Mark Mitchell m...@codesourcery.com wrote:
Martin Guy wrote:
Dropping FPA support from GCC effectively makes the OABI unusable, and
often we are forced to use that by the environment supplied to
On 5/24/10, Richard Earnshaw rearn...@arm.com wrote:
On Sun, 2010-05-23 at 23:15 +0200, Steven Bosscher wrote:
On Sun, May 23, 2010 at 10:27 PM, Mark Mitchell m...@codesourcery.com
wrote:
Martin Guy wrote:
Dropping FPA support from GCC effectively makes the OABI unusable, and
often we
On Mon, 2010-05-24 at 12:42 +0200, Steven Bosscher wrote:
On 5/24/10, Richard Earnshaw rearn...@arm.com wrote:
On Sun, 2010-05-23 at 23:15 +0200, Steven Bosscher wrote:
On Sun, May 23, 2010 at 10:27 PM, Mark Mitchell m...@codesourcery.com
wrote:
Martin Guy wrote:
Dropping FPA
2010/5/24 FX fxcoud...@gmail.com:
Dear gfortranners,
For some work-related issue, I find the need to switch my code regularly
between double precision real arithmetics and quad-float. I currently do that
with a proprietary compiler whose brand name matches the regexp
^In{1,}[t]\x65l$, but
The release of GNU MPFR 3.0.0 (boudin aux pommes) is imminent.
Please help to make this major release as good as possible by
downloading and testing this release candidate:
http://www.mpfr.org/mpfr-3.0.0/mpfr-3.0.0-rc1.tar.xz
http://www.mpfr.org/mpfr-3.0.0/mpfr-3.0.0-rc1.tar.bz2
(I've CC:ed the listed GCC maintainers for various OS ports whose ARM
configurations in GCC do not appear to be using EABI, as well as Pedro for
WinCE, given the discussions of deprecation.) Deprecations are generally
a matter for the relevant maintainers, which in this case means target
On Mon, 24 May 2010, Steven Bosscher wrote:
The vax back-end only affects VAX; likewise for the PDP11 port.
...all this legacy just gets in the way of gcc as a whole. So I still
don't see the difference.
Nb, I don't oppose deprecating any arm stuff, but I just would like to
know if the
On 05/24/2010 06:33 AM, Joseph S. Myers wrote:
(I've CC:ed the listed GCC maintainers for various OS ports whose ARM
configurations in GCC do not appear to be using EABI, as well as Pedro for
WinCE, given the discussions of deprecation.) Deprecations are generally
a matter for the relevant
On Mon, May 24, 2010 at 4:52 AM, Steve Kargl
s...@troutmask.apl.washington.edu wrote:
Kai,
I tested your patch posted here:
http://gcc.gnu.org/ml/gcc/2010-05/msg00445.html
to address the issue
% cat x.c
int main() { }
% gccvs -flto x.c
% gccvs -fwhopr x.c
lto1: fatal error:
On Mon, May 24, 2010 at 1:50 AM, FX fxcoud...@gmail.com wrote:
The current trunk does require flex.
The build dies pretty quickly unless flex is available.
Was the flex dependency recently reintroduced? It used to be that if you
update trunk with contrib/gcc_update (instead of svn up), it
Hello all,
I found something a little odd with delay slot scheduling. If i had the
following bit of code (Note that get builtin functions in picochip
stand for port communication)
int mytest ()
{
int a[5];
int i;
for (i = 0; i 5; i++)
{
a[i] = (int) getctrlIn();
}
switch (a[3])
{
On Mon, 24 May 2010, Joel Sherrill wrote:
The question we would like answered is what impact this
has on our code base. What changes will we have to
make to accomodate this? Register usage changes, stack
frame changes, etc.
For ARM Linux, one change was dealing with __arm__ conditionals in
On Mon, 2010-05-24 at 11:33 +, Joseph S. Myers wrote:
(I've CC:ed the listed GCC maintainers for various OS ports whose ARM
configurations in GCC do not appear to be using EABI, as well as Pedro for
WinCE, given the discussions of deprecation.) Deprecations are generally
a matter for
On Mon, 2010-05-24 at 06:40 -0500, Joel Sherrill wrote:
The question we would like answered is what impact this
has on our code base. What changes will we have to
make to accomodate this? Register usage changes, stack
frame changes, etc.
By far the biggest change is to the layout of 64-bit
What's different is that there is a well-maintained arm-eabi port. The
arm-elf port and all its legacy just gets in the way.
The vax back-end only affects VAX; likewise for the PDP11 port.
I think that's a critical distinction. I can't see removing a port
just because it's not used much
Richard Earnshaw wrote:
Don't know. Does a document specifying it even exist? If we are
supporting an ABI, then I think we need to have a publicly available
SPEC.
I disagree with that statement. If a system is sufficiently popular, we
probably want to support it -- with or without a
On 05/24/10 05:46, Hariharan wrote:
Hello all,
I found something a little odd with delay slot scheduling. If i had
the following bit of code (Note that get builtin functions in
picochip stand for port communication)
int mytest ()
{
int a[5];
int i;
for (i = 0; i 5; i++)
{
a[i] =
On Mon, May 24, 2010 at 08:14:13AM -0600, Jeff Law wrote:
From a correctness standpoint, the uninitialized value will never be
used, so it should cause no ill effects on your code. The biggest
effect would be tools like valgrind purify (if supported on your
architecture) would report
int mytest ()
{
int a[5];
int i;
for (i = 0; i 5; i++)
{
a[i] = (int) getctrlIn();
}
switch (a[3])
{
case 0:
return 4;
default:
return 13;
}
}
The relevant bit of assembly for this compiled at -Os is
_L2:
GET 0,R[5:4]//
Jeff Law wrote:
On 05/24/10 05:46, Hariharan wrote:
Hello all,
I found something a little odd with delay slot scheduling. If i had
the following bit of code (Note that get builtin functions in
picochip stand for port communication)
int mytest ()
{
int a[5];
int i;
for (i = 0; i 5;
Joseph S. Myers wrote:
All in all, perhaps not the most efficient representation for memory
foot print, and the pointer chasing probably doesn't help (cache!).
But changing it is a lot more difficult than the GIMPLE tuples
project. I don't think it can be done.
I don't see any reason
I've got a local port of GCC 4.5.0 to an in-house CPU.
I'm trying to remove *all* single-letter constraints from my cpu.md file and
replace them with define_constraint entries that define *multi-letter*
constraint names. Example: (define_constraint aFOO ...)
But I've found that when I remove
On Mon, 24 May 2010, FX wrote:
1. assume that the user has compiled compile separately a quad-prec
math library (says libmathq; possible relying on MPFR, as the
implementation I propose) and arrange specs so that an option triggers
linking to it
2. assume that the user has an MPFR
Dear Sir/Madam,
We have raised a new GCC mirror at http://gcc.parentinginformed.com.
The mirror is located in Canada and I am the contact point for it.
Thank you.
Best wishes,
James Miller
Jeff Kuskin jk500...@yahoo.com writes:
I'm trying to remove *all* single-letter constraints from my cpu.md
file and replace them with define_constraint entries that define
*multi-letter* constraint names. Example: (define_constraint aFOO
...)
Am I *required* to define at least some of the
On Mon, 24 May 2010, James Miller wrote:
We have raised a new GCC mirror at http://gcc.parentinginformed.com.
The mirror is located in Canada and I am the contact point for it.
Thanks for setting up a mirror and letting us now. I just added this
to our mirrors list at
On Mon, May 24, 2010 at 6:20 PM, Mark Mitchell m...@codesourcery.com wrote:
Joseph S. Myers wrote:
All in all, perhaps not the most efficient representation for memory
foot print, and the pointer chasing probably doesn't help (cache!).
But changing it is a lot more difficult than the GIMPLE
On Sun, 23 May 2010, Kai Wang wrote:
Based on this, it will be great if you can apply your patch to
-CURRENT, 8-STABLE and 7-STABLE.
I'll see what I can do.
Thanks!
The elf_update() failure is caused by an alignment check inside
FreeBSD elf_update(). [...]
Anyway, I attached a patch for
On 5/24/10, Mark Mitchell m...@codesourcery.com wrote:
Certainly removing support for FPA (and any targets that require it) as
a first step would be an option; but we should also focus on where we
want to get to.
I agree with that. But, it would also be interesting to know just how
Steven Bosscher wrote:
The GIMPLE tuples work took man-years (note: plural). There was less
code to convert and the process of conversion was easier, relatively,
than the conversion of RTL would be. So your one person-year seems
grossly underestimated.
I dunno. To get good project
On Mon, 24 May 2010, Mark Mitchell wrote:
As to whether this is a better choice than working on GIMPLE back-ends,
I think that's unclear. There's no question that a GIMPLE back-end
would be prettier. I think it's a question of what your goals are. If
I don't think of the two as being
Hi guys,
About a month ago I opened a bug on Bugzilla:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43805
This relates to gcc crashing out with an Internal Compiler Error when
doing a build of Linux kernel 2.6.34-rc4. Basically, as soon as the
build hits fs/timerfd.c, an ICE is thrown:
Hi all,
when deeply looking into the libgcc.a of
mips64el-unknown-linux-gnu-gcc-4.4.3, I found a object file
_udivdi3.o. but when objdump this object file, no entry for function
_udivdi3 is found, only a __udivti3 function entry, and there are also
some other *di3.o file which only *ti3 can
Philip Pemberton phil...@gmail.com writes:
1) Who's the current maintainer for the lm32 port? Jon Beniston?
I can't see anything on the gcc website that says definitively target
X is maintained by $PERSON, and I really don't want to step on
his/her toes and start a flame war, turf war or any
Ling Kun lkun.e...@gmail.com writes:
when deeply looking into the libgcc.a of
mips64el-unknown-linux-gnu-gcc-4.4.3, I found a object file
_udivdi3.o. but when objdump this object file, no entry for function
_udivdi3 is found, only a __udivti3 function entry, and there are also
some other
Thank you Ian Lance Taylor. Your reply helps me a lot :)
Ling Kun
On Tue, May 25, 2010 at 1:10 PM, Ian Lance Taylor i...@google.com wrote:
Ling Kun lkun.e...@gmail.com writes:
when deeply looking into the libgcc.a of
mips64el-unknown-linux-gnu-gcc-4.4.3, I found a object file
_udivdi3.o.
To whom it may concern:
I'm writing to let you know that the GCC Bugzilla appears to be
misconfigured such that it sends the following MAIL FROM line:
MAIL FROM:bugzilla-admin-daemon\n@sourceware.org
where the \n is a literal newline character (ASCII 10). This violates
RFC 2821 section 4.1.2:
--- Comment #11 from bdubbs at linuxfromscratch dot org 2010-05-24 06:32
---
Updated to gcc (GCC) 4.5.1 20100524 (prerelease) but still have the problem.
There is something about -Os that triggers the kernel panic in
arch/x86/kernel/tsc.c
I tried to disable all -O2 options after -Os
--- Comment #7 from ttsiodras at gmail dot com 2010-05-24 07:24 ---
From my two tests in FreeBSD and Arch Linux, it appears that the -flto bug
that is triggered on my renderer, has occured with the 20100520 (prerelease)
commits.
I hope this helps
Is there anything else I can
--- Comment #6 from jakub at gcc dot gnu dot org 2010-05-24 07:45 ---
Can't reproduce with either branches/gcc-4_4-branch or
branches/redhat/gcc-4_4-branch any more.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from paul dot richard dot thomas at gmail dot com
2010-05-24 08:31 ---
Subject: Re: Missing interface not detected in call to
same file function
With -fwhole-file, we get for the short testcase:
../pr36553/pr36553.f90:2.9:
print *, f( (/ 0.0, 1.0/) )
--- Comment #2 from jakub at gcc dot gnu dot org 2010-05-24 08:52 ---
I think DW_AT_allocated would be wrong for C VLAs, they don't have allocated
property like Fortran arrays.
The problems I see are:
1) for -O0 we don't do any var-tracking, while we should be tracking
i) variables
--- Comment #4 from jakub at gcc dot gnu dot org 2010-05-24 08:58 ---
Current trunk prints fp=optimized out, which is correct (given that the
argument is passed in %eax using regparm calling conventions and the register
has been/could be clobbered by the call).
--
jakub at gcc dot
--- Comment #3 from jakub at gcc dot gnu dot org 2010-05-24 09:01 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #2 from mikpe at it dot uu dot se 2010-05-24 09:31 ---
Bisection identified r159600 as the source of the failure on sparc64:
Author: rsandifo
Date: Wed May 19 21:08:53 2010
New Revision: 159600
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159600
Log:
gcc/
*
--- Comment #8 from bmei at broadcom dot com 2010-05-24 09:31 ---
I integrated Dave's patch into LD with some modification (only emit those with
LTO sections) and hacked collect2 to support that. The size gain of LTO, our
main concern, is quite limited for our application. Large amount
--- Comment #11 from jamborm at gcc dot gnu dot org 2010-05-24 09:43
---
(In reply to comment #9)
(In reply to comment #7)
This is now fixed on both the trunk and the 4.5 branch.
this commit produces broken libkhtml.so.5.4.0 from kdelibs-4.4.3.
in details, it produces
--- Comment #13 from dfranke at gcc dot gnu dot org 2010-05-24 10:44
---
(In reply to comment #12)
With -fwhole-file, we get for the short testcase:
../pr36553/pr36553.f90:2.9:
print *, f( (/ 0.0, 1.0/) )
1
Error: The reference to function 'f' at (1) either needs an
the recent gcc-4.5-branch produces broken libkhtml.so.5.4.0 from kdelibs-4.4.3.
afaics it produces different/broken binaries for khtml/css/parser.cpp
and khtml/svg/SVGGradientElement.cpp.
finally we get a nice GPF during knode/kmail/konqueror startup:
[KCrash Handler]
#5 memcpy () at
--- Comment #1 from pluto at agmk dot net 2010-05-24 11:02 ---
Created an attachment (id=20732)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20732action=view)
preprocessed parser from kdelibs sources.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44258
--- Comment #12 from pluto at agmk dot net 2010-05-24 11:04 ---
(From update of attachment 20731)
moved to separated PR44258.
--
pluto at agmk dot net changed:
What|Removed |Added
--- Comment #2 from jakub at gcc dot gnu dot org 2010-05-24 11:13 ---
Created an attachment (id=20733)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20733action=view)
gcc46-pr41048.patch
Untested fix.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41048
--- Comment #3 from jakub at gcc dot gnu dot org 2010-05-24 11:13 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #3 from iains at gcc dot gnu dot org 2010-05-24 11:46 ---
most likely this is a duplicate of:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44229
and potentially an LE/BE issue given that it's not reported on *x86*
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44255
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44229
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Known to fail||4.5.1
Known to work||4.5.0
--- Comment #2 from arekm at pld-linux dot org 2010-05-24 12:14 ---
In meantime - is reversing the problematic gcc commit a sane thing to do for a
gcc user? (from what I understand it was simply a better optimization and no
real bugfix, right?)
--
--- Comment #9 from rguenth at gcc dot gnu dot org 2010-05-24 12:15 ---
(In reply to comment #8)
I integrated Dave's patch into LD with some modification (only emit those with
LTO sections) and hacked collect2 to support that. The size gain of LTO, our
main concern, is quite limited
--- Comment #8 from rguenth at gcc dot gnu dot org 2010-05-24 12:18 ---
(In reply to comment #6)
Well, I added nostdlib and removed all libraries from the cmd line, but
still:
bash$ g++ -r -nostdlib -O3 -g -Wall -Wextra -fomit-frame-pointer -ffast-math
-funsafe-math-optimizations
--- Comment #9 from rguenth at gcc dot gnu dot org 2010-05-24 12:24 ---
Btw, it reccurs to me that the issue will be fixed by
http://gcc.gnu.org/viewcvs/trunk/gcc/lto/lto.c?r1=158729r2=158728pathrev=158729
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44256
--- Comment #12 from pault at gcc dot gnu dot org 2010-05-24 12:31 ---
Created an attachment (id=20734)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20734action=view)
Fix for this PR and PR40011 #42
This patch regtests OK apart from some peculiarities in proc_ptr_comp_9.f90 and
--- Comment #10 from rguenth at gcc dot gnu dot org 2010-05-24 12:34
---
Subject: Bug 44256
Author: rguenth
Date: Mon May 24 12:34:34 2010
New Revision: 159779
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159779
Log:
2010-05-24 Richard Guenther rguent...@suse.de
PR
--- Comment #11 from rguenth at gcc dot gnu dot org 2010-05-24 12:35
---
The next snapshot will pick up this fix.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44256
--- Comment #24 from rguenth at gcc dot gnu dot org 2010-05-24 12:56
---
(In reply to comment #23)
Just wondering after so many adjustments - is the bug going to be fixed ?
Very unlikely. If there is a small patch that fixed it for 4.4.0 then
that can possibly be back-ported (but
--- Comment #3 from jamborm at gcc dot gnu dot org 2010-05-24 12:57 ---
(In reply to comment #2)
In meantime - is reversing the problematic gcc commit a sane thing to do for a
gcc user? (from what I understand it was simply a better optimization and no
real bugfix, right?)
If
libiberty/pex-unix.c has some alpha64(ia64?)-dec-vms specific
code, that fails to compile for me due to mismatched typedefs:
+ make
if [ x != x ]; then \
alpha64-dec-vms-gcc -c -DHAVE_CONFIG_H -I.
-I/src/binutils/src/libiberty/../include -W -Wall -Wwrite-strings -Wc++-compat
--- Comment #3 from sandra at codesourcery dot com 2010-05-24 13:08 ---
I'm testing a fix for this (better comparison combination logic in the
ifconvert pass).
--
sandra at codesourcery dot com changed:
What|Removed |Added
--- Comment #13 from sandra at codesourcery dot com 2010-05-24 13:21
---
I'm working on a patch that fixes the test case in comment #5 (originally filed
as PR 39874) and some other test cases by improving the comparison combination
logic in both tree-ssa-ifcombine and tree-ssa-reassoc.
If compiled without -O3 option, this code snippet works fine (running
executable will print i=11223344, bswap=44332211)
If compiled with -O3 option, executable will print i=11223344,
bswap=.
Checked on 4.4.1 x86 and 4.4.3 x64.
#include stdio.h
struct int32_bytes
{
int byte1:8;
--- Comment #10 from bmei at broadcom dot com 2010-05-24 13:29 ---
annotating functions with externally_visible sounds a bit difficult to
maintain. Programmer needs to know whether a function is used outside of LTO
objects. This can change over time and extra efforts are needed to keep
--- Comment #1 from dennis at conus dot info 2010-05-24 13:30 ---
The code 4.4.1 x86 generating (with -O3 option) for bswap() function I
mentioned earlier is strange too:
; bswap(unsigned int)
public _Z5bswapj
_Z5bswapj proc near
var_4 = dword ptr -4
--- Comment #12 from ttsiodras at gmail dot com 2010-05-24 13:41 ---
I am at work, so I did a fresh compilation of GCC4.5 from the 20050520
snapshot under my Debian stable using:
../configure --prefix=/opt/gcc45 --enable-languages=c,c++ --enable-lto
The bug still happens, even if I
--- Comment #13 from ttsiodras at gmail dot com 2010-05-24 13:44 ---
I meant 20100520, obviously, not 20050520 (no flto back then! :-)
Anyway, if I understood correctly, I should wait for the next snapshot... ETA?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44256
--- Comment #14 from ttsiodras at gmail dot com 2010-05-24 13:47 ---
And now that we see that it happens even with one object file,
here is the preprocessed (.ii) for the code behind this object file:
http://users.softlab.ntua.gr/~ttsiod/renderer.ii.gz
--
--- Comment #2 from xinping dot huang at gmail dot com 2010-05-24 13:51
---
Subject: Re: Strange behavior on bit fields sructures.
My gcc 4.4.4 generate the correct binary and get the correct result
even with -O3 option.
Wesley
2010/5/24 dennis at conus dot info
--- Comment #3 from xinping dot huang at gmail dot com 2010-05-24 13:53
---
Subject: Re: Strange behavior on bit fields structures
Sorry I made a mistake here, it works on 32bit mode, but failed on the
64bit mode.
Wesley
2010/5/24 xinping dot huang at gmail dot com
--- Comment #14 from dfranke at gcc dot gnu dot org 2010-05-24 14:03
---
(In reply to comment #13)
Should we close this?
Yes, this is testcase gfortran.dg/whole_file_2.f90.
Closing.
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #23 from iains at gcc dot gnu dot org 2010-05-24 14:36 ---
Subject: Bug 43602
Author: iains
Date: Mon May 24 14:36:32 2010
New Revision: 159781
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159781
Log:
2010-05-24 Iain Sandoe ia...@gcc.gnu.org
PR
--- Comment #22 from iains at gcc dot gnu dot org 2010-05-24 14:36 ---
Subject: Bug 44132
Author: iains
Date: Mon May 24 14:36:32 2010
New Revision: 159781
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159781
Log:
2010-05-24 Iain Sandoe ia...@gcc.gnu.org
PR
--- Comment #3 from jakub at gcc dot gnu dot org 2010-05-24 14:38 ---
Created an attachment (id=20735)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20735action=view)
gcc46-pr42801.patch
Patch for the -O2 issue.
The standard says:
Concrete inlined instance entries may omit
--- Comment #6 from danglin at gcc dot gnu dot org 2010-05-24 15:28 ---
this was caused by the maxtsiz limit.
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from danglin at gcc dot gnu dot org 2010-05-24 15:36 ---
I have also seen this error.
It's a bit of a puzzle. A segfault occurs in the startup of
the a.out file run by configure. A null constructor address
is loaded from the constructor table causing the fault.
--
--- Comment #4 from schwab at linux-m68k dot org 2010-05-24 15:48 ---
*** This bug has been marked as a duplicate of 21920 ***
--
schwab at linux-m68k dot org changed:
What|Removed |Added
--- Comment #152 from schwab at linux-m68k dot org 2010-05-24 15:48 ---
*** Bug 44260 has been marked as a duplicate of this bug. ***
--
schwab at linux-m68k dot org changed:
What|Removed |Added
--- Comment #4 from mikpe at it dot uu dot se 2010-05-24 16:16 ---
(In reply to comment #3)
most likely this is a duplicate of:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44229
and potentially an LE/BE issue given that it's not reported on *x86*
However:
1. I see the failure on
--- Comment #5 from mikpe at it dot uu dot se 2010-05-24 16:21 ---
Comparing stage2-libiberty/cp-demangle.o with stage3-libiberty/cp-demangle.o
shows that one instruction has had it's source operands swapped:
objdump -d stage2-libiberty/cp-demangle.o a
objdump -d
The following testcase is an example of code used in a glibc testcase. I'm
trying hard to shake out the bugs in the glibc testsuite for debian, and one
testsuite failure looks like a compiler issue.
The expected behaviour is for the testcase to print the raw IEEE754 value of
-NAN.
The observed
--- Comment #28 from uros at gcc dot gnu dot org 2010-05-24 16:23 ---
Subject: Bug 43733
Author: uros
Date: Mon May 24 16:22:30 2010
New Revision: 159785
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159785
Log:
Backport from mainline:
2010-05-20 Uros Bizjak
--- Comment #29 from uros at gcc dot gnu dot org 2010-05-24 16:26 ---
Subject: Bug 43733
Author: uros
Date: Mon May 24 16:26:17 2010
New Revision: 159786
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159786
Log:
Backport from mainline:
2010-05-20 Uros Bizjak
--- Comment #30 from uros at gcc dot gnu dot org 2010-05-24 16:29 ---
Subject: Bug 43733
Author: uros
Date: Mon May 24 16:28:53 2010
New Revision: 159787
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159787
Log:
Backport from mainline:
2010-05-20 Uros Bizjak
--- Comment #31 from ubizjak at gmail dot com 2010-05-24 16:31 ---
Fixed.
--
ubizjak at gmail dot com changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #11 from rguenther at suse dot de 2010-05-24 17:27 ---
Subject: Re: collect2 does not handle static libraries
On Mon, 24 May 2010, bmei at broadcom dot com wrote:
--- Comment #10 from bmei at broadcom dot com 2010-05-24 13:29 ---
annotating functions with
--- Comment #23 from iains at gcc dot gnu dot org 2010-05-24 17:27 ---
Created an attachment (id=20736)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20736action=view)
candidate solution
OK, so comment #22 is the work-around ...
.. here is the current version of the proper
--- Comment #11 from rguenth at gcc dot gnu dot org 2010-05-24 17:42
---
Subject: Bug 44196
Author: rguenth
Date: Mon May 24 17:41:47 2010
New Revision: 159789
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159789
Log:
2010-05-24 Richard Guenther rguent...@suse.de
PR
--- Comment #12 from rguenth at gcc dot gnu dot org 2010-05-24 17:52
---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-05-24 17:55 ---
Well - GCC has fallback expansions for some sign-related instructions by doing
bit-fiddling instead. I think that's whats required if the arch cannot do
a IEEE negate.
--
--- Comment #15 from rguenth at gcc dot gnu dot org 2010-05-24 18:02
---
Thanks. With the preprocessed source I can confirm the crash and also confirm
that the fix I just committed fixes the crash.
Snapshots are generated every week, so the next is due on May 29th.
--
rguenth at
--- Comment #2 from dave at hiauly1 dot hia dot nrc dot ca 2010-05-24
18:11 ---
Subject: Re: Multiplying -1 by NaN is not valid.
On Mon, 24 May 2010, rguenth at gcc dot gnu dot org wrote:
Well - GCC has fallback expansions for some sign-related instructions by doing
bit-fiddling
1 - 100 of 133 matches
Mail list logo
