--- Comment #9 from anlauf at gmx dot de 2010-05-08 07:44 ---
(In reply to comment #8)
> This PR lacks the ICE-on-{valid,invalid}-code keyword.
> It's too late for me now to attempt to judge which needs to be added.
The test case from comment #3 is accepted by ifort 11.1 and by
nagf95 5
--- Comment #31 from justinmattock at gmail dot com 2010-05-08 08:02
---
o.k... took me a bit, but I got that system up and running with 4.6.0.
(need more machines around here). Anyways gcc 4.6.0 builds fine
with the above patch. As for the kernel I didn't see the original error, but
fo
--- Comment #8 from ubizjak at gmail dot com 2010-05-08 09:20 ---
Confirmed and added Vlad to CC.
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #32 from hubicka at ucw dot cz 2010-05-08 09:23 ---
Subject: Re: [4.6 Regression]
kernel/rtmutex.c:1138:1: internal compiler error: in
cgraph_decide_inlining_of_small_functions, at ipa-inline.c:1009
> o.k... took me a bit, but I got that system up and runnin
--- Comment #1 from dfranke at gcc dot gnu dot org 2010-05-08 10:02 ---
The thread doesn't come to a conclusion. As I read it, it's invalid in F2003,
but maybe valid in F2008?! Thus removing the rejects-valid keyword for now.
--
dfranke at gcc dot gnu dot org changed:
Wha
--- Comment #4 from jay dot krell at cornell dot edu 2010-05-08 10:22
---
Uros your proposed patch seems to cause:
/src/gcc-4.5.0/libgcc/../gcc/libgcc2.c: In function '__negti2':
/src/gcc-4.5.0/libgcc/../gcc/libgcc2.c:76:1: error: insn does not satisfy its
constraints:
(insn 31 16 20 2
--- Comment #25 from dominiq at lps dot ens dot fr 2010-05-08 10:31 ---
This PR is "fixed" by revision 159106. Apparently there is a rampant bug (at
least on Darwin) with the use of "VEC_safe_push".
How safe is "VEC_safe_push"?
--
dominiq at lps dot ens dot fr changed:
W
--- Comment #26 from steven at gcc dot gnu dot org 2010-05-08 10:38 ---
VEC_safe_push is quite safe, actually. But it may re-allocate the VEC. If you
really believe that VEC_safe_push is the problem here, then you should perhaps
look if a VEC is being passed around incorrectly somewhere,
--- Comment #5 from ubizjak at gmail dot com 2010-05-08 11:19 ---
(In reply to comment #4)
> Uros your proposed patch seems to cause:
>
> /src/gcc-4.5.0/libgcc/../gcc/libgcc2.c: In function '__negti2':
> /src/gcc-4.5.0/libgcc/../gcc/libgcc2.c:76:1: error: insn does not satisfy its
> con
--- Comment #11 from pault at gcc dot gnu dot org 2010-05-08 12:57 ---
(In reply to comment #10)
> (In reply to comment #9)
> > It even works!
>
> Paul, any news here? This looks very useful!
> See also PR41137.
>
Daniel,
I totally forgot about this one. I had a first tinker since c
--- Comment #4 from pault at gcc dot gnu dot org 2010-05-08 12:59 ---
Thanks for noticing this Daniel.
Closed - fixed
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2010-05-08 13:06
---
Working on it.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
Assigne
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-05-08 13:13 ---
Subject: Bug 44030
Author: rguenth
Date: Sat May 8 13:12:56 2010
New Revision: 159186
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159186
Log:
2010-05-08 Richard Guenther
PR tree-optimization/
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-05-08 13:13 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #1 from dfranke at gcc dot gnu dot org 2010-05-08 13:17 ---
Patch:
http://gcc.gnu.org/ml/fortran/2010-05/msg00057.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42360
--- Comment #3 from domob at gcc dot gnu dot org 2010-05-08 13:24 ---
Taking this finally.
--
domob at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo
seen with 4.5 20100506 on x86_64-linux-gnu. fails with -O1, works with -O0 and
-O2.
cc -g -O1 ctst_3_medium.i
ctst_3_medium.c: In function 'tst':
ctst_3_medium.c:479:1: error: Conversion of an SSA_NAME on the left hand side.
VIEW_CONVERT_EXPR("");
D.26572_15393 = &VIEW_CONVERT_EXPR("").data[D.265
--- Comment #1 from doko at ubuntu dot com 2010-05-08 13:35 ---
Created an attachment (id=20601)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20601&action=view)
preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44038
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-05-08 14:01 ---
struct Ustr {
char data[1];
};
int ustr_xi__embed_val_get(char *);
inline int ustr_len(struct Ustr *s1)
{
return ustr_xi__embed_val_get(s1->data);
}
static struct Ustr *s1 = ((struct Ustr *) "");
int tst(char
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-05-08 14:02 ---
Mine.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned
--- Comment #7 from pault at gcc dot gnu dot org 2010-05-08 14:02 ---
(In reply to comment #6)
> Paul, this PR seems to be fixed. Can it be closed?
>
Yes. I said on the list that I would not backport, unless asked, and then
waited :-)
Thanks for jogging my memory.
Pau;
--
pau
--- Comment #10 from pault at gcc dot gnu dot org 2010-05-08 14:05 ---
(In reply to comment #9)
> (In reply to comment #8)
> > I guess everything is fixed now. Can we close this PR?
>
> Ping?
>
Note that I did not apply the patch to 4.4 as I said that I would. What do you
think?
Chee
$ g++ -c logTargets.ii
In file included from
/usr/include/boost/date_time/gregorian/formatters.hpp:17:0,
from /usr/include/boost/date_time/gregorian/gregorian.hpp:25,
from
/usr/include/boost/date_time/posix_time/time_formatters.hpp:12,
from
/usr/i
--- Comment #1 from doko at ubuntu dot com 2010-05-08 14:07 ---
Created an attachment (id=20602)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20602&action=view)
preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44039
--- Comment #2 from doko at ubuntu dot com 2010-05-08 14:08 ---
seen with 4.5 20100506 on x86_64-linux-gnu
--
doko at ubuntu dot com changed:
What|Removed |Added
Kno
seen with 4.5 20100508:
g++ -c Abs.ii
In file included from
/scratch/packages/tmp/m/freemat-4.0/libs/libCore/Abs.cpp:20:0:
/scratch/packages/tmp/m/freemat-4.0/libs/libFreeMat/Operators.hpp: In function
'Array DotOp(const Array&, const Array&, DataC
lass)':
/scratch/packages
--- Comment #1 from doko at ubuntu dot com 2010-05-08 14:33 ---
Created an attachment (id=20603)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20603&action=view)
preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44040
--- Comment #44 from howarth at nitro dot med dot uc dot edu 2010-05-08
14:36 ---
Created an attachment (id=20604)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20604&action=view)
example failing test case on powerpc-apple-darwin9
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?i
=/sw --with-mpc=/sw --with-system-zlib
--x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/l
ib --enable-lto --disable-bootstrap --enable-checking
Thread model: posix
gcc version 4.6.0 20100508 (experimental) (GCC)
COMPILER_PATH=/Users/howarth/darwin_objdir/gcc/
LIBRARY_PATH=/Users/howarth
--- Comment #46 from howarth at nitro dot med dot uc dot edu 2010-05-08
14:55 ---
Opps. The second compile in the failing example failing testcase was...
/Users/howarth/darwin_objdir/gcc/xgcc -B/Users/howarth/darwin_objdir/gcc/
--save-temps -O0 -fwhopr -c -o c_lto_2008_1.o
/Users
seen with 4.5 20100508 on x86_64-linux-gnu:
$ gcc -O0 -fwhole-program -combine -Wno-strict-aliasing -Wtype-limits -m32 *.i
-o x.s
In file included from src/apm.c:12:0:
src/util.h:204:6: warning: conflicting types for built-in function 'printf'
src/output.c:135:1: warning: conflicting
--- Comment #1 from doko at ubuntu dot com 2010-05-08 14:56 ---
Created an attachment (id=20605)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20605&action=view)
preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44041
i...@linux-fd1f:/tmp> cat haha.c
int f(n)
{
int r;
switch(n)
{
case 1:
r = 3;
}
return r;
}
i...@linux-fd1f:/tmp> gcc -O3 -c -Wall haha.c
i...@linux-fd1f:/tmp> gcc -v
Es werden eingebaute Spezifikationen verwendet.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/home/ig25/libexec/gcc/x
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
Known to fail||4.4.1 4.5.0 4.6.0
Known to work||3.3
--- Comment #1 from tkoenig at gcc dot gnu dot org 2010-05-08 15:00 ---
Adjusting subject to make this show up on the
regression list...
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
building the kernel hits this error:
include/linux/netfilter.h: In function 'raw_sendmsg':
include/net/dst.h:262:19: sorry, unimplemented: inlining failed in call to
'dst_output': optimizing for size and code size would grow
include/linux/netfilter.h:206:7: sorry, unimplemented: called from here
m
--- Comment #33 from justinmattock at gmail dot com 2010-05-08 15:33
---
o.k. here the new bug report for this new kind of error:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44043
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43791
--- Comment #2 from hjl dot tools at gmail dot com 2010-05-08 15:33 ---
It failed with gcc 4.1 and 4.2. I think 4.3 is the same.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #12 from sandra at gcc dot gnu dot org 2010-05-08 15:54 ---
Subject: Bug 28685
Author: sandra
Date: Sat May 8 15:53:59 2010
New Revision: 159189
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159189
Log:
2010-05-08 Sandra Loosemore
PR middle-end/28685
--- Comment #1 from hjl dot tools at gmail dot com 2010-05-08 15:57 ---
Please provide a preprocessed testcase.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
-
--- Comment #2 from justinmattock at gmail dot com 2010-05-08 16:26 ---
Created an attachment (id=20606)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20606&action=view)
make net/ipv4/raw.i
hopefully this is the correct *.c file
the file gets rejected because of the size
(I comp
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-05-08 16:38 ---
I will hava alook.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Assigned
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-05-08 16:39 ---
That's the usual CCP exploits undefined behavior bug. There's a bug ...
somewhere. WONTFIX.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-05-08 16:40 ---
-combine. ice-checking.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Summary|[4.5 regression] ICE: |[4.5 Regression] ICE:
|cc1plus segmentation fault
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||error-recovery
Target Milestone|--- |4.5.1
--- Comment #6 from dfranke at gcc dot gnu dot org 2010-05-08 17:28 ---
Patch for initial report:
http://gcc.gnu.org/ml/fortran/2010-05/msg00067.html
(In reply to comment #5)
> There is also a lot of noise when a derived type with default
> initialization is instantiated. Moreover
--- Comment #4 from justinmattock at gmail dot com 2010-05-08 17:46 ---
(In reply to comment #3)
> I will hava alook.
>
alright.. let me know if you need any other kind of info.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44043
--- Comment #3 from paolo dot carlini at oracle dot com 2010-05-08 18:28
---
Matthias, can you please reduce to a manageable size these testcases? Thanks in
advance.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44039
--- Comment #3 from jimsmite at rocketmail dot com 2010-05-08 19:50 ---
Thanks for the tip
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43991
--- Comment #8 from dfranke at gcc dot gnu dot org 2010-05-08 20:04 ---
I expect, the array descriptor reform may make this fixable?!
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #12 from dfranke at gcc dot gnu dot org 2010-05-08 20:07
---
In reply to comment #11)
> Paul, can we close this one?
This PR sat here WAITING for a few months.
Everything seems to be done, thus closing now.
--
dfranke at gcc dot gnu dot org changed:
What
The following (valid) test case is currently rejected:
implicit none
type :: t1
integer :: i
end type
type, extends(t1) :: t2
end type
type(t1),target :: x1
type(t2),target :: x2
select type ( y => fun(1) )
type is (t1)
print *,"t1"
type is (t2)
print *,"t2"
class default
print *,"def
lures73
# of unresolved testcases 155
# of unsupported tests 5
/Users/howarth/darwin_objdir/gcc/xgcc version 4.6.0 20100508 (experimental)
(GCC)
on powerpc-apple-darwin9. Interestingly most of these failures seem to be due
to 'main' getting optimized away...
/U
--- Comment #1 from janus at gcc dot gnu dot org 2010-05-08 20:13 ---
Side note: Invalid code like
function fun()
class(t1) :: fun
end function
is not rejected, although the polymorphic 'fun' is neither a pointer,
allocatable nor a dummy.
--
http://gcc.gnu.org/bugzilla/sho
--- Comment #48 from howarth at nitro dot med dot uc dot edu 2010-05-08
20:14 ---
Created an attachment (id=20607)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20607&action=view)
example failing test case at -m64 on powerpc-apple-darwin9
--
http://gcc.gnu.org/bugzilla/show_
--- Comment #2 from janus at gcc dot gnu dot org 2010-05-08 20:20 ---
Bonus feature #1:
Adding this to comment #0 ...
select type ( y => fun(0) )
type is (t1)
print *,"t1"
type is (t2)
print *,"t2"
class default
print *,"default"
end select
... should give a runtime error, since
--- Comment #3 from janus at gcc dot gnu dot org 2010-05-08 20:23 ---
Bonus feature #2:
select type ( y => fun(1) )
type is (t1)
y%i = 1
type is (t2)
y%i = 2
end select
... should be rejected, due to (F08):
C836 (R847) If selector is not a variable or is a variable that has a vect
--- Comment #7 from dfranke at gcc dot gnu dot org 2010-05-08 20:30 ---
(In reply to comment #6)
> So I don't see any problem on the gfortran producer side.
I take this as a suggestion to close this PR.
Please reopen if misinterpreted.
--
dfranke at gcc dot gnu dot org changed:
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW |WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30609
--- Comment #12 from dfranke at gcc dot gnu dot org 2010-05-08 20:58
---
Paul, I'm always unsure with these kind of things; PR31009 and PR31016 may, or
may not, be more of the same ...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40598
--- Comment #3 from dave at hiauly1 dot hia dot nrc dot ca 2010-05-08
21:43 ---
Subject: Re: xgcc: error trying to exec
'/test/gnu/gcc/objdir/./prev-gcc/gnat1': execv: Not e
> > "Not enough space" is an error from the OS.
>
> Yes, but I saw this on two separate machines, one with 8 G
I was able to reproduce this problem with gcc-4.4.4 on x86_64 (Exherbo) and
gcc-4.5.0 on x86 (Arch Linux 2009.08). Just to be honest I'm not quite sure, if
the code used to build this testcase if valid C++, but it seems to me that
there is some issue with initializing array of shared_ptr's with ini
--- Comment #1 from lynczu at gmail dot com 2010-05-08 23:08 ---
Created an attachment (id=20608)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20608&action=view)
preprocessed file gcc-4.4.4 x86_64
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44045
--- Comment #2 from lynczu at gmail dot com 2010-05-08 23:09 ---
Created an attachment (id=20609)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20609&action=view)
preprocessed file gcc-4.5.0 x86
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44045
--- Comment #3 from paolo dot carlini at oracle dot com 2010-05-08 23:15
---
If it's a segmentation fault, isn't a library issue, that for sure.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--
--- Comment #4 from lynczu at gmail dot com 2010-05-08 23:44 ---
On my two different systems it ends with segfault and on a third one (with
Ubuntu gcc-4.4.0) it throws "incompatible types in assignment" error. So
apparently I was in a bit too hurry in filling this bug error, sorry about
--- Comment #5 from paolo dot carlini at oracle dot com 2010-05-09 01:20
---
Maybe I was not clear enough: **any** segmentation fault is a bug in the
compiler. It must **never** seg fault, no matter which is the input. Thus, the
point is simply that a segmentation must be reported as a
We have a user that is getting illegal instruction errors while building
xulrunner.
/var/tmp/portage/net-libs/xulrunner-1.9.2.3-r1/work/mozilla-1.9.2/dist/bin/xpidl
-m typelib -w -I. -I../../dist/idl -e _xpidlgen/nsIConsoleListener.xpt -d
.deps/nsIConsoleListener.pp nsIConsoleListener.idl
make[4]:
--- Comment #1 from dirtyepic at gentoo dot org 2010-05-09 04:48 ---
Created an attachment (id=20610)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20610&action=view)
/proc/cpuinfo
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44046
70 matches
Mail list logo
