--- Comment #8 from sfilippone at uniroma2 dot it 2009-11-20 08:32 ---
(In reply to comment #6)
> 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, beca
--- Comment #14 from singler at gcc dot gnu dot org 2009-11-20 09:53
---
Created an attachment (id=19064)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19064&action=view)
Functional patch for parallel fill and fill_n.
--
singler at gcc dot gnu dot org changed:
What
--- Comment #15 from singler at gcc dot gnu dot org 2009-11-20 09:56
---
There is slowdown, also for large inputs, for the most simple case, namely
filling constant integer values. If assignment is more expensive, thing will
get better. Please try with your application.
--
singler
--- Comment #2 from paolo at gcc dot gnu dot org 2009-11-20 10:05 ---
Subject: Bug 29017
Author: paolo
Date: Fri Nov 20 10:05:37 2009
New Revision: 154360
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154360
Log:
/cp
2009-11-20 Shujing Zhao
PR c++/29017
* cp
--- Comment #3 from ubizjak at gmail dot com 2009-11-20 10:06 ---
Both files compile OK with 4.5 cross from x86_64-pc-linux-gnu.
Probably a target specific patch should be backported from mainline to 4.3 and
4.4 branches.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42113
--- Comment #3 from paolo dot carlini at oracle dot com 2009-11-20 10:07
---
Fixed for 4.5.0.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #4 from ubizjak at gmail dot com 2009-11-20 10:42 ---
Confirmed with 4.4 cross.
--
ubizjak at gmail dot com changed:
What|Removed |Added
CC|ub
Compiling an ARC cross compiler gives ICE:
[lu...@localhost gcc]$/home/luben/ware/arc_gcc_rel2.2/gcc/build/./gcc/xgcc -v
-save-temps -B/home/luben/ware/arc_gcc_rel2.2/gcc/build/./gcc/ -nostdinc
-B/home/luben/ware/arc_gcc_rel2.2/gcc/build/arc-elf32/newlib/ -isystem
/home/luben/ware/arc_gcc_rel2.2/g
--- Comment #1 from ltuikov at yahoo dot com 2009-11-20 10:56 ---
Created an attachment (id=19065)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19065&action=view)
Preprocessed source code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42116
--- Comment #2 from ltuikov at yahoo dot com 2009-11-20 10:57 ---
Created an attachment (id=19066)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19066&action=view)
Assembly output
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42116
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-11-20 10:58 ---
Honza?
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P4
Summary|[4.3/4.4/4.5 Regression]|[4.3/4.4 Regressio
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-11-20 11:01 ---
GCC 4.2 is no longer maintained, please try a newer release.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |paolo dot carlini at oracle
|dot org
--- Comment #4 from ltuikov at yahoo dot com 2009-11-20 11:24 ---
The source I'm trying to compile I got directly from arc. I'll try 4.4.2 from
GNU.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42116
--- Comment #2 from reichelt at gcc dot gnu dot org 2009-11-20 12:23
---
Confirmed. Reduced testcase (crashes with "-fprofile-arcs
-fsched2-use-superblocks -fschedule-insns2 -freorder-blocks -O"):
int foo(int i)
{
if (i)
return 0;
__builtin_allo
The vrp47 testcase currently fails on i386 and S/390. The ssa code before vrp
looks different for both compared to x86_64 due to a different value
returned by BRANCH_COST. (Branches on S/390 are relatively cheap due
to a sophisticated branch prediction unit.) Therefore during
gimplification fold_
--- Comment #5 from ubizjak at gmail dot com 2009-11-20 12:58 ---
This reduced testcase fails also on 4.5:
--cut here--
int make_file (int a, int b)
{
int foo = a * sizeof (int);
if (b)
foo += sizeof (int);
return foo;
}
--cut here--
--
http://gcc.gnu.org/bugzilla/show_
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-11-20 13:12 ---
Confirmed. We do see
x_2: [0, 1] EQUIVALENCES: { x_3(D) } (1 elements)
y_11: [0, 1] EQUIVALENCES: { y_5(D) } (1 elements)
but have no code that actually makes use of this information in
:
if (x_3(D) != 0)
I think that forall statement must be at least as fast as equivalent
do-
-end do construction.
But the next program (variant of LU-decomposition) shows that fragment
containing forall statement is approximately at 2.5(!) times slower then
fragment with do-end do.
program test
implicit
--- Comment #6 from ubizjak at gmail dot com 2009-11-20 13:40 ---
Created an attachment (id=19067)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19067&action=view)
patch to fix mode of scratch register in *cmp_s{add,sub}_si{,di}
This patch fixes wrong modes of scratch register in
--- Comment #9 from dominiq at lps dot ens dot fr 2009-11-20 13:45 ---
I am rather confused by some comments:
(1) Although I am not fluent with x86 assembly, I am pretty sure that no code
in eval is vectorized (assembly taken from this pr or from the original post
http://gcc.gnu.org/ml/
--- Comment #10 from sfilippone at uniroma2 dot it 2009-11-20 14:03 ---
(In reply to comment #9)
> I am rather confused by some comments:
>
> (1) Although I am not fluent with x86 assembly, I am pretty sure that no code
> in eval is vectorized (assembly taken from this pr or from the or
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-11-20 14:03 ---
Confirmed. GFortran seems to split the loops differently and uses a larger
temporary for the forall case.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #11 from sfilippone at uniroma2 dot it 2009-11-20 14:12 ---
(In reply to comment #10)
Again, I am no asking for help in writing a better code (I think I know how to
handle this, and I will convince my colleague), I just thought it was worth
mentioning that the optimizer has a
--- Comment #12 from rguenth at gcc dot gnu dot org 2009-11-20 14:13
---
The loop is not unrolled because the frontend presents us with very funny
obfuscated code:
do k=i,nnd,n
temp=temp+(x(k)-x(k+jmini))**2
end do
gets translated to
{
character(kind=4) countm1
--- Comment #23 from yipiha2008 at gmail dot com 2009-11-20 14:16 ---
Forget #22, as expected it does not work (kernel compiled with a patched GCC as
per #22 does not boot)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40836
--- Comment #2 from burnus at gcc dot gnu dot org 2009-11-20 14:20 ---
(In reply to comment #0)
> I think that forall statement must be at least as fast as equivalent
> do-
-end do construction.
The Fortran standardization committee thought likewise, however, as it turned
out in pra
--- Comment #3 from burnus at gcc dot gnu dot org 2009-11-20 14:22 ---
pure function f() result(i)
integer :: i
integer, allocatable :: loc_ar(:)
allocate(loc_ar(1))
loc_ar = gen_g() ! does not work
That looks OK if gen_g returns a size-1 array or a scalar - and with F
--- Comment #2 from jepler at unpythonic dot net 2009-11-20 14:45 ---
(In reply to comment #0)
> Given the declaration: typedef volatile double D __attribute__((aligned(16)));
That should have been aligned(8)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42098
--- Comment #8 from hjl at gcc dot gnu dot org 2009-11-20 14:50 ---
Subject: Bug 41919
Author: hjl
Date: Fri Nov 20 14:49:22 2009
New Revision: 154366
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154366
Log:
2009-11-20 H.J. Lu
Backport from mainline:
2009-1
--- Comment #3 from hjl at gcc dot gnu dot org 2009-11-20 14:50 ---
Subject: Bug 42055
Author: hjl
Date: Fri Nov 20 14:49:22 2009
New Revision: 154366
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154366
Log:
2009-11-20 H.J. Lu
Backport from mainline:
2009-1
--- Comment #10 from hjl at gcc dot gnu dot org 2009-11-20 14:50 ---
Subject: Bug 41935
Author: hjl
Date: Fri Nov 20 14:49:22 2009
New Revision: 154366
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154366
Log:
2009-11-20 H.J. Lu
Backport from mainline:
2009-
--- Comment #10 from hjl at gcc dot gnu dot org 2009-11-20 14:50 ---
Subject: Bug 41907
Author: hjl
Date: Fri Nov 20 14:49:22 2009
New Revision: 154366
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154366
Log:
2009-11-20 H.J. Lu
Backport from mainline:
2009-
--- Comment #6 from hjl at gcc dot gnu dot org 2009-11-20 14:50 ---
Subject: Bug 41926
Author: hjl
Date: Fri Nov 20 14:49:22 2009
New Revision: 154366
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154366
Log:
2009-11-20 H.J. Lu
Backport from mainline:
2009-1
--- Comment #10 from hjl at gcc dot gnu dot org 2009-11-20 14:50 ---
Subject: Bug 41928
Author: hjl
Date: Fri Nov 20 14:49:22 2009
New Revision: 154366
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154366
Log:
2009-11-20 H.J. Lu
Backport from mainline:
2009-
--- Comment #6 from hjl at gcc dot gnu dot org 2009-11-20 14:50 ---
Subject: Bug 41841
Author: hjl
Date: Fri Nov 20 14:49:22 2009
New Revision: 154366
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154366
Log:
2009-11-20 H.J. Lu
Backport from mainline:
2009-1
--- Comment #27 from hjl at gcc dot gnu dot org 2009-11-20 14:50 ---
Subject: Bug 41750
Author: hjl
Date: Fri Nov 20 14:49:22 2009
New Revision: 154366
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154366
Log:
2009-11-20 H.J. Lu
Backport from mainline:
2009-
--- Comment #24 from enrico dot scholz at informatik dot tu-chemnitz dot de
2009-11-20 15:07 ---
I do not think that the non working kernel is caused by the patch, but that
there are yet more regressions for the iwmmxt arch and that this arch has never
been tested with gcc 4.4.
--
Test file (Test.f90):
-
module Test
use ISO_C_BINDING
contains
subroutine Callback(arg) bind(C)
integer(C_INT) :: arg
end subroutine Callback
subroutine Check(proc)
type(C_FUNPTR) :: proc
end subroutine Check
end module Test
program Main
use Test
--
brunorex at gmail dot com changed:
What|Removed |Added
Status|NEW |SUSPENDED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41979
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-11-20 15:33 ---
Confirmed. Sth as simple as
Index: gcc/expr.c
===
--- gcc/expr.c (revision 154364)
+++ gcc/expr.c (working copy)
@@ -6834,7 +6834,8 @@ expand_expr_a
--- Comment #25 from yipiha2008 at gmail dot com 2009-11-20 15:45 ---
Further tests show that you're right about the non working kernel.
Should the iwmmxt arch be disabled by default on GCC 4.5? At least it would
make it clear that this arch is untested/not supported.
--
http://gcc
--- Comment #7 from janus at gcc dot gnu dot org 2009-11-20 15:51 ---
The runtime problem and the obsolete comment in the manual are fixed now. So
the only issue left is the wrong static declaration reported in comment #3.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42072
Currently g++ requires the -pedantic flag to give a warning on a zero sized
array that is not the last field in a struct. As far as I can see, this is
actually always a significant error if it is not the trailing field in the
struct...
Demonstration:
temp(510)$ cat zero-size-array.cpp
#include
#
--- Comment #2 from ramana at gcc dot gnu dot org 2009-11-20 16:00 ---
(In reply to comment #1)
> only seen when configuring with --with-mode=thumb, disabling scheduling for
> thumb2 shows the same endless loop.
Confirmed unless there's a miscompilation in libc that we are missing.
>
--- Comment #1 from paolo at gcc dot gnu dot org 2009-11-20 16:03 ---
Subject: Bug 42060
Author: paolo
Date: Fri Nov 20 16:03:19 2009
New Revision: 154371
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154371
Log:
cp/
2009-11-20 Paolo Carlini
PR c++/42060
* e
--- Comment #2 from paolo dot carlini at oracle dot com 2009-11-20 16:05
---
Fixed for 4.5.0.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
Follow-up to PR42072. Consider this simple program:
contains
subroutine setpointer (p)
procedure(), pointer :: p
end subroutine
end
Compiling this with -fdump-tree-original shows:
setpointer (void (*) (void) * p)
{
(void) 0;
}
MAIN__ ()
{
static void setpointer (void (*) (void)
--- Comment #8 from janus at gcc dot gnu dot org 2009-11-20 16:08 ---
(In reply to comment #7)
> So the only issue left is the wrong static declaration reported in comment #3.
This is now PR 42122. Closing this one.
--
janus at gcc dot gnu dot org changed:
What|Remov
As per subject, the dll attributes can't be applied to c++ namespaces - this in
fact applies to all windows platforms, not just cygwin. This would be a
desirable mechanism for eliminating the use of auto-import by using explicit
dllimport attributes, without having to uglify every header in the wh
--- Comment #1 from davek at gcc dot gnu dot org 2009-11-20 16:11 ---
Created an attachment (id=19068)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19068&action=view)
work-in-progress
This patch is a bit overly keen in how far it propagates dllimport, leading to
the regression of
--
davek at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |davek at gcc dot gnu dot org
|dot org
--- Comment #6 from olga at gcc dot gnu dot org 2009-11-20 16:57 ---
Subject: Bug 39960
Author: olga
Date: Fri Nov 20 16:57:35 2009
New Revision: 154374
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154374
Log:
2009-11-17 Olga Golovanevsky
PR middle-end/39960
--- Comment #10 from sje at cup dot hp dot com 2009-11-20 16:59 ---
Does freebsd use glibc? Does freebsd have a system libunwind? I am going to
guess yes to the first question and no to the second in which case you need to
edit gcc/config.gcc and modify the 'ia64*-*-freebsd*' entry to
--- Comment #10 from ro at CeBiTec dot Uni-Bielefeld dot DE 2009-11-20
17:10 ---
Subject: Re: Cannot build gcc: gthr-default.h:466: error: '__mutex' was not
declared in this scope
> The #c4 patch looks wrong, instead of that you should IMHO just not use UNUSED
> macro on __gthread_mu
--- Comment #11 from ro at gcc dot gnu dot org 2009-11-20 17:17 ---
Mine.
--
ro at gcc dot gnu dot org changed:
What|Removed |Added
CC|ro at techfak dot u
--- Comment #4 from janus at gcc dot gnu dot org 2009-11-20 17:24 ---
With this patch
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c (revision 154369)
+++ gcc/fortran/resolve.c (working copy)
@@ -132
--- Comment #1 from tom at giftssoft dot com 2009-11-20 17:26 ---
It looks like this bug is related to bug 16350, which was created on 2004-07-03
and resulted in patch 800-arm-bigendian.patch being applied on 2007-11-07 to
gcc 4.3.0. Prior to this patch, gcc defaulted to little-endian m
--- Comment #16 from ro at gcc dot gnu dot org 2009-11-20 17:53 ---
Mine.
--
ro at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc d
--- Comment #2 from mikael at gcc dot gnu dot org 2009-11-20 17:59 ---
This is the same as PR 38530
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42119
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-11-20 18:05 ---
*** Bug 42119 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-11-20 18:05 ---
*** This bug has been marked as a duplicate of 38530 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #1 from redi at gcc dot gnu dot org 2009-11-20 18:09 ---
Looks like this is for compatibility with GNU C, which allows it, but only in
the form char b[0] not char b[]
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42121
--- Comment #11 from kargl at gcc dot gnu dot org 2009-11-20 18:10 ---
(In reply to comment #10)
> Does freebsd use glibc? Does freebsd have a system libunwind? I am going to
> guess yes to the first question and no to the second in which case you need to
> edit gcc/config.gcc and modi
--
ubizjak at gmail dot com changed:
What|Removed |Added
URL||http://gcc.gnu.org/ml/gcc-
||
--- Comment #2 from david dot resnick at comverse dot com 2009-11-20 18:38
---
(In reply to comment #1)
> Looks like this is for compatibility with GNU C, which allows it, but only in
> the form char b[0] not char b[]
b[] seems simply broken unless last in an array for the C99 "flexibl
--- Comment #3 from redi at gcc dot gnu dot org 2009-11-20 18:49 ---
(In reply to comment #2)
> In standard C, a size 0 array is forbidden, at least in C99 doc I have handy,
Yes, but it's a long-standing GNU extension:
http://gcc.gnu.org/onlinedocs/gcc-4.4.2/gcc/Zero-Length.html#Zero-Le
--- Comment #4 from david dot resnick at comverse dot com 2009-11-20 18:56
---
(In reply to comment #3)
> (In reply to comment #2)
> > In standard C, a size 0 array is forbidden, at least in C99 doc I have
> > handy,
> Yes, but it's a long-standing GNU extension:
> http://gcc.gnu.org/o
--- Comment #29 from howarth at nitro dot med dot uc dot edu 2009-11-20
18:59 ---
I have some additional comments from the dsymutils maintainer...
>>> 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_b
CPP code:
#include
#include
const int INT_INVALID = 0x8000;
template class TOPLIST
{
int ind[N], n, lim;
T vals[N];
public:
TOPLIST() { n = 0; lim = N; }
void reset() { n = 0; }
void add(int index, T value)
{
int m;
if(n==l
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-11-20 19:12 ---
D.2919_10 = C39PAT[0][-2147483647];
Well there is an array subscript is below array bounds.
It is hard for GCC to figure out that is dead code really without full
unrolling ...
--
pinskia at gcc dot gnu dot o
--- Comment #13 from toon at moene dot org 2009-11-20 19:45 ---
> The funny conditional initialization of countm1.6 makes the analysis of
> the number of iterations of this loop impossible (not to mention the
> conversions to character(kind=4)).
> Why does the frontend do induction vari
--- Comment #2 from djszapi at archlinux dot us 2009-11-20 19:59 ---
(In reply to comment #1)
> D.2919_10 = C39PAT[0][-2147483647];
>
> Well there is an array subscript is below array bounds.
>
> It is hard for GCC to figure out that is dead code really without full
> unrolling ...
>
--- Comment #5 from joseph at codesourcery dot com 2009-11-20 20:57 ---
Subject: Re: g++ should warn or error on internal 0 size
array in struct
On Fri, 20 Nov 2009, david dot resnick at comverse dot com wrote:
> (In reply to comment #3)
> > (In reply to comment #2)
> > > In standard
--- Comment #4 from bradhomer at gbis dot com 2009-11-20 21:20 ---
Subject: Re: Reference operator (&) error from included file.
Thank you.
The code I submitted for the bug has worked for years in the world of
Borland. Obviously not so good in the world of linux.
Again thank you for
--- Comment #3 from redi at gcc dot gnu dot org 2009-11-20 21:23 ---
Subject: Bug 42019
Author: redi
Date: Fri Nov 20 21:23:02 2009
New Revision: 154377
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154377
Log:
2009-11-20 Jonathan Wakely
PR libstdc++/42019
*
I downloaded the source code gcc 4.4.2 and compiled at cygwin. I used
../gcc-4.4.2/configure --enable-shared --enable-threads=posix --enable-libssp
--enable-libgomp --enable-languages=c,c++ --enable-decimal-float
--disable-bootstrap --without-x --enable-version-specific-runtime-libs
to do config
--- Comment #4 from redi at gcc dot gnu dot org 2009-11-20 21:26 ---
Fixed for 4.5.0
--
redi at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGN
--- Comment #5 from paolo dot carlini at oracle dot com 2009-11-20 21:36
---
Note: "linux" is an operating system; "borland" is a software company.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42097
--- Comment #8 from simartin at gcc dot gnu dot org 2009-11-20 21:37
---
Subject: Bug 38646
Author: simartin
Date: Fri Nov 20 21:37:23 2009
New Revision: 154378
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154378
Log:
gcc/cp/
2009-11-20 Simon Martin
PR c++/38646
--- Comment #2 from tlesher at digium dot com 2009-11-20 21:44 ---
Created an attachment (id=19069)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19069&action=view)
Two files that each use one of either the 32-bit or 64-bit versions of the
function
Each file in this attachment con
--- Comment #9 from simartin at gcc dot gnu dot org 2009-11-20 21:46
---
Fixed in 4.5
--
simartin at gcc dot gnu dot org changed:
What|Removed |Added
Summary|
The problem with the endless loop is in the function "smpAllocMsg". There gcc
makes out of the while loop ("freeList == 0") an endless loop.
The problem with the line which is optimized away is in the
smpSendMsgBroadcast, its the line "serviceMsg= msg". This problem can be
avoided if I call anothe
--- Comment #1 from codemasterhs at yahoo dot de 2009-11-20 22:28 ---
Created an attachment (id=19070)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19070&action=view)
the out from gcc with -v -save-temps
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42126
--- Comment #2 from schwab at linux-m68k dot org 2009-11-20 22:45 ---
Neither freeList nor serviceMsg are volatile. Thus freeList can never change
and serviceMsg = msg is a dead assignment.
--
schwab at linux-m68k dot org changed:
What|Removed |Ad
--- Comment #3 from codemasterhs at yahoo dot de 2009-11-20 22:50 ---
(In reply to comment #2)
> Neither freeList nor serviceMsg are volatile. Thus freeList can never change
> and serviceMsg = msg is a dead assignment.
>
But they are, or is my syntax wrong?
static volatile struct smp
--- Comment #14 from rguenth at gcc dot gnu dot org 2009-11-20 23:48
---
(In reply to comment #13)
> > The funny conditional initialization of countm1.6 makes the analysis of
> > the number of iterations of this loop impossible (not to mention the
> > conversions to character(kind=4)).
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-11-20 23:53 ---
The pointer is not declared volatile.
static struct smpMsg_t * volatile freeList;
would be a volatile pointer.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-11-21 00:54 ---
(In reply to comment #2)
> I've also confirmed that using the 'may_alias' attribute in the 64-bit version
> suppresses the warning, although I think this qualifies as a workaround, not a
> fix to the problem. I'm a
--- Comment #4 from hutchinsonandy at gcc dot gnu dot org 2009-11-21 01:35
---
Subject: Bug 42114
Author: hutchinsonandy
Date: Sat Nov 21 01:34:51 2009
New Revision: 154392
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154392
Log:
PR Testsuite/42114
* gcc-dg/c99-stdint-1.c: Co
GCC 4.5.0 20091119 (r154346)
../../gcc-4.5/gcc/gengtype-parse.c: In function
âarray_and_function_declarators_optâ:
../../gcc-4.5/gcc/gengtype-parse.c:508:1: error: verify_flow_info: Wrong
frequency of block 13 -184951
../../gcc-4.5/gcc/gengtype-parse.c:508:1: internal compiler error:
verify_fl
--- Comment #9 from jvdelisle at gcc dot gnu dot org 2009-11-21 02:44
---
Subject: Bug 42090
Author: jvdelisle
Date: Sat Nov 21 02:44:01 2009
New Revision: 154397
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154397
Log:
2009-11-20 Jerry DeLisle
PR libgfortran/4209
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |paolo dot carlini at oracle
|dot org
--- Comment #10 from jvdelisle at gcc dot gnu dot org 2009-11-21 02:46
---
Subject: Bug 42090
Author: jvdelisle
Date: Sat Nov 21 02:45:48 2009
New Revision: 154398
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154398
Log:
2009-11-20 Jerry DeLisle
PR libgfortran/420
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Summary|Can't explicitly specialize |[DR 147] Can't explicitly
|C++ constructor templates
--- Comment #11 from jvdelisle at gcc dot gnu dot org 2009-11-21 03:33
---
Fixed and closing.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from aoliva at gcc dot gnu dot org 2009-11-21 05:04 ---
Subject: Bug 42078
Author: aoliva
Date: Sat Nov 21 05:04:30 2009
New Revision: 154400
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154400
Log:
gcc/ChangeLog:
PR tree-optimization/42078
* gimple.h (gimple_re
ICE in compiling libgcc2.c (--target=h8300-elf) with -msx (with or without -mn
-mint32)
../../../../../gcc-svn/libgcc/../gcc/libgcc2.c: In function e__negdi2f:
../../../../../gcc-svn/libgcc/../gcc/libgcc2.c:76:1: internal compiler error:
in dwarf2out_begin_epilogue, at dwarf2out.c:2840
To fix t
--- Comment #11 from jason at gcc dot gnu dot org 2009-11-21 06:34 ---
Subject: Bug 9050
Author: jason
Date: Sat Nov 21 06:33:56 2009
New Revision: 154403
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154403
Log:
PR c++/9050, DR 147, DR 318
* parser.c (cp_parser
1 - 100 of 102 matches
Mail list logo
