Hi,
Please take a look at the testcase faadd.c:
--
int foo (int * p, int i)
{
return __sync_fetch_and_add(p, i);
}
int n = 1;
int main()
{
printf("%d %d\n", foo (&n, n), n);
return 0;
}
---
--- Comment #1 from ubizjak at gmail dot com 2009-06-17 07:32 ---
Works for 4.4.1 and 4.5.0
--
ubizjak at gmail dot com changed:
What|Removed |Added
Known to work|
--- Comment #1 from jakub at gcc dot gnu dot org 2009-06-17 08:04 ---
That's undefined behavior, there is no sequence point between the the
evaluation of foo (&n, n) and evaluation of n passed as the next argument.
If foo (&n, n) is evaluated first, you will see 1 2 printed, if n is eval
--- Comment #23 from irar at il dot ibm dot com 2009-06-17 08:22 ---
(In reply to comment #22)
> My understanding is that ([istarget *-*-darwin*] && [is-effective-target
> lp64])
> should return false for -m32 and true for -m64. At least it is how it works on
> other tests I have looked
--- Comment #1 from ramana at gcc dot gnu dot org 2009-06-17 08:29 ---
Could you specify which version of the source tree this was ?
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
I use:
GNU Fortran (GCC) 4.5.0 20090617 (experimental)
Copyright (C) 2009 Free Software Foundation, Inc.
The following piece of code breaks f951 (hangs forever):
REAL, DIMENSION(720,360) :: ZLON_MASK
ZLON_MASK(:,:)= SPREAD( (/ (JLON , JLON=1,720) /) , DIM=2, NCOPIES=360 )
END
--- Comment #2 from janus at gcc dot gnu dot org 2009-06-17 08:33 ---
The test case is also rejected without being inside a module:
contains
function f()
intrinsic :: sin
procedure(sin), pointer :: f
f => sin
end function f
end
However, if the 'contains' is removed, it
--- Comment #6 from rearnsha at arm dot com 2009-06-17 08:40 ---
Subject: Re: use stm and ldm to access consecutive
memory words
> --- Comment #5 from ubizjak at gmail dot com 2009-06-16 18:16 ---
> Registers also need to be consecutive, starting from certain register,
--- Comment #3 from janus at gcc dot gnu dot org 2009-06-17 08:54 ---
The error also goes away if 'implicit none' is inserted.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from ubizjak at gmail dot com 2009-06-17 09:18 ---
See Comment #2!
I tried to enhance ix86_secondary_reload target macro to return XMM
intermediate reg with movdi_to_sse handler for DImode -> DFmode moves. However,
handling of this macro has plenty of FIXMEs, and I was no
--- Comment #1 from dfranke at gcc dot gnu dot org 2009-06-17 09:19 ---
The new simplifier, probably.
Without checking, I'd think that it doesn't hang, but would complete after a
significant amount of time. My guess: the time is spent to traverse the list to
append new elements to the c
/* When compiled with -g -O -mno-sched-prolog, the debug info location
lists for p1 and p2 do not cover the start of f. There are other
inaccuracies, but not covering the start of the function is specific
to -nno-sched-prolog. */
int f (int p1, int p2)
{
extern int bar (int);
int x,
--- Comment #1 from amodra at bigpond dot net dot au 2009-06-17 09:21
---
See http://sourceware.org/bugzilla/show_bug.cgi?id=10231
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40473
--- Comment #4 from janus at gcc dot gnu dot org 2009-06-17 09:26 ---
Mine. Here's a patch:
Index: gcc/fortran/symbol.c
===
--- gcc/fortran/symbol.c(revision 148518)
+++ gcc/fortran/symbol.c(working copy)
@@
--- Comment #7 from carrot at google dot com 2009-06-17 09:30 ---
My command line option is -O2 -Os -mthumb
The compiler didn't run into load_multiple_sequence and
store_multiple_sequence. The peephole rules specified it applies to TARGET_ARM
only. Is there any special reason we didn't
--- Comment #8 from ramana at gcc dot gnu dot org 2009-06-17 09:49 ---
(In reply to comment #7)
> My command line option is -O2 -Os -mthumb
>
> The compiler didn't run into load_multiple_sequence and
> store_multiple_sequence. The peephole rules specified it applies to TARGET_ARM
> only
--- Comment #2 from hailijuan at gmail dot com 2009-06-17 10:07 ---
Subject: Re: __sync_fetch_and_add seems not working well for
-march=i686
Yes, I have seen the difference. Thanks muchly. I will close it.
2009/6/17 jakub at gcc dot gnu dot org :
>
>
> --- Comment #1 from
--- Comment #2 from joseph at codesourcery dot com 2009-06-17 10:13 ---
Subject: Re: linux-eabi.h:79:36: error: identifier "not"
is a special operator name in C++
On Wed, 17 Jun 2009, ramana at gcc dot gnu dot org wrote:
> Could you specify which version of the source tree this was ?
--- Comment #24 from dominiq at lps dot ens dot fr 2009-06-17 10:17 ---
(In reply to comment #23)
If I add to vect-42.c (with my patch) the line
/* { dg-final { scan-tree-dump-times "bla bla bla" 1 "vect" { target
vector_alignment_reachable } } } */
I get:
Running target unix
Using /s
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-06-17 10:26 ---
Subject: Bug 40460
Author: rguenth
Date: Wed Jun 17 10:26:24 2009
New Revision: 148593
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148593
Log:
2009-06-17 Richard Guenther
PR middle-end/40460
--- Comment #7 from rguenth at gcc dot gnu dot org 2009-06-17 10:27 ---
Fixed on the trunk.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Known to w
--- Comment #26 from rguenth at gcc dot gnu dot org 2009-06-17 10:29
---
Subject: Bug 40389
Author: rguenth
Date: Wed Jun 17 10:29:22 2009
New Revision: 148597
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148597
Log:
2009-06-17 Richard Guenther
PR tree-optimizatio
--- Comment #27 from rguenth at gcc dot gnu dot org 2009-06-17 10:34
---
Subject: Bug 40389
Author: rguenth
Date: Wed Jun 17 10:33:31 2009
New Revision: 148601
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148601
Log:
2009-06-17 Richard Guenther
PR middle-end/40389
--- Comment #25 from irar at il dot ibm dot com 2009-06-17 11:06 ---
(In reply to comment #24)
> If I add to vect-42.c (with my patch) the line
>
> /* { dg-final { scan-tree-dump-times "bla bla bla" 1 "vect" { target
vector_alignment_reachable } } } */
...
> i.e., the test is done for -m
--
aldyh at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|aldyh at gcc dot gnu dot org|unassigned at gcc dot gnu
|
--
aldyh at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|aldyh at gcc dot gnu dot org|unassigned at gcc dot gnu
|
When compiling a C or C++ program with gcc 4.3 (and 4.4), there is no longer a
warning about "no newline at end of file".
I work with people that use gcc 4.2, which emits the warning, and we use
-Werror, so this is a major hindrance for us.
I'm attaching a trivial C program:
$ gcc-4.2 -o newline
--- Comment #1 from rlerallut at free dot fr 2009-06-17 11:41 ---
Created an attachment (id=18011)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18011&action=view)
Trivial program that does *not* end with a newline
Make sure that your editor does not add silently a newline charact
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-06-17 11:47 ---
It is.
*** This bug has been marked as a duplicate of 22456 ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #21 from rguenth at gcc dot gnu dot org 2009-06-17 11:47
---
*** Bug 40469 has been marked as a duplicate of this bug. ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #8 from rguenth at gcc dot gnu dot org 2009-06-17 11:55 ---
Subject: Bug 40460
Author: rguenth
Date: Wed Jun 17 11:54:55 2009
New Revision: 148602
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148602
Log:
2009-06-17 Richard Guenther
PR middle-end/40460
--- Comment #18 from rguenther at suse dot de 2009-06-17 11:57 ---
Subject: Re: [4.4 Regression] gcc.c-torture/execute/va-arg-trap-1.c
ICEs on powerpc-apple-darwin9
On Wed, 17 Jun 2009, amylaar at gcc dot gnu dot org wrote:
> --- Comment #17 from amylaar at gcc dot gnu dot org 2
--- Comment #26 from dominiq at lps dot ens dot fr 2009-06-17 11:58 ---
Created an attachment (id=18012)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18012&action=view)
dump file with -fdump-tree-vect-details default (-m32) for revision 148502.
Summary:
[karma] f90/bug% grep pee
--- Comment #22 from manu at gcc dot gnu dot org 2009-06-17 12:00 ---
This bug is about not warning for an empty loop (the empty loop is removed and
there is no warning). Since we don't care (enough to find a fix) about this
case, this bug is considered INVALID.
--
manu at gcc dot gn
--- Comment #9 from rguenth at gcc dot gnu dot org 2009-06-17 12:00 ---
Subject: Bug 40460
Author: rguenth
Date: Wed Jun 17 12:00:40 2009
New Revision: 148603
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148603
Log:
2009-06-17 Richard Guenther
PR middle-end/40460
--- Comment #2 from manu at gcc dot gnu dot org 2009-06-17 12:02 ---
No, it is not. There is no loop here, this is CCP assuming that res is 0
always.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #28 from rguenth at gcc dot gnu dot org 2009-06-17 12:03
---
Subject: Bug 40389
Author: rguenth
Date: Wed Jun 17 12:03:08 2009
New Revision: 148604
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148604
Log:
2009-06-17 Richard Guenther
PR middle-end/40389
--- Comment #27 from dominiq at lps dot ens dot fr 2009-06-17 12:03 ---
Created an attachment (id=18013)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18013&action=view)
dump file with -fdump-tree-vect-details -m64 for revision 148502.
Summary:
[karma] f90/bug% grep peeling vect-
--- Comment #3 from manu at gcc dot gnu dot org 2009-06-17 12:03 ---
... so this is actually a duplicate of bug 18501.
*** This bug has been marked as a duplicate of 18501 ***
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #10 from rguenth at gcc dot gnu dot org 2009-06-17 12:03
---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNE
--- Comment #27 from manu at gcc dot gnu dot org 2009-06-17 12:03 ---
*** Bug 40469 has been marked as a duplicate of this bug. ***
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #29 from rguenth at gcc dot gnu dot org 2009-06-17 12:04
---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNE
--- Comment #28 from rguenth at gcc dot gnu dot org 2009-06-17 12:06
---
We are not going to fix this.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-06-17 12:06 ---
*** This bug has been marked as a duplicate of 18501 ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #29 from rguenth at gcc dot gnu dot org 2009-06-17 12:06
---
*** Bug 30542 has been marked as a duplicate of this bug. ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #30 from manu at gcc dot gnu dot org 2009-06-17 12:09 ---
(In reply to comment #28)
> We are not going to fix this.
>
Why? There are many ways to alleviate this. Doing some warnings in the
front-ends, such LLVM does is one. Or propagate some "uninitialized" bit, that
can ch
--- Comment #28 from dominiq at lps dot ens dot fr 2009-06-17 12:12 ---
Does the following patch makes more sense for you:
--- ../_gcc_clean/gcc/testsuite/gcc.dg/vect/vect-42.c 2009-06-05
18:02:02.0 +0200
+++ gcc/testsuite/gcc.dg/vect/vect-42.c 2009-06-17 14:08:50.0 +0
--- Comment #31 from manu at gcc dot gnu dot org 2009-06-17 12:17 ---
(In reply to comment #30)
> (In reply to comment #28)
> > We are not going to fix this.
> >
>
> Why? There are many ways to alleviate this. Doing some warnings in the
> front-ends, such LLVM does is one. Or propagate
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-06-17 12:28 ---
Subject: Bug 40404
Author: rguenth
Date: Wed Jun 17 12:28:43 2009
New Revision: 148605
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148605
Log:
2009-06-17 Richard Guenther
PR middle-end/40404
--- Comment #7 from rguenth at gcc dot gnu dot org 2009-06-17 12:31 ---
Subject: Bug 40404
Author: rguenth
Date: Wed Jun 17 12:30:54 2009
New Revision: 148606
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148606
Log:
2009-06-17 Richard Guenther
PR middle-end/40404
On Linux/ia64, revision 148518 gave:
FAIL: gcc.dg/vect/vect-nest-cycle-1.c scan-tree-dump-times vect "OUTER LOOP
VECTORIZED" 1
FAIL: gcc.dg/vect/vect-nest-cycle-2.c scan-tree-dump-times vect "OUTER LOOP
VECTORIZED" 1
Revision 148510 is OK.
--
Summary: [4.5 Regression] gcc.dg/vect/ve
--- Comment #20 from rguenth at gcc dot gnu dot org 2009-06-17 12:34
---
WONTFIX for 4.3. Alias fixes are considered too risky at this stage.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #19 from rguenth at gcc dot gnu dot org 2009-06-17 12:35
---
WONTFIX for 4.3.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Stat
--- Comment #13 from rguenth at gcc dot gnu dot org 2009-06-17 12:37
---
WONTFIX for 4.3. Alias fixes are considered too risky at this stage.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #9 from rguenth at gcc dot gnu dot org 2009-06-17 12:37 ---
WONTFIX for 4.3. Alias fixes are considered too risky at this stage.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #10 from rguenth at gcc dot gnu dot org 2009-06-17 12:38
---
WONTFIX for 4.3. Alias fixes are considered too risky at this stage.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #29 from irar at il dot ibm dot com 2009-06-17 12:40 ---
Oh, so the first dump you attached (in comment #11) was for -m32. Now it makes
sense.
I think, we have to distinguish between vect_no_align and the other cases. I
will prepare a patch tomorrow.
Thanks,
Ira
--
htt
--- Comment #10 from rguenth at gcc dot gnu dot org 2009-06-17 12:40
---
I have no plans for fixing the branches.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
$ cat test.c
struct R
{
char c;
}
struct R
{
struct R r;
}
int main(void)
{
struct R r;
return 0;
}
$ gcc test.c
test.c:7: error: redefinition of struct R
test.c:11: error: two or more data types in declaration specifiers
test.c:11: error: two or more data type
--- Comment #1 from irar at il dot ibm dot com 2009-06-17 12:46 ---
Could you please attach a vectorizer dump for one of them? I need to know what
prevented vectorization.
Thanks,
Ira
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40475
--- Comment #30 from dominiq at lps dot ens dot fr 2009-06-17 12:48 ---
> Oh, so the first dump you attached (in comment #11) was for -m32. Now it
> makes sense.
Since I started to have some doubts about it, I redid it for both cases to be
sure.
--
http://gcc.gnu.org/bugzilla/show
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-06-17 12:51 ---
C frontend issue.
The gimplfier is fed (*fp)(0) with fp of type void (*) (const int) but then,
after gimplifying foo we do patch fps type to void (*) (int):
Hardware watchpoint 4: *$2
Old value = (tree) 0xb7d4e230
--- Comment #2 from dominiq at lps dot ens dot fr 2009-06-17 12:57 ---
> Without checking, I'd think that it doesn't hang, but would complete after a
> significant amount of time. My guess: the time is spent to traverse the list
> to
> append new elements to the constructor ...
You're
--- Comment #32 from rguenth at gcc dot gnu dot org 2009-06-17 12:59
---
We can only fix it with the chance of raising more spurious warnings. One
reason why we run the "may be used uninitialized" pass very late.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18501
--- Comment #7 from aldyh at gcc dot gnu dot org 2009-06-17 13:00 ---
Fix for func-ptr-conv-1.c failure.
http://gcc.gnu.org/ml/gcc-patches/2009-06/msg01344.html
--
aldyh at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-06-17 13:02 ---
Works for me.
gcc-4.2 --version
gcc-4.2 (GCC) 4.2.4 (Debian 4.2.4-6)
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even fo
--
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=40475
--- Comment #5 from dominiq at lps dot ens dot fr 2009-06-17 13:04 ---
Note that the latest release of g95 gives now:
E
S, S
E
S, S
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40443
--- Comment #8 from rguenth at gcc dot gnu dot org 2009-06-17 13:06 ---
Subject: Bug 40404
Author: rguenth
Date: Wed Jun 17 13:06:21 2009
New Revision: 148610
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148610
Log:
2009-06-17 Richard Guenther
PR middle-end/40404
--- Comment #9 from rguenth at gcc dot gnu dot org 2009-06-17 13:07 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
This option should just be removed.
Sent from my iPhone
On Jun 17, 2009, at 2:21 AM, "amodra at bigpond dot net dot au" > wrote:
--- Comment #1 from amodra at bigpond dot net dot au 2009-06-17
09:21 ---
See http://sourceware.org/bugzilla/show_bug.cgi?id=10231
--
http://gcc.g
--- Comment #2 from pinskia at gmail dot com 2009-06-17 13:12 ---
Subject: Re: -mno-sched-prolog breaks function parameter debug location lists
This option should just be removed.
Sent from my iPhone
On Jun 17, 2009, at 2:21 AM, "amodra at bigpond dot net dot au"
wrote:
>
>
> -
--- Comment #33 from manu at gcc dot gnu dot org 2009-06-17 13:25 ---
(In reply to comment #32)
> We can only fix it with the chance of raising more spurious warnings. One
> reason why we run the "may be used uninitialized" pass very late.
The solution of moving the passes around has b
--- Comment #2 from joseph at codesourcery dot com 2009-06-17 13:35 ---
Subject: Re: New: gcc 4.3 no longer warns about missing newlines
at end of files (regression from 4.2)
On Wed, 17 Jun 2009, rlerallut at free dot fr wrote:
> When compiling a C or C++ program with gcc 4.3 (and 4
--- Comment #3 from rlerallut at free dot fr 2009-06-17 13:51 ---
(In reply to comment #2)
> This is deliberate; see bug 14331.
Err... What happened to following the standard ?
"
If a source file that is not empty
does not end in a new-line character, or ends in a new-line ch
--- Comment #34 from rguenth at gcc dot gnu dot org 2009-06-17 13:55
---
Huh. Well then.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Stat
--- Comment #35 from rguenth at gcc dot gnu dot org 2009-06-17 13:56
---
> The solution of moving the passes around has been discarded long ago. There
> are
> other possible solutions.
so, what are these? Once we removed the uninitialized use (CCP) we cannot
recover the information.
--- Comment #4 from joseph at codesourcery dot com 2009-06-17 13:59 ---
Subject: Re: gcc 4.3 no longer warns about missing newlines at
end of files (regression from 4.2)
On Wed, 17 Jun 2009, rlerallut at free dot fr wrote:
> (In reply to comment #2)
> > This is deliberate; see bug 14
--- Comment #2 from mikpe at it dot uu dot se 2009-06-17 14:08 ---
(In reply to comment #1)
> Works for 4.4.1 and 4.5.0
ICEs for me with today's 4.4 branch on i686-linux. The -O0 -fstack-protector
combination is key, with -O1 and above it works, ditto without
-fstack-protector.
--
--- Comment #5 from rlerallut at free dot fr 2009-06-17 14:15 ---
(In reply to comment #4)
> Behavior being undefined means no requirement for a diagnostic, and the
> phase 1 mapping can introduce this newline in any case.
Allright, so if I develop my code with gcc 4.3, I have no way o
--- Comment #2 from hjl dot tools at gmail dot com 2009-06-17 14:16 ---
A patch is posted at
http://gcc.gnu.org/ml/gcc-patches/2009-06/msg01355.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
---
--- Comment #2 from hjl dot tools at gmail dot com 2009-06-17 14:24 ---
Created an attachment (id=18014)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18014&action=view)
Vectorizer dump
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40475
--- Comment #3 from hjl dot tools at gmail dot com 2009-06-17 14:24 ---
Created an attachment (id=18015)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18015&action=view)
Vectorizer dump
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40475
--- Comment #6 from joseph at codesourcery dot com 2009-06-17 14:28 ---
Subject: Re: gcc 4.3 no longer warns about missing newlines at
end of files (regression from 4.2)
On Wed, 17 Jun 2009, rlerallut at free dot fr wrote:
> And what happened to configuration flags ?
Configuration
--- Comment #3 from amodra at bigpond dot net dot au 2009-06-17 14:36
---
Created an attachment (id=18016)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18016&action=view)
patch proposal
Actually, it doesn't look all that hard to fix. The attached patch is a little
horrible in t
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40156
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40181
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40341
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40342
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40435
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40468
--- Comment #16 from rguenth at gcc dot gnu dot org 2009-06-17 15:12
---
Back to P2. Testing a backport.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #15 from rguenth at gcc dot gnu dot org 2009-06-17 15:12
---
Testing a backport.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Assig
--- Comment #1 from heydowns at borg dot com 2009-06-17 15:13 ---
This also applies to Solaris x86.
Additionally, this only applies to Solaris 10 and later. Earlier versions of
Solaris did not ship c99-compliant C library and thus do not have the
values-xpg6.o object file for enabling c
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-06-17 15:24 ---
GCC 3.4.x is no longer maintained, please check GCC 4.3.x or newer.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #3 from joseph at codesourcery dot com 2009-06-17 15:34 ---
Subject: Re: -std=c99 does not enable c99 mode in Solaris
C library
On Wed, 17 Jun 2009, rguenth at gcc dot gnu dot org wrote:
> GCC 3.4.x is no longer maintained, please check GCC 4.3.x or newer.
It is a matter
--- Comment #3 from hjl dot tools at gmail dot com 2009-06-17 15:38 ---
This fails with gcc 4.5:
[...@gnu-6 gcc]$ cat /tmp/pr40470-1.c
#include
__m128i load (char *);
char *
foo (char *p1, char *p2,
int bmsk, __m128i mask1, __m128i mask2)
{
int len = 0;
__m128i frag1, frag2;
--- Comment #3 from dave at hiauly1 dot hia dot nrc dot ca 2009-06-17
15:38 ---
Subject: Re: linux-eabi.h:79:36: error: identifier "not" is a special operator
name in C++
> > Could you specify which version of the source tree this was ?
>
> This is trunk, version 147956 or later. U
--- Comment #20 from sje at cup dot hp dot com 2009-06-17 15:41 ---
I forgot to put the defect number in the ChangeLog entry but this is fixed with
r148614, a patch to expr.c.
--
sje at cup dot hp dot com changed:
What|Removed |Added
seen on the 4.3 branch
Matthias
gcc -c -g -fkeep-inline-functions -DIN_GCC -W -Wall -Wwrite-strings
-Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition
-Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros
-Wno-overlength-st
1 - 100 of 136 matches
Mail list logo
