--- Comment #8 from pault at gcc dot gnu dot org 2007-07-05 06:50 ---
Subject: Bug 32526
Author: pault
Date: Thu Jul 5 06:49:54 2007
New Revision: 126354
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126354
Log:
2007-07-05 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
--- Comment #10 from pault at gcc dot gnu dot org 2007-07-05 06:50 ---
Subject: Bug 32613
Author: pault
Date: Thu Jul 5 06:49:54 2007
New Revision: 126354
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126354
Log:
2007-07-05 Paul Thomas <[EMAIL PROTECTED]>
PR fortran
enable-languages=c,fortran
--with-mpfr=/data/programs/mpfr/
Thread model: posix
gcc version 4.3.0 20070704 (experimental)
/data/vondele/gcc_trunk/build/libexec/gcc/x86_64-unknown-linux-gnu/4.3.0/f951
test.f90 -march=core2 -mcx16 -msahf --param l1-cache-size=512 --param
l1-cache-line-size=64 -mtune
--- Comment #5 from aoliva at gcc dot gnu dot org 2007-07-05 04:50 ---
FWIW, I haven't been able to bootstrap on ppc64-linux-gnu after this patch went
in. I'm not sure I'd tried a full bootstrap before (I've only very recently
got easy access to a ppc box), but the failure is bootstrap
gcc version 4.3.0 20070704 (experimental)
test case derived from linux kernel
struct x {
long a,b,c,d,e,f;
char array[32];
};
void f(struct x *p)
{
p->a = 0;
p->b = 0;
p->c = 0;
p->d = 0;
p->e = 0;
p->f = 0;
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-07-04 23:34 ---
A simple example is:
void *f(void)
{
char *a = ((char*)0)+(unsigned long long)(-1);
return a;
}
This is caused by pointer_plus so mine.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
gcc version 4.3.0 20070704 (experimental)
Following test case derived from the Linux ACPI code warns
toverflow.c: In function 'f':
toverflow.c:8: warning: integer overflow in expression
but the warning is not correct because 0 + ULONG_MAX doesn't really overflow.
typedef vo
--- Comment #6 from dje at gcc dot gnu dot org 2007-07-04 23:24 ---
I use GNU Sed. If we need to add that as a requirement, so be it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31957
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-07-04 22:35 ---
I can't reproduce this on the trunk, unless I am making a mistake. I think
the cross jump is happening now.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30905
--- Comment #15 from pinskia at gcc dot gnu dot org 2007-07-04 22:11
---
For foo4.c
> SCCVN says j_3 value numbers to i_2 (VH.3)
But that is really PR 28868.
The orginal issue here I think is fixed because we now use unsigned int for the
addition.
The IR looks like:
:
d = 2;
preph
--- Comment #4 from dberlin at gcc dot gnu dot org 2007-07-04 22:11 ---
Subject: Bug 32606
Author: dberlin
Date: Wed Jul 4 22:11:14 2007
New Revision: 126338
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126338
Log:
2007-07-04 Daniel Berlin <[EMAIL PROTECTED]>
PR tr
--- Comment #7 from dberlin at gcc dot gnu dot org 2007-07-04 22:11 ---
Subject: Bug 32604
Author: dberlin
Date: Wed Jul 4 22:11:14 2007
New Revision: 126338
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126338
Log:
2007-07-04 Daniel Berlin <[EMAIL PROTECTED]>
PR tr
--- Comment #39 from pinskia at gcc dot gnu dot org 2007-07-04 21:53
---
I think this has been imrpvoed for 4.3, it would be nice if someone did some
timings for 4.3.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19923
--- Comment #21 from kauer at os dot inf dot tu-dresden dot de 2007-07-04
21:50 ---
This simple testcase triggers the bug, too. Unfortunatelly I didnot test the
patch yet.
--
inline void g(int b)
{
register int reg __asm__ ("eax") = 0;
asm volatile ("nop" : "+r"(reg), "+r"(b));
}
--- Comment #19 from pinskia at gcc dot gnu dot org 2007-07-04 21:32
---
> lsti = MEM[index: ivtmp.46, offset: 0x0fffc];
H.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-07-04 21:30 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #5 from aesok at gcc dot gnu dot org 2007-07-04 21:10 ---
Subject: Bug 31331
Author: aesok
Date: Wed Jul 4 21:10:28 2007
New Revision: 126337
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126337
Log:
PR target/31331
* config/avr/avr.c (avr_naked_fun
--- Comment #23 from pinskia at gcc dot gnu dot org 2007-07-04 21:01
---
I am going to declare this as fixed for 4.3, pointer plus gets the original
case correctly and the secondary issues are all file seperately.
--
pinskia at gcc dot gnu dot org changed:
What|Remov
--- Comment #5 from pcarlini at suse dot de 2007-07-04 20:39 ---
David, can you have a quick look at this issue? Thanks.
--
pcarlini at suse dot de changed:
What|Removed |Added
---
--- Comment #9 from patchapp at dberlin dot org 2007-07-04 20:30 ---
Subject: Bug number PR32613
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-07/msg00396.html
--
http://gcc.gnu.org/bugzilla/sh
--- Comment #20 from ubizjak at gmail dot com 2007-07-04 20:10 ---
(In reply to comment #17)
> (the variable should be 0), but it looks like the assembly might be wrong:
> b.s:
> (1)cmpl$9, __cp_log_handling_MOD_stack_pointer(%rip)
> callmcount
> movq%
--- Comment #8 from sgk at troutmask dot apl dot washington dot edu
2007-07-04 20:08 ---
Subject: Re: [4.3 regression] Different results depending on unnecessary
variable declaration
On Wed, Jul 04, 2007 at 08:06:08PM -, pault at gcc dot gnu dot org wrote:
>
>
> --- Comment
--- Comment #19 from pinskia at gmail dot com 2007-07-04 20:07 ---
Subject: Re: -pg seemingly causes miscompilation
On 4 Jul 2007 19:17:22 -, jv244 at cam dot ac dot uk
<[EMAIL PROTECTED]> wrote:
> b.s:
>
> .LCFI15:
> cmpl$9, __cp_log_handling_MOD_stack_pointer(%rip)
>
On 4 Jul 2007 19:17:22 -, jv244 at cam dot ac dot uk
<[EMAIL PROTECTED]> wrote:
b.s:
.LCFI15:
cmpl$9, __cp_log_handling_MOD_stack_pointer(%rip)
callmcount
movq%rdi, %rbx
jle .L21
This is obviosuly wrong as the call will most likely clobber th
--- Comment #7 from pault at gcc dot gnu dot org 2007-07-04 20:06 ---
(In reply to comment #6)
> I read this as: Works in 4.2.x, fails in 4.3, which is also what I get; I
> therefore changed the summary from "4.2 regression" to "4.3 regression".
>
Thanks, Tobias. I was about to check
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
Summary|[ISO Bind C] Accept |[ISO Bind C] Accept
|c_pointer_* for TYPE|c_
From:
http://de.wikibooks.org/w/index.php?title=Fortran:_Fortran_und_C:_Fortran_2003#Datenverbund
/tmp/ccW1yqyk.o: In function `MAIN__':
f.f90:(.text+0x3e): undefined reference to `__iso_c_binding_c_f_pointer_s1'
program main
use iso_c_binding
implicit none
type, bind( c ) :: A
integer
--- Comment #18 from ubizjak at gmail dot com 2007-07-04 19:58 ---
(In reply to comment #12)
> thanks for looking into this, but I'm afraid I don't really understand what
> you're asking for. Also the PR mentioned in the above comment is a circular
> reference.
Sorry for the confusion
--- Comment #4 from joerg dot richter at pdv-fs dot de 2007-07-04 19:48
---
Any chance that this gets fixed with 4.2.1? This is the only thing on AIX that
prevents an unpatched bootstrap.
Or perhaps its only missing documentation that GNU sed must be used.
--
http://gcc.gnu.org/bug
--- Comment #4 from woody77 at gmail dot com 2007-07-04 19:22 ---
Marco,
thanks for the pointer to JNC. I'm targeting an embedded platform, with only
32MB of storage, so reducing the classes needed is mandatory.
>From the size of the executable, it looked like the linker had just fail
--- Comment #17 from jv244 at cam dot ac dot uk 2007-07-04 19:17 ---
actually, in gdb, I find that the variable is not corrupted:
(gdb) bt
#0 0x0089dc94 in __message_passing_MOD_mp_stop ()
#1 0x0050ed2e in __cp_log_handling_MOD_cp_add_default_logger ()
#2 0x00
--- Comment #16 from jv244 at cam dot ac dot uk 2007-07-04 19:09 ---
I've added the assembly as obtained from
1044 gfortran -O2 -pg -S cp_log_handling.f90
1045 mv cp_log_handling.s g.s
1046 gfortran -O2 -pg -march=native -S cp_log_handling.f90
1047 mv cp_log_handling.s b.s
(i.e
--- Comment #15 from jv244 at cam dot ac dot uk 2007-07-04 19:03 ---
Created an attachment (id=13848)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13848&action=view)
good assembly
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32450
--- Comment #14 from jv244 at cam dot ac dot uk 2007-07-04 19:02 ---
Created an attachment (id=13847)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13847&action=view)
bad assembly
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32450
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |mark at codesourcery dot com
|dot org
--- Comment #13 from jv244 at cam dot ac dot uk 2007-07-04 18:51 ---
just checked that current trunk (Wed Jul 4 17:21:37 UTC 2007 (revision
126328)) still exhibits the same problem. I don't see the same problem on an
opteron, only on a core2 (both using -march=native), so it could be so
--- Comment #1 from burnus at gcc dot gnu dot org 2007-07-04 18:48 ---
Related:
print *, c_loc(4)
end
gives an ICE. Expected:
Error: .f90, line 5: The argument to C_LOC must be a pointer or target
additionally with -std=f2003:
Error: .f90, line 5: Derived type C_PTR in io-l
--- Comment #2 from jv244 at cam dot ac dot uk 2007-07-04 18:34 ---
a clean bootstrap passes now
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
St
--- Comment #3 from burnus at gcc dot gnu dot org 2007-07-04 18:29 ---
Clean up from my Bind(C) notes: The following should give an error such as:
Error: 'fptr' argument of 'c_f_procpointer' intrinsic at (1) must be a
PROCEDURE POINTER
use iso_c_binding
type(c_funptr) :: cfunptr
--- Comment #2 from burnus at gcc dot gnu dot org 2007-07-04 18:15 ---
> A more general case as described in PR30939?
Well, my example in PR30939 is actually fixed by PR30940, however, as NAG f95
proofs, one can test this at run time. I thus changed the purpose of that bug.
This PR is
We probably need:
-fcheck-*
with
all
bounds
pointers
recursive
The recursive test is simple. C example:
bla(...)
{
static recursive = 0;
if(recursive)
exit_with_error
recursive = 1
...
recursive = 0; // Last statement
}
--
Summary: Run-time check for recursive functions
--- Comment #6 from burnus at gcc dot gnu dot org 2007-07-04 18:10 ---
> This a regression with respect to 4.2.
I read this as: Works in 4.2.x, fails in 4.3, which is also what I get; I
therefore changed the summary from "4.2 regression" to "4.3 regression".
--
burnus at gcc dot gnu
--- Comment #1 from jv244 at cam dot ac dot uk 2007-07-04 18:00 ---
could be due to an interupted & restarted build. I'm trying again with a clean
build.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32625
> cat ../gcc/LAST_UPDATED
Wed Jul 4 19:21:37 CEST 2007
Wed Jul 4 17:21:37 UTC 2007 (revision 126328)
rm -f stage_current
make[3]: Leaving directory `/data/vondele/gcc_trunk/obj'
Comparing stages 2 and 3
tail: cannot open `/data/vondele/gcc_trunk/obj/stage2-gcc/./32/crtbeginS.o' for
reading: No
--- Comment #18 from pinskia at gcc dot gnu dot org 2007-07-04 17:58
---
Yep this was fixed by Pointer_plus.
The load of hmm->tsc is no longer in the inner most loop.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #5 from pault at gcc dot gnu dot org 2007-07-04 17:44 ---
This is my doing - that makes two this week. *groan*
The regression is caused by the patch for pr31204, which goes back to April.
For some reason that I do not yet see, the variable i in the statement function
is bei
--- Comment #17 from ed at fxq dot nl 2007-07-04 17:35 ---
Sorry if I'm being a nitpick...
The committed testcase contains a small error; it has an off-by-one bug that
causes a small buffer overflow.
The line:
foo(numbers[i]);
should be replaced with:
foo(numbers[i - 1])
--- Comment #9 from mmitchel at gcc dot gnu dot org 2007-07-04 17:27
---
Fixed in 4.2.1.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Assigned
--- Comment #8 from mmitchel at gcc dot gnu dot org 2007-07-04 17:18
---
Subject: Bug 31338
Author: mmitchel
Date: Wed Jul 4 17:18:22 2007
New Revision: 126329
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126329
Log:
PR c++/31388
* cp-tree.h (ARITHMETIC_TYPE)
--- Comment #4 from mmitchel at gcc dot gnu dot org 2007-07-04 17:18
---
Subject: Bug 31388
Author: mmitchel
Date: Wed Jul 4 17:18:22 2007
New Revision: 126329
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126329
Log:
PR c++/31388
* cp-tree.h (ARITHMETIC_TYPE)
--- Comment #7 from patchapp at dberlin dot org 2007-07-04 17:15 ---
Subject: Bug number PR32526
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-07/msg00381.html
--
http://gcc.gnu.org/bugzilla/sh
--- Comment #11 from pinskia at gcc dot gnu dot org 2007-07-04 17:02
---
>Which is almost the best you can do :).
Well except to use store with update but that is an IV-OPTs issue.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16913
--- Comment #1 from jakub at gcc dot gnu dot org 2007-07-04 16:35 ---
Created an attachment (id=13846)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13846&action=view)
gcc43-pr32337.patch
The problem seems to be caused by the addition of the
emitted_frame_related_regs
array, there
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-07-04 16:31 ---
So, the following patch brings performance back in-line:
Index: tree-inline.c
===
--- tree-inline.c (revision 126325)
+++ tree-inline.c (wo
--- Comment #4 from kargl at gcc dot gnu dot org 2007-07-04 16:27 ---
Add wrong-code keyword.
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
Keywo
--- Comment #3 from kargl at gcc dot gnu dot org 2007-07-04 16:25 ---
I thought I had confirmed this as a bug. Let's try again.
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #2 from kargl at gcc dot gnu dot org 2007-07-04 16:24 ---
I've compared the output of -fdump-tree-original for 4.2 and trunk, and
the only significant difference is
internal (j)
{
int4 k;
+ int4 i;
logical4 __result_internal;
That is, the implicitly typed 'i' in tr
--- Comment #4 from pcarlini at suse dot de 2007-07-04 16:16 ---
Feedback not forthcoming.
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|WAIT
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-07-04 16:12 ---
Created an attachment (id=13845)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13845&action=view)
alias6 dump of the function with the patch
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32624
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-07-04 16:12 ---
Created an attachment (id=13844)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13844&action=view)
alias6 dump of the function without the patch
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32624
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-07-04 16:11 ---
This seems to be an aliasing problem. Somehow we do not prune SMTs enough
after
the patch. MPT grouping doesn't trigger in.
An example function to look at is (x86_64)
_ZN14MultiArgKernelI9MultiArg4I5FieldI22Unifor
--- Comment #5 from pcarlini at suse dot de 2007-07-04 15:34 ---
Therefore, can we close the PR?
--
pcarlini at suse dot de changed:
What|Removed |Added
C
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2007-07-04 15:23
---
OK, you talked me into it. :)
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from jv244 at cam dot ac dot uk 2007-07-04 14:51 ---
(In reply to comment #11)
>
> Just a wild guess, could this depend on PR32450? Could you check if there is
> an
> access to stack after leave insn?
>
Hi Uros,
thanks for looking into this, but I'm afraid I don't reall
The following part of r126198 causes a 5% slowdown of tramp3d for the
non-leafify
tests (with leafify it makes it run faster):
2007-07-02 Richard Guenther <[EMAIL PROTECTED]>
* fold-const.c (fold_convert): Revert fix for PR15988.
* tree-inline.c (setup_one_parameter): Instead f
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2007-07-04 14:36
---
Please forget comment #3. The reason for the ICE is that substring
simplification was written without taking into account the possibility of
foo(14:) or foo(:14), ie one of the substring bounds being implicit. The
--- Comment #11 from ubizjak at gmail dot com 2007-07-04 14:26 ---
Hm...
--cut here--
// just a stupid testcase, don't bother with source
long long test(long long a, long long b)
{
return a / b;
}
--cut here--
cc1 -O2:
test:
.LFB2:
movq%rdi, %rdx
movq%rdi, %r
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-07-04 14:24 ---
Here is a reduced testcase which has only one function in it:
int inb(int);
void is870(unsigned int wkport, unsigned char j)
{
unsigned int tmport;
unsigned char i;
for (i = 0; i < 16; i++)
{
tmport = wkport +
--- Comment #14 from dberlin at gcc dot gnu dot org 2007-07-04 14:16
---
Subject: Re: [4.2/4.3 Regression] -fstrict-aliasing causes skipped code
On 4 Jul 2007 03:29:25 -, mmitchel at gcc dot gnu dot org
<[EMAIL PROTECTED]> wrote:
>
>
> --
Just as an update:
I have been working wi
On 4 Jul 2007 03:29:25 -, mmitchel at gcc dot gnu dot org
<[EMAIL PROTECTED]> wrote:
--
Just as an update:
I have been working with richi (I code, he tests :P) diligently on a
patch for mainline, and have one that fixes the dealii regression (and
thus, should fix this as well).
--- Comment #10 from ubizjak at gmail dot com 2007-07-04 14:16 ---
(In reply to comment #9)
> So, it loads %r11 and calls mcount. The only thing that can go wrong is, that
> some value in %r11 gets rewritten.
Not even that because x86_64 is a NO_PROFILE_COUNTERS by default.
--
htt
--- Comment #9 from ubizjak at gmail dot com 2007-07-04 14:11 ---
(In reply to comment #1)
> Most likely -pg is changing the alignment of the stack which is incorrect. Oh
> -pg code is emitted by the target specific code so this is a target issue.
Hm, on x86_64 pg inserts:
fprintf (fi
--- Comment #6 from pault at gcc dot gnu dot org 2007-07-04 14:05 ---
(In reply to comment #5)
OK, I now have it understood. The patch in the previous comment is the clue.
The patch for pr31494 was marking generic interfaces as subroutines, thereby
screwing up the mechanism for detect
--- Comment #20 from bonzini at gnu dot org 2007-07-04 13:54 ---
The attached patch makes PR30311 resurface; this seems like a minor problem
because that code is dubious, and can be worked around by not doing the
transformation when the modes mismatch.
--
http://gcc.gnu.org/bugzilla
--- Comment #5 from spop at gcc dot gnu dot org 2007-07-04 13:42 ---
Subject: Re: BOOT_CFLAGS is not passed to stage2 and stage3 compile
> Actually this is caused by config/mh-x86omitfp. If you disable BOOT_CFLAGS in
> that file, it will just work.
Right, that's also what I saw, and
--- Comment #7 from nickc at redhat dot com 2007-07-04 13:40 ---
Subject: Re: [4.3 Regression] gcc -v --help returns no options
for C, C++
Hi Brooks,
> So, if I understand correctly: all of the options are listed somewhere, but we
> no longer provide any information about which of th
--- Comment #18 from rakdver at gcc dot gnu dot org 2007-07-04 13:32
---
(In reply to comment #0)
> The fix to PR31360 has caused significant code size regressions on ARM-EABI.
> An example of this is from zlib (adler32.c) and is attached, compile with -Os
> -mcpu=arm7tdmi -fno-short-e
--- Comment #3 from nickc at redhat dot com 2007-07-04 13:28 ---
Hi Rask,
Well the patch is definitely an improvement, so I have applied it. I will
try to find time to look at the regressions in the next week or two.
Cheers
Nick
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-07-04 13:27 ---
Actually this is caused by config/mh-x86omitfp. If you disable BOOT_CFLAGS in
that file, it will just work.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from manu at gcc dot gnu dot org 2007-07-04 13:08 ---
(In reply to comment #4)
>
> No idea how to untangle -pedantic from -Wtabs or -Wampersand if
> -pedantic-errors has been given, but -Werror has not.
>
What gfortran should do is that if pedantic enables Wtabs, then th
--- Comment #16 from rguenth at gcc dot gnu dot org 2007-07-04 12:40
---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNE
--- Comment #15 from rguenth at gcc dot gnu dot org 2007-07-04 12:39
---
Subject: Bug 32500
Author: rguenth
Date: Wed Jul 4 12:39:42 2007
New Revision: 126316
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126316
Log:
2007-07-04 Richard Guenther <[EMAIL PROTECTED]>
--- Comment #14 from rguenth at gcc dot gnu dot org 2007-07-04 12:38
---
Subject: Bug 32500
Author: rguenth
Date: Wed Jul 4 12:38:23 2007
New Revision: 126315
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126315
Log:
2007-07-04 Richard Guenther <[EMAIL PROTECTED]>
--- Comment #4 from ubizjak at gmail dot com 2007-07-04 12:32 ---
(In reply to comment #1)
> gfortran -ffast-math -funroll-loops -O3 -msse3 -mfpmath=387 rnflow.f90
>
> time ./a.out
> user0m37.982s
> gfortran -ffast-math -funroll-loops -O3 -msse3 -mfpmath=387 -ftree-vectorize
> rnfl
--- Comment #4 from jakub at gcc dot gnu dot org 2007-07-04 12:31 ---
This doesn't ICE any longer on the trunk.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32032
--- Comment #3 from ubizjak at gmail dot com 2007-07-04 12:29 ---
(In reply to comment #2)
> Can't reproduce this, gcc 4.3 actually seems to be faster (tests done on Intel
> quadcore Core2):
On core2 the bug doesn't trigger, but it shows on FC4 with:
vendor_id : GenuineIntel
cpu
--- Comment #13 from ed at fxq dot nl 2007-07-04 12:06 ---
Hello Richard,
I can confirm that the patch fixes this regression. I just installed a patch
compiler on my FreeBSD box and I get a proper binary, even when I build it with
'-O2 -ftree-vrp' (just to be sure). Thanks!
Any chance
--- Comment #2 from jakub at gcc dot gnu dot org 2007-07-04 11:57 ---
Can't reproduce this, gcc 4.3 actually seems to be faster (tests done on Intel
quadcore Core2):
/usr/src/gcc-4.2/obj/gcc/gfortran -B /usr/src/gcc-4.2/obj/gcc/ -L
/usr/src/gcc-4.2/obj/x86_64-unknown-linux-gnu/32/libgfor
--- Comment #6 from rguenth at gcc dot gnu dot org 2007-07-04 11:46 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #5 from rguenth at gcc dot gnu dot org 2007-07-04 11:45 ---
Subject: Bug 32482
Author: rguenth
Date: Wed Jul 4 11:44:58 2007
New Revision: 126314
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126314
Log:
2007-07-04 Richard Guenther <[EMAIL PROTECTED]>
PR
--- Comment #21 from pault at gcc dot gnu dot org 2007-07-04 11:32 ---
> Warsaw, 18.5 C, overcast. Of course, Paul's work on gfortran is more
> important than anything else :-)
>
There is also the question of what I am expected to do over the weekend after
three weeks away from home
--- Comment #8 from eres at il dot ibm dot com 2007-07-04 11:24 ---
I think c__lsm.63_30 is created during the store motion optimization.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25621
--- Comment #30 from dnovillo at google dot com 2007-07-04 11:22 ---
Subject: Re: [4.2 Regression] Incorrect stack sharing
causing removal of live code
On 7/3/07 11:28 PM, mmitchel at gcc dot gnu dot org wrote:
> --- Comment #29 from mmitchel at gcc dot gnu dot org 2007-07-04 03:
--- Comment #7 from dorit at gcc dot gnu dot org 2007-07-04 11:14 ---
The vectorizer reports:
pr25621.f90:7: note: reduction used in loop.
pr25621.f90:7: note: Unknown def-use cycle pattern.
because of the seemingly redundant assignment:
c__lsm.63_30 = D.1361_38;
which uses the reductio
--- Comment #20 from Tobias dot Schlueter at physik dot uni-muenchen dot de
2007-07-04 10:51 ---
Subject: Re: [4.2/4.3 regression] TRANSPOSE/RESHAPE and
strings
jv244 at cam dot ac dot uk wrote:
> --- Comment #19 from jv244 at cam dot ac dot uk 2007-07-04 10:05 ---
> (In rep
When building for a ColdFire V2 CPU, GCC will prefer using shift-and-add over
multiply, even if multiply would generate code that is smaller and as fast, if
not faster, on the target CPU in question. This happens because the multiply
cost is based on ColdFire version rather than the capabilities. B
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org
|dot org
--- Comment #1 from clemens dot koller at anagramm dot de 2007-07-04 10:34
---
Cannot reproduce this problem on PPC32 with gcc-4.2.0. The result is
with all -Ox correct: 234500
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30595
--- Comment #12 from rguenth at gcc dot gnu dot org 2007-07-04 10:16
---
This is SCEV. From
:;
i_7 = ASSERT_EXPR 4>;
i.10_10 = (unsigned int) i_7;
D.2489_11 = i.10_10 - 7;
if (D.2489_11 <= 2) goto ; else goto ;
we have
Found new range for i.10_10: [5, 12]
Visiting stateme
--- Comment #19 from jv244 at cam dot ac dot uk 2007-07-04 10:05 ---
(In reply to comment #18)
> I'll spend this afternoon on
> it, rather than going on the conference excursion.
depending on location/weather, I'd go for the conference excursion ;-)
--
http://gcc.gnu.org/bugzilla/s
1 - 100 of 133 matches
Mail list logo
