--- Comment #3 from vkolluri at cisco dot com 2009-04-11 06:58 ---
The short moves(16-bit)do not work when the -O3 optimization flag is set. It
turns out that there are a couple of instances of instruction misordering in
the asm code.
The same program works fine without the optimization
--- Comment #2 from vkolluri at cisco dot com 2009-04-11 06:49 ---
Created an attachment (id=17617)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17617&action=view)
preprocessed file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39734
--- Comment #1 from vkolluri at cisco dot com 2009-04-11 06:48 ---
Created an attachment (id=17616)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17616&action=view)
gcc version,system type etc
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39734
--
Summary: Misordering of instructions for short moves in a C
program
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component: c
AssignedTo: unassigned at gcc
--- Comment #3 from rob1weld at aol dot com 2009-04-11 03:21 ---
# grep offsetof /home/user/gcc_trunk/gcc/ginclude/stddef.h
#define offsetof(TYPE, MEMBER) __builtin_offsetof (TYPE, MEMBER)
Every other occurrence of stddef.h (in 'trunk', build, or in
/usr/include/stddef.h is defined as:
--- Comment #2 from rob1weld at aol dot com 2009-04-11 02:33 ---
(In reply to comment #1)
...
> This suggests the code is getting the wrong definition of offsetof. It
> should be getting the one in GCC's own or another one
> compatible with recent GCC (using __builtin_offsetof). Sin
--- Comment #27 from rob1weld at aol dot com 2009-04-11 02:27 ---
(In reply to comment #26)
> <<
> We still have the issue that all Platforms accept the (usually non-default)
> ./configure option "--enable-sjlj-exceptions" which leads to this Bug
> on supported Platforms (and leads us do
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-04-11 01:06 ---
Confirmed, please stop setting the target milestone unless the bug is a
regression.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--
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=39733
--- Comment #2 from hjl dot tools at gmail dot com 2009-04-11 01:05 ---
A patch is posted at
http://gcc.gnu.org/ml/gcc-patches/2009-04/msg00852.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
---
--- Comment #1 from hjl dot tools at gmail dot com 2009-04-11 00:55 ---
The problem is both lib/options.exp and gcc.misc-tests/options.exp
define check_for_options. But they take different parameters and are
different. gcc.misc-tests/help.exp has
load_lib options.exp
But you really do
--- Comment #14 from hjl at gcc dot gnu dot org 2009-04-11 00:43 ---
Subject: Bug 39701
Author: hjl
Date: Sat Apr 11 00:43:33 2009
New Revision: 145948
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=145948
Log:
2009-04-10 Paolo Bonzini
PR tree-optimization/39701
On Linux/x86-64 with multilib, gcc.misc-tests/help.exp failed:
http://gcc.gnu.org/ml/gcc-testresults/2009-04/msg01053.html
FAIL: compiler driver -v --help option(s) (assembler options)
FAIL: compiler driver -v --help option(s) (linker options)
FAIL: compiler driver -v --help option(s) (assembler
--- Comment #9 from dominiq at lps dot ens dot fr 2009-04-10 22:41 ---
> Dominique, any improvements here with -fwhole-file?
AFAICT the answer is no: the invalid code in comment #0 is not rejected (see
comment #6 for the kind of expected diagnostic).
I think this PR should be closed as
--- Comment #14 from dominiq at lps dot ens dot fr 2009-04-10 22:33 ---
Could the patches in comments #11 to #13 be applied to trunk too?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25104
--- Comment #1 from zlynx at acm dot org 2009-04-10 22:22 ---
Created an attachment (id=17615)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17615&action=view)
preprocessed C++ test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39732
g++ -O1 -fprofile-generate gcc-bug/test-case.ii
gcc-bug/test-case.cpp: In function int f(const int*):
gcc-bug/test-case.cpp:14: error: address taken, but ADDRESSABLE bit not set
D.27568
gcc-bug/test-case.cpp:14: note: in statement
D.27611 = &D.27568;
gcc-bug/test-case.cpp:14: internal compiler
--- Comment #11 from dfranke at gcc dot gnu dot org 2009-04-10 22:12
---
Testcase of comment #9 now gives:
$ gfortran-svn -fwhole-file -g -Wall -c pr22571.f90
pr22571.f90:13.9:
call a(q)
1
Error: Type mismatch in argument 'p' at (1); passed TYPE(u) to TYPE(t)
Paul, can we c
--- Comment #10 from dfranke at gcc dot gnu dot org 2009-04-10 21:53
---
> To assess whether this is a middle-end issue, the alias dump (with VOPS
> and linenumbers) would be relevant.
The testcase in #8 still gives the same warning.
Manuel, you refer to the output of -fdump-tree-alia
It would be nice to provide separate -W flags for the "is used uninitialized"
and "may be used uninitialized" variants of -Wuninitialized. The former is
always a problem, while the latter is often noise.
See this thread:
http://ozlabs.org/pipermail/linuxppc-dev/2009-April/070540.html
--
--- Comment #11 from dfranke at gcc dot gnu dot org 2009-04-10 21:38
---
Jakub, is anything left to do? Can this one be closed?
How about PR24526, is this fixed as well?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29635
--- Comment #10 from dfranke at gcc dot gnu dot org 2009-04-10 21:35
---
With the commit in comment #9 we get:
$> gfortran-svn -fwhole-file -Wall pr24886.f
[...]
pr24886.f:8.20:
call foo(x)
1
Warning: Character length of actual argument shorter than of d
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dfranke at gcc dot gnu dot
|dot org
--- Comment #11 from dfranke at gcc dot gnu dot org 2009-04-10 21:23
---
Jerry, is this complete? If not, could you please summarize what's left?
Thanks.
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #10 from dfranke at gcc dot gnu dot org 2009-04-10 21:03
---
Closing as this seems to be completed.
Please reopen if there's an issue left.
Thanks for the reports!
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #8 from dfranke at gcc dot gnu dot org 2009-04-10 20:50 ---
Dominique, any improvements here with -fwhole-file?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36553
--- Comment #10 from dfranke at gcc dot gnu dot org 2009-04-10 20:44
---
Is this still valid?
Is there a relation to PR21203?
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--
For this example:
# include
# include
using namespace std;
ifstream x;
ifstream y();
int main(int argc, char** argv) {
return 0;
}
current mainline g++ says:
foo.cc:6: error: aggregate std::ifstream x has incomplete type and cannot be
defined
This is accurate but confusing for the un
For this C++ example:
using namespace std;
ifstream x;
ifstream y();
int main(int argc, char** argv) {
return 0;
}
current mainline g++ says this:
foo.cc:3: error: ifstream does not name a type
foo.cc:4: error: ifstream does not name a type
ifstream not only does not name a type, it i
For this test case:
# include
# include
using namespace std;
ifstream x;
ifstream& y = x;
int main(int argc, char** argv) {
y = x;
return 0;
}
current mainline g++ produces:
In file included from
/home/iant/gcc/install/lib/gcc/i686-pc-linux-gnu/4.5.0/../../../../include/c++/4.5.0/ios:3
--- Comment #1 from bonzini at gnu dot org 2009-04-10 20:06 ---
This was actually fixed already with local patches, at least above -O1.
--
bonzini at gnu dot org changed:
What|Removed |Added
-
--- Comment #12 from hjl dot tools at gmail dot com 2009-04-10 19:37
---
Fixed.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Status|REOPENE
--- Comment #11 from hjl at gcc dot gnu dot org 2009-04-10 19:36 ---
Subject: Bug 28301
Author: hjl
Date: Fri Apr 10 19:36:19 2009
New Revision: 145939
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=145939
Log:
gcc/cp/
2009-04-10 H.J. Lu
Backport from mainline:
--- Comment #14 from pault at gcc dot gnu dot org 2009-04-10 19:06 ---
(In reply to comment #9)
> The code in comment #1 still does not give the right result. I get
> (intel-darwin):
No, it's not right. We have seen this before with module assignments involving
derived types.
It shou
--- Comment #10 from hjl at gcc dot gnu dot org 2009-04-10 19:01 ---
Subject: Bug 28301
Author: hjl
Date: Fri Apr 10 19:01:16 2009
New Revision: 145938
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=145938
Log:
gcc/cp/
2009-04-10 H.J. Lu
Backport from mainline:
--- Comment #13 from hjl at gcc dot gnu dot org 2009-04-10 18:58 ---
Subject: Bug 39701
Author: hjl
Date: Fri Apr 10 18:58:12 2009
New Revision: 145937
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=145937
Log:
2009-04-10 H.J. Lu
PR middle-end/39701
* common.
--- Comment #9 from hjl at gcc dot gnu dot org 2009-04-10 18:56 ---
Subject: Bug 28301
Author: hjl
Date: Fri Apr 10 18:56:07 2009
New Revision: 145936
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=145936
Log:
gcc/cp/
2009-04-10 Jason Merrill
PR c++/28301
*
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-04-10 18:43 ---
I am testing the following
Index: tree-ssa-sccvn.c
===
--- tree-ssa-sccvn.c(revision 145876)
+++ tree-ssa-sccvn.c(working copy)
@@ -257,9 +257,
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-04-10 18:31 ---
I will have a looksee.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Assi
--- Comment #7 from hjl dot tools at gmail dot com 2009-04-10 17:35 ---
Fixed as of revision 145878.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #12 from hjl at gcc dot gnu dot org 2009-04-10 17:14 ---
Subject: Bug 39701
Author: hjl
Date: Fri Apr 10 17:14:35 2009
New Revision: 145930
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=145930
Log:
2009-04-10 Paolo Bonzini
PR middle-end/39701
* t
--- Comment #11 from hp at gcc dot gnu dot org 2009-04-10 16:52 ---
(In reply to comment #9)
> This is an alternative way to fix the PR36901 failures by enabling
> -fdelete-null-pointer-checks at -O0 and -O1.
>
> The patch is preapproved, but I won't have time to test it and apply it un
--- Comment #10 from hp at gcc dot gnu dot org 2009-04-10 16:50 ---
(In reply to comment #6)
> > We know it's not NULL.
> I don't think the compiler can say so if not -fdelete-null-pointer-checks, and
> the flag is off at -O0 and -O1 (which is a separate bug and a separate patch).
Diffe
--- Comment #9 from bonzini at gnu dot org 2009-04-10 16:18 ---
Created an attachment (id=17614)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17614&action=view)
second part of the fix
This is an alternative way to fix the PR36901 failures by enabling
-fdelete-null-pointer-checks
--- Comment #8 from bonzini at gnu dot org 2009-04-10 16:07 ---
The fortran problem is now latent. The PR39601 failures remain and will be
cured differently.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39701
--- Comment #7 from bonzini at gnu dot org 2009-04-10 16:06 ---
Subject: Bug 39701
Author: bonzini
Date: Fri Apr 10 16:06:43 2009
New Revision: 145927
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=145927
Log:
2009-04-10 Paolo Bonzini
PR middle-end/39701
* fo
--- Comment #6 from bonzini at gnu dot org 2009-04-10 16:05 ---
> We know it's not NULL.
I don't think the compiler can say so if not -fdelete-null-pointer-checks, and
the flag is off at -O0 and -O1 (which is a separate bug and a separate patch).
--
http://gcc.gnu.org/bugzilla/show
--- Comment #4 from alpha dot super-one at laposte dot net 2009-04-10
15:42 ---
I have not that's in lot of version, my code tested is here:
http://www.developpez.net/forums/m4191192-3/
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39699
--- Comment #5 from hp at gcc dot gnu dot org 2009-04-10 15:28 ---
For the record, seeing the same regressions for cris-elf, 145839:145857.
Wrt. comment #3, if addresses were unsigned before (or this'd have failed),
they should still be so, and this still be constant true, right? Regar
--- Comment #1 from bonzini at gnu dot org 2009-04-10 15:25 ---
Another testcase, this one failing at -O2:
void foo (unsigned int n)
{
int i, j = -1;
for (i = 0; i < 10 && j < 0; i++)
if ((1UL << i) == n)
j = i;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39
double testit(double _Complex* t)
{
return *t==0.0?0.0:-*t;
}
includes useless sequence like
clr.l -(%sp);clr.l -(%sp);fdmove.d (%sp)+,%fp1
fdmove.d (%a0),%fp0
fcmp.d %fp1,%fp0
where the first and last line are useless -- GCC could instead be using the
flags as set by a fd
unsigned char v;
int baz (unsigned char u, unsigned char w)
{
if ((u - w) & 0x80)
v = 1;
}
Combine does not like as much as for m68k the RTL produced by the optimizers,
because of the lack of byte operations:
(insn 10 9 11 f.c:5 (set (reg:QI 35)
-(and:QI (subreg:QI (reg:SI 34) 3)
--- Comment #13 from pault at gcc dot gnu dot org 2009-04-10 14:27 ---
(In reply to comment #12)
> Comment #11 should probably go to PR38802.
>
Indeed - sorry.
Paul
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38863
MIPS floating-point comparisons are sometimes improved, sometimes pessimized.
Here are the tests that are pessimized more:
gcc.c-torture/execute/ieee/compare-fp-1.c
gcc.c-torture/execute/ieee/compare-fp-4.c (-fno-trapping-math)
gcc.c-torture/unsorted/DFcmp.c
(not for all versions, but for exampl
--- Comment #2 from dfranke at gcc dot gnu dot org 2009-04-10 14:13 ---
Fixed in trunk. Not a regression, no backport.
Closing.
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #1 from dfranke at gcc dot gnu dot org 2009-04-10 14:12 ---
Subject: Bug 38709
Author: dfranke
Date: Fri Apr 10 14:12:01 2009
New Revision: 145909
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=145909
Log:
gcc/fortran/:
2009-04-10 Daniel Franke
PR fortran
--- Comment #13 from dfranke at gcc dot gnu dot org 2009-04-10 14:04
---
Subject: Bug 25104
Author: dfranke
Date: Fri Apr 10 14:04:16 2009
New Revision: 145907
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=145907
Log:
gcc/fortran/:
2009-04-10 Daniel Franke
PR fortr
--- Comment #16 from dfranke at gcc dot gnu dot org 2009-04-10 14:04
---
Subject: Bug 29962
Author: dfranke
Date: Fri Apr 10 14:04:16 2009
New Revision: 145907
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=145907
Log:
gcc/fortran/:
2009-04-10 Daniel Franke
PR fortr
reload_cse_simplify_operandss likes to change (compare REG (const_int 0)) to a
compare between registers on VAX, when it has a register at hand whose value is
zero. This pessimizes code and in some cases even introduces spurious compares
instead of using CC0.
/* -Os */
f(int count,double r,doubl
long long xlrandom (long long x)
{
int bits = 64;
do
{
unsigned b = (random () & 15) + 1;
x <<= b; /* shift up 1-16 steps */
bits -= b;
}
while (bits >= 0);
return x;
}
--
Summary: [cond-optab] worse code with long long shifts
--- Comment #4 from hjl dot tools at gmail dot com 2009-04-10 12:54 ---
(In reply to comment #3)
> The pr36901-* are correct to fail IMO -- they now give an "initializer is not
> constant" error which they weren't giving before -- because you cannot know in
> principle that &sc > 0 at co
--- Comment #9 from manu at gcc dot gnu dot org 2009-04-10 12:51 ---
Fixed in GCC 4.5
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
struct S
{
unsigned int s;
};
struct T
{
struct S t[2];
unsigned int u : 1;
};
void
foo (int x, int y, int z)
{
int i;
struct T t;
t.u = t.u;
for (i = 0; i < x; i++)
if (z != 1)
t.t[i].s = y || t.u;
}
--
Summary: [cond-optab] worse code with bitfields on v850
/* -O2 */
int dialog_calendar(int state)
{
int *obj = (state == 1 ? &state : 0);
return (obj == &state);
}
--
Summary: [cond-optab] worse register allocation on mn10300
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
--- Comment #8 from manu at gcc dot gnu dot org 2009-04-10 12:48 ---
Subject: Bug 20118
Author: manu
Date: Fri Apr 10 12:47:58 2009
New Revision: 145892
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=145892
Log:
2009-04-10 Manuel López-Ibáñez
PR c++/20118
cp/
/* -O1 mn10300 */
int f (int a, int b, int c, _Bool d, _Bool e, _Bool f, char g)
{
if (g != 1 || d != 1 || e != 1 || f != 1) abort ();
return a + b + c;
}
int main (void)
{
if (f (1, 2, -3, 1, 1, 1, '\001'))
abort ();
exit (0);
}
--
Summary: [cond-optab] combine does not
Note that this is a win on most targets:
int
foo ()
{
extern long long Y;
return (0 > Y++);
}
--
Summary: [cond-optab] uses libcall instead of branch on m68hc11
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
/* -O3 -funroll-loops */
int foo (long b, int c)
{
int d = 0, e;
while (b--)
{
e = 0;
if (!d) e = d = 1; else e = 0;
if (!(c & 0x10) || !(c & 0x4000) || !e) continue;
if (c & 0x80) break;
}
}
--
Summary: [cond-optab] crash on crx in IRA
P
/* cris and mn10300 -O2 */
foo (float *c)
{
union
{
float r;
unsigned int i;
}
e;
e.r = c[0];
if (e.i < 0x3f7f) return (e.r = e.r / 2.0f, e.i);
return ((int) e.i < 0) ? 0 : 255;
}
Probably this is a duplicate too for vax:
int a, b;
int baz (short x) { return x; }
int
--
ayers at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |ayers at gcc dot gnu dot org
|dot org
/* -O1 -mthumb -march=armv6t2 -ffinite-math-only */
float repl1 (float varx)
{
if (varx < 0.0)
return 0.0;
return varx;
}
--
Summary: [cond-optab] worse MAX_EXPR expansion for Thumb
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
/* -O1 -mthumb -march=armv5t */
struct foo
{
unsigned b31 : 1;
unsigned b30 : 1;
unsigned b29 : 1;
unsigned b28 : 1;
unsigned rest : 28;
};
foo(a)
struct foo a;
{
return a.b30;
}
should have only one lsl and lsr
--
Summary: [cond-optab] extra sign extensions on Thu
--- Comment #3 from ayers at gcc dot gnu dot org 2009-04-10 12:43 ---
Created an attachment (id=17613)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17613&action=view)
rewrite of dispatch table installation
I agree with the approach you describe, in that we need a look-a-side buff
This bug groups testcases that worsen or (in one case) ICE on cond-optab
branch.
--
Summary: cond-optab fallout meta-bug
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Keywords: meta-bug
Severity: normal
Priority: P3
--- Comment #3 from dodji at gcc dot gnu dot org 2009-04-10 11:46 ---
Subject: Re: No error reporting when function and variable
have the same name
alpha dot super-one at laposte dot net a écrit :
> --- Comment #2 from alpha dot super-one at laposte dot net 2009-04-10
> 04:47 --
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39713
Since r141534 (PR37542), the following testcase segfaults during fre at -O1 and
higher:
template
static inline To
bitwise_cast (From from)
{
union
{
From f;
To t;
} u;
u.f = from;
return u.t;
}
extern void foo (unsigned char *);
double
bar ()
{
unsigned char b[sizeof (unsign
--- Comment #4 from paolo dot carlini at oracle dot com 2009-04-10 09:40
---
This is illegal in C++03, because std::map has 4 template parameters, no matter
the defaults. Changing class A like the below works. In c++0x, thanks to
typedef templates neater solutions will be possible.
tem
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-04-10 08:56 ---
Reduced testcase:
int is_table[2][16];
int is_table_lsf[2][2][16];
void compute_stereo()
{
int (*is_tab)[16];
is_tab = is_table;
}
interestingly removing the unrelated is_table_lsf decl makes the error go a
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-04-10 08:18 ---
Likely due to my patch. I'll have a look.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #11 from jb at gcc dot gnu dot org 2009-04-10 07:23 ---
Subject: Bug 39665
Author: jb
Date: Fri Apr 10 07:23:25 2009
New Revision: 145875
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=145875
Log:
2009-04-10 Janne Blomqvist
PR libfortran/39665 libfortran/
81 matches
Mail list logo
