--- Comment #4 from zsojka at seznam dot cz 2010-03-26 07:13 ---
Created an attachment (id=20203)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20203&action=view)
different problem with -m96bit-long-double
$ /mnt/svn/gcc-trunk/binary-157723-lto/bin/gcc -m96bit-long-double pr43526-
--- Comment #5 from zsojka at seznam dot cz 2010-03-26 07:23 ---
Created an attachment (id=20204)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20204&action=view)
another problem with -m96bit-long-double (last one)
$ /mnt/svn/gcc-trunk/binary-157723-lto/bin/gcc -m96bit-long-double
--
zsojka at seznam dot cz changed:
What|Removed |Added
Severity|normal |minor
Known to fail|4.1.2 4.2.4 4.3.4 4.4.3 |3.3.6 3.4.6 4.1.2 4.2.
--- Comment #8 from developer at sandoe-acoustics dot co dot uk 2010-03-26
07:47 ---
(In reply to comment #7)
> Why
>
> ---
> Propchange: trunk/gcc/testsuite/objc-obj-c++-shared/Object1-implementation.h
> ('svn:executable' added)
>
> Propchange: trunk/gcc/testsuite/objc-ob
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-03-26 07:49 ---
Well -Wshadow warns about shadowing variables. But it is hard to do what you
are asking for since parsing and preprocessing is separate passes.
--
pinskia at gcc dot gnu dot org changed:
What|Rem
--- Comment #9 from developer at sandoe-acoustics dot co dot uk 2010-03-26
08:09 ---
(In reply to comment #8)
> (In reply to comment #7)
> > Why
my first reply was rubbish (should have coffee before email).
This is clearly an error on my part - in fact, looking at my trail here, they
--- Comment #1 from ubizjak at gmail dot com 2010-03-26 09:03 ---
Looks like a wrong assert to me. The compilation works without problems when
assert is removed and the result looks sane for both -m32 and -m64 (you have to
provide your own __chkstk for -mstack-arg-probe, of course).
SVN
--- Comment #4 from rearnsha at gcc dot gnu dot org 2010-03-26 09:05
---
This is a case where we have a 'variable length array' declaration but where
the variable is really const and well-known at compile time. However, we still
end up with it being 'variably sized' at rtl expand time.
--- Comment #1 from ubizjak at gmail dot com 2010-03-26 09:14 ---
Confirmed.
#0 fancy_abort (file=0xd1ad78 "../../gcc-svn/trunk/gcc/tree.c", line=6198,
function=0xd1f441 "tree_low_cst")
at ../../gcc-svn/trunk/gcc/diagnostic.c:762
#1 0x008fd17d in tree_low_cst (t=0x2af
--- Comment #4 from dodji at gcc dot gnu dot org 2010-03-26 09:21 ---
Subject: Bug 43327
Author: dodji
Date: Fri Mar 26 09:20:58 2010
New Revision: 157745
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157745
Log:
Fix for PR c++/43327
gcc/cp/ChangeLog:
PR c++/43327
--- Comment #2 from ubizjak at gmail dot com 2010-03-26 09:27 ---
There is a mismatch in a guard expression. Following patch fixes ICE for me
(I'm not sure if it makes any sense, though):
Index: stor-layout.c
===
--- stor-
--- Comment #6 from dodji at gcc dot gnu dot org 2010-03-26 09:30 ---
Fixed in 4.5
The bootstrap failure should be fixed by
http://gcc.gnu.org/viewcvs?view=revision&revision=157743
--
dodji at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #20 from dodji at gcc dot gnu dot org 2010-03-26 09:31 ---
Should be fixed in 4.5 by the commit for PR c++/43206.
--
dodji at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #5 from dodji at gcc dot gnu dot org 2010-03-26 09:33 ---
Fixed in 4.5.
--
dodji at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGN
On Thu, 25 Mar 2010, Sebastian Pop wrote:
> On Wed, Mar 24, 2010 at 16:35, howarth at nitro dot med dot uc dot edu
> wrote:
> >> Fixed.
> >>
> >> Please use ftp://gcc.gnu.org/pub/gcc/infrastructure/cloog-ppl-0.15.9.tar.gz
> >>
> >
> > Shouldn't the required cloog-ppl version in configure be bumpe
--- Comment #33 from rguenther at suse dot de 2010-03-26 09:58 ---
Subject: Re: [4.5 Regression][graphite]-fgraphite-identity
miscompiles air.f90
On Thu, 25 Mar 2010, Sebastian Pop wrote:
> On Wed, Mar 24, 2010 at 16:35, howarth at nitro dot med dot uc dot edu
> wrote:
> >>
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-03-26 10:05 ---
(In reply to comment #2)
> There is a mismatch in a guard expression. Following patch fixes ICE for me
> (I'm not sure if it makes any sense, though):
>
> Index: stor-layout.c
>
--- Comment #9 from jakub at gcc dot gnu dot org 2010-03-26 10:28 ---
We call get_alias_set on a 1 bit precision unsigned type with no alias set.
This calls lang_hooks.get_alias_set, which does c_common_signed_type. With -g
it returns a type with alias set computed, but with -g0 that ty
--- Comment #10 from jakub at gcc dot gnu dot org 2010-03-26 10:42 ---
In particular, for -g0 the alias set of that unsigned 1 bit type actually
changes.
This is on the #c1 testcase, with
-g -fcompare-debug=-gtoggle pr43516.c -O2 -fdump-final-insns=/tmp/1
resp.
-g0 -fcompare-debug=-gtogg
--- Comment #4 from ebotcazou at gcc dot gnu dot org 2010-03-26 10:54
---
> There is a mismatch in a guard expression. Following patch fixes ICE for me
> (I'm not sure if it makes any sense, though):
No, it isn't correct, because:
/* Return 1 if T is an INTEGER_CST that can be manipu
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-03-26 10:57 ---
I see
(gdb) b error
Breakpoint 5 at 0x6a072d: file /space/rguenther/src/svn/trunk/gcc/diagnostic.c,
line 629.
(gdb) run
Breakpoint 5, error (
gmsgid=0x11a45c0 "type mismatch between an SSA_NAME and its symbol")
--- Comment #11 from jakub at gcc dot gnu dot org 2010-03-26 11:03 ---
Ah, apparently the type returned by c_common_signed_type -> ... ->
build_nonstandard_integer_type is not referenced from anywhere anymore during
FRE, except from
static GTY ((if_marked ("type_hash_marked_p"), param_is
--- Comment #7 from paul dot richard dot thomas at gmail dot com
2010-03-26 11:08 ---
Subject: Re: [4.5 Regression] type mismatch
between an SSA_NAME and its symbol with -O3
Richi, Thanks for intervening. Paul
On Fri, Mar 26, 2010 at 11:57 AM, rguenth at gcc dot gnu dot or
with the gcc-4.5-20100325 (and predecessors) I am facing this kind of
builderrors when cross-building:
...
make[4]: Entering directory
`/users/rtems/src/rpms/BUILD/rtems-4.11-h8300-rtems4.11-gcc-4.5.0/build/h8300-rtems4.11/h8300h/libgcc'
# If this is the top-level multilib, build all the other
# mu
--- Comment #5 from ubizjak at gmail dot com 2010-03-26 11:22 ---
(In reply to comment #4)
> > There is a mismatch in a guard expression. Following patch fixes ICE for me
> > (I'm not sure if it makes any sense, though):
>
> No, it isn't correct, because:
>
> /* Return 1 if T is an IN
Reported and confirmed in the fortran mailing list.
test case, trimmed down by Janus:
implicit none
type myobj
real :: myarray(10)
end type myobj
real:: array(10)
type(myobj) :: obj
call myfunc(obj,array)
contains
subroutine myfunc(this, array)
type(my
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-03-26 11:45 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Severity|minor
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Severity|minor |enhancement
Keywords||missed-op
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-03-26 11:49 ---
It's disabled on a function-by-function basis which looks valid.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43515
--- Comment #6 from ebotcazou at gcc dot gnu dot org 2010-03-26 11:50
---
> If this is indeed required for tree_low_cst (which is defined as signed HWI!),
> then the patch that reverses the semantics of my previous patch works as well.
>
> Index: stor-layout.c
> ===
--- Comment #12 from rguenth at gcc dot gnu dot org 2010-03-26 11:50
---
Not a real bug. P4.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Pr
A bootstrap of current mainline (20100322) fails in stage 2 linking cc1:
libbackend.a(ggc-page.o): In function `ggc_alloc_stat':
/vol/gcc/src/hg/trunk/local/gcc/ggc-page.c:1160: undefined reference to
`__ctzdi2'
and many many more.
The function is present in the linked libgcc.a, but marked hidde
--- Comment #5 from bernds at codesourcery dot com 2010-03-26 12:01 ---
http://gcc.gnu.org/ml/gcc-patches/2010-03/msg01235.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40603
In the following code:
/**
* File : a.c
**/
#include
int main()
{
int a = 1 ;
printf( "%d\n" , + + + a );
}
When compiled as:
gcc -o a a.c
The extra '+' signs are not shown as error. The program compiles and executes
as if the extra '+' signs did not ex
At r157738, the testsuite testcase objc.dg/objc-gc-4.m -fgnu-runtime now fails
with an internal compiler error on x86_64-apple-darwin10...
Executing on host:
/sw/src/fink.build/gcc45-4.4.999-20100325/darwin_objdir/gcc/xgcc
-B/sw/src/fink.build/gcc45-4.4.999-20100325/darwin_objdir/gcc/
/sw/src/fink
--- Comment #1 from brutusjees4 at gmail dot com 2010-03-26 12:09 ---
Created an attachment (id=20205)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20205&action=view)
Extra '+' signs are not reported as error.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43534
--- Comment #2 from ktietz at gcc dot gnu dot org 2010-03-26 12:14 ---
The assert here is just in respect to comment "Only valid for Win32.". Just
win32 targets are providing for gcc a __chkstk implementation. So I think it
was the reason for this assert. But AFAICS there is no other rea
--- Comment #1 from developer at sandoe-acoustics dot co dot uk 2010-03-26
12:16 ---
I believe that this test was not previously carried out with "-fgnu-runtime" .
So, technically I think it's a failed New test rather than a regression (but I
will triple-check a little later).
In any
--- Comment #2 from howarth at nitro dot med dot uc dot edu 2010-03-26
12:20 ---
A backtrace shows...
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x
assemble_external (decl=0x0) at ../../gcc-4.5-20100325/gcc/
--- Comment #2 from steven at gcc dot gnu dot org 2010-03-26 12:24 ---
No, the user should be able to say "do this" and then the compiler should do
so. Right now the flag to enable BB-reorder has no effect at -Os, and that is a
bug.
--
steven at gcc dot gnu dot org changed:
--- Comment #3 from rahul at icerasemi dot com 2010-03-26 12:25 ---
The following test in 'rest_of_handle_reorder_blocks'
if ((flag_reorder_blocks || flag_reorder_blocks_and_partition)
&& optimize_function_for_speed_p (cfun))
{ ... }
suggests when optimize_size is true reordering
--- Comment #2 from falk at debian dot org 2010-03-26 12:28 ---
Unary plus is allowed in standard C. Use -Wtraditional to get a warning.
--
falk at debian dot org changed:
What|Removed |Added
In the following test1() code the SUCCESS branch is never reached when I
optimize the code with -O2. If I add -O2 -fno-tree-vrp or just use -O0, the
SUCCESS branch is executed as expected.
int test1()
{
int vint = 1, *v, i;
QVector vect;
vect.push_back(&vint);
vect.push_back(&vint);
vec
--- Comment #1 from juha dot kallioinen at nokia dot com 2010-03-26 12:39
---
Created an attachment (id=20206)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20206&action=view)
preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43537
--- Comment #2 from juha dot kallioinen at nokia dot com 2010-03-26 12:40
---
Created an attachment (id=20207)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20207&action=view)
gcc -v output
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43537
The file config/mt-gnu currently defines CXXFLAGS_FOR_TARGET =
$(CXXFLAGS) -D_GNU_SOURCE. To me, it seems that it should be +=
-D_GNU_SOURCE (like most of the other frags). Otherwise, I cannot
override the CXXFLAGS without overriding CXXFLAGS_FOR_TARGET, etc.
--
Summary: config/mt-g
--- Comment #11 from dominiq at lps dot ens dot fr 2010-03-26 12:45 ---
Closing as fixed. Thanks for the work.
--
dominiq at lps dot ens dot fr changed:
What|Removed |Added
---
--- Comment #7 from rguenth at gcc dot gnu dot org 2010-03-26 12:57 ---
(In reply to comment #6)
> > If this is indeed required for tree_low_cst (which is defined as signed
> > HWI!),
> > then the patch that reverses the semantics of my previous patch works as
> > well.
> >
> > Index:
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-03-26 13:01 ---
Well, it's like you say -ftree-pre but a partial redundancy is not removed
because it was on a cold path. bb-reorder should probably take into account
size/speed optimization in more general and the optimize_functio
--- Comment #10 from hjl dot tools at gmail dot com 2010-03-26 13:08
---
(In reply to comment #9)
>
> > > Do they have to be executable?
>
> No.
>
Fixed.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--
--- Comment #2 from kretz at kde dot org 2010-03-26 13:13 ---
BTW, I think you should consider this as a bug, not enhancement. Because if the
shift argument is >= (1 << 32) the result of _mm_sll_epi64 differs from the
expected result.
Thus the code GCC generates could potentially hide a
--- Comment #13 from jakub at gcc dot gnu dot org 2010-03-26 13:13 ---
Created an attachment (id=20208)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20208&action=view)
gcc45-pr43516-1.patch
One possible fix, just don't print MEM alias sets in -fdump-final-insns= dump.
--
htt
--- Comment #14 from jakub at gcc dot gnu dot org 2010-03-26 13:15 ---
Created an attachment (id=20209)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20209&action=view)
gcc45-pr43516-2.patch
Another possible patch, this one speeds up build_nonstandard_integer (e.g. on
the #c1 test
--- Comment #9 from dominiq at lps dot ens dot fr 2010-03-26 13:29 ---
Following revision 157731 the number of failures for the objc and obj-c++
testsuite on *-apple-darwin* has drastically decreased. Iain, thanks a lot for
the hard work.
Should I close this PR as fixed, leaving people
--- Comment #15 from rguenth at gcc dot gnu dot org 2010-03-26 13:33
---
(In reply to comment #13)
> Created an attachment (id=20208)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20208&action=view) [edit]
> gcc45-pr43516-1.patch
>
> One possible fix, just don't print MEM alias s
--- Comment #10 from dominiq at lps dot ens dot fr 2010-03-26 13:35 ---
Is there any plan to backport the patches to 4.4?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35165
--- Comment #16 from rguenth at gcc dot gnu dot org 2010-03-26 13:36
---
(In reply to comment #14)
> Created an attachment (id=20209)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20209&action=view) [edit]
> gcc45-pr43516-2.patch
>
> Another possible patch, this one speeds up bui
--- Comment #24 from dominiq at lps dot ens dot fr 2010-03-26 13:38 ---
The result of regression testing for all languages but ADA on
powerpc-apple-darwin9 with -m32 and -m64 with the patch committed on trunk at
revision 148568 posted at
http://gcc.gnu.org/ml/gcc-testresults/2010-03/msg
--- Comment #11 from developer at sandoe-acoustics dot co dot uk
2010-03-26 13:42 ---
(In reply to comment #9)
> Should I close this PR as fixed, leaving people fill new PRs for the remaining
> failures, or should I leave it open?
IMO this should be closed - it clears the faults that a
--- Comment #12 from developer at sandoe-acoustics dot co dot uk
2010-03-26 13:42 ---
(In reply to comment #10)
> Is there any plan to backport the patches to 4.4?
I'll look at that in the next couple of weeks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35165
--- Comment #4 from developer at sandoe-acoustics dot co dot uk 2010-03-26
13:48 ---
I think this is now OK following the patches and no new issues appear to have
arisen elsewhere.
--
developer at sandoe-acoustics dot co dot uk changed:
What|Removed
Playing with the following test case (see
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/83b587a930639741#
):
program sizetest1
use ISO_C_BINDING
implicit none
type contains_pointer
integer data
type(contains_pointer), pointer :: next
end type c
--- Comment #3 from hjl dot tools at gmail dot com 2010-03-26 13:50 ---
It will be easier to debug if you provide a run-time testcase.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43537
--- Comment #4 from juha dot kallioinen at nokia dot com 2010-03-26 13:52
---
(In reply to comment #3)
> It will be easier to debug if you provide a run-time testcase.
That qvector.ii contains a main() function that executes test1() and test2().
If you want all the source files, I can
--- Comment #13 from dominiq at lps dot ens dot fr 2010-03-26 13:53 ---
(In reply to comment #12)
> > Is there any plan to backport the patches to 4.4?
>
> I'll look at that in the next couple of weeks.
If this a sort of "yes", I am leaving the PR open. If at some point you decide
it is
Command line:
$ CXX="/mnt/svn/gcc-trunk/binary-157723-lto/bin/g++"
$ FLAGS="-O1 -freorder-blocks-and-partition -ftree-vectorize
-fgraphite-identity -m32 -mstackrealign"
$ $CXX -fprofile-arcs $FLAGS testcase.c
$ ./a.out
$ $CXX -fprofile-use $FLAGS testcase.c
testcase.c: In function 'int test_for2(in
--- Comment #1 from zsojka at seznam dot cz 2010-03-26 13:55 ---
Created an attachment (id=20210)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20210&action=view)
reduced testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43540
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-03-26 13:58 ---
Usually this happens when we after writing out LTO IL drop some symbols because
we keep optimizing. But we use the final set of symbols in the object files
for doing linker resolution - that's possibly a different s
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-03-26 13:58 ---
Which means that we should probably stop optimizing right after writing out
LTO IL and simply expand to RTL and assembly at that point.
--
rguenth at gcc dot gnu dot org changed:
What|Removed
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-03-26 14:06 ---
Confirmed. Works on trunk.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #13 from jiez at gcc dot gnu dot org 2010-03-26 14:31 ---
Subject: Bug 43024
Author: jiez
Date: Fri Mar 26 14:30:49 2010
New Revision: 157750
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157750
Log:
2010-03-26 Volker Reichelt
PR c++/43024
* g++.
--- Comment #2 from jakub at gcc dot gnu dot org 2010-03-26 14:39 ---
Can't reproduce this (ran cc1plus in a loop, still haven't reproduced after
several minutes).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43540
--- Comment #8 from rguenth at gcc dot gnu dot org 2010-03-26 14:40 ---
Cary, can you give advice and/or fix gold and/or the linker plugin?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42757
--- Comment #3 from zsojka at seznam dot cz 2010-03-26 14:56 ---
Created an attachment (id=20211)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20211&action=view)
generated profile data
It can be reproduced only when compiled as C++ code.
With this profile file and file from comm
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-03-26 14:58 ---
I can't reproduce this either but regs seems to leak in that function.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43540
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-03-26 15:04 ---
Honza - ping.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43391
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-03-26 15:06 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|SUSPENDED
--- Comment #6 from hjl dot tools at gmail dot com 2010-03-26 15:06 ---
(In reply to comment #4)
> (In reply to comment #3)
> > It will be easier to debug if you provide a run-time testcase.
>
> That qvector.ii contains a main() function that executes test1() and test2().
> If you want
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43358
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43469
--- Comment #5 from zsojka at seznam dot cz 2010-03-26 15:07 ---
Created an attachment (id=20212)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20212&action=view)
reduced executable testcase
This testcase aborts for me when compiled with -fprofile-use, but works with
-fprofile-arc
--- Comment #10 from rguenth at gcc dot gnu dot org 2010-03-26 15:10
---
PR43505 has a smaller testcase and analysis. The unreduced testcase from this
bug also passes with -fno-ipa-cp.
*** This bug has been marked as a duplicate of 43505 ***
--
rguenth at gcc dot gnu dot org chang
--- Comment #8 from rguenth at gcc dot gnu dot org 2010-03-26 15:10 ---
*** Bug 41056 has been marked as a duplicate of this bug. ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #6 from zsojka at seznam dot cz 2010-03-26 15:17 ---
(From update of attachment 20212)
The testcase is invalid
--
zsojka at seznam dot cz changed:
What|Removed |Added
-
--- Comment #7 from juha dot kallioinen at nokia dot com 2010-03-26 15:24
---
Created an attachment (id=20213)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20213&action=view)
source files
Here are the source files to reproduce the bug, just untar and 'make'.
--
http://gcc.g
--- Comment #8 from falk at debian dot org 2010-03-26 15:30 ---
This seems to be a problem with the struct hack in QVector. Here is a test
case:
extern "C" {
void *memset(void *s, int c, __SIZE_TYPE__ n);
void *malloc(__SIZE_TYPE__ size);
int printf(const char *format, ...);
--- Comment #9 from rguenth at gcc dot gnu dot org 2010-03-26 15:44 ---
I think it is SCEV leading to false D.2100_10: [4294967293, +INF] as it
assumes
D.2100_10 = i.2_9 + 4294967293;
if (D.2100_10 <= 1)
doesn't wrap. Probably fixed on the trunk by the patch that restricts
asking
--- Comment #7 from jakub at gcc dot gnu dot org 2010-03-26 15:51 ---
Created an attachment (id=20214)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20214&action=view)
gcc45-pr43540.patch
Ah, finally managed to reproduce it. The problem seems to be in confusion
about the operand
I think there is an already filed bug about this option with the gnu
runtime also. This option should not be supported or a nop there.
Sent from my iPhone
On Mar 26, 2010, at 5:16 AM, "developer at sandoe-acoustics dot co dot
uk" wrote:
--- Comment #1 from developer at sandoe-acous
--- Comment #3 from pinskia at gmail dot com 2010-03-26 16:14 ---
Subject: Re: ICE on objc.dg/objc-gc-4.m -fgnu-runtime
I think there is an already filed bug about this option with the gnu
runtime also. This option should not be supported or a nop there.
Sent from my iPhone
On Mar
--- Comment #17 from jakub at gcc dot gnu dot org 2010-03-26 16:19 ---
Subject: Bug 43516
Author: jakub
Date: Fri Mar 26 16:18:51 2010
New Revision: 157753
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157753
Log:
PR debug/43516
* flags.h (final_insns_dump_p): N
This one just needs a couple of casts:
/cygdrive/j/Home/cvsroot/gcc-obj/./prev-gcc/xgcc
-B/cygdrive/j/Home/cvsroot/gcc-obj/./prev-gcc/ -B/usr/local/i686-pc-cygwin/bin/
-B/usr/local/i686-pc-cygwin/bin/ -B/usr/local/i686-pc-cygwin/lib/ -isystem
/usr/local/i686-pc-cygwin/include -isystem
/usr/local/i
--- Comment #4 from developer at sandoe-acoustics dot co dot uk 2010-03-26
16:36 ---
(In reply to comment #3)
> Subject: Re: ICE on objc.dg/objc-gc-4.m -fgnu-runtime
> This option should not be supported or a nop there.
if gc is incompatible with gnu runtime then that should be throw
--- Comment #10 from hjl dot tools at gmail dot com 2010-03-26 16:39
---
The original testcase was fixed by revision 151360:
http://gcc.gnu.org/ml/gcc-cvs/2009-09/msg00106.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43537
--- Comment #8 from ubizjak at gmail dot com 2010-03-26 16:47 ---
(In reply to comment #7)
> > Yep, that's the right version.
>
> Well, but negative sizes do not make much sense, so I think ,1 makes more
> sense (with unsigned HOST_WIDE_INT then).
Eh, what now?
--
http://gcc.gnu.
--- Comment #17 from mckelvey at maskull dot com 2010-03-26 16:48 ---
(In reply to comment #16)
> (In reply to comment #15)
> > (In reply to comment #14)
>
> > > So I guess that the build and install recreates those rogue dlls.
> > >
> >
> > My project compiles and links, but cannot r
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-03-26 16:49 ---
This has been fixed already.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from mckelvey at maskull dot com 2010-03-26 16:51 ---
(In reply to comment #2)
> James, you reported this against 4.3.0. I've just tried your testcase against
> both 4.3.4 and HEAD, neither of which had any problem; can you see if you
> still
> get it at all, or if we ca
--- Comment #8 from zsojka at seznam dot cz 2010-03-26 17:12 ---
Patch from comment #7 seems to solve the isue even for the nonreduced testcase.
Thanks
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43540
Current libtool does not yet work with lto. When generating symbol lists, it
does not grep out __gnu_lto_v1 (BTW, which would be the right pattern to grep
out?)
Anyway, that can cause something like this to happen:
cat >a.c <<'EOF'
extern char __gnu_lto_v1;
const struct {
const char *name;
1 - 100 of 149 matches
Mail list logo
