--- Comment #5 from H9XLrv5oXVNvHiUI at spambox dot us 2009-09-15 07:37
---
Any update about this?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38392
--- Comment #6 from gerald at pfeifer dot com 2009-09-15 08:16 ---
Confirming as FIXED on i386-unknown-freebsd7.2. Thanks!
--
gerald at pfeifer dot com changed:
What|Removed |Added
--
--- Comment #12 from potswa at mac dot com 2009-09-15 08:55 ---
Just for safekeeping, here's the body of the final code. It's much faster than
the current revision on my machine, 2.2 sec for 100 iterations rotating a 10
million int vector 5 places left or right, vs 10.5 sec currently. Al
--- Comment #12 from rguenth at gcc dot gnu dot org 2009-09-15 09:02
---
Why do you think refering to other debug stmts decl is not a good idea? I
was thinking of simplifying propagation into debug stmts by simply replacing
all uses of a to-become dead SSA name with a non-artificial de
--- Comment #13 from jakub at gcc dot gnu dot org 2009-09-15 09:18 ---
For dwarf2out.c, it is IMHO desirable to be able to find out the original decls
which you refer to, rather than have some artificial ones. Otherwise for
DW_OP_call{2,4} you'd have to create artificial variables in th
--- Comment #13 from paolo dot carlini at oracle dot com 2009-09-15 09:58
---
Thanks. I'm attaching a slightly tweaked version of the patch, avoiding
postincrement of the iterators and reformatted according to our conventions,
which I successfully regtested. A minor issue I can see, in
--- Comment #14 from paolo dot carlini at oracle dot com 2009-09-15 09:59
---
Created an attachment (id=18582)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18582&action=view)
Draft, passes the testsuite
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41351
--- Comment #10 from rguenth at gcc dot gnu dot org 2009-09-15 10:14
---
Subject: Bug 41230
Author: rguenth
Date: Tue Sep 15 10:14:29 2009
New Revision: 151714
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=151714
Log:
2009-09-15 Richard Guenther
PR lto/41230
--- Comment #11 from rguenth at gcc dot gnu dot org 2009-09-15 10:15
---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNE
--- Comment #15 from paolo dot carlini at oracle dot com 2009-09-15 10:16
---
If I'm not mistaken, (__k < __n - __k) would be just fine.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41351
--- Comment #2 from rainer at emrich-ebersheim dot de 2009-09-15 11:23
---
I think it's the same issue for PR41357.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41357
The attached diff updates types for OpenBSD.
ie as per http://marc.info/?l=openbsd-cvs&m=113717477200754&w=2
size_t, ssize_t, intptr_t and uintptr_t have been standardised across all
OpenBSD platforms for several years.
--
Summary: correct types for OpenBSD targets
Produc
--- Comment #1 from jsg at openbsd dot org 2009-09-15 12:16 ---
Created an attachment (id=18583)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18583&action=view)
update types for OpenBSD targets
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41358
Considering the following fortran code:
=== begin code ===
program main
implicit none
integer :: a = 7
if( a == 0 ) then
print *, "a is null"
else if( a > 0 ) then
print *, "a is positif"
else
print *, "a is negatif"
end if
end program
=== end code ===
comp
--- Comment #3 from davek at gcc dot gnu dot org 2009-09-15 12:47 ---
This bug is also present on i686-pc-cygwin at r.151703, so given Jie's
diagnosis in comment 2, let's switch the component from 'target' to 'debug'.
libtool: link: /gnu/gcc/obj.libstdc.enabled/./gcc/xgcc
-B/gnu/gcc/ob
--- Comment #4 from davek at gcc dot gnu dot org 2009-09-15 12:52 ---
(In reply to comment #2)
> I think it's the same issue for PR41357.
>
*This* is PR41357; you must mean PR41308. Yes, I think so, I'll mark it as a
dup of this one.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=
--- Comment #5 from davek at gcc dot gnu dot org 2009-09-15 12:52 ---
*** Bug 41308 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41357
--- Comment #1 from davek at gcc dot gnu dot org 2009-09-15 12:52 ---
*** This bug has been marked as a duplicate of 41357 ***
--
davek at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #2 from joseph at codesourcery dot com 2009-09-15 13:04 ---
Subject: Re: correct types for OpenBSD targets
Please send patches to gcc-patches.
http://gcc.gnu.org/contribute.html
(I believe existing testcases already cover consistency of these types.)
If sorting out type
--- Comment #1 from jv244 at cam dot ac dot uk 2009-09-15 13:07 ---
As you can see with
gfortran -fdump-tree-original-lineno test.f90
which leads to garbage line numbers in
gfortran -fdump-tree-gimple-lineno test.f90
I believe there is some similarity to PR40823
http://gcc.gnu.org
--- Comment #3 from erik at arbat dot com 2009-09-15 13:22 ---
Created an attachment (id=18584)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18584&action=view)
Self-contained program demonstrating the issue.
Correct behaviour is to do nothing.
Incorrect behaviour is to crash with
On Linux/ia32, revision 151702 gave:
FAIL: gcc.c-torture/compile/builtin_unreachable-1.c -Os (internal compiler
error)
FAIL: gcc.c-torture/compile/builtin_unreachable-1.c -Os (test for excess
errors)
Revision 151692 is OK.
--
Summary: [4.5 regression] gcc.c-
--- Comment #6 from davek at gcc dot gnu dot org 2009-09-15 13:29 ---
(In reply to comment #1)
> The cause is that DW_TAG_variable references gomp_tls_data instead of
> ___emutls_v.gomp_tls_data.
>
Here's an example:
<1>: Abbrev Number: 49 (DW_TAG_variable)
DW_AT_name
--- Comment #7 from davek at gcc dot gnu dot org 2009-09-15 13:40 ---
This looks a little tricky.
Knowledge of the "__emutls_v." prefix is entirely private to varasm.c. The
actual prefixed object itself escapes publicly with that name, but only
varasm.c knows that subsequent references
--- Comment #4 from jakub at gcc dot gnu dot org 2009-09-15 13:45 ---
Created an attachment (id=18585)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18585&action=view)
gcc45-pr41353.patch
I've looked briefly at the problem with correct var location notes followed by
(nil) ones and
Hi,
How do I get a 64-bit gcc (compiles 64 bit
apps for Intel Core 2 Duo)?
Thanks,
--Stuart
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-09-15 14:07 ---
With the alias issue fixed I get
good:
.LFB0:
.cfi_startproc
movdsrcshift(%rip), %xmm1
xorl%eax, %eax
.p2align 4,,10
.p2align 3
.L2:
movdqu (%rdi,%rax), %xmm0
--- Comment #8 from davek at gcc dot gnu dot org 2009-09-15 14:07 ---
(In reply to comment #6)
> (In reply to comment #1)
> > The cause is that DW_TAG_variable references gomp_tls_data instead of
> > ___emutls_v.gomp_tls_data.
> >
>
> Here's an example:
No, that's not it, that's n
--- Comment #16 from paolo dot carlini at oracle dot com 2009-09-15 14:16
---
I'm also carrying out some experiments with builtin types, like int, and the
patched implementation indeed appears to perform well, usually beating by a
good amount the current implementation, easily 2x-3x for
--- Comment #9 from jzhang918 at gmail dot com 2009-09-15 14:21 ---
(In reply to comment #8)
> (In reply to comment #6)
> > (In reply to comment #1)
> > > The cause is that DW_TAG_variable references gomp_tls_data instead of
> > > ___emutls_v.gomp_tls_data.
> > >
> >
> > Here's an ex
--- Comment #10 from davek at gcc dot gnu dot org 2009-09-15 14:24 ---
(In reply to comment #9)
> (In reply to comment #8)
> > (In reply to comment #6)
> > > (In reply to comment #1)
> > > > The cause is that DW_TAG_variable references gomp_tls_data instead of
> > > > ___emutls_v.gomp_tl
--- Comment #17 from potswa at mac dot com 2009-09-15 14:33 ---
Hmm, on my Core2 my impl still beats the present one on many cases of shift by
1, but the margin is narrower.
Shift by 1 is the only case where the temporary can really help, and I
eliminated it completely. I suppose I shou
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-09-15 14:40 ---
Which is likely because it decides to allocate $cx for the load destination
(operand for the scalar shift) and then needs to re-load it to $xmm? for the
vector shift. The placement of the re-load inside the loop is
--- Comment #18 from paolo dot carlini at oracle dot com 2009-09-15 14:41
---
Thanks David for your further ideas. I want to wait a bit other people, but I
don't know if specializing for k == 1 is worth the trouble, and the patch
becomes bigger. Really, if you are willing to help more,
--- Comment #19 from chris at bubblescope dot net 2009-09-15 14:45 ---
I think this generally looks good. The testsuite could do with some
improvement, there are quite a lot of cases for this algorithm, and it's
probably worth testing they all work properly.
I unfortunately cam't execut
--- Comment #20 from paolo dot carlini at oracle dot com 2009-09-15 14:53
---
Chris, please check my actual patch, the code inline above is just the main
body. Besides that, are you willing to contribute a new testcase for rotate, at
the moment David can't, it would be too much code, I'
--- Comment #11 from davek at gcc dot gnu dot org 2009-09-15 14:53 ---
The bogus const info is added in at the end of this call chain, when generating
the var die:
#0 0x004d0679 in add_const_value_attribute (die=0x7fcbd660, rtl=0x7fd20270)
at /gnu/gcc/gcc/gcc/tree.h:182
#1 0x004d2
--- Comment #21 from potswa at mac dot com 2009-09-15 14:56 ---
Just to be clear that "working properly" in this context means "working faster"
;v) .
I just coded up a special case for k = ± 1 that uses std::copy, which should
map to memmove for std::vector::iterator. That should beat a
--- Comment #22 from paolo dot carlini at oracle dot com 2009-09-15 15:04
---
__gcd isn't important for now, there is no reason to remove it. At some point
we can erase it and another small function which Chris left, but there is no
hurry to do that.
Otherwise, I'm seeing the same slow
--- Comment #14 from matz at gcc dot gnu dot org 2009-09-15 15:21 ---
http://gcc.gnu.org/ml/gcc-patches/2009-09/msg01001.html
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #23 from potswa at mac dot com 2009-09-15 15:29 ---
With the new special case, I get 3x faster than current for n = 100, k = 99.
Now it weighs in at 45 lines in my style, before conversion to official style,
and not coincidentally I don't really feel like posting it again :vP
--- Comment #24 from paolo dot carlini at oracle dot com 2009-09-15 15:37
---
My gut feeling is that left and right by one is the special case we only want
to treat separately, but we can always proceed incrementally, and add
optimizations when people really ask. Remember that code size
--- Comment #1 from hjl dot tools at gmail dot com 2009-09-15 15:38 ---
Revision 151696:
http://gcc.gnu.org/ml/gcc-cvs/2009-09/msg00443.html
is the cause.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #2 from hjl dot tools at gmail dot com 2009-09-15 15:42 ---
[...@gnu-34 rrs]$ ./151696/usr/bin/gcc
/export/gnu/import/rrs/151696/src/gcc/testsuite/gcc.c-torture/compile/builtin_unreachable-1.c
-m32 -S -Os
/export/gnu/import/rrs/151696/src/gcc/testsuite/gcc.c-torture/compile/b
--- Comment #3 from matz at gcc dot gnu dot org 2009-09-15 15:53 ---
Problem is a barrier inside a basic block:
(gdb) debug_bb(bb)
...
(call_insn 7 6 8 3 builtin_unreachable-1.c:4 (call (mem:QI (symbol_ref:SI
("bar") [flags 0x41] ) [0 S1 A8])
(const_int 16 [0x10])) -1 (nil)
--- Comment #12 from davek at gcc dot gnu dot org 2009-09-15 16:16 ---
(In reply to comment #11)
> The bogus const info is added in at the end of this call chain, when
> generating
> the var die:
>
> #0 0x004d0679 in add_const_value_attribute (die=0x7fcbd660, rtl=0x7fd20270)
> at
--- Comment #15 from jv244 at cam dot ac dot uk 2009-09-15 16:20 ---
(In reply to comment #14)
> http://gcc.gnu.org/ml/gcc-patches/2009-09/msg01001.html
This also fixes PR41312 (that I will close as a duplicate).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41212
--- Comment #4 from jv244 at cam dot ac dot uk 2009-09-15 16:21 ---
duplicate of PR41212
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
Status|UNC
--- Comment #13 from jakub at gcc dot gnu dot org 2009-09-15 16:42 ---
tls-local-exec for the VAR_DECL is not expected to me, I'd say it should be
TLS_MODEL_EMULATED for the !targetm.have_tls case. dwarf2out.c has no way
knowing the SYMBOL_REF needs special treatment, as when it is crea
--- Comment #14 from davek at gcc dot gnu dot org 2009-09-15 17:08 ---
Created an attachment (id=18586)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18586&action=view)
reduced testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41357
--- Comment #15 from davek at gcc dot gnu dot org 2009-09-15 17:16 ---
(In reply to comment #14)
> Created an attachment (id=18586)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18586&action=view) [edit]
> reduced testcase
>
Ok, this is really interesting.
The generated debu
--- Comment #16 from jakub at gcc dot gnu dot org 2009-09-15 17:19 ---
Please read what I wrote.
vartrack uses cselib as a value numbering implementation, not for anything
else.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41357
--- Comment #16 from kargl at gcc dot gnu dot org 2009-09-15 17:21 ---
(In reply to comment #14)
> http://gcc.gnu.org/ml/gcc-patches/2009-09/msg01001.html
>
I'm not in a position to test this patch at the moment.
Does this PR 41347?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4
--- Comment #17 from davek at gcc dot gnu dot org 2009-09-15 17:25 ---
(In reply to comment #16)
> Please read what I wrote.
I did, but I'm a few steps behind, and haven't figured out whether to blame
encode_section_info() for being naive, or to look at where the SYM_REF gets
created
--- Comment #18 from davek at gcc dot gnu dot org 2009-09-15 17:36 ---
Created an attachment (id=18587)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18587&action=view)
patch based on jakub's suggestion
this fixes the testcase, so I may as well take it for a full bootstrap cycle.
--- Comment #19 from hjl dot tools at gmail dot com 2009-09-15 17:41
---
Index: varasm.c
===
--- varasm.c(revision 151703)
+++ varasm.c(working copy)
@@ -6420,6 +6420,8 @@ default_encode_section_info (tree decl, rtx
--- Comment #20 from jakub at gcc dot gnu dot org 2009-09-15 17:45 ---
See PR41353 for possible explanation. The last patch isn't complete there,
I'll post a fixed one once I do some further .debug_info analysis. Anyway,
that has nothing to do with this PR, a SYMBOL_REF for a tls symbo
--- Comment #17 from jv244 at cam dot ac dot uk 2009-09-15 17:56 ---
(In reply to comment #16)
> Does this PR 41347?
no, it doesn't.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41212
--- Comment #22 from davek at gcc dot gnu dot org 2009-09-15 17:57 ---
Created an attachment (id=18588)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18588&action=view)
slightly reworked patch
slightly reworked per hj's suggestion
--
davek at gcc dot gnu dot org changed:
--- Comment #21 from davek at gcc dot gnu dot org 2009-09-15 17:51 ---
(In reply to comment #19)
> Index: varasm.c
> ===
> --- varasm.c(revision 151703)
> +++ varasm.c(working copy)
> @@ -6420,6 +6420,8 @@ default_en
I compile an executable:
gcj --main=MyApp -findirect-dispatch --classpath=xxx MyApp.class -o my-app
When I run my-app and class required by MyClass to run is missing I see
Segmentation fault: 11.
It should be a meaningful message, not just segv.
FreeBSD-72.
--
Summary: segmentation
--- Comment #2 from karvonen dot jorma at gmail dot com 2009-09-15 20:13
---
Subject: Re: Make command failed with fortran when
compiling source
Yes, the directory was: /home/jorma/gnu/gcc-4.3.4
2009/9/15, pinskia at gcc dot gnu dot org :
>
>
> --- Comment #1 from pinski
I was compiling gcc-4.3.4.tar.bz2 package using gcc version 4.4.1, I think, but
for example g++ was some older version. So I decided to compile package that
included all compilers to get same version for all, and selected 4.3.4.
if /bin/sh ./libtool --tag=CC --mode=compile
/home/jorma/gnu/gcc-4.3.
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-09-15 20:16 ---
*** This bug has been marked as a duplicate of 35619 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #30 from pinskia at gcc dot gnu dot org 2009-09-15 20:16
---
*** Bug 41362 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 2009-09-15 20:16 ---
*** This bug has been marked as a duplicate of 35619 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #31 from pinskia at gcc dot gnu dot org 2009-09-15 20:16
---
*** Bug 41363 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35619
I was compiling gcc-4.3.4.tar.bz2 package using gcc version 4.4.1, I think, but
for example g++ was some older version. So I decided to compile package that
included all compilers to get same version for all, and selected 4.3.4.
if /bin/sh ./libtool --tag=CC --mode=compile
/home/jorma/gnu/gcc-4.3.
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-09-15 20:11 ---
Are you compiling in the source directory?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41362
--- Comment #10 from jakub at gcc dot gnu dot org 2009-09-15 20:12 ---
Subject: Bug 40677
Author: jakub
Date: Tue Sep 15 20:12:18 2009
New Revision: 151729
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=151729
Log:
PR target/41175
PR target/40677
* config
--- Comment #5 from jakub at gcc dot gnu dot org 2009-09-15 20:12 ---
Subject: Bug 41175
Author: jakub
Date: Tue Sep 15 20:12:18 2009
New Revision: 151729
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=151729
Log:
PR target/41175
PR target/40677
* config/
--- Comment #3 from kargl at gcc dot gnu dot org 2009-09-15 20:42 ---
Created an attachment (id=18589)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18589&action=view)
Reduced testcase
This is reduced testcase from the original source.
--
http://gcc.gnu.org/bugzilla/show_bug.
--- Comment #12 from lordhoto at gmail dot com 2009-09-15 21:24 ---
Happens for me too on Linux/AMD64 with:
gcc (Debian 4.3.4-2) 4.3.4
and
gcc (Debian 4.4.1-4) 4.4.1
It also happens with structs of sizes 3, 5 and 7 for me.
An easy (non-runtime) test case for different struct sizes c
--- Comment #4 from kargl at gcc dot gnu dot org 2009-09-15 21:49 ---
troutmask:sgk[231] gfc4x -c -O2 -finline-functions reduced.f90
reduced.f90: In function '__hsl_ma41_m_MOD_prininfo':
reduced.f90:12:0: error: type mismatch in component reference
integer(kind=4)[0:D.1361] * restrict
i
--- Comment #13 from a dot heider at gmail dot com 2009-09-15 21:54 ---
Still present on a recent GCC snapshot:
Johannes' Code compiled with "(Ubuntu 20090912-1ubuntu2) 4.5.0 20090912
(experimental) [trunk revision 151650]" and -O0 -DTEST_SIZE=5:
subq$16, %rsp
movq
--- Comment #1 from nemet at gcc dot gnu dot org 2009-09-15 22:18 ---
Subject: Bug 41349
Author: nemet
Date: Tue Sep 15 22:18:34 2009
New Revision: 151731
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=151731
Log:
PR bootstrap/41349
* reorg.c (redundant_insn): Do
--- Comment #2 from nemet at gcc dot gnu dot org 2009-09-15 22:20 ---
Was also happening on MIPS.
Fixed.
--
nemet at gcc dot gnu dot org changed:
What|Removed |Added
Compiling ruby 1.9.1 causes the error in the summary here are the details. This
happens with gcc-4.4.1 and gcc-4.3.3 but not with the shipped gcc-3.4.6
I can send a .i file if needed, but I'm not sure putting it in here would be a
good idea.
r...@ruby:/export/src/ruby-1.9.1-p243# gcc4
--- Comment #1 from heinz at licenser dot net 2009-09-15 22:51 ---
Created an attachment (id=18590)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18590&action=view)
the precompiled code that causes the problem.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41364
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-09-15 23:03 ---
>init2.c:37: assertion failed: ((64 - 0)+0) == (((64 - 0)+0)/8) * 8 &&
sizeof(mp_limb_t) == (((64 - 0)+0)/8)
This usually means the version of GMP/MPFR you have installed have bugs in
them. Did you build GCC yours
--- Comment #3 from heinz at licenser dot net 2009-09-15 23:17 ---
I build the GCC myself, the GMP not, it's a precompiled library. So I take it
it's a GMP problem? :) thanks, I'll see into compiling that tomorrow myself and
see if that fixes the problem.
--
http://gcc.gnu.org/bugzi
The gcc.dg/vect/vect-cond-[123].c tests started failing on IA64 Linux and HP-UX
starting with version 5150588, Bernd Schmidt's auto-increment changes. The
tests in question don't actually get vectorized and the bug can be reproduced
using just -O1 or -O2 optimization. (-mlp64 is also needed on HP
--- Comment #1 from sje at cup dot hp dot com 2009-09-15 23:40 ---
Created an attachment (id=18591)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18591&action=view)
test case that aborts when compiled with -O1 or -O2
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41365
The following C function:
unsigned long long foo( unsigned a, unsigned b )
{
return a | ((unsigned long long) b << 32 );
}
is actually a no-op on a 32-bit ARM target. Argument a is received in r0,
argument b is received in r1 and the returned long long's lower half should be
in r0 and the uppe
Hi all,
I am trying to port GCC on ARM (though GCC is already ported on ARM, this is
just as an exercise to learn how to port GCC to a new architecture.)
But I am unable to solve the error occurred(segmentation fault - program cc1)
while compiling a simple void main() program.
I used dummy values
--- Comment #3 from george at gcc dot gnu dot org 2009-09-16 04:49 ---
Additional investigation reveals that the ICE is triggered by OpenMP
conformance violation. There is a go to out of the body of an OMP parallel
region. Commenting out line 1105 of xrotate.f suppresses the ICE and le
--- Comment #4 from george at gcc dot gnu dot org 2009-09-16 05:00 ---
Created an attachment (id=18592)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18592&action=view)
Simplified test case that elicits the ICE
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41344
When the attached testcase is compiled with gcc-4.4.1 there are two aliasing
error messages issued, that appear to be wrong.
--
Summary: Erroneous aliasing rules violation messages are issued
Product: gcc
Version: 4.4.1
Status: UNCONFIRMED
S
--- Comment #1 from yuri at tsoft dot com 2009-09-16 05:12 ---
Created an attachment (id=18593)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18593&action=view)
testcase
command line: g++ -c -O5 -Wall pr.C
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41368
--- Comment #2 from yuri at tsoft dot com 2009-09-16 05:17 ---
gcc-4.3.1 didn't issue such warnings.
I wasn't able to minimize the testcase more.
Somehow if eee instance of Z is removed and just F::bbb() is called
messages disappear. This is strange since code around lines in qu
--- Comment #1 from ramana at gcc dot gnu dot org 2009-09-16 06:48 ---
This is a forum to report bugs on existing releases of GCC or the current
development version. Queries regarding porting GCC should be taken on
g...@gcc.gnu.org.
In this case you might find it useful to look at some
91 matches
Mail list logo
