--- 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
--- 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
--- 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=16514action=view)
New Failing Example.
This a more complicated example that still fails after Jerry's fix for the
--- 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 #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 #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
--
rsandifo at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36217
--
rsandifo at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36969
--- 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 #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 #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: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 #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 1;
--- 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 #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
--- 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 #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
--- Comment #6 from mikael dot morin at tele2 dot fr 2008-10-18 12:03
---
updated testcase :
#include complex.h
int main ()
{
float a = 1.;
complex float v;
v = I * 1.; /* works */
v = I * a; /* fails */
return 0;
}
Two conditions seem
--- 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 #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:
bb 2:
D.1235 =
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:
--- 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
--- 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 #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
--- Comment #17 from burnus at gcc dot gnu dot org 2008-10-18 14:53 ---
The problem seems to be that atmkey%name = list of quoted strings reads also
OUTGEO%NLEV=10 as string.
Can you try:
open(file where the namelist is, delim='quote')
in the real program? That unfortunately does not
--- 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 #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 #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 string
--- 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
--- 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
--- 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
--- 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 #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
--- 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 truncated
--- 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
+++ 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
--- 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 at
--- 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 #1 from sabre at nondot dot org 2008-10-18 18:29 ---
Here is the testcase. I should work with -fno-strict-aliasing:
#include stdio.h
#include stdint.h
struct X {
unsigned char pad : 4;
uint64_t a : 64;
uint64_t b : 60;
} __attribute__((packed));
int main (void)
{
--- 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
--- 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=16515action=view)
Proposed patch for this second test case.
Toon and Tobias: Please try this attached patch. This fixes
--- 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
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 ();
--- 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
--- 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
--- 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 redundant
--- 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 #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
48 matches
Mail list logo
