--- Comment #2 from jvdelisle at gcc dot gnu dot org 2008-10-19 04:00
---
Marking this as a duplicate of 37839.
*** This bug has been marked as a duplicate of 37839 ***
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2008-10-19 04:00
---
*** Bug 37842 has been marked as a duplicate of this bug. ***
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #7 from paolo dot carlini at oracle dot com 2008-10-18 23:05
---
The issue with std::pair is now also fixed by:
2008-10-18 Douglas Gregor <[EMAIL PROTECTED]>
* include/bits/stl_pair.h (__may_be_null_pointer_init): New.
(pair::pair): Eliminate the redundan
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-10-18 22:42 ---
4.3 is broken because PTA figures
D.1187_2 = { x.a }
from the constraints
x.0_1 = &x
D.1187_2 = x.0_1 + 64
because the 4.3 branch doesn't have the PTA fixes, in particular
/* If the found variable is n
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-10-18 22:34 ---
It works on the trunk for me with -fno-strict-aliasing, with -fstrict-aliasing
TBAA pruning prunes the points-to set.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |A
For the testcase
typedef struct cpp_token { int type; } cpp_token;
typedef struct _cpp_buff { struct _cpp_buff *next; } _cpp_buff;
extern cpp_token *cpp_get_token ();
extern _cpp_buff *cpp_get_buff ();
static void collect_args (_cpp_buff **pragma_buff)
{
cpp_token *token = _cpp_get_token ();
d
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2008-10-18 22:09
---
hmm, curious.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
Assigned
--- Comment #21 from jvdelisle at gcc dot gnu dot org 2008-10-18 21:48
---
Created an attachment (id=16515)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16515&action=view)
Proposed patch for this second test case.
Toon and Tobias: Please try this attached patch. This fixes act
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-10-18 18:57 ---
I don't see why it _should_ work with -fno-strict-aliasing. It may. Note that
this testcase also violates pointer arithmetic rules - you have a pointer that
doesn't point to a valid object.
On the 4.3 branch we st
--- Comment #1 from sabre at nondot dot org 2008-10-18 18:29 ---
Here is the testcase. I should work with -fno-strict-aliasing:
#include
#include
struct X {
unsigned char pad : 4;
uint64_t a : 64;
uint64_t b : 60;
} __attribute__((packed));
int main (void)
{
struct X x;
u
--- Comment #12 from andreast at gcc dot gnu dot org 2008-10-18 18:22
---
results here: http://gcc.gnu.org/ml/gcc-testresults/2008-10/msg01245.html
and here: http://gcc.gnu.org/ml/gcc-testresults/2008-10/msg01246.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37815
--- Comment #3 from ubizjak at gmail dot com 2008-10-18 18:18 ---
(In reply to comment #2)
> > So the 64bit version is fine, the 32bit version is still funny.
> Default 32bit target doesn't have cmov insn.
> -O3 -m32 -msse produces expected asm:
This is further optimized by the patch a
+++ This bug was initially created as a clone of Bug #37867 +++
Cloning bug on Chris's request.
Running gcc-4.3 -O2 on PR1386.c I get different results than with -O1.
$ gcc-4.3 -O1 PR1386.c && ./a.out
PR1386.c: In function main:
PR1386.c:15: warning: large integer implicitly truncated to unsig
--- Comment #5 from sabre at nondot dot org 2008-10-18 18:11 ---
Please clone/reopen this bug, it should work with -fno-strict-aliasing.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37867
--- Comment #4 from edwintorok at gmail dot com 2008-10-18 18:07 ---
(In reply to comment #3)
> Does it work with -fno-strict-aliasing?
>
It doesn't.
[EMAIL PROTECTED]:~$ g++ -O2 -fno-strict-aliasing x.c
x.c: In function int main():
x.c:15: warning: large integer implicitly truncate
--- Comment #8 from joseph at codesourcery dot com 2008-10-18 18:06 ---
Subject: Re: infinite recursive call to __mulsc3 when
multiplying not-constant complexs
On Sat, 18 Oct 2008, rguenth at gcc dot gnu dot org wrote:
> The question is whether the standard requires actual complex mu
--- Comment #3 from sabre at nondot dot org 2008-10-18 18:06 ---
Does it work with -fno-strict-aliasing?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37867
--- Comment #20 from jvdelisle at gcc dot gnu dot org 2008-10-18 17:46
---
There are a few problems going on here. When writing a namelist with no delim=
specified, we should default to a quote. That is trivial. Then, we also need
to enable finding a namelist object name vs a characte
--- Comment #11 from dick dot hendrickson at gmail dot com 2008-10-18
17:02 ---
Subject: Re: wrong result for vector subscripted array expression in MVBITS
Also, MVBITS is a special case. See the top of page 215 in the F95
standard. The FROM
and TO arguments are allowed to be the sa
--- Comment #2 from ubizjak at gmail dot com 2008-10-18 16:43 ---
(In reply to comment #1)
> So the 64bit version is fine, the 32bit version is still funny.
Default 32bit target doesn't have cmov insn.
-O3 -m32 -msse produces expected asm:
foo:
bsfl8(%esp), %eax
m
--- Comment #19 from toon at moene dot indiv dot nluug dot nl 2008-10-18
15:33 ---
> character*200 :: l = " &NAMINTERP atmkey%ppp = 076,058,062,079, atmkey%nnn = 0
1
> Warning: CHARACTER expression at (1) is being truncated (222/200)
Tobias, you are right - the stri
--- Comment #18 from burnus at gcc dot gnu dot org 2008-10-18 15:12 ---
I think your program is valid. For "tag = list of strings" in a namelist the
quotes are required and delim= is ignored for namelist read/write.
See:
"10.10.1.3 Namelist group object list items"
[...]
"When the next
--- Comment #2 from manu at gcc dot gnu dot org 2008-10-18 15:07 ---
We do not have any way to know that something comes from preprocessor
expansion.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #17 from burnus at gcc dot gnu dot org 2008-10-18 14:53 ---
The problem seems to be that atmkey%name = reads also
OUTGEO%NLEV=10 as string.
Can you try:
open(, delim='quote')
in the real program? That unfortunately does not work for internal I/O as
delim= is not allowed i
--- Comment #16 from burnus at gcc dot gnu dot org 2008-10-18 14:33 ---
character*200 :: l = " &NAMINTERP atmkey%ppp = 076,058,062,079, atmkey%nnn = 0
1
Warning: CHARACTER expression at (1) is being truncated (222/200)
This namelist poses really a challenge:
- NAG f
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-10-18 14:05 ---
You invoke undefined behavior by accessing parts of a and b via
*(1+(uint64_t *) &x). This access is not valid because of C aliasing rules.
--
rguenth at gcc dot gnu dot org changed:
What|Removed
--- Comment #1 from edwintorok at gmail dot com 2008-10-18 13:39 ---
(In reply to comment #0)
> Running gcc-4.3 -O2 on PR1386.c I get different results than with -O1.
>
> $ gcc-4.3 -O2 PR1386.c && ./a.out
> PR1386.c: In function main:
> PR1386.c:15: warning: large integer implicitly t
Running gcc-4.3 -O2 on PR1386.c I get different results than with -O1.
$ gcc-4.3 -O2 PR1386.c && ./a.out
PR1386.c: In function main:
PR1386.c:15: warning: large integer implicitly truncated to unsigned type
PR1386.c:17: warning: large integer implicitly truncated to unsigned type
bad bits: f
--- Comment #7 from rguenth at gcc dot gnu dot org 2008-10-18 12:43 ---
This is because the implementation of __muldc3 uses
return x + I * y;
which if built with -O0 results in a call to __muldc3 ... because this
is what complex lowering at -O0 produces:
:
D.1235 = COMPLEX_EXPR ;
--- Comment #6 from mikael dot morin at tele2 dot fr 2008-10-18 12:03
---
updated testcase :
#include
int main ()
{
float a = 1.;
complex float v;
v = I * 1.; /* works */
v = I * a; /* fails */
return 0;
}
Two conditions seem necessary for t
--- Comment #2 from marco at sitek dot it 2008-10-18 11:54 ---
Hello,
I confirm I could successfully build mips64vrel-elf with gcc 4.2.4. The same
settings. Did not attempt any further build with gcc-4.2-20080507. Thank you.
m.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36217
--- Comment #10 from burnus at gcc dot gnu dot org 2008-10-18 11:36 ---
Somehow reading the bug report first before replying helps ... Ignore the crap
I just wrote.
Dick's (comment 0)
CALL MVBITS ((ILA1(NFV3)), 2, 4, ILA1, 3) !fails
is valid as the first and the fourth argum
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-10-18 11:22 ---
I don't see where the bug is here. So let's turn this into an enhancement
request - to what? - emit these kinds of diagnostics from the preprocessor?
IMHO not a very sane request.
--
rguenth at gcc dot gnu dot
--- Comment #24 from rguenth at gcc dot gnu dot org 2008-10-18 11:17
---
Fixed then. Thanks.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-10-18 11:11 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--- Comment #6 from sylvestre dot ledru at inria dot fr 2008-10-18 10:46
---
I must say that I am very impressed by your reactivity!
Thanks!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37863
--- Comment #9 from burnus at gcc dot gnu dot org 2008-10-18 10:20 ---
(In reply to comment #8)
> ifort returns "2 2" and g95 "2 1". As far as I understand the scalarization
> of elemental procedures, I think g95 is right.
sunf95, openf95, NAG f95 and pathscale's pathf95 also return 2
--
rsandifo at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36969
--
rsandifo at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36217
--- Comment #6 from rsandifo at gcc dot gnu dot org 2008-10-18 09:47
---
*** Bug 36973 has been marked as a duplicate of this bug. ***
--
rsandifo at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from rsandifo at gcc dot gnu dot org 2008-10-18 09:47
---
*** This bug has been marked as a duplicate of 37368 ***
--
rsandifo at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #8 from dominiq at lps dot ens dot fr 2008-10-18 09:31 ---
(In reply to comment #7)
> This prints "2 2" at the moment, which seems quite reasonable to me; or does
> the standard enforce it should print "2 1"?
ifort returns "2 2" and g95 "2 1". As far as I understand the sca
--- Comment #1 from rsandifo at gcc dot gnu dot org 2008-10-18 09:13
---
This was fixed by:
2008-07-09 David Daney <[EMAIL PROTECTED]>
* config/mips/driver-native.c: Include coretypes.h and tm.h.
--
rsandifo at gcc dot gnu dot org changed:
What|Removed
--- Comment #1 from rsandifo at gcc dot gnu dot org 2008-10-18 09:09
---
Can you still reproduce this? TBH, it doesn't really look like a gcc bug, but
I could be wrong.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36217
--- Comment #15 from toon at moene dot indiv dot nluug dot nl 2008-10-18
08:47 ---
Sorry, source code of new example got mangled; I created an attachment
(nl4.f90)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37707
--- Comment #14 from toon at moene dot indiv dot nluug dot nl 2008-10-18
08:46 ---
Created an attachment (id=16514)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16514&action=view)
New Failing Example.
This a more complicated example that still fails after Jerry's fix for the
fir
--- Comment #13 from toon at moene dot indiv dot nluug dot nl 2008-10-18
08:43 ---
Unfortunately, while the original test case has been solved, the original
problem that led me to file this bug report hasn't been ...
Here's a failing example closer to the original source:
TYPE geomet
--- Comment #7 from domob at gcc dot gnu dot org 2008-10-18 08:27 ---
I'm having some difficulties seeing what the problem really is... My
understanding of elemental procedures so far is that they should be more or
less equivalent to looping over the arguments and then performing them a
48 matches
Mail list logo
