--- Comment #21 from ebotcazou at gcc dot gnu dot org 2010-01-07 07:39
---
> Because at the point of propagation, propagated constant _is_ equal to
> whatever REG_EQUAL says. Removing this note at the point of propagation
> would IMO disable much more optimization opportunities.
What k
--- Comment #20 from ubizjak at gmail dot com 2010-01-07 07:29 ---
(In reply to comment #19)
> > Following patch changes the fix from PR21767 to remove REG_EQUAL notes from
> > all
> > moved instructions, not only from ones that have non-function-invariant
> > sources.
>
> This seems l
--- Comment #2 from steven at gcc dot gnu dot org 2010-01-07 07:17 ---
Can you try with -fnoweb?
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Ass
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31775
--- Comment #1 from janis at gcc dot gnu dot org 2010-01-07 01:43 ---
Created an attachment (id=19495)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19495&action=view)
minimized executable testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42644
Test 183.equake from SPEC CPU2000 gets wrong results on powerpc64-linux (-m32
or -m64) when compiled with either "-O2 -fgraphite-identity" or "-O2
-floop-parallelize-all". I'll attach an executable testcase that demonstrates
the failure. Test 178.galgel fails with the same options but I haven't
i
When compiling the source with "-Wall -O", gcc gives the following warning:
% gcc -c -Wall -O gcc_test.c
gcc_test.c: In function ?functionLeon?:
gcc_test.c:11: warning: ?reference? may be used uninitialized in this function
% cat gcc_test.c
#include
typedef struct {
int yb;
} TCRData;
void fu
--- Comment #1 from zsojka at seznam dot cz 2010-01-07 00:39 ---
Created an attachment (id=19494)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19494&action=view)
reduced testcase
Command line:
g++ -O1 -fpeel-loops -fcompare-debug pr42642.cpp -c
--
http://gcc.gnu.org/bugzilla
Command line:
g++ -O1 -fpeel-loops -fcompare-debug -c testcase.cpp
it has to be compiled as C++ code, even though it's valid C code
Tested revisions (x86_64):
r155680 - crash
r155662 - crash (x86)
r154886 - crash
r154830 - crash
r153685 - OK (built without graphite support, if that matters)
Outpu
--- Comment #9 from paolo dot carlini at oracle dot com 2010-01-07 00:33
---
Fixed.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
Statu
--- Comment #8 from paolo at gcc dot gnu dot org 2010-01-07 00:23 ---
Subject: Bug 26701
Author: paolo
Date: Thu Jan 7 00:22:51 2010
New Revision: 155685
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155685
Log:
2010-01-06 Paolo Carlini
PR libstdc++/26701
*
Graphites code generation depends on virtual addresses because we traverse
hashtables (at least) when inserting guard phis from sese.c:insert_guard_phis
which elements are hashed by pointer, sese.c:rename_map_elt_info
A fix is to hash the SSA name instead:
Index: sese.c
==
--- Comment #19 from ebotcazou at gcc dot gnu dot org 2010-01-07 00:00
---
> Following patch changes the fix from PR21767 to remove REG_EQUAL notes from
> all
> moved instructions, not only from ones that have non-function-invariant
> sources.
This seems like a tad aggressive. Why no
--- Comment #3 from steven at gcc dot gnu dot org 2010-01-06 23:53 ---
In the .loop2_done dump, the RTL looks like this:
7 NOTE_INSN_BASIC_BLOCK
6 NOTE_INSN_FUNCTION_BEG
22 {r63:SI=r62:SI-0x1;clobber flags:CC;}
23 {r64:SI=r63:SI&0x7;clobber flags:CC;}
26: debug k => r62
--- Comment #8 from fxcoudert at gcc dot gnu dot org 2010-01-06 23:50
---
Patch works for me.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42424
--- Comment #2 from steven at gcc dot gnu dot org 2010-01-06 23:48 ---
Works with -fno-web.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42631
--- Comment #4 from paolo dot carlini at oracle dot com 2010-01-06 23:45
---
Thanks a lot!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42491
--- Comment #2 from hjl dot tools at gmail dot com 2010-01-06 23:33 ---
Function pointer != function address in shared library.
When a function is protected, the one defined in shared library
will be called. But its function pointer can be outside of
shared library. So protected function
--- Comment #5 from hjl dot tools at gmail dot com 2010-01-06 23:27 ---
Function pointer != function address in shared library.
"f2" is protected and the one defined in shared library
will be called. But its function pointer can be out
side of shared library. That is why R_X86_64_PC32
ca
--- Comment #7 from ghazi at gcc dot gnu dot org 2010-01-06 23:26 ---
Proposed patch:
http://gcc.gnu.org/ml/gcc-patches/2010-01/msg00300.html
The bug is masked on my box by an old libgmp installation. So to be sure the
above patch actually fixes the problem, I'd appreciate hearing from
--- Comment #18 from ubizjak at gmail dot com 2010-01-06 23:16 ---
Following patch changes the fix from PR21767 to remove REG_EQUAL notes from all
moved instructions, not only from ones that have non-function-invariant
sources.
--cut here--
Index: ifcvt.c
===
--- Comment #1 from janis at gcc dot gnu dot org 2010-01-06 23:11 ---
Created an attachment (id=19493)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19493&action=view)
minimized executable testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42640
Benchmark test 175.vpr from SPEC CPU2000 gets incorrect results on
powerpc64-linux when compiled with "-O2 -ftree-loop-distribution", as shown by
a minimized testcase that I'll attach to this PR. The inner loop is:
inode = s_node;
for (iloop = 1; iloop <= 2; iloop++)
{
--- Comment #7 from fredrik dot svahn at gmail dot com 2010-01-06 23:00
---
Summary:
The patch works great when building gcc from trunk (revision 155680). Both
supplied test program and real application are optimized.
With gcc-4.4.2 I get the optimization for the test program only with
--- Comment #3 from bkoz at gcc dot gnu dot org 2010-01-06 22:58 ---
Sure. We can fix this by adding -std=gnu++0x for all compiles, and then marking
up the testcase appropriately.
Sadly, this results in widespread observance of:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42634
These
--- Comment #2 from bkoz at gcc dot gnu dot org 2010-01-06 22:57 ---
Sure. We can fix this by adding -std=gnu++0x for all compiles, and then marking
up the testcase appropriately.
Sadly, this results in widespread observance of:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42634
These
--- Comment #1 from bkoz at gcc dot gnu dot org 2010-01-06 22:56 ---
Subject: Bug 42491
Author: bkoz
Date: Wed Jan 6 22:55:52 2010
New Revision: 155681
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155681
Log:
2010-01-06 Benjamin Kosnik
PR libstdc++/42491
*
--- Comment #3 from bkoz at gcc dot gnu dot org 2010-01-06 22:50 ---
Running into this as well.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42634
--- Comment #2 from bkoz at gcc dot gnu dot org 2010-01-06 22:49 ---
*** This bug has been marked as a duplicate of 42634 ***
--
bkoz at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from bkoz at gcc dot gnu dot org 2010-01-06 22:49 ---
*** Bug 42639 has been marked as a duplicate of this bug. ***
--
bkoz at gcc dot gnu dot org changed:
What|Removed |Added
-
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
Status|WAITING |NEW
Last reconfirmed|2010-01-06 22:46:02 |2010-01-06 22:4
--- Comment #1 from bkoz at gcc dot gnu dot org 2010-01-06 22:47 ---
Created an attachment (id=19492)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19492&action=view)
pre-processed
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42639
>From the libstdc++ performance testsuite:
%/mnt/share/bld/gcc/./gcc/g++ -shared-libgcc -B/mnt/share/bld/gcc/./gcc
-nostdinc++ -L/mnt/share/bld/gcc/x86_64-unknown-linux-gnu/libstdc++-v3/src
-L/mnt/share/bld/gcc/x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs
-B/mnt/share/bld/H-x86-gcc/x86_64-unkno
--- Comment #8 from ebotcazou at gcc dot gnu dot org 2010-01-06 22:45
---
ICE on x86_64-apple-darwin10 too.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #7 from ebotcazou at gcc dot gnu dot org 2010-01-06 22:43
---
*** Bug 42627 has been marked as a duplicate of this bug. ***
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2010-01-06 22:43
---
*** This bug has been marked as a duplicate of 42068 ***
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #2 from simon at pushface dot org 2010-01-06 22:38 ---
Having rolled back the change in ipa.c as suggested in 42068, the library
builds successfully.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42627
--- Comment #2 from simon at pushface dot org 2010-01-06 22:35 ---
This is a duplicate of bootstrap/41180, see comment #8. It's an Xcode 3.2
linker bug, (radar 6320843) "duplicate symbols from static libraries not
properly ignored".
Fixes in 41180 were like my fix suggestion, which work
--- Comment #3 from raj dot khem at gmail dot com 2010-01-06 22:34 ---
http://gcc.gnu.org/ml/gcc-patches/2009-06/msg01317.html
could be the fix.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42638
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |paolo dot carlini at oracle
|dot org
--- Comment #6 from burnus at gcc dot gnu dot org 2010-01-06 21:49 ---
Created an attachment (id=19491)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19491&action=view)
Draft patch
Not regtested, need to re-check that the patch is correct, but seems to work
otherwise.
--
http
--- Comment #4 from 3b87w8mt2n at snkmail dot com 2010-01-06 21:27 ---
Er, sorry, that's the message from the wrong run. Here's the right one:
$ gcc -fPIC -c -o test2.o test2.c && gcc -shared -o test2.so test2.o
/usr/bin/ld: test2.o: relocation R_X86_64_PC32 against protected symbol `f
--- Comment #3 from 3b87w8mt2n at snkmail dot com 2010-01-06 21:01 ---
As a data point, this occurs for me with GCC 4.3.4 (Debian 4.3.4-6) on AMD64
(x86_64), compiling the given test file as C:
$ gcc -c -o test2.o test2.c && gcc -shared -o test2.so test2.o
/usr/bin/ld: test2.o: relocati
--- Comment #6 from aoliva at gcc dot gnu dot org 2010-01-06 20:36 ---
Mine
--
aoliva at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at
--- Comment #7 from jocke at vmlinux dot org 2010-01-06 20:31 ---
Yep, works for me too, using crosstool-NG to build an
armeb-unknown-linux-uclibcgnueabi for i686 host. Thanks Ralf!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41818
--- Comment #2 from raj dot khem at gmail dot com 2010-01-06 20:28 ---
Created an attachment (id=19490)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19490&action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42638
--- Comment #1 from raj dot khem at gmail dot com 2010-01-06 20:27 ---
Created an attachment (id=19489)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19489&action=view)
C testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42638
When a formal parameter 1 is not stored on stack the location list mark the
life of this parameter in DW_OP_reg0 however it does not consider the function
calls that would be made in the function in question and the fact that eax can
be destroyed down the call chain. Attached example demonstrates t
--- Comment #6 from denis dot onischenko at gmail dot com 2010-01-06 20:19
---
(In reply to comment #5)
> Created an attachment (id=19486)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19486&action=view) [edit]
> patch to add TARGET_LIB_PATH only when bootstrapping
>
> Please try
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW |SUSPENDED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41995
--- Comment #4 from jason at gcc dot gnu dot org 2010-01-06 19:44 ---
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#225
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#993
--
jason at gcc dot gnu dot org changed:
What|Removed
--- Comment #8 from jason at gcc dot gnu dot org 2010-01-06 19:41 ---
Suspending along with 16635.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #15 from jason at gcc dot gnu dot org 2010-01-06 19:40 ---
I believe http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#993 will
be resolved to allow the G++ behavior. Suspending.
--
jason at gcc dot gnu dot org changed:
What|Removed
--- Comment #5 from dominiq at lps dot ens dot fr 2010-01-06 19:20 ---
"-O3 -floop-interchange -ftree-loop-distribution" gives also a wrong code. This
pr could be a duplicate of pr42637.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42479
--- Comment #2 from dominiq at lps dot ens dot fr 2010-01-06 19:19 ---
The test in comment #1 fails also with "-O2 -floop-block" on
x86_64-apple-darwin10. This pr could be a duplicate of pr42479.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42637
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Summary|[graphite] wrong code for - |[4.5 Regression][graphite]
|floop-interchange -ftre
--- Comment #3 from janis at gcc dot gnu dot org 2010-01-06 18:52 ---
I should have mentioned in comment #2 that the ICE for sixtrack only happens
with -m32, not -m64.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42246
--- Comment #2 from janis at gcc dot gnu dot org 2010-01-06 18:48 ---
The patch at http://gcc.gnu.org/ml/gcc-patches/2009-12/msg01209.html fixes the
testcase in the submitter's description, but there is code in CPU2000 test
200.sixtrack that triggers the same ICE with the same set of opt
--- Comment #7 from rth at gcc dot gnu dot org 2010-01-06 18:48 ---
Fixed.
--
rth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #6 from janis at gcc dot gnu dot org 2010-01-06 18:44 ---
With the patch at http://gcc.gnu.org/ml/gcc-patches/2009-12/msg01209.html the
testcase in the submitter's description no longer fails, but there is other
code in 197.parser that gets the same ICE with the same options.
--- Comment #6 from rth at gcc dot gnu dot org 2010-01-06 18:34 ---
Subject: Bug 41883
Author: rth
Date: Wed Jan 6 18:34:31 2010
New Revision: 155680
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155680
Log:
PR middle-end/41883
* haifa-sched.c (add_to_note_list
--- Comment #1 from janis at gcc dot gnu dot org 2010-01-06 18:27 ---
Created an attachment (id=19488)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19488&action=view)
executable testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42637
As mentioned in PR 42334, 200.sixtrack from SPEC CPU2000 started getting wrong
answers on powerpc64-linux with the Graphite merge at r140301 when compiled
with "-O2 -floop-interchange -ftree-loop-distribution". The loop that is
miscompiled is:
real*8 rt(6,6),r(6,6),rtt(6,6)
do i=1,6
--- Comment #5 from rth at gcc dot gnu dot org 2010-01-06 18:24 ---
*** Bug 42396 has been marked as a duplicate of this bug. ***
--
rth at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #3 from rth at gcc dot gnu dot org 2010-01-06 18:24 ---
*** This bug has been marked as a duplicate of 41883 ***
--
rth at gcc dot gnu dot org changed:
What|Removed |Added
--
--
rth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org
|dot org
--- Comment #4 from rth at gcc dot gnu dot org 2010-01-06 18:23 ---
*** Bug 41889 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41883
--- Comment #8 from rth at gcc dot gnu dot org 2010-01-06 18:23 ---
*** This bug has been marked as a duplicate of 41883 ***
--
rth at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #7 from rth at gcc dot gnu dot org 2010-01-06 18:23 ---
Oops, wrong duplicate.
--
rth at gcc dot gnu dot org changed:
What|Removed |Added
Status|R
--- Comment #5 from rth at gcc dot gnu dot org 2010-01-06 18:22 ---
*** Bug 41889 has been marked as a duplicate of this bug. ***
--
rth at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #6 from rth at gcc dot gnu dot org 2010-01-06 18:22 ---
*** This bug has been marked as a duplicate of 41833 ***
--
rth at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #2 from bkoz at gcc dot gnu dot org 2010-01-06 18:20 ---
Fixed.
--
bkoz at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #17 from ubizjak at gmail dot com 2010-01-06 18:14 ---
This bug is similar (or even a duplicate of) PR21767. ifcvt.c has a fixup code
for cases like this, grep ifcvt.c for:
/* PR 21767: When moving insns above a conditional branch, REG_EQUAL
notes might become
--- Comment #16 from ro at gcc dot gnu dot org 2010-01-06 18:07 ---
Fixed for 4.5.0.
--
ro at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #5 from tschwinge at gcc dot gnu dot org 2010-01-06 17:57
---
This bug exists, by the way, not only when GCC is emitting CFI statements, but
also when it's emitting .debug_frame directly.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42380
--- Comment #4 from gmorin1 at bloomberg dot net 2010-01-06 17:51 ---
My original tests were done on x86/x86_64. I observed the same problem with
gcc 4.3.2 when compiling for PowerPC on AIX. For some reason, the output is
properly optimized with the same version (different build though
--- Comment #4 from torbenh at gmx dot de 2010-01-06 17:42 ---
Created an attachment (id=19487)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19487&action=view)
patch to add the attribute
i am not sure about the decl_req, type_req, fn_type_req values.
maybe its true, false, false
--- Comment #5 from rwild at gcc dot gnu dot org 2010-01-06 17:33 ---
Created an attachment (id=19486)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19486&action=view)
patch to add TARGET_LIB_PATH only when bootstrapping
Please try this patch. Thanks.
--
http://gcc.gnu.org/b
Hello,
the program below gives a warning with some versions of gcc.
I tried with 4.3.4, 4.4.2 (debian versions) and 4.5.0 (snapshot, compiled
myself today). Some people told me that 4.2.4, 4.2.1 and 3.4.6 don't warn.
4.5.0 outputs:
#Âssa_name not supported by pp_c_expression#]Âkr-1-17.c: In fu
--- Comment #3 from ljrittle at gcc dot gnu dot org 2010-01-06 17:15
---
Considered and rejected.
--
ljrittle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from paolo dot carlini at oracle dot com 2010-01-06 16:39
---
Ok, thanks. Can you summarize the present status, then? Outstanding issues,
maybe more patchlets... ;)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42460
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-01-06 16:48 ---
(In reply to comment #4)
> By the same argument, shouldn't we drop the assignment early, and make it a
> non-assigning call?
Sure - fixing this during gimplification would be fine with me. I'm not
sure it cannot ha
--- Comment #24 from paolo dot carlini at oracle dot com 2010-01-06 16:37
---
As I understand the audit trail, this can be closed. If somebody has solid
reasons to disagree, please re-open.
--
paolo dot carlini at oracle dot com changed:
What|Removed
--- Comment #4 from aoliva at gcc dot gnu dot org 2010-01-06 16:36 ---
By the same argument, shouldn't we drop the assignment early, and make it a
non-assigning call? The assignment is also supposed to occur after the call,
although it's not denoted in a separate statement, but SSA anal
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-01-06 16:30 ---
Confirmed. Older releases ICE differently.
Note that I don't see an ICE with -g0 but only with -g.
With plain -g the code is even rejected:
> ./cc1plus -quiet -std=c++0x t.ii
ok
> ./cc1plus -quiet -std=c++0x t.ii
--- Comment #5 from aoliva at gcc dot gnu dot org 2010-01-06 16:15 ---
Mine. Patch at http://gcc.gnu.org/ml/gcc-patches/2010-01/msg00267.html
The thread is about bug 42604, but the improvements for the fix for that patch
fixed this one too.
--
aoliva at gcc dot gnu dot org changed:
--- Comment #16 from ubizjak at gmail dot com 2010-01-06 15:17 ---
The problem turns out to be quite complex interaction between cse1, cprop3 and
cse2 pass.
Let's start with this RTL dump for from:
tree-ssa-loop-im.i.148r.subreg1
;; Function determine_max_movement (determine_max_movem
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-01-06 15:17 ---
Created an attachment (id=19485)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19485&action=view)
testcase using vec.h
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42635
The following two functions are not if-converted at the tree level (the 2nd
example happens a lot from VEC code via VEC_BASE):
int *bar (char *p)
{
int *q;
if (p)
q = (int *)p;
else
q = (int *)0;
return q;
}
struct X { int q; };
int *foo (struct X *p)
{
int *q;
if (p)
q =
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Target Milestone|--- |4.3.6
Version|4.5.0 |4.3.5
http://
--- Comment #16 from hjl dot tools at gmail dot com 2010-01-06 14:59
---
(In reply to comment #15)
> Can we expect a 4.4 backport for this, at least in the ix86/4.4 branch if not
> in the main 4.4 branch?
>
It will be backported to 4.3/4.4 in a few days.
--
http://gcc.gnu.org/bug
--- Comment #2 from burnus at gcc dot gnu dot org 2010-01-06 14:16 ---
I think a description does not belong into "man gfortran" (invoke.texi), but
maybe into the general text of gfortran.texi.
I think .mod files are not obvious; the standard does not say anything about
them, though (al
> cat bug.ii
template T declval();
template struct is_constructible {
template
static decltype(T1(declval()...), char()) test();
static const bool value = sizeof(test()) == 1;
};
template struct enable_if {
typedef void type;
};
template struct pair {
--- Comment #4 from jamborm at gcc dot gnu dot org 2010-01-06 14:07 ---
(In reply to comment #2)
> SRA here again does somthing stupid:
>
As I have already told richi on IRC, if "in.value = value_1(D)" was an
assignment of two unions, it would have loaded the chars from the rhs
and thu
--- Comment #3 from burnus at gcc dot gnu dot org 2010-01-06 14:04 ---
Hmm, seemingly, comment 0 also works - at least with patch
http://gcc.gnu.org/ml/fortran/2010-01/msg00043.html
Close as WORKSFORME.
--
burnus at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from burnus at gcc dot gnu dot org 2010-01-06 13:57 ---
The following also looks bogus:
static struct t a = {.i=4};
Though, it seems to work - contrary to the version in comment 0.
program test
implicit none
type t
integer :: i = 4
integer, allocatable :: a(
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-01-06 13:57 ---
Mine.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned
--- Comment #4 from jocke at vmlinux dot org 2010-01-06 13:53 ---
I can confirm this issue while building an armeb-unknown-uclibcgnueabi
(big-endian) cross toolchain on i686 (Ubuntu 9.10 32-bit) using crosstool-NG.
However, I cannot replicate it on any host running x86_64 (Ubuntu 9.04 o
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-01-06 13:32 ---
Actually this bug was fixed by
2010-01-05 Martin Jambor
PR tree-optimization/42462
* ipa-inline.c (compute_inline_parameters): Pass node->decl instead of
current_function_decl to helper f
--- Comment #2 from torbenh at gmx dot de 2010-01-06 13:19 ---
the generated x86_64 asm: _Z11fill_bufferPfm: .LFB3: testq %rsi, %rsi
je .L4 xorl%eax, %eax movss .LC0(%rip), %xmm2
.p2align 4,,10 .p2align 3 .L3: movss ramp(%rip), %xmm1 m
1 - 100 of 130 matches
Mail list logo
