--- Comment #1 from bje at gcc dot gnu dot org 2009-07-14 07:06 ---
Confirmed.
--
bje at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #26 from burnus at gcc dot gnu dot org 2009-07-14 07:43 ---
Patch: http://gcc.gnu.org/ml/gcc-patches/2009-07/msg00739.html
- MPC compile-time evaluation of complex tan and sinh/cosh/tanh
- Run-time complex a(sin,cos,tan)(h) with C99 fallback (for finite values only)
TODO:
-
--- Comment #3 from burnus at gcc dot gnu dot org 2009-07-14 07:50 ---
Confirm (kind of) with GCC 4.3.2 on i686-linux. With -DBIGMOD one gets:
/tmp/ccmoM1rS.o: In function `tf_ad_splitting_driver_plane_':
t.F90:(.text+0xad): undefined reference to `span.1'
t.F90:(.text+0x15c): undefined
>From https://bugzilla.redhat.com/show_bug.cgi?id=511168:
template
T addsome(T v) {
return v+1;
}
int addsome(int v) {
return v+2;
}
int main() {
int i = 0;
if (addsome(i) != 2)
return 1;
if (addsome<>(i) != 1)
return 2;
return 0;
}
Broken by fix for PR 13549.
--
--- Comment #4 from photon at seznam dot cz 2009-07-14 08:37 ---
(In reply to comment #3)
> and with integer promotion happening with simple stuff like a + b,
> some folks will have a hard time to understand that happens which
> is why it is not enabled with -Wall.
The warning is issue
Compile following function with options -Os -mthumb -march=armv5te:
int returnbool(int a, int b)
{
if (a < b)
return 1;
return 0;
}
Gcc 4.5 generates:
lsr r3, r1, #31
asr r2, r0, #31
cmp r0, r1
adc r2, r2, r3
mov r0, r2
--- Comment #1 from carrot at google dot com 2009-07-14 08:41 ---
Created an attachment (id=18191)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18191&action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40741
At revision 149591, compiling iso_varying_string.f95 gives the following error:
[ibook-dhum] f90/bug% gfc -c iso_varying_string.f95
iso_varying_string.f95:2548.29:
end module iso_varying_string
1
Internal Error at (1):
resolve_code(): Bad statement code
Probably due
Note: GCC for Microblaze was used (mb-gcc)
The code that caused the error:
#define APP_ENTRY_POINT_BASE((unsigned int)0x30)
#define APP_ENTRY_POINT_OFFSET ((unsigned int)0x20)
#define APP_ENTRY_POINT (APP_ENTRY_POINT_BASE + APP_ENTRY_POINT_OFFSET)
int main()
{
(*((v
--- Comment #4 from carrot at google dot com 2009-07-14 09:14 ---
In TREE level, the two stores are different statements. Only after register
allocation, the two stores get same register and make the load redundant.
try_crossjump_bb tries to find same instruction sequence in all predece
--- Comment #5 from steven at gcc dot gnu dot org 2009-07-14 09:18 ---
As you said, try_crossjump_bb tries to find the same instruction sequence in
*all* predecessors of a basic block bb. Meaning that the load must have been
redundant even before cross jumping occurred.
If you are right
--- Comment #6 from steven at gcc dot gnu dot org 2009-07-14 09:20 ---
Carrot, can you please try this test case with my patch
"crossjump_abstract.diff" from Bug 20070 applied?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40730
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-07-14 09:20 ---
I cannot compile the attached testcase.
gcc-4.2 -S -o /dev/null -g -fstack-protector -fPIE -Os test_node.i -std=c99
In file included from ../nih/test_alloc.h:32,
from ../nih/test.h:36,
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-07-14 09:22 ---
Recent regression, revision 149585 works.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40739
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-07-14 09:22 ---
Maybe caused by the cond-optab rework.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-07-14 09:23 ---
GCC 4.1.1 is no longer maintained, please update to at least GCC 4.3.3 and
try there. Also always paste the output of gcc -v.
--
rguenth at gcc dot gnu dot org changed:
What|Removed
--- Comment #5 from jakub at gcc dot gnu dot org 2009-07-14 09:24 ---
-Wconversion hits extremely often, it is definitely not a warning that can or
should be enabled in -Wall, nor in -W.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40733
--- Comment #2 from steven at gcc dot gnu dot org 2009-07-14 09:26 ---
Microblaze is not an FSF GCC version.
Please report this bug to the distributor of mb-gcc (Google says this is
http://www.petalogix.com/resources/downloads/mb-gcc). and kindly request them
to adjust the bug-reporting
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfir
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-07-14 09:28 ---
Hm, or rather it works for me (on x86_64 w/ and w/o -m32).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40739
--- Comment #21 from rguenth at gcc dot gnu dot org 2009-07-14 09:33
---
Subject: Bug 37889
Author: rguenth
Date: Tue Jul 14 09:32:55 2009
New Revision: 149620
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149620
Log:
2009-07-14 Richard Guenther
Backport from mainl
--- Comment #11 from rguenth at gcc dot gnu dot org 2009-07-14 09:33
---
Subject: Bug 39110
Author: rguenth
Date: Tue Jul 14 09:32:55 2009
New Revision: 149620
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149620
Log:
2009-07-14 Richard Guenther
Backport from mainl
--- Comment #12 from rguenth at gcc dot gnu dot org 2009-07-14 09:33
---
Subject: Bug 38921
Author: rguenth
Date: Tue Jul 14 09:32:55 2009
New Revision: 149620
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149620
Log:
2009-07-14 Richard Guenther
Backport from mainl
--- Comment #22 from rguenth at gcc dot gnu dot org 2009-07-14 09:33
---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNE
--- Comment #13 from rguenth at gcc dot gnu dot org 2009-07-14 09:34
---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNE
--- Comment #1 from burnus at gcc dot gnu dot org 2009-07-14 09:46 ---
> Probably due (or uncovered) by revision 149586
That's: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149586
2009-07-13 Janus Weil
PR fortran/40646
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4
--- Comment #2 from burnus at gcc dot gnu dot org 2009-07-14 09:47 ---
> [ibook-dhum] f90/bug% gfc -c iso_varying_string.f95
I assume that's the file: http://www.fortran.com/iso_varying_string.f95
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40743
--- Comment #3 from bonzini at gnu dot org 2009-07-14 10:08 ---
One side problem here is that
mov r0, r2
mov r3, #1
eor r0, r0, r3
could become
mov r0, #1
eor r0, r0, r2
--
bonzini at gnu dot org changed:
What
--- Comment #3 from doko at ubuntu dot com 2009-07-14 10:31 ---
my bad, should be -std=gnu99 instead: gcc-4.2 -S -o /dev/null -g
-fstack-protector -fPIE -Os test_node.i -std=gnu99
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40735
--- Comment #4 from bonzini at gnu dot org 2009-07-14 10:34 ---
... and besides that, we do not take rtx_costs into account.
--
bonzini at gnu dot org changed:
What|Removed |Added
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
Status|WAITING |NEW
Last reconfirmed|2009-04-30 13:18:25 |2009-07-14 10:47:3
--- Comment #2 from bonzini at gnu dot org 2009-07-14 10:51 ---
Here combine simplifies the zero extension from
(lshiftrt:SI (ashift:SI (subreg:SI (reg:QI 138) 0)
(const_int 24 [0x18]))
(const_int 24 [0x18]))
to (ne:SI (subreg:SI (reg:QI 138)). From there it cannot derive
--- Comment #3 from dominiq at lps dot ens dot fr 2009-07-14 10:54 ---
> I assume that's the file: http://www.fortran.com/iso_varying_string.f95
yes.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40743
struct X { int i; int j; };
void foo(void)
{
struct X x;
x.i = 1;
x.j = 2;
}
early SRA produces
foo ()
{
int x$j;
int x$i;
struct X x;
:
x$i_3 = 1;
x$j_2 = 2;
return;
which is unnecessary work as DCE will end up removing the stores anyway.
We should avoid doing useless work h
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-07-14 11:31 ---
This is likely caused by the DF merge. There are numerous bugs about this
already and nothing really can be done here.
Btw, my numbers are
rguent...@murzim:/tmp> ~/bin/maxmem2.sh gcc-4.4 -S -o /dev/null -g
-fstack
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |major
Component|target |rtl-optimizat
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-07-14 12:32 ---
If 4.3.3 worked please add that release in the known-to-work field.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #3 from bonzini at gnu dot org 2009-07-14 12:56 ---
Richard, is your testcase also a regression? In that case the culprit is
mostly
#if 0
/* Disabled to avoid exponential mutual recursion between nonzero_bits
and num_sign_bit_copies. */
if (num_sign_bi
Revision 149624:
http://gcc.gnu.org/ml/gcc-cvs/2009-07/msg00505.html
caused:
FAIL: gcc.target/x86_64/abi/test_3_element_struct_and_unions.c compilation,
-O0 (internal compiler error)
FAIL: gcc.target/x86_64/abi/test_basic_array_size_and_align.c compilation, -O0
(internal compiler error)
--
--- Comment #4 from janus at gcc dot gnu dot org 2009-07-14 13:20 ---
Here is a minimal test case:
implicit none
type :: varying_string
end type
interface assignment(=)
procedure op_assign_VS_CH
end interface
contains
subroutine op_assign_VS_CH (var, exp)
type(v
--- Comment #4 from jakub at gcc dot gnu dot org 2009-07-14 13:26 ---
Created an attachment (id=18192)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18192&action=view)
gcc45-pr40643.patch
Slightly adjusted patch, so that even when array size isn't known compile time
constant it ca
--- Comment #5 from jakub at gcc dot gnu dot org 2009-07-14 13:31 ---
Created an attachment (id=18193)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18193&action=view)
gcc45-pr40643.patch
And now a patch which uses two loops instead of one if needed for performance
(in the honor n
--- Comment #5 from janus at gcc dot gnu dot org 2009-07-14 13:38 ---
Backtrace for the code in comment #4:
#0 resolve_code (code=0x2f26580, ns=0x2f25520) at
/home/jweil/gcc45/trunk/gcc/fortran/resolve.c:7168
#1 0x00512703 in resolve_codes (ns=0x2f25520) at
/home/jweil/gcc45/t
--- Comment #6 from janus at gcc dot gnu dot org 2009-07-14 13:50 ---
The error goes away with the following patch:
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c (revision 149623)
+++ gcc/fortran/resolve.
--- Comment #11 from paolo dot carlini at oracle dot com 2009-07-14 14:00
---
Jason, this is the issue, you are in CC. Actually, using declarations are not
directly involved - I was misremembering - are only part of my ugly workaround,
and, beware, I menace to use it... ;)
--
http:
--- Comment #6 from manu at gcc dot gnu dot org 2009-07-14 14:04 ---
There is a FAQ for the new Wconversion:
http://gcc.gnu.org/wiki/NewWconversion#faq
It should answer users' concerns.
As for Wall, we have users requesting less warnings from Wall and users
requesting more. We try to
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-07-14 14:08 ---
Subject: Bug 40745
Author: rguenth
Date: Tue Jul 14 14:08:09 2009
New Revision: 149627
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149627
Log:
2009-07-14 Richard Guenther
PR middle-end/40745
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-07-14 14:08 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRM
--- Comment #11 from rearnsha at gcc dot gnu dot org 2009-07-14 14:53
---
The following define_split works for this specific case, but it needs to be
made more generic (handling IOR and HImode variants).
It also needs reworking for big-endian -- that needs (subreg...3).
(define_split
namespace A
{
int i;// { dg-error "i" }
}
using namespace A;
namespace B
{
namespace B2
{
int i; // { dg-error "i" }
}
using namespace B2;
}
using namespace B;
int j = ::i;// { dg-error "ambiguous" }
The code currently
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed|0 |1
Last reco
--- Comment #5 from dodji at gcc dot gnu dot org 2009-07-14 15:02 ---
Subject: Bug 40705
Author: dodji
Date: Tue Jul 14 15:01:55 2009
New Revision: 149628
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149628
Log:
2009-07-14 Dodji Seketeli
gcc/ChangeLog:
PR debug/407
--- Comment #7 from photon at seznam dot cz 2009-07-14 15:13 ---
(In reply to comment #5)
> -Wconversion hits extremely often, it is definitely not a warning that can or
> should be enabled in -Wall, nor in -W.
>
The fact that "it hits often" should not be an argument against including
--- Comment #6 from dodji at gcc dot gnu dot org 2009-07-14 15:19 ---
Fixed in gcc 4.5
--
dodji at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASS
--- Comment #4 from dodji at gcc dot gnu dot org 2009-07-14 15:29 ---
Fixed by the patch for PR debug/40705
--
dodji at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from photon at seznam dot cz 2009-07-14 15:31 ---
(In reply to comment #6)
>
> As for Wall, we have users requesting less warnings from Wall and users
> requesting more. We try to find a balance. But you are free to suggest that
> existing warnings be moved to Wall or Wex
Tested with:
trunk r149624
# ./gcc -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --enable-languages=c,c++
--prefix=/mnt/svn/gcc-trunk/build/
Thread model: posix
gcc version 4.5.0 20090714 (experimental) (GCC)
and gentoo's 4.4.0, 4.5_alpha20090709
--- Comment #1 from jamborm at gcc dot gnu dot org 2009-07-14 16:32 ---
OK, I have now added this to my todo list. The simple tweaks would be
simple. On the other hand, if DCE is clever, it still might figure
out a structure is dead at some code paths while I don't even attempt
to
--- Comment #1 from zsojka at seznam dot cz 2009-07-14 16:35 ---
Created an attachment (id=18194)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18194&action=view)
preprocessed source
most of that file is content of included
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4074
--- Comment #9 from pinskia at gcc dot gnu dot org 2009-07-14 16:47 ---
(In reply to comment #8)
> The current -Wall should be
> renamed to something like -W3 to prevent misleading users.
It only misleading users who don't read the documentation. The all part is
described in the docu
--- Comment #7 from janus at gcc dot gnu dot org 2009-07-14 16:53 ---
Here is a much better patch:
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c (revision 149623)
+++ gcc/fortran/resolve.c (working
Tested r149624, 4.4.0 and 4.3.3
# ./gcc -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --enable-languages=c,c++
--prefix=/mnt/svn/gcc-trunk/build/
Thread model: posix
gcc version 4.5.0 20090714 (experimental) (GCC)
4.4.0 and 4.5 have better behaviour in
This code below wont generate a warning for function a(). Compiled with -Wall.
If you remove the const from the return, it will work.
class A {
public:
};
const A a() {
}
int main() {
A b = a();
}
--
Summary: g++ doesnt report missing return if return is of type
--- Comment #2 from sezeroz at gmail dot com 2009-07-14 17:16 ---
Also happens with i686-pc-linux-gnu with gcc-4.4.1 (gcc-4_4-branch, r149543).
--
sezeroz at gmail dot com changed:
What|Removed |Added
---
--- Comment #1 from zsojka at seznam dot cz 2009-07-14 17:11 ---
Created an attachment (id=18195)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18195&action=view)
testcase
Even at -O3, f1() and f2() don't have the same code as f3().
--
http://gcc.gnu.org/bugzilla/show_bug.cgi
--- Comment #3 from jakub at gcc dot gnu dot org 2009-07-14 17:25 ---
Confirmed, introduced between r134374 + r134467, looking into it.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #5 from ro at techfak dot uni-bielefeld dot de 2009-07-14
17:26 ---
Subject: Re: lto-plugin is built unconditionally
> --- Comment #4 from bje at gcc dot gnu dot org 2009-07-14 04:39 ---
> Can this PR be closed now, Rainer?
Yes, this works now.
Rainer
--- Comment #4 from jakub at gcc dot gnu dot org 2009-07-14 18:00 ---
Indeed, caused by http://gcc.gnu.org/ml/gcc-patches/2008-04/msg01303.html
(r134384).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40747
--- Comment #10 from photon at seznam dot cz 2009-07-14 18:11 ---
(In reply to comment #9)
>
> So your definition of -Wall is not very useful at all and will be even more
> misleading to users or why the warnings are happening.
>
MSC's /Wall enables all warnings and I don't find it mi
GCC mis-compiles the following code for mysterious reasons. While it should
output "called", it outputs nothing at all
// snip
typedef void Fn() const;
struct Foo { Fn fn; };
void Foo::fn() const { std::cout << "called" << std::endl; }
int main() { Foo f; f.fn(); }
// snap
Any one of the fol
--- Comment #1 from jason at gcc dot gnu dot org 2009-07-14 18:15 ---
Subject: Bug 40740
Author: jason
Date: Tue Jul 14 18:15:35 2009
New Revision: 149636
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149636
Log:
PR c++/40740
* semantics.c (perform_koenig_lookup
--- Comment #12 from jason at gcc dot gnu dot org 2009-07-14 18:16 ---
Subject: Bug 37276
Author: jason
Date: Tue Jul 14 18:16:03 2009
New Revision: 149638
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149638
Log:
PR c++/37276
* decl.c (decls_match): A non-exter
--- Comment #2 from jason at gcc dot gnu dot org 2009-07-14 18:35 ---
Subject: Bug 40740
Author: jason
Date: Tue Jul 14 18:35:13 2009
New Revision: 149640
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149640
Log:
PR c++/40740
* semantics.c (perform_koenig_lookup
--- Comment #3 from jason at gcc dot gnu dot org 2009-07-14 18:41 ---
Fixed for 4.4.1.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNC
--- Comment #1 from jason at gcc dot gnu dot org 2009-07-14 18:43 ---
Fixed for 4.5.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIG
--- Comment #13 from jason at gcc dot gnu dot org 2009-07-14 18:44 ---
Fixed for 4.5.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #3 from jason at gcc dot gnu dot org 2009-07-14 18:50 ---
Yeah, that's a known issue; it's XFAILed in one of the auto tests.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
--
The following enumerated type definitions packs to one byte as expected in C,
but not in C++:
typedef enum __attribute__ ((packed)) {
ZERO = 0,
ONE,
TWO
} my_enum_t;
The enum will pack as expected if using -fshort-enums, but that doesn't allow
me to pack on a per-enum basi
--- Comment #1 from bryce dot schober at gmail dot com 2009-07-14 19:09
---
Created an attachment (id=18196)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18196&action=view)
test case
Built without warnings, to try to make sure I'm not doing something marginal:
gcc -Wall -Wextra
-Wconversion generates false warnings for the following clean code:
{
char c = 1;
char c2 = 2;
// warning: conversion to char from int may alter its value
c >>= 1;
c += (char) 1;
c += c2;
c = ~c2;
}
--
Summary: -Wconversion
--- Comment #6 from tkoenig at gcc dot gnu dot org 2009-07-14 19:18 ---
See also PR 30694.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40643
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-07-14 19:21 ---
Theses are not false warnings:
c >>= 1;
is really c = (int)c >> 1;
c += (char) 1;
c = (int)c + (int)(char)1;
c += c2;
c = (int)c + (int) c2;
c = ~c2;
c = ~(int)c2;
Only the l
--- Comment #7 from phorgan1 at gmail dot com 2009-07-14 19:37 ---
Verified that original test case now compiles with -g flag--Thanks!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40705
Compiling libffi/src/powerpc/ffi.c as part of a bootstrap for powerpc*-*-linux*
fails starting with this patch:
http://gcc.gnu.org/viewcvs?view=rev&rev=149624
r149624 | rguenth | 2009-07-14 09:59:18 + (Tue, 14 Jul 2009)
This minimized testcase demonstrates the problem:
-
--- Comment #15 from mikpe at it dot uu dot se 2009-07-14 19:51 ---
(In reply to comment #14)
> Bah. So this then becomes "it would be interesting to know what fixed this on
> the gimple-tuples-branch" ...
Revision 134191 fixed this on gimple-tuples-branch.
--
http://gcc.gnu.org/b
--- Comment #1 from bonzini at gnu dot org 2009-07-14 20:35 ---
This fails for me with r149508 with a reload failure.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39716
--- Comment #1 from bonzini at gnu dot org 2009-07-14 20:36 ---
I meant that on most targets this testcase was improved by cond-optab, but not
on m68hc11.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39719
Running the testsuite on sparc-sun-solaris2.11 with the lto branch as of
20090709
reveals many testsuite errors like this:
Executing on host:
/vol/gccsrc/obj/gcc-lto-20090709/11-gcc/gcc/testsuite/g++/../../g++
-B/vol/gccsrc/obj/gcc-lto-20090709/11-gcc/gcc/testsuite/g++/../../
cp_lto_20080709_0.o
--- Comment #2 from manu at gcc dot gnu dot org 2009-07-14 20:55 ---
Andrew, what you say is true, but in this case the warning is not very useful.
I'd prefer to warn only when the operator is larger than the target of the
assignment. I would like to hear other opinions.
--
manu at g
--- Comment #3 from manu at gcc dot gnu dot org 2009-07-14 20:56 ---
Joseph, could you comment on this?
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #22 from pthaugen at gcc dot gnu dot org 2009-07-14 21:15
---
The original problem, multi-block loop preventing movement of loads, was
reintroduced with revision 149206, Jan's CD-DCE patch to remove empty loops.
--
pthaugen at gcc dot gnu dot org changed:
Wha
--- Comment #2 from bonzini at gnu dot org 2009-07-14 21:17 ---
(This is gcc.c-torture/compile/20071128-1.c).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39722
--- Comment #1 from bonzini at gnu dot org 2009-07-14 21:25 ---
(This is peak-gcc-src/gcc/testsuite/gcc.c-torture/compile/pr38564.c).
I cannot reproduce this anymore.
--
bonzini at gnu dot org changed:
What|Removed |Added
-
--- Comment #2 from rguenther at suse dot de 2009-07-14 21:28 ---
Subject: Re: SRA scalarizes dead objects,
single-use objects
On Tue, 14 Jul 2009, jamborm at gcc dot gnu dot org wrote:
> --- Comment #1 from jamborm at gcc dot gnu dot org 2009-07-14 16:32
> ---
> OK, I have
--- Comment #1 from bonzini at gnu dot org 2009-07-14 21:32 ---
Cannot reproduce this anymore.
--
bonzini at gnu dot org changed:
What|Removed |Added
Status|U
--- Comment #1 from bonzini at gnu dot org 2009-07-14 21:34 ---
I cannot reproduce this anymore.
--
bonzini at gnu dot org changed:
What|Removed |Added
Status
--- Comment #4 from dnovillo at gcc dot gnu dot org 2009-07-14 21:41
---
This is likely fixed by
http://gcc.gnu.org/ml/gcc-patches/2009-07/msg00819.html,
could you try again?
--
dnovillo at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-07-14 21:46 ---
Obviously mine.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-07-14 21:58 ---
Huh, we end up with a FUNCTION_DECL here, from
(gdb) call debug_rtx (mem)
(mem/c/i:SI (const:SI (plus:SI (symbol_ref:SI ("ffi_closure_LINUX64") [flags
0x41] )
(const_int 12 [0xc]))) [0 ffi_closure_LINUX6
--- Comment #4 from ian at airs dot com 2009-07-14 22:23 ---
Manu, I agree that these warnings are in some sense technically correct but
they are not useful. They can't point to any actual bug. I guess would be
that if every input to the expression has the size of the target of the
exp
1 - 100 of 136 matches
Mail list logo
