--- Comment #3 from jakub at gcc dot gnu dot org 2007-08-31 07:25 ---
Subject: Bug 32914
Author: jakub
Date: Fri Aug 31 07:25:20 2007
New Revision: 127958
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127958
Log:
PR debug/32914
* dwarf2out.c (rtl_for_decl_init):
--- Comment #7 from jakub at gcc dot gnu dot org 2007-08-31 07:27 ---
Subject: Bug 33148
Author: jakub
Date: Fri Aug 31 07:27:40 2007
New Revision: 127959
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127959
Log:
PR rtl-optimization/33148
* simplify-rtx.c (simpl
--- Comment #4 from jakub at gcc dot gnu dot org 2007-08-31 07:30 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #4 from jakub at gcc dot gnu dot org 2007-08-31 07:33 ---
I think the 4.2/4.3 error is just fine, this is mainly a user error.
The crtfiles must not be compiled with any options that will cause
the special sections to be populated with other stuff (be it .ctors, .dtors,
.eh_f
I wrote a simple test of division and remainder results that should always be
true ((a/b)*b+(a%b)==a, with a hardcoded constant for b). In testing a current
source tree (trunk rev 127954), I found that the test properly went away...
unless I later printed out the quotient and remainder values. If
--- Comment #1 from raeburn at raeburn dot org 2007-08-31 07:46 ---
Created an attachment (id=14143)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14143&action=view)
C test case, with description & assembly in comments
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33257
As in 33257, I was playing around with division+remainder code, and found
another case gcc didn't optimize. I was using signed and unsigned variants,
and tried a couple different constants. The test case was optimized properly
with the constant 3 (signed or unsigned math), and with the constant 1
--- Comment #1 from raeburn at raeburn dot org 2007-08-31 07:53 ---
Created an attachment (id=14144)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14144&action=view)
C test case, description and assembly in comments
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33258
On 31 Aug 2007 04:33:12 -, michelin60 at gmail dot com
<[EMAIL PROTECTED]> wrote:
> Regarding the last quote I am led to believe that Mr. Pinski is taking undue
> credit. PR30758 (marked as a duplicate) is the first addressing the
> re-appearance of mayalias. there are another 5 PR, all appear
--- Comment #12 from pinskia at gcc dot gnu dot org 2007-08-31 07:59
---
Subject: Re: GCC-4.3.0 Bootstrap testsuite error increase
On 31 Aug 2007 04:33:12 -, michelin60 at gmail dot com
<[EMAIL PROTECTED]> wrote:
> Regarding the last quote I am led to believe that Mr. Pinski is t
The result of a signed remainder operation with a constant divisor is limited
in absolute value to less than the value of the divisor. Following it with
code to force the remainder to be positive by adjusting the quotient and
remainder values is pretty straightforward. However, if it's written as
--- Comment #1 from raeburn at raeburn dot org 2007-08-31 08:06 ---
Created an attachment (id=14145)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14145&action=view)
C test case, description and assembly in comments
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33259
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirm
--- Comment #1 from anlauf at gmx dot de 2007-08-31 08:20 ---
(In reply to comment #0)
> It does work with ifort, for example.
I works with g95, but fails with xlf, unless I add an
delim='apostrophe' to the open statement.
I the latter case gfortran still fails, so this might be
a bug
--- Comment #5 from rguenth at gcc dot gnu dot org 2007-08-31 08:38 ---
Well, but 4.2/4.3 reject the testcase only if you compile with -fprofile-arcs,
which is bogus.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33216
--- Comment #10 from pcarlini at suse dot de 2007-08-31 08:41 ---
(In reply to comment #8)
> Aren't unused typedefs sometimes useful for static assertions and concept
> checking, using templates?
I understand the general spirit of your concerns. However I'm under the
impression that suc
--- Comment #11 from pcarlini at suse dot de 2007-08-31 08:44 ---
(In reply to comment #7)
> I did not mean to imply that the problem is unsolvable or NP-complete
> or something like that. I just pointed out that usually we rely on
>
> (1) data flow insfrastructure,
> (2) uniquenes
--- Comment #15 from andreagrassi at sogeasoft dot com 2007-08-31 08:57
---
Subject: R: Error in compiling when there is a function with a char parameter
called before its declaration with inline parameters.
Thank you again
Bye and good work.
Le informazioni contenute in questo mess
--- Comment #1 from paolo at gcc dot gnu dot org 2007-08-31 09:11 ---
Subject: Bug 33212
Author: paolo
Date: Fri Aug 31 09:11:43 2007
New Revision: 127962
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127962
Log:
/cp
2007-08-31 Paolo Carlini <[EMAIL PROTECTED]>
PR c+
--- Comment #2 from pcarlini at suse dot de 2007-08-31 09:12 ---
Fixed.
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-08-31 09:29 ---
We don't optimize the following at the tree level either but only combine get's
this.
void foo_u_3_noprint (unsigned x) {
unsigned q = x / 3, r = x % 3;
if (q * 3 + r != x) abort();
}
--
http://gcc.gnu.
The following program produces a variable scope warning, even when compiled
with -ffor-scope, preventing use of -Werror. The documentation only mentions
warnings being generated if the flag is not given.
int main()
{
int i;
{
for (int i = 0; i < 100; ++i);
--- Comment #13 from cyberflex at mail dot ru 2007-08-31 09:42 ---
(In reply to comment #12)
> Does GCJ's behavior differ from Sun's in this test?
>
Well.. tried that (jdk1.6 i386)
Answer is: at this point NOT. So this is "not an issue"
But while performing this test I found a slight
--- Comment #1 from paolo at gcc dot gnu dot org 2007-08-31 09:45 ---
Subject: Bug 32113
Author: paolo
Date: Fri Aug 31 09:44:54 2007
New Revision: 127963
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127963
Log:
/cp
2007-08-31 Paolo Carlini <[EMAIL PROTECTED]>
PR c+
--- Comment #2 from paolo at gcc dot gnu dot org 2007-08-31 09:55 ---
Subject: Bug 32113
Author: paolo
Date: Fri Aug 31 09:55:43 2007
New Revision: 127965
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127965
Log:
/cp
2007-08-31 Paolo Carlini <[EMAIL PROTECTED]>
PR c+
--- Comment #4 from pcarlini at suse dot de 2007-08-31 09:58 ---
Fixed.
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|ASSIGNED
I have installed gfortran 4.3.0 (version 20070813) on Windows Vista Home
Premium. Trying to compile simple Fortran programs ( gfortran .f )
results in the ( first and only ) error message:
f951: error: unrecognized command line option "-fintrinsic-modules path"
The same gfortran version on Windo
--- Comment #3 from paolo at gcc dot gnu dot org 2007-08-31 09:58 ---
Subject: Bug 32113
Author: paolo
Date: Fri Aug 31 09:57:50 2007
New Revision: 127966
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127966
Log:
/cp
2007-08-31 Paolo Carlini <[EMAIL PROTECTED]>
PR c+
--- Comment #6 from charlet at gcc dot gnu dot org 2007-08-31 10:19 ---
Subject: Bug 4720
Author: charlet
Date: Fri Aug 31 10:19:18 2007
New Revision: 127967
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127967
Log:
2007-08-30 Vincent Celier <[EMAIL PROTECTED]>
PR ad
--- Comment #1 from nickc at redhat dot com 2007-08-31 10:38 ---
Subject: Re: New: m32r: ICE: RTL check: expected elt 0
type 'i' or 'n', have 'w' (rtx const_int) in insn_current_length, at
insn-attrtab.c:29:
RTL check: expected elt 0 type 'i' or 'n', have 'w' (rtx const_int) in
insn_
--- Comment #20 from rguenth at gcc dot gnu dot org 2007-08-31 10:50
---
Works now but still broken with --param max-aliased-vops=0.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30375
--- Comment #21 from rguenth at gcc dot gnu dot org 2007-08-31 10:59
---
Runtime testcase that fails with --param max-aliased-vops=0:
typedef struct _s {
int a;
int b;
int c;
int d;
} s;
extern void abort(void);
void __attribute__((noinline)) g(s *p)
{
if (p->d != 0
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-08-31 10:32
---
Can you paste (or attach as a file) the output of "gfortran -v .f"? In
the error message you get:
unrecognized command line option "-fintrinsic-modules path"
what exactly is the character between -fintrinsic-mod
--- Comment #3 from pcarlini at suse dot de 2007-08-31 10:32 ---
On it.
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot g
--- Comment #7 from charlet at gcc dot gnu dot org 2007-08-31 10:32 ---
This is now fixed.
--
charlet at gcc dot gnu dot org changed:
What|Removed |Added
Stat
--- Comment #2 from joerg dot richter at gedas dot de 2007-08-31 10:44
---
Subject: AW: gfortran 4.3.0 doesn't work on Windows V
ista.
Dear Sir,
The character between modules and path is a -. I just missed to type it into
my bugzilla-message.
I will send the output of
gf
--- Comment #13 from fxcoudert at gcc dot gnu dot org 2007-08-31 11:10
---
Allow me to step in... michelin60, what about discussing constructively? Here
are the comments I can make one the failures and your remarks. Please answer to
them, or ask further questions if something isn't clea
--- Comment #4 from joerg dot richter at gedas dot de 2007-08-31 11:28
---
Subject: AW: gfortran 4.3.0 doesn't work on Windows Vi
sta.
I must confess that I only found the 4.2.0 documentation but not the
gfortran 4.2.0 compiler in a comfortable .exe self installing version (I
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-08-31 11:14
---
(In reply to comment #2)
> The character between modules and path is a -. I just missed to type it into
> my bugzilla-message.
OK.
> By the way: I did not found the option -fintrinsic-modules-path in
> the curre
When I compile the attached source file, the s2_multiway_merge function gets
apparently miscompiled. The do loop near the end of this function loses both of
its terminating conditions and it is compiled to:
.L101:
addl$1, %esi
.L53:
movl-76(%ebp), %edi
movl
--- Comment #1 from mj at ucw dot cz 2007-08-31 11:38 ---
Created an attachment (id=14146)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14146&action=view)
Source file triggering the problem
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33262
--- Comment #5 from pcarlini at suse dot de 2007-08-31 11:41 ---
Fixed in mainline. Frankly, I'm not interested in fixing the issue in the other
branches, taking also into account that it dates back to 3_4...
--
pcarlini at suse dot de changed:
What|Removed
--- Comment #2 from rask at gcc dot gnu dot org 2007-08-31 11:42 ---
It still fails here at revision 127986. I forgot to mention the configure
flags:
--target m32r-unknown-elf --with-newlib --enable-sim --disable-gdb
--disable-nls --enable-checking=yes,rtl
Note in particular that I enabl
--- Comment #4 from paolo at gcc dot gnu dot org 2007-08-31 11:38 ---
Subject: Bug 33210
Author: paolo
Date: Fri Aug 31 11:38:45 2007
New Revision: 127987
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127987
Log:
/cp
2007-08-31 Paolo Carlini <[EMAIL PROTECTED]>
PR c+
--- Comment #7 from vda dot linux at googlemail dot com 2007-08-31 11:30
---
This is unfortunate, it skews busybox's "make bloatcheck" results.
In general, I suppose if generated asm sequences are different -> one of them
is "better" (for some definition of "better") -> gcc generates b
seen with trunk 20070829
=== libffi Summary ===
# of expected passes1108
# of unsupported tests 8
=== libjava tests ===
Running target unix
FAIL: TestClosureGC run
FAIL:
/build/buildd/gcc-snapshot-20070829/src/libjava/testsuite/libjava.jar/Te
When assigning from an array with lower index bound /=1 the lower index bound
is ignored (set to 1). Afaik the lower index bound should be copied from the
target.
PROGRAM TST
IMPLICIT NONE
REAL, TARGET :: A(10:20)
REAL, POINTER :: B(:)
B => A
WRITE(*,*) LBOUND(B,1)
END PROGRAM TST
bash>
seen with trunk 20070829, not seen with the 4.2 ubuntu branch, not seen with
4.1.0. didn't check with the fedora 4.1 branch.
Matthias
=== libjava tests ===
Running target unix
FAIL: noclass execution - gij test
FAIL: pr11951 execution - gij test
FAIL: throwit execution - gij t
--- Comment #1 from andreast at gcc dot gnu dot org 2007-08-31 12:57
---
The failures are solved with PR32758 except the N19990310_02 ones. These happen
on every other arch I have access to. (sparc, darwin, hppa, x86).
The N19990310_02 failures are here since
http://gcc.gnu.org/ml/gcc-
seen with trunk 20070829, on linux targets
=== libjava tests ===
Running target unix
FAIL: N19990310_02 -O3 output - source compiled test
FAIL: N19990310_02 -O3 -findirect-dispatch output - source compiled test
--
Summary: [4.3 regression] N19990310_02 test failure
trunk 20070829, configured with --enable-targets=all, and tested with
RUNTESTFLAGS="--target_board=unix\{,-m64\}:
Matthias
Running target unix/-m64
WARNING: program timed out.
FAIL: libgomp.c/loop-1.c execution test
WARNING: program timed out.
FAIL: libgomp.c/loop-2.c execution test
WARNING: p
--- Comment #1 from dorit at gcc dot gnu dot org 2007-08-31 13:39 ---
(In reply to comment #0)
> The innermost loop in "j" cannot be vectorized because of the
> irregular code in that loop, i.e. the condition "IF ( l.NE.k )". But
> the cond expression is invariant in that loop, so the w
--- Comment #22 from rguenth at gcc dot gnu dot org 2007-08-31 13:56
---
We are clearly missing the use of signInfo.d by the call, thus we should
from the bitmap of clobbered parts of signInfo remove the used parts once we
encounter the call. But somehow we never remove bits from this
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-08-31 13:56
---
This was PR33139. It's fixed on mainline (4.3), but as it's actually not a
regression, it will probably not be backported to the 4.2 branch. Sorry.
*** This bug has been marked as a duplicate of 33139 ***
--
--- Comment #9 from fxcoudert at gcc dot gnu dot org 2007-08-31 13:56
---
*** Bug 33264 has been marked as a duplicate of this bug. ***
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #3 from dorit at gcc dot gnu dot org 2007-08-31 13:57 ---
...
> This is due to data ref analysis problems:
> ./fatigue.f90:14: note: not vectorized: data ref analysis failed
> (*stress_tensor.0_16)[D.1508_168] = D.1513_173
> ./fatigue.f90:14: note: bad data references.
> and
gfortran rejects the following due to the extra (), the same is accepted for
PRINT. I believe this is valid (or if it is invalid, it is also invalid for
PRINT).
print('a'), 'Hello'
write(*,('(a)')) 'Hello'
read (*,('(f3.3)')) a
read '(f3'//'.3)', a
read ('(f3.3)'), a ! Rejected
end
read ('(f3.3)'
--- Comment #1 from patchapp at dberlin dot org 2007-08-31 14:05 ---
Subject: Bug number PR 33232
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2007-08/msg02276.html
--
http://gcc.gnu.org/bugzilla/s
--- Comment #23 from rguenth at gcc dot gnu dot org 2007-08-31 14:13
---
DSE would need to keep track of the "last" partial store to the aggregate and
use that for memory_address_same () check to make
" The single use of the store's virtual definition ensures that
there are no int
--- Comment #1 from burnus at gcc dot gnu dot org 2007-08-31 14:16 ---
Actually, all of the following is affected. The last one fails before
due to PR 33268.
print ('a'), 'Hello'
write(*,('a')) 'Hello'
read (*,('f3.3')) a
read ('f3.3'), a
end
--
http://gcc.gnu.org/bugzilla/show_bug
--- Comment #3 from nickc at redhat dot com 2007-08-31 14:18 ---
Created an attachment (id=14147)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14147&action=view)
Fix length calculation for get_pc pattern
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33132
--- Comment #3 from dorit at gcc dot gnu dot org 2007-08-31 14:18 ---
(In reply to comment #2)
> Subject: Re: Missed opportunities for vectorization due to invariant
> condition
> > Looks like -fno-tree-pre is not enough, because if PRE doesn't do it, then
> > sink
> > does it. When I
--- Comment #4 from nickc at redhat dot com 2007-08-31 14:19 ---
Hi Rask,
Ah, yes, I see what you mean. The uploaded patch should fix this for you.
Please let me know if you have any problems with it.
Cheers
Nick
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33132
--- Comment #4 from spop at gcc dot gnu dot org 2007-08-31 14:19 ---
*** Bug 33246 has been marked as a duplicate of this bug. ***
--
spop at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #4 from spop at gcc dot gnu dot org 2007-08-31 14:19 ---
Duplicate.
*** This bug has been marked as a duplicate of 33113 ***
--
spop at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #24 from rguenth at gcc dot gnu dot org 2007-08-31 14:26
---
Ugh. But of course memory_address_same only checks what the name suggests.
Nowhere do we check for intermediate uses. That whole-aggregate DSE just
cannot work at all.
--
http://gcc.gnu.org/bugzilla/show_bug
On 31 Aug 2007 08:38:43 -, rguenth at gcc dot gnu dot org
<[EMAIL PROTECTED]> wrote:
>
>
> --- Comment #5 from rguenth at gcc dot gnu dot org 2007-08-31 08:38
> ---
> Well, but 4.2/4.3 reject the testcase only if you compile with -fprofile-arcs,
> which is bogus.
With your testcase .
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-08-31 14:31 ---
Subject: Re: [4.1/4.2/4.3 Regression] ICE in named_section_real, at
varasm.c:419
On 31 Aug 2007 08:38:43 -, rguenth at gcc dot gnu dot org
<[EMAIL PROTECTED]> wrote:
>
>
> --- Comment #5 from rguenth at gcc
--- Comment #25 from rguenth at gcc dot gnu dot org 2007-08-31 14:34
---
Aldy, can you look into this again? I tried to simply revert the
whole-aggregate
DSE change, but it went in with the mem-ssa merge :/
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30375
The format must be '(a)' and not 'a', however, gfortran does not diagnose this
in
PRINT ('a'), 'Hello'
NAG f95:
Error: a.f90, line 1: Missing left parenthesis in format specification
ifort:
Error: First non-blank character in a character type format specifier must be a
left parenthesis.
Without
--- Comment #2 from spop at gcc dot gnu dot org 2007-08-31 14:06 ---
Subject: Re: Missed opportunities for vectorization due to invariant condition
> Looks like -fno-tree-pre is not enough, because if PRE doesn't do it, then
> sink
> does it. When I use "-O3 -ftree-vectorize -msse2 -f
--- Comment #5 from nickc at gcc dot gnu dot org 2007-08-31 14:27 ---
Subject: Bug 33132
Author: nickc
Date: Fri Aug 31 14:27:19 2007
New Revision: 127992
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127992
Log:
PR target/33132
* config/m32r/constraints.md: Add W constraint fo
--- Comment #7 from rguenth at gcc dot gnu dot org 2007-08-31 14:38 ---
... how so?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33216
--- Comment #14 from michelin60 at gmail dot com 2007-08-31 14:52 ---
>
> > FAIL: gfortran.dg/nint_2.f90 -O0 execution test
>
This one is annoying, I think I had it fixed (I saw it on numerous targets, and
fixed it on most... I believed it was fixed on all targets). If you are willi
The following code generates a "1" with gcc-4.1 and generates a "2" with a lot
of other compilers (Visual Studio, gcc-3.2, ...). I have read the non-bugs
section on http://gcc.gnu.org/bugs.html (also bug 11751) and I have read about
"sequence points" on http://c-faq.com/expr/seqpoints.html. Still I
--disable-libmudflap --disable-nls --disable-werror
--disable-multilib --with-ibmlongdouble --with-cpu=G4 --enable-clocale=gnu
--with-system-zlib
Thread model: posix
gcc version 4.3.0 20070831 (experimental) (GCC)
/var/tmp/43/build-159/gcc/testsuite/gfortran/../../f951
/var/tmp/43/gcc-4.3.0/gcc
--- Comment #12 from rakdver at gcc dot gnu dot org 2007-08-31 15:34
---
Subject: Bug 33224
Author: rakdver
Date: Fri Aug 31 15:34:45 2007
New Revision: 127996
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127996
Log:
PR rtl-optimization/33224
* loop-iv.c (latc
--- Comment #1 from michelin60 at gmail dot com 2007-08-31 15:36 ---
While I am properly logged in I did not even try using the attachment ptocess
given the difficulties Torsten and myself had with PR33126 and PR33252
--
michelin60 at gmail dot com changed:
What|Remov
--- Comment #15 from michelin60 at gmail dot com 2007-08-31 15:52 ---
> > Regarding the last quote I am led to believe that Mr. Pinski is taking undue
> > credit. PR30758 (marked as a duplicate) is the first addressing the
> > re-appearance of mayalias. there are another 5 PR, all appea
--- Comment #2 from burnus at gcc dot gnu dot org 2007-08-31 16:02 ---
Subject: Bug 33232
Author: burnus
Date: Fri Aug 31 16:01:57 2007
New Revision: 127997
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127997
Log:
2007-08-31 Tobias Burnus <[EMAIL PROTECTED]>
PR fort
--- Comment #81 from pinskia at gcc dot gnu dot org 2007-08-31 16:09
---
*** Bug 33270 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-08-31 16:09 ---
*** This bug has been marked as a duplicate of 11751 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #3 from burnus at gcc dot gnu dot org 2007-08-31 16:22 ---
FIXED for the trunk.
Contrary what I claimed in comment 0, only READ was affected - WRITE was
already properly diagnosed.
--
burnus at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-08-31 16:36
---
Could you compile with "-O0 -fdump-tree-original" and attach the
nint_3.f90.003t.original file (or similarly named)? Could you also run with
"-O1 -fdump-tree-optimized" and attach nint_3.f90.115t.optimized (or sim
--- Comment #12 from debian-gcc at lists dot debian dot org 2007-08-31
17:24 ---
a hppa-linux-gnu -> hppa64-linux-gnu cross compiler builds with this patch.
Matthias
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33029
--- Comment #3 from michelin60 at gmail dot com 2007-08-31 17:24 ---
> Could you compile with "-O0 -fdump-tree-original" and attach the
> nint_3.f90.003t.original file (or similarly named)? Could you also run with
> "-O1 -fdump-tree-optimized" and attach nint_3.f90.115t.optimized (or sim
--- Comment #15 from drow at gcc dot gnu dot org 2007-08-31 17:42 ---
Has Segher's patch been sent to gcc-patches? I've just encountered the ppc64
bootstrap failure too.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31490
--- Comment #2 from debian-gcc at lists dot debian dot org 2007-08-31
18:48 ---
fixed in trunk 20070831, the N19990310_02 failures are tracked in PR33266
--
debian-gcc at lists dot debian dot org changed:
What|Removed |Added
--- Comment #1 from andreast at gcc dot gnu dot org 2007-08-31 18:53
---
The N19990310_02 failures are here since
http://gcc.gnu.org/ml/gcc-cvs/2007-08/msg00523.html.
The failures I see on darwin{x86|ppc} sparc-solaris8, HPUX11.11, ppc-linux and
x86-linux.
--
andreast at gcc dot gn
--- Comment #2 from raeburn at raeburn dot org 2007-08-31 19:04 ---
Subject: Re: New: Wrong evaluation
On Aug 31, 2007, at 11:05, tim dot bruylants at vub dot ac dot be wrote:
> The following code generates a "1" with gcc-4.1 and generates a "2"
> with a lot
> of other compilers (Vi
--- Comment #3 from tim dot bruylants at vub dot ac dot be 2007-08-31
19:05 ---
Can someone please explain me why this behavior is correct according to the
specifications? Isn't the function call issuing a new sequence point? Isn't the
++(*p_a); statement in the function a separate sequ
--- Comment #2 from dgregor at gcc dot gnu dot org 2007-08-31 19:18 ---
Subject: Bug 32597
Author: dgregor
Date: Fri Aug 31 19:18:20 2007
New Revision: 128000
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=128000
Log:
2007-08-31 Douglas Gregor <[EMAIL PROTECTED]>
PR c++
--- Comment #3 from dgregor at gcc dot gnu dot org 2007-08-31 19:19 ---
Fixed
--
dgregor at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #4 from tim dot bruylants at vub dot ac dot be 2007-08-31
19:30 ---
Thank you for this explanation.
A friend of me also found an explaining document on
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n926.htm. Looking at 12.4.1
seems to be the case that I am in... and it's
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-08-31 19:35 ---
They failed with 127910 but now pass with revision 127935. So closing.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #2 from dberlin at gcc dot gnu dot org 2007-08-31 19:35 ---
This one is mine.
--
dberlin at gcc dot gnu dot org changed:
What|Removed |Added
AssignedT
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2007-08-31 19:47
---
gfortran does catch these at run time.
Also, the last case, read ('f3.3'), a, does give a legitimate error:
read ('f3.3'), a
1
Error: UNIT specification at (1) must be an INTEGER expression or a CHARACTER
v
--- Comment #2 from anlauf at gmx dot de 2007-08-31 19:45 ---
(In reply to comment #1)
If I replace the open by:
open(10,delim='apostrophe')
then the file fort.10 contains after the crash:
% cat fort.10
&FOO
A='a'a', /
This looks like a quoting bug.
Jerry?
--
http://gcc.
--- Comment #3 from burnus at gcc dot gnu dot org 2007-08-31 20:02 ---
> gfortran does catch these at run time.
Well, at compile time is nicer ;-)
> Also, the last case, read ('f3.3'), a, does give a legitimate error:
> read ('f3.3'), a
> 1
> Error: UNIT specification at (1) must
Compiling this test case with -O2 -std=c99:
void f(int *restrict r,
int a[restrict 16][16],
int b[restrict 16][16],
int i,
int j)
{
int x;
*r = 0;
for (x = 1; x < 16; ++x)
*r = *r + a[i][x] * b[x][j];
}
does not sink the store to "*r" outside of the loop; we
1 - 100 of 118 matches
Mail list logo
