--- Comment #6 from domob at gcc dot gnu dot org 2009-01-25 08:36 ---
(In reply to comment #4)
in gfc_conv_elemental_dependencies which then in
gfc_trans_allocate_array_storage gets accessed as:
tmp = TREE_TYPE (initial); /* Pointer to descriptor. */
--- Comment #6 from irar at il dot ibm dot com 2009-01-25 09:12 ---
(In reply to comment #5)
So,
4) The vectorized version sucks because we have to use peeling for niters
because we need to unroll the loop once and cannot apply SLP here.
What do you mean by unroll the loop
--- Comment #19 from tammer at tammer dot net 2009-01-25 09:18 ---
Hello,
I second that.
Bye
Rainer
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38547
--- Comment #4 from pluto at agmk dot net 2009-01-25 09:57 ---
adding try{throw 0;}catch(...){} to main() shows that dw2-exceptions
don't work at all, so it's not related to dll crossing.
new testcase attached.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38920
--- Comment #5 from pluto at agmk dot net 2009-01-25 09:57 ---
Created an attachment (id=17180)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17180action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38920
--- Comment #6 from pluto at agmk dot net 2009-01-25 10:02 ---
maybe this bug is related to PR38952.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38920
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #7 from rguenther at suse dot de 2009-01-25 11:04 ---
Subject: Re: Fortran Complex reduction /
multiplication not vectorized
On Sun, 25 Jan 2009, irar at il dot ibm dot com wrote:
--- Comment #6 from irar at il dot ibm dot com 2009-01-25 09:12 ---
(In
--- Comment #10 from rguenth at gcc dot gnu dot org 2009-01-25 11:15
---
The self-init is of course for the case where the -Wuninitialized warning is
bogus (which happens). It simply has no effect on whatever undefinedness
is in your code - it was added to be a cheaper way instead of
--- Comment #8 from jakub at gcc dot gnu dot org 2009-01-25 11:31 ---
I think it is fine to submit the patch as is, assuming you've
bootstrapped/regtested it. Please mail it to gcc-patches for review.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38857
--- Comment #16 from rguenth at gcc dot gnu dot org 2009-01-25 11:40
---
Mine.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|pinskia
--- Comment #8 from irar at il dot ibm dot com 2009-01-25 12:17 ---
(In reply to comment #7)
Q1: does SLP work with reductions at all?
No. SLP currently originates from groups of strided stores.
Ah, I see. In this loop we have two reductions, so to apply SLP
we would need to
--- Comment #7 from uros at gcc dot gnu dot org 2009-01-25 12:26 ---
Subject: Bug 38931
Author: uros
Date: Sun Jan 25 12:26:15 2009
New Revision: 143663
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143663
Log:
Backport from mainline:
2009-01-22 Uros Bizjak
--- Comment #7 from uros at gcc dot gnu dot org 2009-01-25 12:26 ---
Subject: Bug 38879
Author: uros
Date: Sun Jan 25 12:26:15 2009
New Revision: 143663
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143663
Log:
Backport from mainline:
2009-01-22 Uros Bizjak
--- Comment #8 from ubizjak at gmail dot com 2009-01-25 12:27 ---
Fixed.
--
ubizjak at gmail dot com changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #8 from ubizjak at gmail dot com 2009-01-25 12:28 ---
Backported to 4.3 branch.
--
ubizjak at gmail dot com changed:
What|Removed |Added
Target
The TBAA side-effects of C++ operator/expression new are still not properly
(read: conservatively correct) handled. The current implementation idea of
dealing with that in a flow-insensitive way is going to severely pessimize
optimization.
See
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-01-25 13:21 ---
As soon as we do not have to properly represent this in the virtual use-def
chains (while still being semi-precise) we can deal with this properly.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38964
to keep track of the issue mentioned here
http://gcc.gnu.org/ml/gcc-patches/2009-01/msg00937.html
the frontend should do the right thing here, to make TBAA work just fine.
--
Summary: Fortran has a type merging problem
Product: gcc
Version: 4.4.0
When GCC tries to resolve paths to executables it generates an exec prefix
based on argv[0]. It does that using the make_relative_prefix_1 function in
libiberty (make-relative-prefix.c). If argv[0] doesn't contain a path (i.e. it
only reads gcc), make_relative_prefix_1 searches the PATH to find
--- Comment #1 from mmlr at mlotz dot ch 2009-01-25 14:56 ---
Created an attachment (id=17181)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17181action=view)
Proposed fix for make_relative_prefix_1
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38966
--- Comment #1 from dfranke at gcc dot gnu dot org 2009-01-25 15:25 ---
Richard already opened a PR for this :)
*** This bug has been marked as a duplicate of 38913 ***
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from dfranke at gcc dot gnu dot org 2009-01-25 15:25 ---
*** Bug 38965 has been marked as a duplicate of this bug. ***
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-01-25 15:56 ---
One thing to note is that the adjustment we do during inlining means that
we miss that same adjustment iff inlining is disabled and the simple
(placement) new wrappers are marked const (and thus do not appear as
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-01-25 16:02 ---
Plan for attacking the problem:
1) Write a verifier that discovers illegal code motion.
1a) Each store and load is assigned a generation count.
1b) After code motion optimizations verify that out-of-order
-checking=release --without-system-libunwind
--with-tune=k8 --with-cpu=k8 --with-arch=k8 --with-gnu-as
--with-as=/usr/local/bin/as --with-gnu-ld --with-ld=/usr/local/bin/ld
Thread model: posix
gcc version 4.4.0 20090125 (experimental) [trunk revision 143660] (GCC)
# gmake -i -k check
...
gmake[4
As shown by the following code, the complex matrix product is not vectorized,
even with the patch in http://gcc.gnu.org/ml/gcc-patches/2009-01/msg01174.html:
program mymatmul
implicit none
integer, parameter :: kp = 4
integer, parameter :: n = 2000
real(kp), dimension(n,n) :: rr, ri
gcc 4.3 on alpha generates wrong code when -foptimize-sibling-calls is
used (which is enabled at -O2). It was not the case with gcc 4.2, and
this is still reproducible with gcc from trunk from 20090106. This is
the reason why most of the complex tests of the glibc testsuite are
failing with gcc
. Above you ask Could you try before/after this
do you mean compile and run the Testuite on bothboth r143461 and r143463?
Results for 4.4.0 20090125 (experimental) [trunk revision 143660] (GCC)
testsuite on i386-pc-solaris2.11
http://gcc.gnu.org/ml/gcc-testresults/2009-01/msg02585.html
Thanks
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-01-25 17:33 ---
Confirmed. Note the patch mentioned does not try to address any issue present
in the testcase.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from rob1weld at aol dot com 2009-01-25 17:35 ---
# ./e_d_fmt.exe
Abort (core dumped)
# ldd ./e_d_fmt.exe
libgfortran.so.3 =
/usr/share/src/gcc_build/i386-pc-solaris2.11/./libgfortran/.libs/libgfortran.so.3
libm.so.2 = /usr/lib/libm.so.2
--- Comment #1 from ubizjak at gmail dot com 2009-01-25 17:39 ---
Can you attach a working asm dump?
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #13 from rguenth at gcc dot gnu dot org 2009-01-25 17:54
---
Do we have a testcase for a primary platform that is affected by this bug?
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from rguenth at gcc dot gnu dot org 2009-01-25 17:56
---
We seem to have a lot of similar sse performance regression P2 bugs, can
someone make sure that there are no duplicates here?
--
rguenth at gcc dot gnu dot org changed:
What|Removed
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-01-25 18:02 ---
struct S8 D.2460;
struct S8 D.2470;
bb 2:
# VUSE D.2460_1(D)
# D.2470_3 = VDEF D.2470_2(D)
D.2470 = D.2460;
and struct S8 is empty.
This is a dup of PR38851 which has a smaller testcase.
*** This bug
--- Comment #13 from rguenth at gcc dot gnu dot org 2009-01-25 18:02
---
*** Bug 38908 has been marked as a duplicate of this bug. ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #14 from ebotcazou at gcc dot gnu dot org 2009-01-25 18:02
---
Do we have a testcase for a primary platform that is affected by this bug?
FWIW I haven't seen this failure mode on the SPARC yet.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38740
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38934
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-01-25 18:05 ---
Does the following patch fix this?
http://gcc.gnu.org/ml/gcc-patches/2009-01/msg01245.html
If so please mark this bug as a dup of PR38503.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38937
--- Comment #6 from pault at gcc dot gnu dot org 2009-01-25 18:21 ---
(In reply to comment #5)
(In reply to comment #4)
(In reply to comment #3)
In the latter case, it is non-empty if ubound lbound only. Comparing
ubound and lbound according to the stride to check for
--- Comment #7 from rguenth at gcc dot gnu dot org 2009-01-25 18:29 ---
I have a patch.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-01-25 18:35 ---
Fixed for 4.4.0.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Known to
On Linux/ia32, revision 143662 caused:
FAIL: g++.dg/ext/bitfield2.C (test for excess errors)
FAIL: g++.dg/ext/bitfield4.C (test for excess errors)
FAIL: gcc.dg/bitfld-15.c (test for excess errors)
FAIL: gcc.dg/bitfld-17.c (test for excess errors)
--
Summary: [4.4 Regression]
--- Comment #39 from rguenth at gcc dot gnu dot org 2009-01-25 18:39
---
Even with SSA at -O0 now and forcefully trying to enable TER with -ftree-ter
the testcase still fails. So, re-confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed
--- Comment #19 from gcc at spatium dot org 2009-01-25 19:25 ---
This thing still exists in 2.6.28.2; what do you suggest should be changed in
the kernel to let it compile again?
--
gcc at spatium dot org changed:
What|Removed |Added
--- Comment #14 from mmitchel at gcc dot gnu dot org 2009-01-25 19:45
---
Richard --
I don't agree that it's necessarily the FE's job to omit all stores to such
types. Our general theory is that FEs get to emit dumb code and the optimizers
get to fix it up. Of course, I don't object
--- Comment #2 from ubizjak at gmail dot com 2009-01-25 19:55 ---
gcc should initialize pseudos from x variable in my_print_complex:
;; Function my_print_complex (my_print_complex)
;; Generating RTL for gimple basic block 2
;; D.2813 = internal_print_complex (x); [tail call]
(insn
--- Comment #15 from rguenther at suse dot de 2009-01-25 19:59 ---
Subject: Re: [4.4 regression] Compiler warns about
uninitialized variable that is an object with a constructor
On Sun, 25 Jan 2009, mmitchel at gcc dot gnu dot org wrote:
--- Comment #14 from mmitchel at gcc dot
--- Comment #16 from mark at codesourcery dot com 2009-01-25 20:03 ---
Subject: Re: [4.4 regression] Compiler warns about
uninitialized variable that is an object with a constructor
rguenther at suse dot de wrote:
Therefore, I don't think that the key here is zero-size. Instead,
--- Comment #1 from hp at gcc dot gnu dot org 2009-01-25 20:25 ---
.
--
hp at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #1 from gerald at pfeifer dot com 2009-01-25 20:40 ---
Since I reported this, things have improved somewhat. Per
http://gcc.gnu.org/ml/gcc-testresults/2009-01/msg02566.html
we now have
=== libgomp Summary ===
# of expected passes 2277
# of
--- Comment #17 from rguenther at suse dot de 2009-01-25 20:45 ---
Subject: Re: [4.4 regression] Compiler warns about
uninitialized variable that is an object with a constructor
On Sun, 25 Jan 2009, mark at codesourcery dot com wrote:
--- Comment #16 from mark at codesourcery
--- Comment #7 from pault at gcc dot gnu dot org 2009-01-25 21:08 ---
Created an attachment (id=17182)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17182action=view)
A provisional patch for the PR
It take back what I said previously:-)
The attached bootstraps and regtests OK.
I
--- Comment #20 from rguenth at gcc dot gnu dot org 2009-01-25 21:10
---
The testcase from #17 does not reproduce the issue for me with recent GCC 4.3.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36359
--- Comment #18 from dave dot korn dot cygwin at gmail dot com 2009-01-25
21:36 ---
Created an attachment (id=17183)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17183action=view)
Implement TARGET_BUILTIN_SETJMP_FRAME_VALUE.
Now testing this patch which should fix setjmp
--- Comment #21 from bunk at stusta dot de 2009-01-25 22:00 ---
(In reply to comment #20)
The testcase from #17 does not reproduce the issue for me with recent GCC 4.3.
This bug is a regression in gcc 4.4, it was AFAIK never present in gcc 4.3.
Haven't tried more recent gcc versions,
--- Comment #18 from rguenth at gcc dot gnu dot org 2009-01-25 22:02
---
I am testing another patch, improving simple-DSE instead.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #22 from bunk at stusta dot de 2009-01-25 22:05 ---
Check my comments #10 and #11 and the definition of ilog2() in
--- Comment #23 from rguenth at gcc dot gnu dot org 2009-01-25 22:17
---
It doesn't reproduce for me with 4.4 either. Maybe this is a dup of PR38789?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36359
--- Comment #19 from dave dot korn dot cygwin at gmail dot com 2009-01-25
23:07 ---
Created an attachment (id=17184)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17184action=view)
Implement TARGET_BUILTIN_SETJMP_FRAME_VALUE *correctly*.
Dur. Corrected patch for return type
--- Comment #24 from bunk at stusta dot de 2009-01-26 00:49 ---
(In reply to comment #23)
It doesn't reproduce for me with 4.4 either. Maybe this is a dup of PR38789?
Seems so:
I've confirmed that the 4.4-20090109 snapshot is broken, and the 4.4-20090123
snapshot is fixed.
--
--- Comment #1 from rob1weld at aol dot com 2009-01-26 02:40 ---
This might become more important when you build gcc with cloog and without ppl
.
Note: A major upcoming improvement is the support of multiple backends,
not only PolyLib. CLooG will support PPL and already supports in
+++ This bug was initially created as a clone of Bug #38911 +++
I'm compiling gcc revision 143664 on F10.
The cloog website recommends it's .git for best results:
http://www.bastoul.net/cloog/download.php#DEV
The '.git' version (newest) creates version.h with this content:
#define CLOOG_HEAD
--- Comment #1 from spop at gcc dot gnu dot org 2009-01-26 03:09 ---
You are not supposed to use Cloog trunk, for GCC 4.4 you have to use
this: ftp://gcc.gnu.org/pub/gcc/infrastructure/cloog-ppl-0.15.tar.gz
and follow the install instructions either from GCC's docs or from the
wiki
--- Comment #7 from dannysmith at users dot sourceforge dot net 2009-01-26
03:30 ---
AFAICT DW2 unwind has never worked on x86_64-mingw32, which is why Kai made
sjlj the default EH model for that target.
http://gcc.gnu.org/ml/gcc-patches/2007-12/msg00273.html
--
dannysmith at users
--- Comment #2 from spop at gcc dot gnu dot org 2009-01-26 03:32 ---
Again, you are not supposed to use other versions of CLooG than the one
documented: CLooG-PPL.
Sebastian
--
spop at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #17 from pault at gcc dot gnu dot org 2009-01-26 05:12 ---
Subject: Bug 38657
Author: pault
Date: Mon Jan 26 05:12:03 2009
New Revision: 143669
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143669
Log:
2009-01-26 Paul Thomas pa...@gcc.gnu.org
PR
--- Comment #18 from pault at gcc dot gnu dot org 2009-01-26 05:13 ---
Fixed on trunk and 4.3
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from pault at gcc dot gnu dot org 2009-01-26 05:43 ---
Subject: Bug 38859
Author: pault
Date: Mon Jan 26 05:43:44 2009
New Revision: 143670
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143670
Log:
2009-01-26 Mikael Morin mikael.mo...@tele2.fr
PR
--- Comment #9 from pault at gcc dot gnu dot org 2009-01-26 05:44 ---
Closed on trunk and 4.3.
Once again, thanks for the report.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from pault at gcc dot gnu dot org 2009-01-26 06:15 ---
Subject: Bug 38907
Author: pault
Date: Mon Jan 26 06:15:41 2009
New Revision: 143671
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143671
Log:
2009-01-26 Paul Thomas pa...@gcc.gnu.org
PR
--- Comment #11 from pault at gcc dot gnu dot org 2009-01-26 06:16 ---
Fixed on trunk and 4.3
Thanks for the report and thanks to Mikael for the fix.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
72 matches
Mail list logo
