Hi,
I'm now working on Graphite branch and need to know
the alias set information for each data_reference_p, which
would be an integer (or alias_set_type) stands for which
alias set it is in.
I tried to get the alias set information with get_alias_set (tree)
(I've no idea how this function
Hi,
Here's some code that produced a surprising result with GCC 4.3.3 on linux 64.
I'd have expected all addresses output to be the same.
I guess the reason for this is that when merging the templates instantiated in
one.cpp and two.cpp, the linker doesn't perform a complete merge, but only
On Tue, Jul 14, 2009 at 8:01 AM, Li Fengnemoking...@gmail.com wrote:
Hi,
I'm now working on Graphite branch and need to know
the alias set information for each data_reference_p, which
would be an integer (or alias_set_type) stands for which
alias set it is in.
I tried to get the alias set
Hi Richard,
On Tue, Jul 14, 2009 at 4:54 PM, Richard
Guentherrichard.guent...@gmail.com wrote:
On Tue, Jul 14, 2009 at 8:01 AM, Li Fengnemoking...@gmail.com wrote:
Hi,
I'm now working on Graphite branch and need to know
the alias set information for each data_reference_p, which
would be an
On Tue, Jul 14, 2009 at 11:12 AM, Li Fengnemoking...@gmail.com wrote:
Hi Richard,
On Tue, Jul 14, 2009 at 4:54 PM, Richard
Guentherrichard.guent...@gmail.com wrote:
On Tue, Jul 14, 2009 at 8:01 AM, Li Fengnemoking...@gmail.com wrote:
Hi,
I'm now working on Graphite branch and need to know
Why does find_basic_block ignore NOTE_INSN_BASIC_BLOCK notes?
The same question arises to me.
That's explained in the head comment of find_basic_block: the CFG is destroyed
by the DBR pass in some controlled way so the strategy is to recompute the
liveness info starting from data that are
Eric Botcazou ebotca...@adacore.com wrote:
Patch attached. I'll give it a whirl on SPARC but not immediately so, Kaz,
if
you can test it on SH in the meantime, you can apply it on all branches.
2009-07-14 Eric Botcazou ebotca...@adacore.com
PR rtl-optimization/40710
*
Stefan Lampe stefanla...@hotmail.com writes:
Here's some code that produced a surprising result with GCC 4.3.3 on
linux 64. I'd have expected all addresses output to be the same.
This message should have gone to gcc-h...@gcc.gnu.org rather than
g...@gcc.gnu.org. Please take any followups to
Hi Richi,
On Tue, Jul 14, 2009 at 04:40, Richard
Guentherrichard.guent...@gmail.com wrote:
You misunderstood what alias-set numbers represent. Alias-set
numbers encode type-based alias information only - which in
your case cannot disambiguate a or Q.
I also have misunderstood this.
For
On Tue, Jul 14, 2009 at 5:14 PM, Sebastian Popseb...@gmail.com wrote:
Hi Richi,
On Tue, Jul 14, 2009 at 04:40, Richard
Guentherrichard.guent...@gmail.com wrote:
You misunderstood what alias-set numbers represent. Alias-set
numbers encode type-based alias information only - which in
your
On Tue, Jul 14, 2009 at 11:03, Sebastian Popseb...@gmail.com wrote:
Why do you need alias-set numbers?
We want to represent the alias set information as an extra subscript
on memory accesses: for example,
if we have A[10] and supposing that A is in alias set 6, this would be
represented as
On Tue, 2009-07-14 at 17:16 +0200, Jason Merrill wrote:
On 07/09/2009 12:32 AM, Janis Johnson wrote:
Given that libstdc++ is used with compilers other than G++, is it
allowable to depend on non-standard C++ compiler support?
Seems reasonable to me, but we may want to standardize the
On 07/14/2009 07:35 PM, Janis Johnson wrote:
What's the forum for discussions about the C++ ABI?
cxx-abi-...@codesourcery.com
Jason
Hey Ralf! Saw your message about updating gcc/src to current auto
tools, in favor. But, it looks like the autoconf 2.64 release is not
out, last I see is 2.63b at the end of March. This and
confirmation of --with-build-sysroot working seem to be the only open
issues standing in the way of the
On Wed, 8 Jul 2009, Diego Novillo wrote:
http://gcc.gnu.org/gcc-4.5/criteria.html
Thanks. I've filtered the non-ELF platforms from both lists to get this:
You should test LTO-enabled cross tools from a non-ELF primary or
secondary host to an ELF primary or secondary target, as well as
Jean Christophe Beyler jean.christophe.bey...@gmail.com writes:
In file included from ./tm_p.h:5,
from /home/toto/gcc-4.3.2/gcc/c-pragma.c:35:
./tm-preds.h:40:1: warning: CONSTRAINT_LEN redefined
In file included from ./tm.h:6,
from
Dear all,
As some might know, I've been concentrating on optimizing the handling
of loads for my port of GCC. I'm now considering this code:
uint64_t data[107];
uint64_t foo (void)
{
uint64_t x0, x1, x2, x3, x4, x5,x6,x7;
uint64_t i;
for(i=0;i107;i++) {
data[i] = i;
}
I think the ARM specification is pretty sensible, and would make a
good cross-platform approach.
Could you distill it for us?
The relevant bits are from AAPCS \S 7.1.7.5, and quoted below.
I finally got the last of the feedback I needed from our customers,
and they agree that the
Ok, so actually, my cpu.h file had some of those included. I've
removed them and am now filling in the constraints.md file with what
is needed. I also so that they were obsolete in the GCC internals,
I'll be moving everything to the constraints then.
Thank you for your help,
Jc
On Tue, Jul 14,
On Tue, Jul 14, 2009 at 6:08 PM, Sebastian Popseb...@gmail.com wrote:
On Tue, Jul 14, 2009 at 11:03, Sebastian Popseb...@gmail.com wrote:
Why do you need alias-set numbers?
We want to represent the alias set information as an extra subscript
on memory accesses: for example,
if we have A[10]
Snapshot gcc-4.4-20090714 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20090714/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.4 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
DJ Delorie wrote:
I think the ARM specification is pretty sensible, and would make a
good cross-platform approach.
I finally got the last of the feedback I needed from our customers,
and they agree that the AAPCS functionality is suitable for their
ports as well.
Great!
What's the next
At the risk of being naive: implement it. I'm not quite sure what
you're looking for here?
I'd rather have some confidence that the way I choose to implement it
would be acceptable to those who would be reviewing it ;-)
I'll give it a shot at the same point in the code where we call the
As you can see, the compiler uses r9 to store data and then uses that
for data[0] but also loads in r7 data+8 instead of directly using r9.
If I remove the loop then it does not do this.
This optimization is done by CSE only, currently. That's why it cannot
look through loops.
Paolo
On 07/14/2009 10:31 PM, Jean Christophe Beyler wrote:
Ok, so actually, my cpu.h file had some of those included. I've
removed them and am now filling in the constraints.md file with what
is needed. I also so that they were obsolete in the GCC internals,
I'll be moving everything to the
--- Comment #9 from xenofears at gmail dot com 2009-07-14 06:35 ---
I was about to post this:
--enable-version-specific-runtime-libs is pretty broken:
in the sysroot/lib/gcc/x86_64-w64-mingw32 dir, there exists a lib32 and lib64
dir alongside the version (i.e. 4.4.1) dir. Neither are
--- 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):
From https://bugzilla.redhat.com/show_bug.cgi?id=511168:
templateclass T
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 issued
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=18191action=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()
{
--- 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
--- 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
--- 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
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- 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=gccview=revrev=149620
Log:
2009-07-14 Richard Guenther rguent...@suse.de
--- 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=gccview=revrev=149620
Log:
2009-07-14 Richard Guenther rguent...@suse.de
--- 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=gccview=revrev=149620
Log:
2009-07-14 Richard Guenther rguent...@suse.de
--- 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
--- 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
--- 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=gccview=revrev=149586
2009-07-13 Janus Weil ja...@gcc.gnu.org
PR fortran/40646
--
--- 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:
--- 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
--- 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;
bb 2:
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
--- 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
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |major
Component|target
--- 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
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)
--- 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=18192action=view)
gcc45-pr40643.patch
Slightly adjusted patch, so that even when array size isn't known compile time
constant it can
--- 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=18193action=view)
gcc45-pr40643.patch
And now a patch which uses two loops instead of one if needed for performance
(in the honor
--- 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
--- 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)
+++
--- 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... ;)
--
--- 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=gccview=revrev=149627
Log:
2009-07-14 Richard Guenther rguent...@suse.de
PR
--- 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
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
--- 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=gccview=revrev=149628
Log:
2009-07-14 Dodji Seketeli do...@redhat.com
gcc/ChangeLog:
--- 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 it
--- 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
--- 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
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=18194action=view)
preprocessed source
most of that file is content of included stdio.h
--
--- 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
--- 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
This code below wont generate a warning for function a(). Compiled with -Wall.
If you remove the const from the return, it will work.
code
class A {
public:
};
const A a() {
}
int main() {
A b = a();
}
/code
--
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=18195action=view)
testcase
Even at -O3, f1() and f2() don't have the same code as f3().
--
--- 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
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 following
--- 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=gccview=revrev=149636
Log:
PR c++/40740
* semantics.c
--- 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=gccview=revrev=149638
Log:
PR c++/37276
* decl.c (decls_match): A
--- 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=gccview=revrev=149640
Log:
PR c++/40740
* semantics.c
--- 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
--- 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
1 - 100 of 151 matches
Mail list logo
