--- Comment #11 from pault at gcc dot gnu dot org 2009-11-20 07:57 ---
Many thanks for the report.
Fixed on trunk
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #10 from janus at gcc dot gnu dot org 2009-11-20 06:57 ---
(In reply to comment #8)
> I will take it that this is an OK from you.
Sure thing. Thanks for committing.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42104
--- Comment #9 from pault at gcc dot gnu dot org 2009-11-20 06:43 ---
Subject: Bug 42104
Author: pault
Date: Fri Nov 20 06:43:13 2009
New Revision: 154358
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154358
Log:
2009-11-20 Paul Thomas
Janus Weil
PR fo
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org
|dot org
--- Comment #7 from jason at gcc dot gnu dot org 2009-11-20 05:15 ---
friend S::S() is not valid; S::S names the constructor, which is
not a template.
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#147
--
jason at gcc dot gnu dot org changed:
What|Remov
--- Comment #11 from jason at gcc dot gnu dot org 2009-11-20 05:10 ---
Fixed.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #5 from jason at gcc dot gnu dot org 2009-11-20 05:06 ---
Fixed.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #4 from jason at gcc dot gnu dot org 2009-11-20 05:03 ---
Subject: Bug 42115
Author: jason
Date: Fri Nov 20 05:03:21 2009
New Revision: 154357
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154357
Log:
PR c++/42115
* call.c (build_op_delete_call): Don
--- Comment #8 from pault at gcc dot gnu dot org 2009-11-20 04:59 ---
(In reply to comment #7)
Janus,
That version is a very good suggestion - thanks. I am set up to apply the
patch, so, although component procedure pointers is one of your
specialisations, I can efficiently get on and
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2009-11-20 04:02
---
Subject: Bug 42090
Author: jvdelisle
Date: Fri Nov 20 04:02:33 2009
New Revision: 154356
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154356
Log:
2009-11-19 Jerry DeLisle
PR libgfortran/4209
--- Comment #7 from jvdelisle at gcc dot gnu dot org 2009-11-20 04:00
---
Subject: Bug 42090
Author: jvdelisle
Date: Fri Nov 20 04:00:03 2009
New Revision: 154355
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154355
Log:
2009-11-19 Jerry DeLisle
PR libgfortran/4209
--- Comment #7 from hjl dot tools at gmail dot com 2009-11-20 04:00 ---
(In reply to comment #6)
> The good ones produce:
>
> 650: 55 push %ebp
> 651: 89 e5 mov%esp,%ebp
> 653: 83 e4 f0and$0xfff0,%esp
>
> The ba
--- Comment #3 from jason at gcc dot gnu dot org 2009-11-20 03:10 ---
That said, I can see a reading whereby since PPL also defines operator delete
(void *), the operator delete (void *, size_t) isn't the usual deallocation
function, so we shouldn't give an error. I'll implement that.
--- Comment #2 from jason at gcc dot gnu dot org 2009-11-20 03:05 ---
I just had another email exchange about this, but can't find it right now.
Anyway, 5.3.4 [expr.new]:
A declaration of a placement deallocation function matches the declaration of a
placement allocation function if it
--- Comment #9 from jason at gcc dot gnu dot org 2009-11-20 02:37 ---
.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #3 from joseph at codesourcery dot com 2009-11-20 02:36 ---
Subject: Re: c99-stdint test fails for ptrdiff test
On Fri, 20 Nov 2009, hutchinsonandy at gcc dot gnu dot org wrote:
> So should I skip ptrdiff limit test based on pointers being <32 bits? Perhaps
> ints < 32 bit
--- Comment #8 from jason at gcc dot gnu dot org 2009-11-20 02:31 ---
Fixed
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|---
--- Comment #2 from hutchinsonandy at gcc dot gnu dot org 2009-11-20 02:07
---
I found c99 limit now which explains it.
I was tempted to make PTRDIFF_TYPE signed 32 bits to solve c99 compliance -
however that completely useless as we cannot declare array exceeding > 32767
bytes anyw
--- Comment #7 from suren dot r at live dot in 2009-11-20 02:02 ---
(In reply to comment #6)
> (In reply to comment #5)
> > Mr. Andrew,
> > I dont understand the term 'undefined code'. Are you saying this is not a
> > bug?
>
> This is not a bug in GCC but the code you wrote. scanf's %
--- Comment #1 from rainer at emrich-ebersheim dot de 2009-11-20 01:47
---
Created an attachment (id=19063)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19063&action=view)
preprocessed source, still quite large
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42115
There is an issue with non-placement deallocation:
In file included from
../../../../../../../src/ppl-0.10.2/src/Row.defs.hh:504:0,
from
../../../../../../../src/ppl-0.10.2/src/Linear_Row.defs.hh:28,
from
../../../../../../../src/ppl-0.10.2/src/Constraint.defs.hh:
--- Comment #1 from joseph at codesourcery dot com 2009-11-20 01:13 ---
Subject: Re: New: c99-stdint test fails for ptrdiff test
On Fri, 20 Nov 2009, hutchinsonandy at gcc dot gnu dot org wrote:
> __PTRDIFF_MAX__ is set by gcc at 32767 and so stdint.h gives PTRDIFF_MAX 32767
> and PT
Test gcc.dg/c99-stdint-1.c checks for range of__PTRDIFF_TYPE__ and fails for
avr target.
test_misc_limits (void)
{
CHECK_SIGNED_LIMITS_2(__PTRDIFF_TYPE__, PTRDIFF_MIN, PTRDIFF_MAX, -65535L,
65535L);
On AVR pointers and integers are 16bit.
INTPTR_MIN =-32768
INTPTR_MAX = 32767
UINTPTR_MAX = 6
--- Comment #6 from tglx at linutronix dot de 2009-11-20 00:52 ---
I changed the summary to match the real problem.
Further info:
While testing various kernel configs we found out that the problem
comes and goes. Finally I started to compare the gcc command line
options and after some
--- Comment #2 from mattst88 at gmail dot com 2009-11-20 00:45 ---
Created an attachment (id=19062)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19062&action=view)
Test Case 2 - flist.i - preprocessed flist.c from rsync
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42113
--- Comment #1 from mattst88 at gmail dot com 2009-11-20 00:44 ---
Created an attachment (id=19061)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19061&action=view)
Test Case 1 - pp.i - preprocessed pp.c from libperl
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42113
Unfortunately, but 8603 seems to cause internal compiler errors on select files
when using -O3. -O{s,0,1,2} are unaffected.
I'm attaching pp.i (preprocessed pp.c from libperl), and flist.i (preprocessed
flist.c from rsync) as test cases.
gcc-4.3.4 does not exhibit this failure, but when patched f
--- Comment #2 from sgk at troutmask dot apl dot washington dot edu
2009-11-20 00:20 ---
Subject: Re: overloaded function with allocatable result problem
If the code is compiled with -fdump-tree-original one
immediately see the cause of the runtime error. Eliminating
the common code
--- Comment #28 from howarth at nitro dot med dot uc dot edu 2009-11-20
00:13 ---
Why do we have
case dw_val_class_const_double:
switch (HOST_BITS_PER_WIDE_INT)
{
case 8:
return DW_FORM_data2;
case 16:
return DW_FORM_data4;
--- Comment #1 from kargl at gcc dot gnu dot org 2009-11-19 23:55 ---
If you remove
allocate(loc_ar(1))
deallocate(loc_ar)
in function f(), the code compiles and runs in either case.
--
kargl at gcc dot gnu dot org changed:
What|Removed |
--- Comment #27 from howarth at nitro dot med dot uc dot edu 2009-11-19
23:27 ---
We have an update on radar 7397601 from Nick Kledzik...
7397601 is a bug in dsymutils. It was not handling the case when the
dwarf debug info contained an AT_location with form DW_FORM_block1 with
--- Comment #7 from anlauf at gmx dot de 2009-11-19 22:33 ---
I tried the code on a x86 Core2 system (32 bit mode).
gfortran 4.3, 4.5:
22.74user 0.03system 0:22.82elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
Intels ifort 11.1 is only ~ 5% faster, but:
SunStudio 12.1: (sunf95 -fast
--- Comment #9 from spop at gcc dot gnu dot org 2009-11-19 22:33 ---
Subject: Bug 40281
Author: spop
Date: Thu Nov 19 22:32:50 2009
New Revision: 154348
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154348
Log:
Fix PR40281.
2009-11-18 Sebastian Pop
PR middle-end/40
--- Comment #3 from spop at gcc dot gnu dot org 2009-11-19 22:33 ---
Subject: Bug 42050
Author: spop
Date: Thu Nov 19 22:32:44 2009
New Revision: 154347
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154347
Log:
Testcase for PR42050.
2009-11-18 Sebastian Pop
PR midd
The attached code produces an error at runtime, however it seems fine
to me. Notice that there is no error accessing the function with the
specific name "g", while there is an error when using the generic name
"gen_g".
gfortran --version
GNU Fortran (GCC) 4.5.0 20091105 (experimental)
gfortran ./
--- Comment #8 from spop at gcc dot gnu dot org 2009-11-19 22:14 ---
Subject: Re: [4.4/4.5 Regression] -fprefetch-loop-arrays:
ICE: in initialize_matrix_A, at tree-data-ref.c:1887
Hi,
Here is a fix for this one, on top of the graphite branch.
I will commit this fix to the gra
--- Comment #7 from janus at gcc dot gnu dot org 2009-11-19 21:59 ---
(In reply to comment #6)
> Index: gcc/fortran/trans-expr.c
> ===
> --- gcc/fortran/trans-expr.c(revision 154327)
> +++ gcc/fortran/trans-expr.c(wo
I seeing failures in gcc.dg/cleanup-13.c on x86_64-unknown-linux-gnu and
i686-unknown-linux-gnu with gcc-4.4.3 svn. E.g.:
FAIL: gcc.dg/cleanup-13.c (test for excess errors)
http://gcc.gnu.org/ml/gcc-testresults/2009-11/msg01708.html
gcc.dg/cleanup-13.c: Assembler messages:
gcc.dg/cleanup-13.c:30
x
gcc version 4.5.0 20091119 (experimental) [trunk revision 154326] (GCC)
And now I always get the abort too:
[deuterium:~] andreast% gcj -C hello.java
gcj: Internal error: Abort trap (program ecj1)
Please submit a full bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
CrashReporter
--- Comment #2 from spop at gcc dot gnu dot org 2009-11-19 21:12 ---
Fixed in the Graphite branch. The changes of the branch will be pushed into
trunk soon.
I will commit the reduced testcase to the Graphite testsuite.
Sebastian
--
spop at gcc dot gnu dot org changed:
W
--- Comment #6 from janus at gcc dot gnu dot org 2009-11-19 21:09 ---
(In reply to comment #5)
> The fix is to make use of the fact a proc_pointer component call is already
> detected and can be used to suppress the internal_pack. Thusly:
>
> Index: gcc/fortran/trans-expr.c
> =
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42110
The following valid code snippet triggers an ICE on trunk
when compiled with "-O2":
===
bool foo();
struct A
{
A* fooA() { if (foo()) foo(); return this; }
virtual void barA(char);
};
template struct B
{
A *p, *q;
void fooB(char c
--- Comment #7 from brunorex at gmail dot com 2009-11-19 20:08 ---
I don't get the error anymore with gcc 4.5.0 20091112.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41979
--- Comment #6 from toon at moene dot org 2009-11-19 19:53 ---
Richard Guenther wrote:
> Well, within eval there's nothing really obvious to me. The
> innermost loop is exactly the same:
But it is a very inefficient way of vectorizing, because the inner loop's body
is either executed
--- Comment #5 from sfilippone at uniroma2 dot it 2009-11-19 19:42 ---
(In reply to comment #4)
> Subject: Re: [4.4/4.5 Regression] Vectorizer
> cannot deal with PAREN_EXPR gracefully, 50% performance regression
>
>
> Heh, with -fwhole-program GCC optimizes the test away and I get 0.
--- Comment #5 from tglx at linutronix dot de 2009-11-19 19:27 ---
(In reply to comment #4)
> Is this really a bug since you have:
> struct entry {
> ...
> } __attribute__((__aligned__((1 << (4);
>
> ...
>
> void timer_stats_update_stats(void *timer, pid_t pid, void *startf,
>
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-11-19 19:12 ---
>Take a look at "The C Programming Language" by Kernighan and Ritchie,
chapter 5.
But this is not a reference operator at this point. It is for a reference
type. Reference types are different from the reference op
--- Comment #2 from bradhomer at gbis dot com 2009-11-19 19:11 ---
Subject: Re: Reference operator (&) error from included file.
Take a look at "The C Programming Language" by Kernighan and Ritchie,
chapter 5.
On 18 Nov 2009 20:11:51 -, "pinskia at gcc dot gnu dot org"
wrote:
>
--- Comment #13 from aoliva at gcc dot gnu dot org 2009-11-19 18:54 ---
> one could randomize the delta we add to next_decl_uid
Yeah, that would be an interesting test. In fact, we had something along these
lines before, when we used (randomized) pointers rather than uids, and we
faile
--- Comment #7 from ludovic at ludovic-brenta dot org 2009-11-19 18:50
---
Created an attachment (id=19060)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19060&action=view)
Disassembly of prj-part.adb, with sources (objdump -S)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4
--- Comment #4 from pinskia at gcc dot gnu dot org 2009-11-19 18:34 ---
Is this really a bug since you have:
struct entry {
...
} __attribute__((__aligned__((1 << (4);
...
void timer_stats_update_stats(void *timer, pid_t pid, void *startf,
void *timerf, char *comm,
--- Comment #3 from tglx at linutronix dot de 2009-11-19 18:30 ---
Created an attachment (id=19059)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19059&action=view)
compiler command line
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42109
--- Comment #2 from tglx at linutronix dot de 2009-11-19 18:28 ---
Created an attachment (id=19058)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19058&action=view)
intermediate file timer_stats.i
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42109
--- Comment #1 from tglx at linutronix dot de 2009-11-19 18:27 ---
Created an attachment (id=19057)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19057&action=view)
source code (kernel/time/timer_stat.c)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42109
Random Linux Kernel functions have 16 byte stack alignment at the start of the
function. This stack alignment happens before the
push %ebp
mov %esp, %ebp
sequence and breaks the kernel function graph tracer which needs to manipulate
the return address. When the alignment happens then still 4
--- Comment #6 from pinskia at gcc dot gnu dot org 2009-11-19 18:07 ---
(In reply to comment #5)
> Mr. Andrew,
> I dont understand the term 'undefined code'. Are you saying this is not a bug?
This is not a bug in GCC but the code you wrote. scanf's %d takes a pointer to
an int variable
--- Comment #5 from suren dot r at live dot in 2009-11-19 18:05 ---
Mr. Andrew,
I dont understand the term 'undefined code'. Are you saying this is not a bug?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42107
--- Comment #4 from rguenther at suse dot de 2009-11-19 17:30 ---
Subject: Re: [4.4/4.5 Regression] Vectorizer
cannot deal with PAREN_EXPR gracefully, 50% performance regression
On Thu, 19 Nov 2009, sfilippone at uniroma2 dot it wrote:
> --- Comment #3 from sfilippone at uniroma2
--- Comment #3 from sfilippone at uniroma2 dot it 2009-11-19 17:17 ---
(In reply to comment #2)
> -ftree-vectorizer-verbose=2 tells you:
>
> eval.f90:35: note: not vectorized: relevant stmt not supported: D.1684_73 =
> ((D.1683_72));
>
> eval.f90:32: note: not vectorized: relevant stmt
--- Comment #9 from paolo dot carlini at oracle dot com 2009-11-19 17:03
---
Fixed for 4.5.0.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #10 from jason at gcc dot gnu dot org 2009-11-19 16:59 ---
Subject: Bug 561
Author: jason
Date: Thu Nov 19 16:59:05 2009
New Revision: 154336
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154336
Log:
PR c++/561
* decl.c (static_fn_type): Split out...
--- Comment #8 from paolo at gcc dot gnu dot org 2009-11-19 16:55 ---
Subject: Bug 41622
Author: paolo
Date: Thu Nov 19 16:55:25 2009
New Revision: 154335
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154335
Log:
2009-11-19 Paolo Carlini
PR libstdc++/41622
*
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-11-19 16:49 ---
-ftree-vectorizer-verbose=2 tells you:
eval.f90:35: note: not vectorized: relevant stmt not supported: D.1684_73 =
((D.1683_72));
eval.f90:32: note: not vectorized: relevant stmt not supported: D.1684_58 =
((D.1683
--- Comment #22 from yipiha2008 at gmail dot com 2009-11-19 16:47 ---
I tried applying this patch:
(define_insn "*iwmmxt_movsi_insn"
- [(set (match_operand:SI 0 "nonimmediate_operand" "=rk,r,r,rk,
m,z,r,?z,Uy,z")
+ [(set (match_operand:SI 0 "nonimmediate_operand" "=rk,r,r,rk,
m,z,rk
--- Comment #8 from tromey at gcc dot gnu dot org 2009-11-19 16:45 ---
Created an attachment (id=19056)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19056&action=view)
patch for readelf
This patch modifies the binutils readelf utility to
dump the new section.
--
http://gcc.g
--- Comment #7 from tromey at gcc dot gnu dot org 2009-11-19 16:30 ---
Created an attachment (id=19055)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19055&action=view)
modified patch
I've slightly updated the patch to handle non-public entities
as well.
--
http://gcc.gnu.org
--- Comment #1 from sfilippone at uniroma2 dot it 2009-11-19 16:01 ---
Created an attachment (id=19054)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19054&action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42108
With the attached sample code I get a substantial performance drop from 4.3.1
to either 4.4.1 or 4.5.0, same compiler option, same machine. To reproduce,
feed a size to the program (in the case below, 4) and time the executable.
[sfili...@donald fgp_fmm_20091112]$ gfortran -v
Using built-in
--- Comment #4 from espindola at gcc dot gnu dot org 2009-11-19 15:57
---
Closing this bug as bootstrap should now work. The gold plugin still needs some
portability improvements.
--
espindola at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #13 from wuerzner at gmail dot com 2009-11-19 15:47 ---
If you have no speedup, do you recognize any loss of speed due to the
parallelization overhead (for small examples)?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38875
--- Comment #12 from rguenther at suse dot de 2009-11-19 15:36 ---
Subject: Re: flag_gtoggle in free_lang_data hides -fcompare-debug
errors
On Thu, 19 Nov 2009, ebotcazou at gcc dot gnu dot org wrote:
> --- Comment #11 from ebotcazou at gcc dot gnu dot org 2009-11-19 15:11
> --
--- Comment #12 from singler at gcc dot gnu dot org 2009-11-19 15:35
---
Remove old email address.
--
singler at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from singler at gcc dot gnu dot org 2009-11-19 15:33
---
Created an attachment (id=19053)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19053&action=view)
Functional patch for parallel fill and fill_n.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38875
--- Comment #10 from singler at gcc dot gnu dot org 2009-11-19 15:32
---
The new patch is functional. However, for simple cases like setting integers,
I have no speedup (yet).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38875
--- Comment #4 from suren dot r at live dot in 2009-11-19 15:31 ---
Created an attachment (id=19052)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19052&action=view)
.o file created
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42107
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-11-19 15:31 ---
Compiling with -W -Wall, we get the following warnings:
t.c: In function âmainâ:
t.c:9: warning: format â%dâ expects type âint *â, but argument 2 has
type âunsigned char *â
t.c:11: warning: format â
--- Comment #2 from suren dot r at live dot in 2009-11-19 15:30 ---
Created an attachment (id=19051)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19051&action=view)
.i file generated
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42107
--- Comment #3 from espindola at gcc dot gnu dot org 2009-11-19 15:30
---
Subject: Bug 42096
Author: espindola
Date: Thu Nov 19 15:30:04 2009
New Revision: 154330
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154330
Log:
2009-11-19 Rafael Avila de Espindola
PR boot
--- Comment #1 from suren dot r at live dot in 2009-11-19 15:29 ---
Created an attachment (id=19050)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19050&action=view)
Source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42107
Declare two variables as unsigned char.
use scanf with %d to read two values and store in the variables
when executing,
the first variable have 0 instead of scanned number;
the second variable have the scanned number;
--
Summary: Scaning unsigned char variable as integer using scanf
--- Comment #11 from ebotcazou at gcc dot gnu dot org 2009-11-19 15:11
---
> For not doing the boolean_type_node fixing we'd need to not pre-load the
> streamer chache with (selected) builtin type nodes but instead stream them
> with every unit and function and pass them through the mer
--- Comment #10 from rguenth at gcc dot gnu dot org 2009-11-19 14:40
---
Btw I can reproduce the bootstrap comparison fail with Ada when removing the
bogus flag_gtoggle check. Fixing the problem with canonicalize_cond_expr_cond
isn't the whole story appearantly - fixing it doesn't fix
--- Comment #21 from enrico dot scholz at informatik dot tu-chemnitz dot de
2009-11-19 14:39 ---
forget comment #20.
WLDRW wcgr0, [fp, #-1324]
would be an invalid instruction. Offset is 10 bit only so that the RTL is
invalid for the iwmmxt processor.
--
http://gcc.gnu.org/bugz
--- Comment #20 from enrico dot scholz at informatik dot tu-chemnitz dot de
2009-11-19 14:09 ---
This patch creates now
---
(insn 460 148 153 20 ../sysdeps/unix/sysv/linux/libc_fatal.c:106 (set (reg:SI
43 wcgr0)
(mem/c:SI (plus:SI (reg/f:SI 11 fp)
(const_int -1
--- Comment #19 from enrico dot scholz at informatik dot tu-chemnitz dot de
2009-11-19 13:57 ---
Created an attachment (id=19049)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19049&action=view)
patch to fix reported ICE
[not official, I really do not know whether this is the cor
Simplistic build works, then fails to find cc1plus on its own
when using g++
SunOS cairo 5.10 Generic_13-08 sun4u sparc SUNW,Sun-Fire-280R
~:cairo> ../gcc-4.3.4/configure --prefix=/cairo/tmp/jblaine \
--with-as=/usr/ccs/bin/as --with-ld=/usr/ccs/bin/ld \
--disable-shared --w
--- Comment #18 from enrico dot scholz at informatik dot tu-chemnitz dot de
2009-11-19 13:47 ---
(define_insn "*iwmmxt_movsi_insn"
- [(set (match_operand:SI 0 "nonimmediate_operand" "=rk,r,r,rk,
m,z,r,?z,Uy,z")
+ [(set (match_operand:SI 0 "nonimmediate_operand" "=rk,r,r,rk, m,z
,rk,?z
--- Comment #5 from pault at gcc dot gnu dot org 2009-11-19 13:25 ---
Martien,
Thank you very much for this report.
I have assigned it to myself and have a non-regtested fix:
As remarked by Janus, the problem is with the array argument. The code
produced for the proc_pointer call is
--- Comment #17 from yipiha2008 at gmail dot com 2009-11-19 13:18 ---
I tried removing the whole movsi section from the machine definition file
(iwmmxt.md) but if I do that GCC refuses to compile. Reading the GCC internals
documentation it appears that the movsi section is mandatory.
Do
--- Comment #2 from ebotcazou at gcc dot gnu dot org 2009-11-19 12:31
---
> This is most likely due to one of Jan's recent commits.
Right, r154121 changed
gcc_assert ((!DECL_WEAK (vnode->decl) || DECL_COMMON (vnode->decl))
|| TREE_PUBLIC (vnode->decl) || DECL_E
--- Comment #2 from manu at gcc dot gnu dot org 2009-11-19 12:28 ---
I think this is a duplicate of either bug 2972 or bug 19808 or one of the SRA
testcases.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #1 from ebotcazou at gcc dot gnu dot org 2009-11-19 12:26
---
Created an attachment (id=19048)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19048&action=view)
Reduced testcase
To be gnatchop-ed and cross-compiled.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4
--- Comment #3 from manu at gcc dot gnu dot org 2009-11-19 12:22 ---
The best we can do is to add this testcase to GCC 4.5 and close this as FIXED
in mainline. These kind of fixes are typically not easy to backport.
--
manu at gcc dot gnu dot org changed:
What|Removed
--- Comment #7 from manu at gcc dot gnu dot org 2009-11-19 12:19 ---
This is still unconfirmed until someone looks at the dumps and check that the
variables are indeed initialized in all paths that can be sensibly detected by
GCC.
BTW, when you release code, your compiler flags should n
--- Comment #2 from manu at gcc dot gnu dot org 2009-11-19 12:13 ---
If the loop does nothing, the whole loop is removed before warning about
anything. If you find a testcase where the loop does something useful, and
there is still no warning, please open a new bug report. Thanks.
--
--- Comment #17 from manu at gcc dot gnu dot org 2009-11-19 12:00 ---
*** Bug 42079 has been marked as a duplicate of this bug. ***
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from manu at gcc dot gnu dot org 2009-11-19 12:00 ---
Taking address of var causes missing may be uninitialized.
*** This bug has been marked as a duplicate of 19430 ***
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #4 from janus at gcc dot gnu dot org 2009-11-19 11:57 ---
Let's have a look at the dump for the test case in comment #2.
The call to 'func' is translated to:
real(kind=4) D.1568;
struct array1_real(kind=4) parm.7;
static real(kind=4) A.6[2] = {1.000149
--- Comment #9 from jakub at gcc dot gnu dot org 2009-11-19 11:54 ---
The #c4 patch looks wrong, instead of that you should IMHO just not use UNUSED
macro on __gthread_mutex_destroy argument. It is perfectly fine on
__gthread_key_delete.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?
1 - 100 of 113 matches
Mail list logo
