[reg...@bethe tmp603]$ current-gcc -O2 small.c -c
small.c: In function 'int329':
small.c:31:38: warning: assignment makes integer from pointer without a cast
[enabled by default]
small.c:24:5: internal compiler error: in propagate_rhs_into_lhs, at
tree-ssa-dom.c:2728
Please submit a full bug report
--- Comment #3 from kkojima at gcc dot gnu dot org 2010-07-18 06:15 ---
(In reply to comment #1)
> Does this fix it?
Yes. With it, the failure go away and my cross sh-linux
build has just completed successfully.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44973
--- Comment #1 from roy dot 1rosen at gmail dot com 2010-07-18 05:22
---
Created an attachment (id=21240)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21240&action=view)
preprocessed file
For the following code, if ts is short it does not get vectorized.
If ts is unsigned short
short variables do not get vectorized the same as unsigned short variables
--
Summary: short variables do not get vectorized
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-opt
--- Comment #2 from ramiro dot polla at gmail dot com 2010-07-18 05:14
---
Thanks. Is there anything that can be done in the code to say that is not a
leaf function, or at least to tell gcc that a call is being made inside the
inline asm?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-07-18 04:40 ---
Well this is called the red zone as GCC assumes anything that does not call a
function is a leaf function.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44975
When there are no functions being called by the C code, gcc decides to use
negative offsets in the stack instead of sub'ing rsp. But if there's a call
inside an inline asm, it will trash the "stack" with a return pointer, and that
might lead to random code being run, for example:
$ cat main.c
void
4.6.0 20100713 r162159 cross, target arm-unknown-eabi, newlib 1.18
Compile:
arm-unknown-eabi-gcc -O1 -S -o bug.s bug.c
With bug.c:
--8<--
extern void foo1 (int status) __attribute__ ((__noreturn__));
extern void _Exit (int status) __attribute__ ((__noreturn__));
extern void foo3 (int status)
--- Comment #13 from hjl dot tools at gmail dot com 2010-07-18 00:32
---
(In reply to comment #12)
> Created an attachment (id=21239)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21239&action=view) [edit]
> Better patch.
>
> Here's something that's a little more likely to work.
--- Comment #12 from bernds at gcc dot gnu dot org 2010-07-17 23:29 ---
Created an attachment (id=21239)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21239&action=view)
Better patch.
Here's something that's a little more likely to work.
--
bernds at gcc dot gnu dot org change
--- Comment #4 from steven at gcc dot gnu dot org 2010-07-17 23:27 ---
Confirmed with r162278. Scheduling after reload (which is bundling for the ia64
backend) seems to cause this:
$ ./xgcc -B. -O2 vector-2.c -fno-inline -fPIC ; echo Testing ; ./a.out
Testing
Aborted
$ ./xgcc -B. -O2
--- Comment #4 from danglin at gcc dot gnu dot org 2010-07-17 23:00 ---
Fixed on trunk.
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
Status|
--- Comment #6 from steven at gcc dot gnu dot org 2010-07-17 22:57 ---
Not mine anymore.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|
--- Comment #1 from steven at gcc dot gnu dot org 2010-07-17 22:56 ---
Jakub, please do not forget about this one for stage1 GCC 4.6.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #54 from steven at gcc dot gnu dot org 2010-07-17 22:55 ---
FIXED in r162047.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #3 from danglin at gcc dot gnu dot org 2010-07-17 22:51 ---
Subject: Bug 44805
Author: danglin
Date: Sat Jul 17 22:51:34 2010
New Revision: 162278
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162278
Log:
PR target/44805
* config/pa/pa.h (CONSTANT_AL
--- Comment #11 from bernds at gcc dot gnu dot org 2010-07-17 22:36 ---
Created an attachment (id=21238)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21238&action=view)
Potential fix
Yeah, I think it trips over DEBUG_INSNs. I'm testing this fix, does it help in
any way?
--
b
--- Comment #2 from steven at gcc dot gnu dot org 2010-07-17 22:34 ---
Ideally, the code would look at the CFG instead, like the loop above it, that
uses FOR_EACH_BB_REVERSE. But most of the postreload.c code ignores the CFG,
unfortunately...
--
http://gcc.gnu.org/bugzilla/show_bug.
--- Comment #1 from bernds at gcc dot gnu dot org 2010-07-17 22:22 ---
Created an attachment (id=21237)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21237&action=view)
Potential fix
Does this fix it?
--
bernds at gcc dot gnu dot org changed:
What|Removed
On sh4-unknown-linux-gnu,
r162270 | bernds | 2010-07-17 08:47:46 +0900 (Sat, 17 Jul 2010) | 26 lines
caused a build failure during compiling libjava:
../trunk/libjava/verify.cc: In member function 'void
_Jv_BytecodeVerifier::merge_into(int, _Jv_BytecodeVerifier::state*)':
../trunk/libjava/verify
--- Comment #5 from John dot Tytgat at aaug dot net 2010-07-17 21:24
---
Patch attachment 21195 fixes reported problem as well (4.6 cross with target
arm-unknown-eabi). Thanks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44902
--- Comment #6 from paolo dot carlini at oracle dot com 2010-07-17 21:09
---
Great, thanks a lot.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44969
--- Comment #5 from jason at redhat dot com 2010-07-17 20:53 ---
Subject: Re: [C++0x] std::is_constructible broken
for fundamental types.
> irrespective of complain. Jason, should complete_type_or_else be something
> different when tf_none?
Perhaps, but we shouldn't be dealing with
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last re
--- Comment #4 from paolo dot carlini at oracle dot com 2010-07-17 19:14
---
I attached a draft which fixes the original testcase as a SFINAE issue. Seems
to me rather straightforward and consistent with existing practice in typeck.c,
just passes down complain to build_x_compound_expr_f
--- Comment #3 from paolo dot carlini at oracle dot com 2010-07-17 19:05
---
Created an attachment (id=21236)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21236&action=view)
Draft patch for the original testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44969
--- Comment #13 from segher at gcc dot gnu dot org 2010-07-17 19:04 ---
(In reply to comment #12)
> What does the standard say here? What is the type in effect for aliasing
> when doing
>
> int i = va_arg (va, int);
>
> ? Is type-punning allowed when unpacking args?
>From C99, 7.15
--- Comment #3 from marc dot glisse at normalesup dot org 2010-07-17 18:49
---
In case it may help, let me mention that other test programs for our library
show:
internal compiler error: in refs_may_alias_p_1, at tree-ssa-alias.c:1023
or:
warning: '#'mem_ref' not supported by dump_ex
--- Comment #2 from hjl dot tools at gmail dot com 2010-07-17 18:07 ---
It is caused by revision 161655:
http://gcc.gnu.org/ml/gcc-cvs/2010-07/msg6.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
---
--- Comment #10 from hjl dot tools at gmail dot com 2010-07-17 17:42
---
With stage3 gcc, I got
[...@gnu-29 stage3-gcc]$ ./xgcc -B./ -B/usr/local/i686-pc-linux-gnu/bin/
-B/usr/local/i686-pc-linux-gnu/bin/ -B/usr/local/i686-pc-linux-gnu/lib/
-isystem /usr/local/i686-pc-linux-gnu/include
--- Comment #9 from hjl dot tools at gmail dot com 2010-07-17 17:39 ---
The patch uses uid of the insn. Will DEBUG_INSN affect
uid processing?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44970
--- Comment #8 from hjl dot tools at gmail dot com 2010-07-17 17:35 ---
The difference in recog.o is in peep2_find_free_register:
@@ -5271,8 +5271,8 @@ Disassembly of section .text:
4884: 74 5e je 48e4
4886: 8d 74 24 30 lea0x30(
I wanted to create a bugzilla bug report, but I seem to have forgotten
my password; moreover, it would seem that bugzilla isn't actually sending
out password-change emails.
Here's the build error:
Comparing stages 2 and 3
warning: gcc/cc1-checksum.o differs
warning: gcc/cc1plus-checksum.o d
--- Comment #7 from hjl dot tools at gmail dot com 2010-07-17 16:56 ---
It also miscompiled 450.soplex in SPEC CPU 2006 on
Linux/i386 with
-m32 -O3 -msse2 -mfpmath=sse -ffast-math -funroll-loops
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44970
--- Comment #6 from bernds at gcc dot gnu dot org 2010-07-17 16:41 ---
(In reply to comment #5)
> > x86_64 failures are expected due to a backend bug, see the patch I sent
> > today.
>
> With the patch in http://gcc.gnu.org/ml/gcc-patches/2010-07/txt00119.txt
> bootstrap fails at stage
--- Comment #5 from dominiq at lps dot ens dot fr 2010-07-17 16:15 ---
> x86_64 failures are expected due to a backend bug, see the patch I sent today.
With the patch in http://gcc.gnu.org/ml/gcc-patches/2010-07/txt00119.txt
bootstrap fails at stage 1 with:
/bin/sh ./libtool --tag=CC
--- Comment #4 from hjl dot tools at gmail dot com 2010-07-17 16:12 ---
(In reply to comment #0)
> On Linux/ia32, revision 162270:
>
> http://gcc.gnu.org/ml/gcc-cvs/2010-07/msg00624.html
>
> caused:
>
> make[6]: Leaving directory `/export/gnu/import/svn/gcc-test/bld'
> Comparing stage
--- Comment #3 from bernds at gcc dot gnu dot org 2010-07-17 15:53 ---
x86_64 failures are expected due to a backend bug, see the patch I sent today.
HJ, any chance you could run make check on the stage1 compiler on ia64 to find
a testcase?
--
http://gcc.gnu.org/bugzilla/show_bug.c
--- Comment #4 from bdsatish at gmail dot com 2010-07-17 15:51 ---
Yes Janus, Dominique. The diagnosis is correct. The error messages are valid. I
think this PR can be closed.
(In reply to comment #3)
> At revision 162276, I get
>
>
> pr44868.f90:245.24:
>
> tst_case => s
--- Comment #2 from dominiq at lps dot ens dot fr 2010-07-17 15:49 ---
On x86_64-apple-darwin10.4 bootstrap fails with
/bin/sh: line 1: 55341 Illegal instruction build/genattrtab
../../work/gcc/config/i386/
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44970
--- Comment #3 from dominiq at lps dot ens dot fr 2010-07-17 15:47 ---
At revision 162276, I get
pr44868.f90:245.24:
tst_case => self%list(i)
1
Error: Pointer assignment target is neither TARGET nor POINTER at (1)
pr44868.f90:231.24:
ts
--- Comment #2 from janus at gcc dot gnu dot org 2010-07-17 15:35 ---
At r162275, I'm neither seeing the ICE nor any valgrind errors. Can anyone
confirm this?
[My guess is that it has been fixed by the recent cleanup of generics, i.e.
r162125.]
--
janus at gcc dot gnu dot org change
--- Comment #1 from hjl dot tools at gmail dot com 2010-07-17 15:28 ---
On Linux/ia64, I got
Bootstrap comparison failure!
gcc/fortran/trans-openmp.o differs
gcc/dwarf2out.o differs
make[5]: *** [compare] Error 1
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44970
--- Comment #5 from iains at gcc dot gnu dot org 2010-07-17 14:51 ---
Subject: Bug 44418
Author: iains
Date: Sat Jul 17 14:51:20 2010
New Revision: 162277
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162277
Log:
PR testsuite/44418
* gcc.target/powerpc/recip-1.
--- Comment #1 from marc dot glisse at normalesup dot org 2010-07-17 13:48
---
Created an attachment (id=21235)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21235&action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44972
(the choice of component is random)
When I compile this code (I am going to attach it immediatly) with g++ -O1 -c
test_api.cpp, I get:
test_api.cpp: In function boost::optional
construct_normal_offset_lines_isecC2():
test_api.cpp:129:15: internal compiler error: in
load_assign_lhs_subreplacemen
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Target Milestone|--- |4.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44971
--- Comment #2 from hjl dot tools at gmail dot com 2010-07-17 13:37 ---
It is caused by revision 161655:
http://gcc.gnu.org/ml/gcc-cvs/2010-07/msg6.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
---
--- Comment #1 from zsojka at seznam dot cz 2010-07-17 11:46 ---
Created an attachment (id=21234)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21234&action=view)
reduced testcase (from libXft sources)
The original testcase didn't have any implicit conversions from/to/between
poin
Command line:
$ gcc -O2 -fcompare-debug testcase.c
Valgrind output:
$ valgrind -q --trace-children=yes
/mnt/svn/gcc-trunk/binary-16-lto-fortran-checking-yes-rtl-df/bin/gcc -O2
-fcompare-debug testcase.c
testcase.c: In function '_XftCloseint':
testcase.c:21:3: warning: passing argument 1 of '_X
--- Comment #4 from iains at gcc dot gnu dot org 2010-07-17 11:16 ---
http://gcc.gnu.org/ml/gcc-patches/2010-07/msg01407.html
--
iains at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #4 from janus at gcc dot gnu dot org 2010-07-17 08:49 ---
Another failing example was reported by Andrew Benson in
http://gcc.gnu.org/ml/fortran/2010-07/msg00222.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44065
--- Comment #4 from rearnsha at gcc dot gnu dot org 2010-07-17 08:36
---
Not a bug.
The ARM ARM says that the shift must be in the range 1
If you want a vmovl instruction, then write one.
--
rearnsha at gcc dot gnu dot org changed:
What|Removed
--- Comment #7 from iains at gcc dot gnu dot org 2010-07-17 08:22 ---
Subject: Bug 44862
Author: iains
Date: Sat Jul 17 08:22:09 2010
New Revision: 162275
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162275
Log:
2010-07-17 Jack Howarth
PR target/44862
* Ma
--- Comment #22 from iains at gcc dot gnu dot org 2010-07-17 07:20 ---
(In reply to comment #16)
> Created an attachment (id=21188)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21188&action=view) [edit]
> proposed patch
>
> This patch should restore the use of the previous stage
55 matches
Mail list logo
