--- Comment #6 from ghazi at gcc dot gnu dot org 2010-02-23 08:12 ---
Subject: Bug 21769
Author: ghazi
Date: Tue Feb 23 08:12:35 2010
New Revision: 156990
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156990
Log:
Backport:
2010-01-20 Janis Johnson
--- Comment #20 from manu at gcc dot gnu dot org 2010-02-23 08:39 ---
(In reply to comment #19)
>
> The proposed logic is the same, *except* that the conversion to a common
> type goes via the semantic type, *if* there is excess precision involved
> *and* the operand being converted h
--- Comment #6 from burnus at gcc dot gnu dot org 2010-02-23 08:45 ---
Just to make sure it won't get forgotten: REOPEN.
(In reply to comment #4)
> Paul, for the test case in comment 0 we still create a temporary:
>
> b(a)=1
>
> where "a" is a simple-contiguous rank-one array withou
d -t x1 show?
Steve tested with:
> troutmask:sgk[212] gfc44 --version
> GNU Fortran (GCC) 4.4.3 20091216 (prerelease)
I also tested with 4.4.4 20100223 and 4.4.2 [gcc-4_4-branch revision 155966]
(SUSE Linux).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43146
--- Comment #6 from burnus at gcc dot gnu dot org 2010-02-23 09:08 ---
Regarding my question, Toon ask this question to Bill Long @ Cray and Jim Xia @
IBM at the Las Vegas meeting of J3/WG5 - they came to different conclusions ;-)
Bill Long stated what he also wrote at
http://j3-fortr
--- Comment #7 from rguenther at suse dot de 2010-02-23 09:33 ---
Subject: Re: COMMON block, BIND(C) and LTO interoperability
issues
On Tue, 23 Feb 2010, burnus at gcc dot gnu dot org wrote:
> --- Comment #6 from burnus at gcc dot gnu dot org 2010-02-23 09:08
> ---
> Regard
--- Comment #7 from ghazi at gcc dot gnu dot org 2010-02-23 09:42 ---
Subject: Bug 21769
Author: ghazi
Date: Tue Feb 23 09:41:37 2010
New Revision: 156991
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156991
Log:
Backport:
2010-01-20 Janis Johnson
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-02-23 10:20 ---
Created an attachment (id=19939)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19939&action=view)
reduced testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43142
--- Comment #21 from manu at gcc dot gnu dot org 2010-02-23 10:23 ---
(In reply to comment #19)
>
> The present logic is: convert (with convert_and_check) both operands to a
> common type, which may have excess precision; then, later, after producing
> the tree for the result of the o
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-02-23 10:42 ---
(In reply to comment #3)
> Subject: Re: vld4 and vst4 intrinsics are not handled
> correctly
>
> On Fri, Feb 19, 2010 at 11:08:18AM -, rguenth at gcc dot gnu dot org
> wrote:
> > Likely because of the union i
--- Comment #6 from manu at gcc dot gnu dot org 2010-02-23 10:44 ---
Patch: http://gcc.gnu.org/ml/gcc-patches/2010-02/msg00915.html
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from jakub at gcc dot gnu dot org 2010-02-23 11:38 ---
Can't reproduce this, at least not with a cross gcc (and -m32 -msecure-plt -O2
-fPIC), on neither the original nor the reduced testcase.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43142
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-02-23 11:51 ---
(In reply to comment #4)
> Can't reproduce this, at least not with a cross gcc (and -m32 -msecure-plt -O2
> -fPIC), on neither the original nor the reduced testcase.
Ok, there's a single ppc specific patch in our tr
--- Comment #6 from jakub at gcc dot gnu dot org 2010-02-23 12:10 ---
I doubt that could be related. My memory is weak about this stuff and why it
hasn't made it into trunk, search reveals
http://gcc.gnu.org/ml/gcc-patches/2005-11/msg01951.html
http://gcc.gnu.org/ml/gcc-patches/2005-11/
--- Comment #7 from marcus at jet dot franken dot de 2010-02-23 12:46
---
the issue is btw new with 4.5, it was not there with 4.4
it affects
agg
cairomm
gnash
google-perftools
hugin
libofa
libqt4
libstlport_gcc4
openjade
pcp
pwlib
python-cryptopp
unrar
yast2-squid
--
http://gcc.
--- Comment #8 from spop at gcc dot gnu dot org 2010-02-23 12:58 ---
Subject: Bug 43026
Author: spop
Date: Tue Feb 23 12:58:44 2010
New Revision: 156993
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156993
Log:
Fix PR43026: handle COMPONENT_REFs in expand scalar expressions.
2
--- Comment #6 from spop at gcc dot gnu dot org 2010-02-23 12:59 ---
Subject: Bug 43140
Author: spop
Date: Tue Feb 23 12:59:00 2010
New Revision: 156994
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156994
Log:
Fix PR43140: Add -Wno-conversion-null to pr41305.C.
2010-02-22 Se
--- Comment #7 from spop at gcc dot gnu dot org 2010-02-23 12:59 ---
Subject: Bug 43140
Author: spop
Date: Tue Feb 23 12:59:17 2010
New Revision: 156995
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156995
Log:
Fix PR43097: rename only SSA_NAMEs.
2010-02-22 Sebastian Pop
--- Comment #7 from spop at gcc dot gnu dot org 2010-02-23 13:00 ---
Subject: Bug 43083
Author: spop
Date: Tue Feb 23 12:59:48 2010
New Revision: 156997
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156997
Log:
Fix PR43083: Do not handle regions ending with multiple edges on th
--- Comment #8 from spop at gcc dot gnu dot org 2010-02-23 13:03 ---
Fixed.
--
spop at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #9 from spop at gcc dot gnu dot org 2010-02-23 13:04 ---
Fixed.
--
spop at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #8 from spop at gcc dot gnu dot org 2010-02-23 13:05 ---
Fixed.
--
spop at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #4 from spop at gcc dot gnu dot org 2010-02-23 13:06 ---
Fixed on trunk with this commit:
Author: spop
Date: Tue Feb 23 12:59:17 2010
New Revision: 156995
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156995
Log:
Fix PR43097: rename only SSA_NAMEs.
2010-02-22 Seba
--- Comment #1 from burnus at gcc dot gnu dot org 2010-02-23 13:11 ---
Reduced test case:
Program received signal SIGSEGV, Segmentation fault.
0x0055cbfd in gfc_trans_structure_assign (dest=)
at trans-expr.c:4365
4365 tmp = fold_build3 (COMPONENT_REF, TREE_TYPE (fie
This is a feature request and the first bug report here so bear with me:
It would be an extremely useful feature if code from a certain template
libraries could be optimized while the own code is still compiled in debug
mode.
It's easy to link against an optimized version of a library, but this
With VTA it ought to be possible at least in many cases to provide proper debug
info for variable length arrays.
--
Summary: Proper debug info for debugging VLAs
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Prio
--- Comment #1 from jakub at gcc dot gnu dot org 2010-02-23 13:49 ---
Created an attachment (id=19940)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19940&action=view)
gcc45-pr43150.patch
Patch with a testcase. Before the patch the testcase fails:
unix/-m32
FAIL: gcc.dg/guality/v
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35259
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36513
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41779
--- Comment #2 from jakub at gcc dot gnu dot org 2010-02-23 14:08 ---
I see some VTA bugs and missed debug optimizations though:
1) in f1 say -O2 -m64 -g we have in *.alignments:
(debug_insn 7 14 8 2 vla-1.c:15 (var_location:DI D#2 (sign_extend:DI (plus:SI
(reg/v:SI 5 di [orig:62 i ] [62
--- Comment #11 from jakub at gcc dot gnu dot org 2010-02-23 14:24 ---
To emit an extra DEBUG_INSN to a D# temporary and using that D# temporary you'd
need to know where exactly to insert the DEBUG_INSN. I guess we'd need to
remember for MAY_HAVE_DEBUG_INSNS a mapping from each of the S
--- Comment #12 from matz at gcc dot gnu dot org 2010-02-23 14:31 ---
Yeah, I have a patch already which emits it before the last real use of an
SSA name (which by design of TER is a point where all constituent
subexpressions still have their correct value).
--
http://gcc.gnu.org/bu
For
struct X { int i; int j[2]; };
const long x = ((struct X *)0)->j - (int *)0;
char a[((struct X *)0)->j - (int *)0];
char b[__builtin_offsetof(struct X, j)];
char c[x];
we now issue the following diagnostics:
> gcc-4.5 -S t.i
t.i:3:17: warning: variably modified a at file scope
t.i:5:6: er
--- Comment #3 from jakub at gcc dot gnu dot org 2010-02-23 14:46 ---
Actually, 2) is present also on the trunk, again in f2 -O2 -g -m64.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43150
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-02-23 14:50 ---
6.6/7 explains the differenece. And const long x = ...; isn't amongst the
allowed operands of an integer constant expression.
--
rguenth at gcc dot gnu dot org changed:
What|Removed
--- Comment #1 from bangerth at gmail dot com 2010-02-23 15:13 ---
This feature already exists. See the discussion of the "optimize" attribute
in
http://gcc.gnu.org/onlinedocs/gcc-4.4.3/gcc/Function-Attributes.html#Function-Attributes
W.
--
bangerth at gmail dot com changed:
--- Comment #6 from burnus at gcc dot gnu dot org 2010-02-23 15:29 ---
Result with current trunk (4.5.0 2010-02-23 Rev. 156999)
In a nutshell: gas_dyn is still slower - now 35% instead of 70%.
-fgraphite-identity has normal speed (or a tiny bit faster?!?), but all other
options (-floop-
--- Comment #2 from bschindler at inf dot ethz dot ch 2010-02-23 15:45
---
Thank you for that hint, however the problem does not disappear just like that.
I would like the entire namespace be optimized that way and from the discussion
it seems that there is no easy way to do this?
-
--- Comment #1 from manu at gcc dot gnu dot org 2010-02-23 15:52 ---
Subject: Bug 43123
Author: manu
Date: Tue Feb 23 15:51:42 2010
New Revision: 157007
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157007
Log:
2010-02-23 Manuel López-Ibáñez
PR 43123
* co
--- Comment #3 from wirawan0 at gmail dot com 2010-02-23 15:52 ---
Here's my activity log. It's using gcc 4.4.3 that I just compiled yesterday.
It's still yielding char(0) instead of char(10). Weird.
~/toys/gfortran/ch10 $ cat testme5.F90
module blahblah
character(len=1), parameter ::
--- Comment #3 from bangerth at gmail dot com 2010-02-23 15:53 ---
So the attribute would have to be attached to the namespace, I guess.
We can keep the PR open, but my best guess is that this is going to be
one of those PRs that stay open forever as there is so little demand
for this k
The vectorizer cannot vectorize if-converted COND_EXPRs with V8SF or V4DF types
because the backend does not provide patterns for this.
--
Summary: vcond<> not supported for AVX float modes
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Key
Sent from my iPhone
On Feb 23, 2010, at 7:53 AM, "bangerth at gmail dot com" > wrote:
--- Comment #3 from bangerth at gmail dot com 2010-02-23 15:53
---
So the attribute would have to be attached to the namespace, I guess.
Or just use the pragma instead :).
We can keep the
--- Comment #4 from pinskia at gmail dot com 2010-02-23 16:02 ---
Subject: Re: Partial optimization
Sent from my iPhone
On Feb 23, 2010, at 7:53 AM, "bangerth at gmail dot com"
wrote:
>
>
> --- Comment #3 from bangerth at gmail dot com 2010-02-23 15:53
> ---
> So the at
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-02-23 16:10 ---
Simply changing the vcond pattern for fp to use AVX_VEC_FLOAT_MODE_P and
AVXMODEF2P seems to work. Thus, mine.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-02-23 16:13 ---
I wouldn't surprised if it doesn't work very well for template instantiations
though.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43149
--- Comment #6 from bschindler at inf dot ethz dot ch 2010-02-23 16:16
---
Also, the following would not work
#pragma GCC optimize(2) // I don't know whether I got that syntax right
#include
#pragma pop_options
blubb;
Eigen/Core is a separate file so I'd expect the pragma to have no
--- Comment #7 from bschindler at inf dot ethz dot ch 2010-02-23 16:24
---
Okay, the need is simply this:
I have an octree implemented using eigen.
With gcc -g, it takes roughly 3 minutes to build the tree
With gcc -O1 -g, it takes about 1-2 seconds for the same
The problem is Eige
Sent from my iPhone
On Feb 23, 2010, at 8:16 AM, "bschindler at inf dot ethz dot ch" > wrote:
--- Comment #6 from bschindler at inf dot ethz dot ch
2010-02-23 16:16 ---
Also, the following would not work
#pragma GCC optimize(2) // I don't know whether I got that syntax
right
--- Comment #8 from pinskia at gmail dot com 2010-02-23 16:29 ---
Subject: Re: Partial optimization
Sent from my iPhone
On Feb 23, 2010, at 8:16 AM, "bschindler at inf dot ethz dot ch"
wrote:
>
>
> --- Comment #6 from bschindler at inf dot ethz dot ch
> 2010-02-23 16:16 ---
--- Comment #22 from joseph at codesourcery dot com 2010-02-23 16:32
---
Subject: Re: [4.5 Regression] c-c++-common/pr41779.c doesn't
work
On Tue, 23 Feb 2010, manu at gcc dot gnu dot org wrote:
> --- Comment #20 from manu at gcc dot gnu dot org 2010-02-23 08:39 ---
> (In r
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43068
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40823
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43015
--- Comment #23 from joseph at codesourcery dot com 2010-02-23 16:38
---
Subject: Re: [4.5 Regression] c-c++-common/pr41779.c doesn't
work
On Tue, 23 Feb 2010, manu at gcc dot gnu dot org wrote:
> --- Comment #21 from manu at gcc dot gnu dot org 2010-02-23 10:23 ---
> (In r
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Target Milestone|--- |4.5.0
Version|unknown |4.5.0
http://
--- Comment #13 from matz at gcc dot gnu dot org 2010-02-23 16:42 ---
Subject: Bug 43077
Author: matz
Date: Tue Feb 23 16:41:52 2010
New Revision: 157009
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157009
Log:
PR debug/43077
* cfgexpand (expand_debug_expr): Ex
--- Comment #14 from matz at gcc dot gnu dot org 2010-02-23 16:46 ---
Fixed.
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #4 from tromey at gcc dot gnu dot org 2010-02-23 16:55 ---
It seems to me that, by analogy with constructors, we would want debuginfo
for all the destructors, so that "break X::~X" would put breakpoints in all
the clones.
Then we would need additional information to distingui
--- Comment #9 from hjl at gcc dot gnu dot org 2010-02-23 17:04 ---
Subject: Bug 42870
Author: hjl
Date: Tue Feb 23 17:02:26 2010
New Revision: 157010
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157010
Log:
Backport testcases from mainline.
2010-02-23 H.J. Lu
Bac
--- Comment #4 from hjl at gcc dot gnu dot org 2010-02-23 17:04 ---
Subject: Bug 43079
Author: hjl
Date: Tue Feb 23 17:02:26 2010
New Revision: 157010
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157010
Log:
Backport testcases from mainline.
2010-02-23 H.J. Lu
Bac
--- Comment #3 from hjl at gcc dot gnu dot org 2010-02-23 17:04 ---
Subject: Bug 43109
Author: hjl
Date: Tue Feb 23 17:02:26 2010
New Revision: 157010
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157010
Log:
Backport testcases from mainline.
2010-02-23 H.J. Lu
Bac
--- Comment #5 from hjl at gcc dot gnu dot org 2010-02-23 17:04 ---
Subject: Bug 43068
Author: hjl
Date: Tue Feb 23 17:02:26 2010
New Revision: 157010
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157010
Log:
Backport testcases from mainline.
2010-02-23 H.J. Lu
Bac
--- Comment #5 from hjl at gcc dot gnu dot org 2010-02-23 17:04 ---
Subject: Bug 43111
Author: hjl
Date: Tue Feb 23 17:02:26 2010
New Revision: 157010
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157010
Log:
Backport testcases from mainline.
2010-02-23 H.J. Lu
Bac
--- Comment #4 from hjl at gcc dot gnu dot org 2010-02-23 17:04 ---
Subject: Bug 43007
Author: hjl
Date: Tue Feb 23 17:02:26 2010
New Revision: 157010
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157010
Log:
Backport testcases from mainline.
2010-02-23 H.J. Lu
Bac
--- Comment #7 from hjl at gcc dot gnu dot org 2010-02-23 17:04 ---
Subject: Bug 42999
Author: hjl
Date: Tue Feb 23 17:02:26 2010
New Revision: 157010
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157010
Log:
Backport testcases from mainline.
2010-02-23 H.J. Lu
Bac
--- Comment #8 from hjl at gcc dot gnu dot org 2010-02-23 17:04 ---
Subject: Bug 43066
Author: hjl
Date: Tue Feb 23 17:02:26 2010
New Revision: 157010
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157010
Log:
Backport testcases from mainline.
2010-02-23 H.J. Lu
Bac
--- Comment #16 from hjl at gcc dot gnu dot org 2010-02-23 17:04 ---
Subject: Bug 42824
Author: hjl
Date: Tue Feb 23 17:02:26 2010
New Revision: 157010
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157010
Log:
Backport testcases from mainline.
2010-02-23 H.J. Lu
Ba
--- Comment #4 from hjl at gcc dot gnu dot org 2010-02-23 17:04 ---
Subject: Bug 43017
Author: hjl
Date: Tue Feb 23 17:02:26 2010
New Revision: 157010
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157010
Log:
Backport testcases from mainline.
2010-02-23 H.J. Lu
Bac
--- Comment #5 from hjl at gcc dot gnu dot org 2010-02-23 17:04 ---
Subject: Bug 43000
Author: hjl
Date: Tue Feb 23 17:02:26 2010
New Revision: 157010
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157010
Log:
Backport testcases from mainline.
2010-02-23 H.J. Lu
Bac
--- Comment #22 from hjl at gcc dot gnu dot org 2010-02-23 17:04 ---
Subject: Bug 42742
Author: hjl
Date: Tue Feb 23 17:02:26 2010
New Revision: 157010
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157010
Log:
Backport testcases from mainline.
2010-02-23 H.J. Lu
Ba
--- Comment #9 from hjl at gcc dot gnu dot org 2010-02-23 17:04 ---
Subject: Bug 43031
Author: hjl
Date: Tue Feb 23 17:02:26 2010
New Revision: 157010
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157010
Log:
Backport testcases from mainline.
2010-02-23 H.J. Lu
Bac
--- Comment #5 from hjl at gcc dot gnu dot org 2010-02-23 17:04 ---
Subject: Bug 43093
Author: hjl
Date: Tue Feb 23 17:02:26 2010
New Revision: 157010
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157010
Log:
Backport testcases from mainline.
2010-02-23 H.J. Lu
Bac
--- Comment #18 from hjl at gcc dot gnu dot org 2010-02-23 17:04 ---
Subject: Bug 42749
Author: hjl
Date: Tue Feb 23 17:02:26 2010
New Revision: 157010
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157010
Log:
Backport testcases from mainline.
2010-02-23 H.J. Lu
Ba
--- Comment #4 from hjl at gcc dot gnu dot org 2010-02-23 17:04 ---
Subject: Bug 43008
Author: hjl
Date: Tue Feb 23 17:02:26 2010
New Revision: 157010
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157010
Log:
Backport testcases from mainline.
2010-02-23 H.J. Lu
Bac
--- Comment #4 from hjl at gcc dot gnu dot org 2010-02-23 17:04 ---
Subject: Bug 43069
Author: hjl
Date: Tue Feb 23 17:02:26 2010
New Revision: 157010
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157010
Log:
Backport testcases from mainline.
2010-02-23 H.J. Lu
Bac
--- Comment #7 from hjl at gcc dot gnu dot org 2010-02-23 17:04 ---
Subject: Bug 42998
Author: hjl
Date: Tue Feb 23 17:02:26 2010
New Revision: 157010
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157010
Log:
Backport testcases from mainline.
2010-02-23 H.J. Lu
Bac
--- Comment #1 from jakub at gcc dot gnu dot org 2010-02-23 17:06 ---
Subject: Bug 43139
Author: jakub
Date: Tue Feb 23 17:05:56 2010
New Revision: 157011
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157011
Log:
PR target/43139
* config/i386/i386.c (ix86_delegi
--- Comment #4 from kargl at gcc dot gnu dot org 2010-02-23 17:16 ---
(In reply to comment #3)
> Here's my activity log. It's using gcc 4.4.3 that I just compiled yesterday.
> It's still yielding char(0) instead of char(10). Weird.
>
Can you add the -fdump-tree-original option and post
--- Comment #2 from jakub at gcc dot gnu dot org 2010-02-23 17:21 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED
i686 or newer processors support multi-byte NOPs, which
is preferred for aligning code:
[...@gnu-6 tmp]$ cat a.s
jmp bar
mov %eax,%ebx
mov %eax,%ebx
.p2align 4
bar:
mov %eax,%ebx
[...@gnu-6 tmp]$ as --32 -o old.o a.s
[...@gnu-6 tmp]$ as --32 -mtune=i686 -o
--- Comment #24 from manu at gcc dot gnu dot org 2010-02-23 17:33 ---
OK, I get it. Thanks for the explanation. Testing a patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43128
--- Comment #4 from jakub at gcc dot gnu dot org 2010-02-23 17:36 ---
Regarding 2), the regcprop pass doesn't call df_analyze at all, so it can't
rely on REG_DEAD notes nor use df_* APIs to check for life info. I'm not 100%
sure why we are propagating into debug insns at all, guess to h
--- Comment #5 from wirawan0 at gmail dot com 2010-02-23 17:49 ---
Here's the dump content. Indeed it misses the "\n" stuff.
~/toys/gfortran/ch10 $ cat testme5.F90.003t.original
testme3 ()
{
static integer(kind=4) options.0[8] = {68, 255, 0, 0, 0, 1, 0, 1};
_gfortran_set_options (8
--- Comment #6 from kargl at gcc dot gnu dot org 2010-02-23 18:29 ---
(In reply to comment #5)
> Here's the dump content. Indeed it misses the "\n" stuff.
>
> ~/toys/gfortran/ch10 $ cat testme5.F90.003t.original
Can you rename the file to testme5.f90 and try again?
The .F90 extension w
--- Comment #12 from jason at gcc dot gnu dot org 2010-02-23 18:32 ---
Subject: Bug 42837
Author: jason
Date: Tue Feb 23 18:31:58 2010
New Revision: 157013
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157013
Log:
PR c++/42837
* stor-layout.c (place_field): Don'
--- Comment #8 from jason at gcc dot gnu dot org 2010-02-23 18:32 ---
Fixed.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #9 from jason at gcc dot gnu dot org 2010-02-23 18:32 ---
Subject: Bug 42800
Author: jason
Date: Tue Feb 23 18:32:09 2010
New Revision: 157014
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157014
Log:
PR debug/42800
* cfgexpand.c (expand_used_vars):
--- Comment #1 from jason at gcc dot gnu dot org 2010-02-23 18:32 ---
Subject: Bug 43143
Author: jason
Date: Tue Feb 23 18:32:20 2010
New Revision: 157015
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157015
Log:
PR c++/43143
* typeck2.c (digest_init_r): Accept
--- Comment #13 from jason at gcc dot gnu dot org 2010-02-23 18:33 ---
Fixed.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Status|REOPENED
--- Comment #2 from jason at gcc dot gnu dot org 2010-02-23 18:34 ---
Fixed for 4.5.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIG
--- Comment #7 from wirawan0 at gmail dot com 2010-02-23 18:38 ---
There are no changes if I compiled with *.f90 instead of *.F90 extension.
Wirawan
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43146
--- Comment #9 from janis at gcc dot gnu dot org 2010-02-23 19:07 ---
Is there a reason this hasn't been fixed? If not, I'll try.
--
janis at gcc dot gnu dot org changed:
What|Removed |Added
The documentation says that vec_mergel and vec_mergeh are supported for the
vector double and vector long long types when the VSX instruction set is used,
unfortunately it was never implemented in the compiler.
--
Summary: vec_mergel and vec_mergeh should support V2DF/V2DI
--- Comment #3 from janis at gcc dot gnu dot org 2010-02-23 19:27 ---
The minimized testcase and 175.vpr still fail on powerpc64-linux with "-O2
-ftree-loop-distribution" for both -m32 and -m64. With the confirmation in
comment #2 this report ought to be moved from UNCONFIRMED to NEW.
--
bangerth at gmail dot com changed:
What|Removed |Added
CC||mmitchel at gcc dot gnu dot
|
--- Comment #10 from bangerth at gmail dot com 2010-02-23 20:40 ---
(In reply to comment #9)
> Is there a reason this hasn't been fixed?
Lack of public demand? There's only one duplicate of this bug that has
been reported in the last 9 years...
> If not, I'll try.
I think that would
The following program runs with ifort, sunf95, and pathscale, but it fails with
gfortran, NAG f95 and g95. I think the number is not standard conform, but a
"processor" is allowed to accept it. For "a" ifort et al. print "438.0".
Additionally, I have the feeling that there is an off-by-one er
--- Comment #4 from spop at gcc dot gnu dot org 2010-02-23 21:07 ---
Reza Yazdani has a patch to fix this.
He's going to post the patch after test.
Sebastian
--
spop at gcc dot gnu dot org changed:
What|Removed |Added
-
1 - 100 of 128 matches
Mail list logo
