Quoting Joseph S. Myers jos...@codesourcery.com:
If you want to have documentation extracted from source files, you need to
engage with the SC and FSF at an early stage to get suitable license
exception wording to permit the relevant text to be used in the manuals as
well as the main (GPL)
Hi,
I am working on a micro controller and trying to port gcc(4.3.2) for it.
Not the compiling process runs into the following error:
a.c: In function 'task':
a.c:150: error: unrecognizable insn:
(insn 479 478 320 19 a:381 (set (reg:SI 12 a12)
(plus:SI (mult:SI (reg:SI 9 a9 [204])
Your instruction is likely too specific to be picked up by GCC.
You may use an intrinisc for it.
Bingfeng
-Original Message-
From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On
Behalf Of fanqifei
Sent: 12 January 2010 12:50
To: gcc@gcc.gnu.org
Subject: GCC-How does
2010/1/13 Bingfeng Mei b...@broadcom.com:
Your instruction is likely too specific to be picked up by GCC.
You may use an intrinisc for it.
Bingfeng
but insv is a standard pattern name.
the semantics of expression x= (x0xFF00) | ((i16)0x00FF);
is exactly what insv can do.
I all tried
OOPs, I don't know that. Anyway, I won't count on GCC to
reliably pick up these complex patterns. In our port, we
implemented clz/ffs/etc as intrinsics though they are present as
standard patterns.
Bingfeng
-Original Message-
From: fanqifei [mailto:fanqi...@gmail.com]
Sent: 13
Hi,
On Wed, 9 Dec 2009, H.J. Lu wrote:
So, IMO we have two sensible proposals:
(a) specify that bits 7:1 must be zero
(b) specify that bits 31:1 must be zero
I uploaded sources and object files generated by gcc 4.4, icc 11.1
and Sun Studio 12 Update 1 at -O to:
Hi,
On Sun, 10 Jan 2010, Dave Korn wrote:
Ok. So if I had four ints, and I wanted to cast the pointers to char
and compare them as 16 chars, that would be OK, because the chars would
alias the ints; but in this case, where they started as chars and I cast
them to ints, those ints don't
On Wed, 13 Jan 2010, Joern Rennecke wrote:
Quoting Joseph S. Myers jos...@codesourcery.com:
If you want to have documentation extracted from source files, you need to
engage with the SC and FSF at an early stage to get suitable license
exception wording to permit the relevant text to be
Adding and maintaining target hooks is unnecessarily hard at the moment,
because the definition is spread across three places, and these are supposed
to be kept in sync. The code is necessarily kept more or less in sync because
it generally fails to compile or work when it isn't - and if someone
Quoting Joseph S. Myers jos...@codesourcery.com:
Please note that your initial change to implement automatic doc extraction
should not result in any changes to the Texinfo content of the manual.
Such fixes should all go in either before or after the automatic doc
extraction change, but not at
On Wed, 13 Jan 2010, Joern Rennecke wrote:
Duplicating all these changes separately by hand seems nigh impossible.
I think the best approach is then to take the auto-generated tm.texi as
the new tm.texi, and packages it up as a patch together with the
struct member / hook name changes that I
Hi Jan,
Can you take a look at this patch when you find the time ? This is
being blocked needing an approval from a x86 backend maintainer and
you are the only one listed in the MAINTAINERS file.
Thanks,
-Sriraman.
On Tue, Oct 6, 2009 at 2:56 PM, Paolo Bonzini bonz...@gnu.org wrote:
On
On Sun, 2010-01-10 at 15:46 +0100, Eric Botcazou wrote:
The aliasing rules treat char specially because char is a bit like a
poor main's void.
Not symmetrically though, only for the type of the lvalue expression used to
access the object (C99 6.5.7).
BTW in Ada if one uses address clause
We use TLS relocated symbols to create thread-local symbols
in the GCC UPC compiler, and have run into an issue illustrated
by the following program, on a test case that defines a
common symbol in several files, and uses it in a single file.
The following program fails to link, with multiple
Joern Rennecke wrote:
References: 4ae6e471.4020...@starynkevitch.net
mcr3a54lwb4@dhcp-172-17-9-151.mtv.corp.google.com
4ae70c5e.4050...@starynkevitch.net
84fc9c000910270839v2d9efe0dw829c8647f361c...@mail.gmail.com
4ae7164d.9010...@starynkevitch.net
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
IMHO it would be a godd idea to add the following two configure options to ppl
configure:
--with-gmp-include=DIR GMP include directory
--with-gmp-lib=DIR GMP lib directory
On 64-bit Linux systems you have the libraries in lib64 instead of
On Wed, Jan 13, 2010 at 14:55, Rainer Emrich rai...@emrich-ebersheim.de wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
IMHO it would be a godd idea to add the following two configure options to ppl
configure:
--with-gmp-include=DIR GMP include directory
--with-gmp-lib=DIR GMP
BTW in Ada if one uses address clause to overlay a 16 character string
and a 4 4-byte integer array (both aliased) which is then accessed what
can we expect GCC-wise? Are we safe from aliasing related optimizations?
Yes, we use a big hammer to make sure 'Address is immune to these issues.
--
Gary Funck g...@intrepid.com writes:
We use TLS relocated symbols to create thread-local symbols
in the GCC UPC compiler, and have run into an issue illustrated
by the following program, on a test case that defines a
common symbol in several files, and uses it in a single file.
The only way
2010/1/13 Bingfeng Mei b...@broadcom.com:
OOPs, I don't know that. Anyway, I won't count on GCC to
reliably pick up these complex patterns. In our port, we
implemented clz/ffs/etc as intrinsics though they are present as
standard patterns.
Bingfeng
Could you please show me the path of the
On 01/13/10 17:15:10, Ian Lance Taylor wrote:
[...]
Otherwise TLS variables are generated as definitions rather than as
common variables.
Why do you want them to be common?
For GCC/UPC compiled programs there are two compilation modes: 1) Each
UPC thread is implemented as a full process,
--- Comment #14 from spop at gcc dot gnu dot org 2010-01-13 07:59 ---
Fixed also in the 4.4 branch.
--
spop at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from spop at gcc dot gnu dot org 2010-01-13 08:06 ---
Fixed: there is only one graphite testcase failing in trunk
FAIL: g++.dg/graphite/pr42130.C execution test
for which we have a P1 bug.
--
spop at gcc dot gnu dot org changed:
What|Removed
--- Comment #3 from burnus at gcc dot gnu dot org 2010-01-13 08:44 ---
(In reply to comment #2)
A related issue has been reported here
http://groups.google.com/group/comp.lang.fortran/browse_frm/thread/ddc211f2987326b8#
That example is invalid and correctly rejected; if one makes it
--- Comment #11 from ebotcazou at gcc dot gnu dot org 2010-01-13 08:45
---
Jan, are you there?
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from dodji at gcc dot gnu dot org 2010-01-13 09:21 ---
Subject: Re: Aggregate initialization requires copy
constructor
On Tue, Jan 12, 2010 at 11:33:56PM -, paolo dot carlini at oracle dot com
wrote:
Since we are talking of etiquette, and with the obvious caveats
--- Comment #10 from irar at il dot ibm dot com 2010-01-13 09:35 ---
Yes, I understand that we can't assume that an access is aligned if we can't
prove it's aligned. I don't understand how we can prove that a COMPONENT_REF is
aligned, i.e., if there is a way to check if a struct is
The move_by_pieces() function incorrectly works on targets with enabled
PUSH_ARGS that support post-increment loads. To reproduce the bug, the
following code should be compiled:
struct test { int a, b, c, d, e, f; } //Enough fields to pass structure in
stack
void func2(test copy);
void func1(test
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42715
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-01-13 09:55 ---
struct QVectorData {
static QVectorData shared_null;
};
template typename T class QVector {
union {
QVectorData *d;
};
public:
inline QVector() : d(QVectorData::shared_null) { }
inline
--- Comment #7 from ebotcazou at gcc dot gnu dot org 2010-01-13 10:03
---
This patch fixes the bug.
Do you think if this patch is favorable? If yes, I will do dejagnu
test and send it to gcc-patches for review.
The patch is probably correct, but I'd ditch hunks #1 and #3. In
--- Comment #5 from jakub at gcc dot gnu dot org 2010-01-13 10:06 ---
I believe this is a dupe of PR42604, at least the testcase in there comes from
http://bugzilla.redhat.com/show_bug.cgi?id=552073
which is also ICE on dcraw.cc in the same function.
*** This bug has been marked as a
--- Comment #10 from jakub at gcc dot gnu dot org 2010-01-13 10:07 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #7 from jakub at gcc dot gnu dot org 2010-01-13 10:08 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-01-13 10:08 ---
Subject: Bug 42678
Author: rguenth
Date: Wed Jan 13 10:07:47 2010
New Revision: 155853
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155853
Log:
2010-01-13 Richard Guenther rguent...@suse.de
PR
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-01-13 10:15 ---
HWI32 issue? It doesn't reproduce for me on x86_64 with -m32.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-01-13 10:20 ---
We have
ASSERT_EXPR g_13.1_7, g_13.1_7 == g_13.1_7
huh.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Dear all,
I am trying to build gcc using mingw on my new win64 machine.
I have downloaded the latest mingw code
(mingw-w64-trunk-snapshot-20091222.tar.bz2) that is aimed to port gcc and
mingw to win64 (as far as I understand). I followed the instructions in
mingw-w64-howto-build.txt.
However I
--- Comment #6 from jamborm at gcc dot gnu dot org 2010-01-13 11:07 ---
Patch posted to the mailing list:
http://gcc.gnu.org/ml/gcc-patches/2010-01/msg00562.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42703
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-01-13 11:08 ---
Because at gimplification time we simplify *g_13 == g_13 which is not folded
by fold to g_13 == g_13 but the gimplifier doesn't re-fold parents of folded
expressions. And we never fold that comparison again.
--
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-01-13 11:12 ---
Created an attachment (id=19568)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19568action=view)
somewhat reduced testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42715
--
irar at il dot ibm dot com changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |irar at il dot ibm dot com
|dot org
--- Comment #13 from rguenth at gcc dot gnu dot org 2010-01-13 11:37
---
Single-file testcase:
subroutine loop_list(list)
integer, intent(in), dimension(:) :: list
integer :: ii
!$ integer :: chunk_size
!$ chunk_size = 4
!$OMP PARALLEL DO
--- Comment #4 from jakub at gcc dot gnu dot org 2010-01-13 11:56 ---
More reduced testcase (-m32 -g -O2 -fpic):
struct A { unsigned a1; char a2[15]; };
struct B { long b1; unsigned char b2; long b3; };
struct C { void *c1; unsigned c2; unsigned c3; };
static struct A v1;
struct A
--- Comment #12 from matz at gcc dot gnu dot org 2010-01-13 12:08 ---
The ABI (http://www.x86-64.org/documentation/abi.pdf) now contains this
language:
When a value of type \code{_Bool} is returned or passed in a register or
on the stack, bit 0 contains the truth
--- Comment #5 from jakub at gcc dot gnu dot org 2010-01-13 12:09 ---
Looks like some var-tracking bug. We have:
(insn:TI 108 37 38 3 (set (reg/f:SI 2 cx [93]) (const:SI (unspec:SI
[(symbol_ref:SI (v1) [flags 0x2] var_decl 0x7fc316f38000 v1)] 1))) 247
{*lea_1} (expr_list:REG_EQUAL
--- Comment #2 from mikpe at it dot uu dot se 2010-01-13 12:14 ---
With a recent gcc-4.4 I see this -O1/-O2 difference on i686 but not powerpc64.
On i686 gcc-4.3 also seems affected (-O0 vs -O1), but 4.2 and 4.1 seem Ok.
--
mikpe at it dot uu dot se changed:
What
Building the GCC compiler for the language Fortran fails in bootstrapping
mode. Strangely, I am able to build the Fortran compiler in native
non-bootstrapping mode.
If I do start the build in bootstrapping mode, it finally fails with the
following error (I will attach the complete log):
--- Comment #1 from Roger dot Jeurninck at home dot nl 2010-01-13 12:25
---
Created an attachment (id=19569)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19569action=view)
libgfortran/config.log
file containing the log (libgfortran) of the failing bootstrap build
--
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-01-13 12:35 ---
Mine.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from jakub at gcc dot gnu dot org 2010-01-13 12:39 ---
Indeed, looks like HWI32 issue.
Smaller testcase:
static unsigned long long
foo (unsigned long long x, unsigned long long y)
{
return x / y;
}
static int a, b;
int
main (void)
{
unsigned long long c = 1;
b ^=
--- Comment #2 from burnus at gcc dot gnu dot org 2010-01-13 12:50 ---
No direct idea, but so far almost all libgfortran/configure issues were due to
problems with GMP/MPFR - can you check that the correct library is used?
And can you post a backtrace of the the failing gfortran run?
--- Comment #4 from sezeroz at gmail dot com 2010-01-13 12:56 ---
gcc-3.4.6, 4.3.2 and 4.4.3 always print 1 with or without -m32 for both -O1 and
-O2 on x86_64 (fedora 10). On i686 (fedora 9), gcc-3.3.6 and 3.4.6 always
prints 1, gcc-4.3.0 (as shipped by fedora) always prints 0, and
Possibly related to BUG 39799
The attached very simple test case does not produce any warning on build, using
'-W -Wall -Wextra -O3 -Wuninitialized -Werror'.
If the condition is not seen as false at build time, the compiler does not
complaint.
--
Summary: Trivial uninitialized
--- Comment #1 from roche+gccbugs at exalead dot com 2010-01-13 13:14
---
Created an attachment (id=19570)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19570action=view)
Test case that should produce a warning with -O -Wuninitialized
--
seen with trunk 20100112
$ g++ -c -g -O2 -c mainwindow.ii
mainwindow.cc: In member function 'void MainWindow::preprocess()':
mainwindow.cc:273:13: warning: deprecated conversion from string constant to
'char*'
mainwindow.cc:274:13: warning: deprecated conversion from string constant to
'char*'
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-01-13 13:16 ---
This:
/* We are sure that for every live PHI we are seeing control dependent
BB.
This means that we can look up the end of control dependent path
leading
to the PHI itself. */
--- Comment #1 from doko at ubuntu dot com 2010-01-13 13:17 ---
Created an attachment (id=19571)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19571action=view)
preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42725
--- Comment #14 from jakub at gcc dot gnu dot org 2010-01-13 13:27 ---
Subject: Bug 41371
Author: jakub
Date: Wed Jan 13 13:26:47 2010
New Revision: 155858
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155858
Log:
PR debug/41371
* var-tracking.c
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-01-13 13:31 ---
Subject: Bug 42716
Author: rguenth
Date: Wed Jan 13 13:31:13 2010
New Revision: 155859
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155859
Log:
2010-01-13 Richard Guenther rguent...@suse.de
PR
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-01-13 13:31 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-01-13 13:39 ---
The uninitialized use is optimized away before we would warn about it.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from faure at kde dot org 2010-01-13 13:40 ---
I agree with Tom, the new behavior of -Wconversion is useless with bitfields,
this should be fixed so that we can use -Wconversion again.
Why is this bug on WAITING?
--
faure at kde dot org changed:
What
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-01-13 13:42 ---
Confirmed. 4.4 accepts the code, reducing based on that.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
The 4.4.2 documentation states that the -fno-common option specifies that the
compiler should place uninitialized global variables in the __data__ section of
the object file.
This is different from action, where -fno-common forces gcc to place
uninitialized global variables in the BSS section of
--- Comment #14 from singler at kit dot edu 2010-01-13 13:53 ---
(In reply to comment #13)
This code is compiled with -fno-exceptions, could that be a problem?
No, that should rather help.
Still, it is very difficult to debug this. Is there at least a way to access
clamd's stdout
--- Comment #13 from joseph at codesourcery dot com 2010-01-13 13:55
---
Subject: Re: Gcc doesn't follow x86-64 psABI on _Bool
On Wed, 13 Jan 2010, matz at gcc dot gnu dot org wrote:
The ABI (http://www.x86-64.org/documentation/abi.pdf) now contains this
language:
Any chance you
While looking to see that my daily build on an older i686 machine was still
working, I discover this. The failure started on 12-7-2009. This is with
trunk updated daily. The machine is running fedora 8.
checking for i686-pc-linux-gnu-gcc... /home/jerry/gcc/objdir/./gcc/xgcc
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2010-01-13 13:57
---
Created an attachment (id=19572)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19572action=view)
config.log
I don't see anything obvious.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42727
--- Comment #2 from hjl dot tools at gmail dot com 2010-01-13 14:07 ---
(In reply to comment #1)
Created an attachment (id=19572)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19572action=view) [edit]
config.log
I don't see anything obvious.
Did you have g++ installed?
---
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2010-01-13 14:32
---
g++ was not installed. I have now installed it and will try again and report
back here tonight. Thanks
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42727
--- Comment #14 from matz at gcc dot gnu dot org 2010-01-13 14:33 ---
Yeah, I started to use micro version numbers, but I can't write to the html
file on that webserver, only to the subdirectory containing the PDFs. See
http://www.x86-64.org/documentation/
for a listing. The current
--- Comment #15 from hjl dot tools at gmail dot com 2010-01-13 14:45
---
We have Google groups for gABI and i386 psABI. Should I create an x86-64
psABI group?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42324
--- Comment #16 from matz at gcc dot gnu dot org 2010-01-13 14:49 ---
We have a mailing list already, I don't think we need another one.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42324
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-01-13 15:01 ---
Doesn't work.
FAIL: gcc.c-torture/execute/20010129-1.c compilation, -O3 -fomit-frame-pointer
(internal compiler error)
--
rguenth at gcc dot gnu dot org changed:
What|Removed
--- Comment #12 from ro at CeBiTec dot Uni-Bielefeld dot DE 2010-01-13
15:03 ---
Subject: Re: [4.5 regression] ICE in function_and_variable_visibility breaks
Ada bootstrap
--- Comment #10 from simon at pushface dot org 2010-01-11 22:12 ---
I have (locally!) rolled back the
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-01-13 15:04 ---
Subject: Bug 42705
Author: rguenth
Date: Wed Jan 13 15:04:38 2010
New Revision: 155861
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155861
Log:
2010-01-13 Richard Guenther rguent...@suse.de
PR
--- Comment #5 from jakub at gcc dot gnu dot org 2010-01-13 15:05 ---
The bug is in add_double_with_sign it seems.
319int
320add_double_with_sign (unsigned HOST_WIDE_INT l1, HOST_WIDE_INT h1,
321 unsigned HOST_WIDE_INT l2, HOST_WIDE_INT h2,
322 unsigned HOST_WIDE_INT *lv,
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-01-13 15:05 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #3 from hjl dot tools at gmail dot com 2010-01-13 15:07 ---
It is caused by revision 155347:
http://gcc.gnu.org/ml/gcc-cvs/2009-12/msg00491.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #6 from rguenther at suse dot de 2010-01-13 15:08 ---
Subject: Re: possible integer wrong code bug
On Wed, 13 Jan 2010, jakub at gcc dot gnu dot org wrote:
--- Comment #5 from jakub at gcc dot gnu dot org 2010-01-13 15:05 ---
The bug is in
--- Comment #7 from rguenth at gcc dot gnu dot org 2010-01-13 15:10 ---
http://gcc.gnu.org/ml/gcc-cvs/2009-03/msg00226.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42721
Command line:
gcc -O1 -fgraphite-identity -fcompare-debug -c testcase.c
Tested revisions:
r155833 - crash
r155363 - crash
r154886 - crash
r153685 - crash
Output:
$ /mnt/svn/gcc-trunk/binary-155833-lto/bin/gcc -O1 -fgraphite-identity
-fcompare-debug -c testcase.c
gcc: testcase.c: -fcompare-debug
--- Comment #1 from zsojka at seznam dot cz 2010-01-13 15:15 ---
Created an attachment (id=19573)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19573action=view)
reduced testcase
Command line:
gcc -O1 -fcompare-debug -c pr42728.c
Now I found out, -fgraphite-identity is not needed
--
dodji at gcc dot gnu dot org changed:
What|Removed |Added
CC|dseketel at redhat dot com |
AssignedTo|unassigned at gcc dot gnu |dodji at gcc dot gnu
--- Comment #7 from jamborm at gcc dot gnu dot org 2010-01-13 15:37 ---
Subject: Bug 42703
Author: jamborm
Date: Wed Jan 13 15:37:37 2010
New Revision: 155863
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155863
Log:
2010-01-13 Martin Jambor mjam...@suse.cz
PR
--- Comment #8 from jamborm at gcc dot gnu dot org 2010-01-13 15:38 ---
Fixed.
--
jamborm at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #5 from jamborm at gcc dot gnu dot org 2010-01-13 15:40 ---
Patch posted to the mailing list:
http://gcc.gnu.org/ml/gcc-patches/2010-01/msg00575.html
I can also confirm it fixes the same problem in the preprocessed
source from PR 42707.
--
jamborm at gcc dot gnu dot org
--- Comment #3 from kargl at gcc dot gnu dot org 2010-01-13 15:41 ---
Are you trying to build the compiler within
the gcc source tree?
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from jakub at gcc dot gnu dot org 2010-01-13 16:09 ---
Created an attachment (id=19574)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19574action=view)
gcc45-pr42721.patch
This is what I'm going to bootstrap/regtest now.
Regarding fallouts, I believe this particular
Command line:
gcc -O1 -fcompare-debug -fgraphite-identity -c testcase.c
Tested revisions:
r155833 - crash
r154886 - crash
r153685 - crash
Output:
$ /mnt/svn/gcc-trunk/binary-155833-lto/bin/gcc -O1 -fcompare-debug
-fgraphite-identity -c testcase.c
gcc: testcase.c: -fcompare-debug failure
--- Comment #14 from rguenth at gcc dot gnu dot org 2010-01-13 16:21
---
I am testing the workaround
Index: gcc/gimple.c
===
--- gcc/gimple.c(revision 155860)
+++ gcc/gimple.c(working copy)
@@ -3707,8
--- Comment #1 from zsojka at seznam dot cz 2010-01-13 16:22 ---
Created an attachment (id=19575)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19575action=view)
reduced testcase
Command line:
gcc -O1 -fcompare-debug -fgraphite-identity -c pr42729.c
--
--- Comment #3 from manu at gcc dot gnu dot org 2010-01-13 16:33 ---
CCP removing the uninitialized value.
*** This bug has been marked as a duplicate of 18501 ***
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--
aph at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #3 from hjl dot tools at gmail dot com 2010-01-13 16:45 ---
It is caused by revision 154413:
http://gcc.gnu.org/ml/gcc-cvs/2009-11/msg00634.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42714
--- Comment #4 from jamborm at gcc dot gnu dot org 2010-01-13 16:47 ---
I'm already testing a fix.
--
jamborm at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from spop at gcc dot gnu dot org 2010-01-13 17:00 ---
The fix for this PR produces an ICE in 434.zeusmp:
+ /home/seb/gcc/graphite/usr/bin/gfortran -c -g -O2 -DSPEC_CPU_LP64 -o pdv_d.o
pdv_d.f
pdv_d.f: In function pdv_d:
pdv_d.f:89:0: error: definition in block 40 does
Seen on Ubuntu 9.10.
reg...@john-home:~/volatile/bugs/tmp255$ current-gcc -Os small.c
small.c: In function foo:
small.c:14:1: error: non-trivial conversion at assignment
unsigned int *
void *
# .MEM_4 = VDEF .MEM_3(D)
u.pa = 0B;
small.c:14:1: internal compiler error: verify_stmts failed
Please
seen with trunk 20100113
$ g++ -g -O2 -c kanjisaver.ii
kanjisaver.cpp: In member function 'void kanjisaver::draw_kanji()':
kanjisaver.cpp:328:48: error: cannot call constructor 'QPoint::QPoint' directly
kanjisaver.cpp:328:48: note: for a function-style cast, remove the redundant
'::QPoint
1 - 100 of 216 matches
Mail list logo
