--- Comment #6 from wlam at kosmix dot com 2010-03-20 06:40 ---
Thanks for the quick fix! (I was just trying trunk at r157584 after your
comment above.)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43415
Fails to compile, but should work:
struct A {
char x[4];
A():x("bug") { }
};
Error i get is:
"main.cpp:3: error: array used as initializer"
--
Summary: Initialization of char array with string literal fails
in mem-initializer
Product: gcc
--- Comment #2 from redi at gcc dot gnu dot org 2010-03-20 01:03 ---
Hmm, on second thoughts...
Technically that program has undefined behaviour because p does not have a
value that comes from a previous new expression, however this variation is not
undefined as long as Foo has a trivial
--- Comment #1 from redi at gcc dot gnu dot org 2010-03-20 00:57 ---
It's undefined behaviour
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43452
This code:
class Foo;
int main() {
Foo* p;
delete [] p;
}
Produces this error:
dt.cpp:6: error: invalid use of incomplete type `struct Foo'
dt.cpp:1: error: forward declaration of `struct Foo'
...but shouldn't it compile?
With: g++ -c -std=c++98
...on 4.3.4 20090804 (release) 1 in Cygwin;
--- Comment #13 from ramana at gcc dot gnu dot org 2010-03-20 00:09 ---
I think the documentation is adequate in the sense that it is for installation
into a "staging area" rather than the final install area. Notice also the use
of installing this into a chroot.
cheers
Ramana
--
ra
--- Comment #4 from ramana at gcc dot gnu dot org 2010-03-20 00:02 ---
No further feedback in more than 3 months.
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #4 from ramana at gcc dot gnu dot org 2010-03-19 23:45 ---
Also, what's the configuration in this case i.e what architecture, mode / cpu /
fpu ? Is there a smaller testcase which can be looked at ? Otherwise this will
end up being a WONTFIX bug because we don't have a clear
--- Comment #3 from howarth at nitro dot med dot uc dot edu 2010-03-19
23:42 ---
Should this bug be closed? I don't every recall seeing it in recent history on
i686-apple-darwin*.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26552
--- Comment #6 from ramana at gcc dot gnu dot org 2010-03-19 23:37 ---
The 3.x compilers are no longer supported and even if we got a sensible problem
report I don't expect anyone to fix it. Please reopen this if you still have
issues with a compiler in the current release series.
chee
--- Comment #12 from pinskia at gcc dot gnu dot org 2010-03-19 23:26
---
Basically I would not use svn switch unless you really need that space (the
space is small compared to most things now anyways).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43446
--- Comment #4 from pinskia at gcc dot gnu dot org 2010-03-19 23:22 ---
The problem shows up with gcc-core only.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-03-19 23:22 ---
*** Bug 43446 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #11 from pinskia at gcc dot gnu dot org 2010-03-19 23:22
---
>'S' entries are because of multiple:
svn switch svn://gcc.gnu.org/svn/gcc/emptydir libada
(I selected dirs that were not in gcc-core tarball).
Oh yes and that is the issue. See PR 43073
*** This bug has been m
--- Comment #23 from mikpe at it dot uu dot se 2010-03-19 23:20 ---
While working on another debugging patch I noticed something that I think might
explain the libjava regressions, especially the stack trace ones.
The binutils change breaks _Unwind_GetRegionStart().
Example: We have th
--- Comment #10 from mirq-gccboogs at rere dot qmqm dot pl 2010-03-19
23:20 ---
This was a fresh build. I did
rm -rf gcc-build && mkdir gcc-build && cd gcc-build && ../gcc/configure ... &&
make
[1910] m...@rechot:/usr/src/gcc $ LANG=C svn info
Path: .
URL: svn://gcc.gnu.org/svn/gcc/tru
--- Comment #3 from ramana at gcc dot gnu dot org 2010-03-19 23:15 ---
While working on another bug I noticed this macro definition for Thumb2 - the
comment in that macro is self explanatory.
Trying just the patch below shows a nice code size difference for Thumb2 for
the test case a
--- Comment #3 from dougkwan at google dot com 2010-03-19 23:09 ---
Yes, I lied to configure. So this is not a real bug.
--
dougkwan at google dot com changed:
What|Removed |Added
---
--- Comment #9 from pinskia at gcc dot gnu dot org 2010-03-19 23:04 ---
Can you revert all your patches and try again? Because this used to work for
me.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43446
--- Comment #8 from mirq-gccboogs at rere dot qmqm dot pl 2010-03-19 23:01
---
../gcc/configure --without-headers --with-newlib --prefix=/usr/src/gcc-armtest
--target arm-none-eabi --enable-languages=c --disable-libssp
Now make fails with:
/usr/src/gcc-build/./gcc/xgcc -B/usr/src/gcc-
--- Comment #8 from pinskia at gcc dot gnu dot org 2010-03-19 22:53 ---
Subject: Bug 43211
Author: pinskia
Date: Fri Mar 19 22:52:41 2010
New Revision: 157585
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157585
Log:
2010-03-19 Andrew Pinski
PR C/43211
* c-d
--- Comment #8 from pinskia at gcc dot gnu dot org 2010-03-19 22:53 ---
Subject: Bug 43211
Author: pinskia
Date: Fri Mar 19 22:52:41 2010
New Revision: 157585
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157585
Log:
2010-03-19 Andrew Pinski
PR C/43211
* c-d
--- Comment #7 from pinskia at gcc dot gnu dot org 2010-03-19 22:24 ---
So please try with the flags I offered for configuring. Since those are the
options which are needed to build a cross without newlib built (or a combined
tree).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43
--- Comment #2 from paolo dot carlini at oracle dot com 2010-03-19 22:25
---
Benjamin, I'm adding you in CC, I don't know which plans do we have wrt to this
issue for 4.5.0...
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
---
--- Comment #6 from mirq-gccboogs at rere dot qmqm dot pl 2010-03-19 22:23
---
I haven't looked at newlib yet, as I needed just the C compiler. Source tree is
a vanilla svn checkout from svn://gcc.gnu.org/svn/gcc/trunk.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43446
--- Comment #1 from paolo dot carlini at oracle dot com 2010-03-19 22:15
---
Yes. To be clear, Bugzilla isn't the proper tool for this kind of issue: it is
for *bug* tracking - not for managing the development of new projects - and the
whole C++0x is indeed a new project, and an experim
--- Comment #5 from pinskia at gcc dot gnu dot org 2010-03-19 22:08 ---
Are you building a combined tree? Or are you doing the building in different
steps? For a combined tree, it should just work and if you are building a
combined tree please attach the config.log from libiberty subdi
Since the resolution of LWG 1147, most of the methods on the atomic integral
types should have two overloads, a volatile and a non-volatile version.
However, it appears that since r155377, the volatile overloads are missing from
the atomic integral types altogether.
--
Summary: [C++0
c/gcc-armtest/libexec/gcc/arm-none-eabi/4.5.0/lto-wrapper
Target: arm-none-eabi
Configured with: ../gcc/configure --prefix=/usr/src/gcc-armtest --target
arm-none-eabi --enable-languages=c --disable-libssp
Thread model: single
gcc version 4.5.0 20100319 (experimental) (GCC)
--
http://gcc.gn
--- Comment #3 from mirq-gccboogs at rere dot qmqm dot pl 2010-03-19 21:57
---
I forgot to add, that the configure error is the same as in bug #37634 for
libgfortran.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43446
--- Comment #2 from mirq-gccboogs at rere dot qmqm dot pl 2010-03-19 21:56
---
I'm building a compiler for Cortex-M3 based microcontroller, so i used this
configure options:
../gcc/configure --prefix=/usr/src/gcc-armtest --target arm-none-eabi
--enable-languages=c --disable-libssp
The
--- Comment #3 from jakub at gcc dot gnu dot org 2010-03-19 21:50 ---
Similar effects on x86_64 cc1plus:
before:
DW_AT_location count 312834, cc1plus size 83M
[28] .debug_info PROGBITS 10eb517 149edb3 00
0 0 1
[32] .debug_locPROGBITS
--- Comment #7 from jakub at gcc dot gnu dot org 2010-03-19 21:14 ---
I really think it is score backend that should be fixed here.
Say the store multiple should be represented with
(insn/f 93 8 94 2 pr43437.c:4 (parallel [
(set/f (mem:SI (plus:SI (reg/f:SI 0 r0) (const_int
Moved from PR 40011 comment 40 into an extra PR. Joost reported that the
following ICEs in gfc_create_module_variable, at fortran/trans-decl.c:3386
The failing assert is:
gcc_assert (TYPE_CONTEXT (decl) == NULL_TREE
|| TYPE_CONTEXT (decl) == sym->ns->proc_name->backend_dec
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-03-19 21:05 ---
This is the comment from hwint.h (which I know I did :) ):
/* Define HOST_WIDEST_FAST_INT to the widest integer type supported
efficiently in hardware. (That is, the widest integer type that fits
in a hardwar
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-03-19 21:02 ---
SBITMAP_ELT_TYPE is defined as HOST_WIDEST_FAST_INT. And HOST_WIDEST_FAST_INT
(added by me) is either "long" or "long long". Yes there should be a cast but
it cannot be an issue really with -m32 really because long
--- Comment #2 from jakub at gcc dot gnu dot org 2010-03-19 20:56 ---
The patch has been bootstrapped/regtested on x86_64-linux and i686-linux and
apparently has huge effect on the debug info size.
i686 cc1 before:
DW_AT_location count 305862
[28] .debug_info PROGBITS000
We found a problem in sbitmap.c:
bool
sbitmap_range_empty_p (const_sbitmap bmap, unsigned int start, unsigned int n)
{
unsigned int i = start / SBITMAP_ELT_BITS;
SBITMAP_ELT_TYPE elm;
...
/* The bits are totally contained in a single element. */
if (shift + n < SBITMAP_ELT_BITS)
gccbug hasn't worked in months if not years. Bug reports submitted using it
are silently dropped, which is the worse that can happen: submitters being
ignored
and possibly even losing their submission are far less likely to report bugs in
the future. Since it seems highly unlikely that a voluntee
At least on Solaris 10 and 11, both SPARC and x86, the 64-bit TestLeak.exe test
consumes all available memory, possibly bringing the machine to a complete
halt.
The problem seems to be far more severe if gcc is built to use GNU ld instead
of Sun ld.
--
Summary: TestLeak.exe test consu
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-03-19 20:45 ---
How did you configure GCC?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43446
build fails in configure-target-libiberty with:
checking for library containing strerror... configure: error: Link tests are
not allowed after GCC_NO_EXECUTABLES.
Anyway, Probably libiberty should not be built anyway for this target. The same
goes for libssp (can be disabled) and zlib.
--
During a libjava build on i386-pc-solaris2.11, I noticed the following error:
ld.so.1: gcj-dbtool: fatal:
/vol/gcc/obj/gcc-4.5.0-20100208/11-gcc-gld/./gcc/libgcc_s.so.1: wrong ELF
class: ELFCLASS32
/bin/ksh: 29209 Killed
This happens when trying to execute the 64-bit gcj-dbtool. gcj-dbtool itsel
--- Comment #6 from jakub at gcc dot gnu dot org 2010-03-19 20:37 ---
Created an attachment (id=20144)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20144&action=view)
gcc45-pr43437.patch
Possible patch. Except that note_uses (and note_stores) walk parallels from
end to start, so
--- Comment #1 from ro at gcc dot gnu dot org 2010-03-19 20:32 ---
Fails on 64-bit Solaris 10, 11/SPARC, too.
I get the following stacktrace:
#0 0xfee7248c in abort () from /lib/libc.so.1
#1 0x08859957 in _cpp_process_line_notes (pfile=0x8b5c468, in_comment=0) at
/vol/gcc/src/hg/trun
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2010-03-19 20:25
---
On it.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unas
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
OtherBugsDependingO||16996
nThis||
Seve
--- Comment #5 from bernds at gcc dot gnu dot org 2010-03-19 18:41 ---
Subject: Bug 40697
Author: bernds
Date: Fri Mar 19 18:41:22 2010
New Revision: 157582
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157582
Log:
gcc/
PR target/40697
* optabs.c (avoid_expensiv
--- Comment #5 from aldyh at gcc dot gnu dot org 2010-03-19 18:41 ---
Err, I was just going to say that. Curse you Jakub. Let me know when you're
looking at something so we don't duplicate efforts. Wait, am I not supposed to
say curse on a PR? Oh well.
--
http://gcc.gnu.org/bugz
--- Comment #4 from steven at gcc dot gnu dot org 2010-03-19 18:39 ---
Comment #3 makes no sense: There is no such thing as target specific GIMPLE
canonicalization. And also there is no hoisting for GIMPLE so the form of the
IR given in comment #3 wouldn't make a difference.
Even withou
--- Comment #15 from pinskia at gcc dot gnu dot org 2010-03-19 18:19
---
*** Bug 43444 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-03-19 18:19 ---
Just fixed after this morning (which was done after the snapshot was done).
*** This bug has been marked as a duplicate of 43399 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #7 from bernds at gcc dot gnu dot org 2010-03-19 18:19 ---
Subject: Bug 42258
Author: bernds
Date: Fri Mar 19 18:18:54 2010
New Revision: 157581
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157581
Log:
gcc/
PR rtl-optimization/42258
* ira-lives.c (c
ICE while building cross-compiler for ARM.
$ /usr/src/gcc-build/./gcc/xgcc -B/usr/src/gcc-build/./gcc/
-B/usr/src/armtest/arm-none-eabi/bin/ -B/usr/src/armtest/arm-none-eabi/lib/
-isystem /usr/src/armtest/arm-none-eabi/include -isystem
/usr/src/armtest/arm-none-eabi/sys-include-g -O2 -mfloat-
--- Comment #5 from burnus at gcc dot gnu dot org 2010-03-19 17:40 ---
(In reply to comment #4)
> size.1 is always kind=4 so we may need some error checks if someone tries to
> stuff a large file size into a small space.
Thus, we should change the ABI at some point (e.g. when doing the
--- Comment #4 from jakub at gcc dot gnu dot org 2010-03-19 17:35 ---
Ah, I see. We have
(insn/f 93 8 94 2 pr43437.c:4 (parallel [
(set/f (mem:SI (pre_dec:SI (reg/f:SI 0 r0)) [0 S4 A32])
(reg:SI 12 r12))
(set/f (mem:SI (pre_dec:SI (reg/f:SI 0 r0))
--- Comment #1 from jakub at gcc dot gnu dot org 2010-03-19 17:12 ---
Created an attachment (id=20143)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20143&action=view)
gcc45-pr43443.patch
Fix.
--
jakub at gcc dot gnu dot org changed:
What|Removed
__attribute__((noinline))
void bar (void)
{
asm volatile ("" : : : "memory");
}
int
main (void)
{
int i = 6;
bar ();
i++;
asm ("" : "+r" (i));
i++;
return i;
}
on x86_64-linux -g -O2 has bogosity in VAR_LOCATION note:
(note 33 13 21 2 (var_location i (expr_list:REG_DEP_TRUE (plus:SI
--- Comment #14 from ramana at gcc dot gnu dot org 2010-03-19 17:04 ---
Fixed.
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #6 from jakub at gcc dot gnu dot org 2010-03-19 17:01 ---
Well, we have to call cselib_process_insn on DEBUG_INSNs at least during
var-tracking. As for other passes, such as DSE, haven't thought about the
impliciations of not doing so. Alex?
--
http://gcc.gnu.org/bugzi
--- Comment #5 from matz at gcc dot gnu dot org 2010-03-19 16:59 ---
How about not calling cselib_process_insn on DEBUG_INSNs (or better make
cselib_process_insn ignore them).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42977
--- Comment #2 from matz at gcc dot gnu dot org 2010-03-19 16:55 ---
Actually I have a patch for this, need to polish it somewhat.
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #5 from matz at gcc dot gnu dot org 2010-03-19 16:40 ---
Fixed for 4.5. Unassigning myself.
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from jakub at gcc dot gnu dot org 2010-03-19 16:38 ---
Created an attachment (id=20142)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20142&action=view)
gcc45-pr43442.patch
Untested patch that cures the size of .debug_loc on the reduced pr43058.c
testcase even witho
--- Comment #4 from matz at gcc dot gnu dot org 2010-03-19 16:37 ---
Subject: Bug 43116
Author: matz
Date: Fri Mar 19 16:37:27 2010
New Revision: 157578
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157578
Log:
PR c++/43116
* attribs.c (decl_attributes): When re
--- Comment #12 from zsojka at seznam dot cz 2010-03-19 16:34 ---
Thank you for the answer. I didn't realise check is usually done only with
compilers built with checking. (and thank you for fixing the issue, of course)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43305
--- Comment #11 from matz at gcc dot gnu dot org 2010-03-19 16:23 ---
I'm not sure what you're asking. When the unpatched compiler the testcase
(with the printf or the x!=6->abort) will ICE with a checking compiler,
and produce wrong output ("0" or an abort) with a nonchecking compiler.
--- Comment #3 from matz at gcc dot gnu dot org 2010-03-19 16:18 ---
I have a patch: http://gcc.gnu.org/ml/gcc-patches/2010-03/msg00899.html
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #4 from nightstrike at gmail dot com 2010-03-19 16:16 ---
Can we fix this before 4.5 is released?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40722
--- Comment #10 from zsojka at seznam dot cz 2010-03-19 16:08 ---
How does the test work, would it fail on non-patched trunk?
- extern int printf(const char *format, ...);
- printf("%d\n", foo(100));
+ if (foo(100) != 6)
+ __builtin_abort ();
I *think* this would do the job, but I
While looking at PR43058, I've noticed that we generate tons of completely
useless location list elements. E.g. on the pr43058.c testcase with X2 instead
of X4 X4 and without the PR43058 patch applied, we generate extremely long
location list for the first a variable and then each loclist is 2 ent
--- Comment #13 from ramana at gcc dot gnu dot org 2010-03-19 15:58 ---
Subject: Bug 43399
Author: ramana
Date: Fri Mar 19 15:58:37 2010
New Revision: 157574
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157574
Log:
Fix PR target/43399
2010-03-19 Ramana Radhakrishnan
--- Comment #3 from aldyh at gcc dot gnu dot org 2010-03-19 15:58 ---
Reproduce with: ./cc1 -g -O a.i -mscore3
--
aldyh at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #2 from aldyh at gcc dot gnu dot org 2010-03-19 15:48 ---
Created an attachment (id=20141)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20141&action=view)
reduced testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43437
--- Comment #9 from jakub at gcc dot gnu dot org 2010-03-19 15:46 ---
Well, just fixed on the trunk. This fix looks simple enough that it should be
backportable.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #49 from dominiq at lps dot ens dot fr 2010-03-19 15:40 ---
A few remarks about comments #47 and #48
> Note that this PR isn't too serious as -fwhole-file isn't the default
> for Fortran so we do not run into this unfortunate interaction of
> profile estimation and inlining.
--- Comment #3 from matz at gcc dot gnu dot org 2010-03-19 15:33 ---
I have a patch: http://gcc.gnu.org/ml/gcc-patches/2010-03/msg00893.html
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #2 from ramana at gcc dot gnu dot org 2010-03-19 15:21 ---
Confirmed with trunk.
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
Sta
--- Comment #3 from ramana at gcc dot gnu dot org 2010-03-19 15:12 ---
Is this for Thumb1 or Thumb2 ? Can you check with trunk today ?
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #6 from marti at juffo dot org 2010-03-19 14:46 ---
(In reply to comment #5)
> I think the compiler should throw an error if there are any statements in the
> naked function other than asm statements.
This would break a lot of code; there are use cases where you want to
save
--- Comment #1 from nightstrike at gmail dot com 2010-03-19 14:25 ---
This is probably due to the way you built GCC. To have a completely
relocatable toolchain, you need to use the --with-sysroot option to configure,
and you need to set it equal to prefix or below prefix in the director
Executing on host: /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/
-
O2 -fexceptions -fnon-call-exceptions -fpeel-loops -c -o pr42427.o
/test/gnu/gc
c/gcc/gcc/testsuite/gcc.dg/pr42427.c(timeout = 300)
/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/pr42427.c:5:21: fatal error: complex.h:
N
--- Comment #1 from ramana at gcc dot gnu dot org 2010-03-19 13:32 ---
Yes, there is no easy way of describing the container relationship of the Neon
registers to the compiler at the minute. Thus the only work around at the
moment is to indicate that all the registers contained as part o
--- Comment #12 from danglin at gcc dot gnu dot org 2010-03-19 13:30
---
Fixed.
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
Status|WAITING
--- Comment #9 from eli dot osherovich at gmail dot com 2010-03-19 13:29
---
(In reply to comment #7)
> Subject: Re: sinl is not computed correctly
>
> On Thu, 18 Mar 2010, bangerth at gmail dot com wrote:
>
> > Also: 1e22 is not exactly representable as a floating point number. By
>
--- Comment #5 from rearnsha at gcc dot gnu dot org 2010-03-19 13:27
---
I think the compiler should throw an error if there are any statements in the
naked function other than asm statements. All such asms should be treated as
volatile.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi
--- Comment #8 from eli dot osherovich at gmail dot com 2010-03-19 13:27
---
(In reply to comment #6)
> Also: 1e22 is not exactly representable as a floating point number. By
> consequence, 1e22 is different numbers when stored as a double or a
> long double, and we should expect differ
Function:
float y;
float foo(float x)
{
y = x * x + x;
asm volatile ("vmov.i8 q0, #0" ::: "q0");
asm volatile ("vmov.i8 q1, #0" ::: "q1");
asm volatile ("vmov.i8 q2, #0" ::: "q2");
asm volatile ("vmov.i8 q3, #0" ::: "q3");
asm volatile ("vmov.i8 q4, #0" ::: "q4");
asm vo
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-03-19 13:07 ---
*** This bug has been marked as a duplicate of 43426 ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-03-19 13:07 ---
*** Bug 43429 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43426
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-03-19 12:53 ---
(In reply to comment #2)
> Oh it might also need the patch for PR 29751 which I hope to submit for 4.6.
> Note the patch in there still works and has been tested as of earlier this
> week.
New mem-ref will make tha
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||rguenth at gcc dot gnu dot
|
--- Comment #7 from rguenth at gcc dot gnu dot org 2010-03-19 12:40 ---
make_extraction (mode=SImode, inner=0x75b48ac8, pos=0, pos_rtx=0x0, len=8,
unsignedp=1, in_dest=0, in_compare=0)
at /space/rguenther/src/svn/trunk/gcc/combine.c:6648
6648 enum machine_mode is_mode =
--- Comment #8 from matz at gcc dot gnu dot org 2010-03-19 12:38 ---
Fixed.
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #7 from matz at gcc dot gnu dot org 2010-03-19 12:37 ---
Subject: Bug 43305
Author: matz
Date: Fri Mar 19 12:37:28 2010
New Revision: 157567
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157567
Log:
PR 43305
* builtins.c (expand_builtin_interclass_ma
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-03-19 12:06 ---
Breakpoint 7, combine_simplify_rtx (x=0x75ae6e58, op0_mode=VOIDmode,
in_dest=0) at /space/rguenther/src/svn/trunk/gcc/combine.c:4861
4861 enum rtx_code code = GET_CODE (x);
(set (reg:SI 69)
(and:SI
--- Comment #4 from ramana at gcc dot gnu dot org 2010-03-19 12:04 ---
Yes - haven't thought about it much, maybe the backend could give an error if a
frame were allocated for a naked function rather than ICE'ing in an awkward
place.
--
ramana at gcc dot gnu dot org changed:
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-03-19 11:35 ---
It combines
(insn 6 5 7 2 t.c:16 (parallel [
(set (reg:SI 59 [ D.2732 ])
(ior:SI (reg:SI 67 [ g_9 ])
(const_int 1 [0x1])))
(clobber (reg:CC 17 flags))
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-03-19 11:29 ---
Combine breaks this.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Compo
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-03-19 11:02 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
1 - 100 of 114 matches
Mail list logo
