James Dennett wrote:
On Thu, Mar 12, 2009 at 4:56 PM, Robert Dewar de...@adacore.com wrote:
Nathan Ridge wrote:
Why does gcc not give an error about this?
If I compile with -Wall, it will give a WARNING saying
control reaches end of non-void function.
However, shouldn't it be an ERROR to
On Thu, Mar 12, 2009 at 11:29 PM, Dave Korn
dave.korn.cyg...@googlemail.com wrote:
James Dennett wrote:
On Thu, Mar 12, 2009 at 4:56 PM, Robert Dewar de...@adacore.com wrote:
Nathan Ridge wrote:
Why does gcc not give an error about this?
If I compile with -Wall, it will give a WARNING saying
Revital1 Eres/Haifa/IBM wrote on 13/03/2009 07:50:08:
Hello,
Using testsuite/gcc.dg/sms-6.c as an example and compiling it for
PowerPC,
node 18 (see attachment) is in a SCC and cannot be scheduled until
spliting
twice. The MII = 20 and the schedule can only be found at II = 24.
On Thu, Mar 12, 2009 at 5:50 PM, Diego Novillo dnovi...@google.com wrote:
On Thu, Mar 12, 2009 at 12:46, Steven Bosscher stevenb@gmail.com wrote:
On Thu, Mar 12, 2009 at 5:36 PM, Diego Novillo dnovi...@google.com wrote:
The temptation is to use C++'s limits, but I'm concerned that may
James Dennett james.denn...@gmail.com writes:
This appears to be a difference between C and C++. Unfortunate.
6.6.3 [stmt.return]/2 of N2800 says Flowing off the end of a function
is equivalent to a return with no value; this results in undefined
behavior in a value-returning function.
Hello I posted to binutils list as I guess it is an ld problem, but
maybe some gcc people might be interested as well.
-- Forwarded message --
From: Hector Oron hector.o...@gmail.com
Date: 2009/3/13
Subject: Re: ld fails to look under /usr/$arch-linux-gnu/lib64
To:
These are all the !SHIFT_COUNT_TRUNCATED targets.
For 4.5 I would like to improve our RTL canonicalization so that no
out-of-range shifts are ever in the RTL representation.
This in turn means that the description given by SHIFT_COUNT_TRUNCATED
must be exact. Right now !SHIFT_COUNT_TRUNCATED
Hello,
I have been discussing lately with other people about implementing a
proof of concept for multiarch[1] (my objectives are to improve cross
building), as I understand you already have a nice approach to cross
building with-sysroot option, but I would like to know how much it
this
Andreas Schwab wrote:
James Dennett james.denn...@gmail.com writes:
This appears to be a difference between C and C++. Unfortunate.
6.6.3 [stmt.return]/2 of N2800 says Flowing off the end of a function
is equivalent to a return with no value; this results in undefined
behavior in a
Paolo Bonzini bonz...@gnu.org wrote:
I would like to know whether for avr,bfin,cris,frv,h8300,pdp11,rs6000
(which define SHIFT_COUNT_TRUNCATED as 0) and for mcore,sh,vax (which
do not define it at all) it is right that shift counts are never
truncated.
sh defines SHIFT_COUNT_TRUNCATED
Paolo Bonzini bonz...@gnu.org writes:
This in turn means that the description given by SHIFT_COUNT_TRUNCATED
must be exact. Right now !SHIFT_COUNT_TRUNCATED means I don't know,
I want it to mean it is never truncated.
You need to do more work to make that happen, as SHIFT_COUNT_TRUNCATED
Paolo Bonzini wrote:
These are all the !SHIFT_COUNT_TRUNCATED targets.
For 4.5 I would like to improve our RTL canonicalization so that no
out-of-range shifts are ever in the RTL representation.
This in turn means that the description given by SHIFT_COUNT_TRUNCATED
must be exact. Right
Ian Lance Taylor wrote:
Paolo Bonzini bonz...@gnu.org writes:
This in turn means that the description given by SHIFT_COUNT_TRUNCATED
must be exact. Right now !SHIFT_COUNT_TRUNCATED means I don't know,
I want it to mean it is never truncated.
You need to do more work to make that happen,
The Blackfin does not truncate shift counts. The documentation
specifies that e.g. for Dx = Dy instructions, shift counts greater
than 31 produce a result of zero. Other shift instructions use a sign
extended part of the shift count to shift either left or right. I
don't know is probably
On Fri, 2009-03-13 at 12:34 +0100, Paolo Bonzini wrote:
These are all the !SHIFT_COUNT_TRUNCATED targets.
For 4.5 I would like to improve our RTL canonicalization so that no
out-of-range shifts are ever in the RTL representation.
This in turn means that the description given by
/* Immediate shift counts are truncated by the output routines (or was it
the assembler?). Shift counts in a register are truncated by SH. Note
that the native compiler puts too large ( 32) immediate shift counts
into a register and shifts by the register, letting the SH decide what
On Fri, Mar 13, 2009 at 2:14 PM, Bernd Schmidt bernds_...@t-online.de wrote:
Paolo Bonzini wrote:
These are all the !SHIFT_COUNT_TRUNCATED targets.
For 4.5 I would like to improve our RTL canonicalization so that no
out-of-range shifts are ever in the RTL representation.
This in turn means
Hm. In fold-const.c we try to make sure to produce the same result
as the target would for constant-folding shifts. Thus, Paolo, I think
what fold-const.c does is what we should assume for
!SHIFT_COUNT_TRUNCATED. No?
Unfortunately it is not so simple. fold-const.c is actually wrong, as
On Fri, Mar 13, 2009 at 4:07 PM, Paolo Bonzini bonz...@gnu.org wrote:
Hm. In fold-const.c we try to make sure to produce the same result
as the target would for constant-folding shifts. Thus, Paolo, I think
what fold-const.c does is what we should assume for
!SHIFT_COUNT_TRUNCATED. No?
Paolo Bonzini bonz...@gnu.org wrote:
So you have that in the RTL stream we should canonicalize a 32 to
a, but a (b 31) is not the same as a b?
Yes when the msb of b is set.
Also, how is the sign bit is significant? Does it determine whether the
value is left- or right-shifted?
Yep.
On Thu, 12 Mar 2009, H.J. Lu wrote:
Executing on host:
/sw/src/fink.build/gcc44-4.3.999-20090312/darwin_objdir/gcc/xgcc
-B/sw/src/fink.build/gcc44-4.3.999-20090312/darwin_objdir/gcc/
/sw/src/fink.build/gcc44-4.3.999-20090312/gcc-4.4
-20090312/gcc/testsuite/gcc.dg/asm-b.c -O1 -lm
On Fri, Mar 13, 2009 at 12:34:49PM +0100, Paolo Bonzini wrote:
These are all the !SHIFT_COUNT_TRUNCATED targets.
For 4.5 I would like to improve our RTL canonicalization so that no
out-of-range shifts are ever in the RTL representation.
This in turn means that the description given by
Status
==
The trunk is still in stage 4 which means it is open under the usual
release branch rules. Thus the trunk is open for regression and
documentation fixes only.
We have been asked by the SC to not branch for now but wait for
the wording for the new runtime license to arrive from
Richard Guenther rguent...@suse.de writes:
We have been asked by the SC to not branch for now but wait for
the wording for the new runtime license to arrive from the FSF and
that being put in place.
We've been waiting a long time. At what point do we give up and
branch anyway?
On Fri, Mar 13, 2009 at 5:04 PM, Richard Guenther rguent...@suse.de wrote:
We have been asked by the SC to not branch for now but wait for
the wording for the new runtime license to arrive from the FSF and
that being put in place.
This is the saddest thing that I have seen in GCC politics so
Hello,
I came across an issue regarding BLKmode and returning structure in register.
For following code, I try to return the structure in register instead of
memory.
extern void abort();
typedef struct {
short x;
short y;
} COMPLEX;
COMPLEX foo (void) __attribute__ ((noinline));
2009/3/13 Steven Bosscher stevenb@gmail.com:
On Fri, Mar 13, 2009 at 5:04 PM, Richard Guenther rguent...@suse.de wrote:
We have been asked by the SC to not branch for now but wait for
the wording for the new runtime license to arrive from the FSF and
that being put in place.
This is the
Hm. In fold-const.c we try to make sure to produce the same result
as the target would for constant-folding shifts. Thus, Paolo, I think
what fold-const.c does is what we should assume for
!SHIFT_COUNT_TRUNCATED. No?
Unfortunately it is not so simple. fold-const.c is actually wrong, as
On Mar 13, 2009, at 10:06 AM, Paolo Bonzini wrote:
Hm. In fold-const.c we try to make sure to produce the same result
as the target would for constant-folding shifts. Thus, Paolo, I
think
what fold-const.c does is what we should assume for
!SHIFT_COUNT_TRUNCATED. No?
Unfortunately it
On Fri, Mar 13, 2009 at 5:42 PM, Manuel López-Ibáñez
lopeziba...@gmail.com wrote:
2009/3/13 Steven Bosscher stevenb@gmail.com:
On Fri, Mar 13, 2009 at 5:04 PM, Richard Guenther rguent...@suse.de wrote:
We have been asked by the SC to not branch for now but wait for
the wording for the new
[resend to list only owing to running up against the spamfilter]
Manuel López-Ibáñez wrote:
2009/3/13 Steven Bosscher stevenb@gmail.com:
On Fri, Mar 13, 2009 at 5:04 PM, Richard Guenther rguent...@suse.de wrote:
We have been asked by the SC to not branch for now but wait for
the wording
On Fri, 13 Mar 2009, Dave Korn wrote:
On Fri, Mar 13, 2009 at 5:04 PM, Richard Guenther rguent...@suse.de
wrote:
We have been asked by the SC to not branch for now but wait for
[...]
Can anyone clarify if the SC *really* need us to not branch before the
license change, as opposed to
On Fri, 2009-03-13 at 17:04 +0100, Richard Guenther wrote:
Status
==
The trunk is still in stage 4 which means it is open under the usual
release branch rules. Thus the trunk is open for regression and
documentation fixes only.
What do you think about possibly-disruptive testsuite
On Fri, 13 Mar 2009, Janis Johnson wrote:
On Fri, 2009-03-13 at 17:04 +0100, Richard Guenther wrote:
Status
==
The trunk is still in stage 4 which means it is open under the usual
release branch rules. Thus the trunk is open for regression and
documentation fixes only.
What
I found that compiling for mips with -mabi=n32 produces such inefficient code.
When -mabi=n32, mips_return_in_memory returns 0 if size is small regardless
BLKmode or not.
.type foo, @function
foo:
.frame $sp,16,$31 # vars= 16, regs= 0/0, args= 0, gp= 0
On Fri, Mar 13, 2009 at 06:25:34PM +0100, Richard Guenther wrote:
On Fri, 13 Mar 2009, Dave Korn wrote:
On Fri, Mar 13, 2009 at 5:04 PM, Richard Guenther rguent...@suse.de
wrote:
We have been asked by the SC to not branch for now but wait for
[...]
Can anyone clarify if the
Richard Guenther wrote:
On Fri, 13 Mar 2009, Dave Korn wrote:
On Fri, Mar 13, 2009 at 5:04 PM, Richard Guenther rguent...@suse.de
wrote:
We have been asked by the SC to not branch for now but wait for
[...]
Can anyone clarify if the SC *really* need us to not branch before the
Steven Bosscher wrote:
Or ship as-is and fix the license for GCC 4.5. I haven't followed the
legal discussion -- so maybe I'm being naive or I've missed it -- but
I haven't seen anyone explaining why this is not an option.
I can see why that won't work. If there's a problem with the
On Fri, Mar 13, 2009 at 6:47 PM, Dave Korn
dave.korn.cyg...@googlemail.com wrote:
Steven Bosscher wrote:
Or ship as-is and fix the license for GCC 4.5. I haven't followed the
legal discussion -- so maybe I'm being naive or I've missed it -- but
I haven't seen anyone explaining why this is
Paolo == Paolo Bonzini bonz...@gnu.org writes:
Paolo These are all the !SHIFT_COUNT_TRUNCATED targets. For 4.5 I
Paolo would like to improve our RTL canonicalization so that no
Paolo out-of-range shifts are ever in the RTL representation.
Paolo This in turn means that the description given
Note, one thing I encountered when doing the SSE5 work at AMD, is
SHIFT_COUNT_TRUNCATED really needs a mode argument (and ideally should be
moved
into the gcc_target structure).
In fact I'm reusing the TARGET_SHIFT_TRUNCATION_MASK element that is
already there and accepts a mode.
Paolo
On Fri, 13 Mar 2009, Steven Bosscher wrote:
Or what about branching now and starting the gcc 4.5 development
cycle? The argument against this, that the same changes will have to
There might also be the temptation to create a trunk-substitute branch to
receive Stage 1 developments and branch
On Fri, Mar 13, 2009 at 09:30:19AM -0700, Steven Bosscher wrote:
On Fri, Mar 13, 2009 at 5:04 PM, Richard Guenther rguent...@suse.de wrote:
We have been asked by the SC to not branch for now but wait for
the wording for the new runtime license to arrive from the FSF and
that being put in
On Fri, 13 Mar 2009, Richard Guenther wrote:
Hm. In fold-const.c we try to make sure to produce the same result
as the target would for constant-folding shifts. Thus, Paolo, I think
what fold-const.c does is what we should assume for
!SHIFT_COUNT_TRUNCATED. No?
I think attempting the same
On Fri, Mar 13, 2009 at 7:07 PM, Joseph S. Myers
jos...@codesourcery.com wrote:
On Fri, 13 Mar 2009, Richard Guenther wrote:
Hm. In fold-const.c we try to make sure to produce the same result
as the target would for constant-folding shifts. Thus, Paolo, I think
what fold-const.c does is
Paolo Bonzini bonz...@gnu.org writes:
In addition, for arm and m68k I'd like to know whether bitfield
instructions truncate the bit position the same as shifts (8 bits for
arm, 6 bits for m68k).
For the m68k bitfield insns (when operating on memory) the bit position
can be in the full range
On Fri, Mar 13, 2009 at 7:03 PM, Joe Buck joe.b...@synopsys.com wrote:
On Fri, Mar 13, 2009 at 09:30:19AM -0700, Steven Bosscher wrote:
On Fri, Mar 13, 2009 at 5:04 PM, Richard Guenther rguent...@suse.de wrote:
We have been asked by the SC to not branch for now but wait for
the wording for
On Fri, Mar 13, 2009 at 10:25:34AM -0700, Richard Guenther wrote:
The topmost sentence should be unambiguous. Yes, the SC asked us not
to branch.
The request came from RMS, the SC just passed it on.
On Fri, 13 Mar 2009, Richard Guenther wrote:
Last time I sent a patch to remove the SHIFT_COUNT_TRUNCATED check
from fold-const.c the reason that this was rejected was that we want to
be consistend with target behavior...
I would disagree with such a rejection. If we want to provide any sort
Date: Fri, 13 Mar 2009 12:34:49 +0100
From: Paolo Bonzini bonz...@gnu.org
I would like to know whether for avr,bfin,cris,frv,h8300,pdp11,rs6000
(which define SHIFT_COUNT_TRUNCATED as 0) and for mcore,sh,vax (which
do not define it at all) it is right that shift counts are never
truncated.
On Fri, Mar 13, 2009 at 6:06 PM, Paolo Bonzini bonz...@gnu.org wrote:
So, I'd still need the information for arm and m68k, because that
information is about the bitfield instructions.
For ARM, shifts by immediate use a 5-bit constant, shifts by register
use the lower 8 bits of the register.
This is similar to the discussion that happened some time ago about
extending return values. The decisions for that was that the callee
could just leave the higher bits undefined and the caller would
extent the result if it needed to.
We have a similar issue with function arguments. We compile
Steven Bosscher wrote:
On Fri, Mar 13, 2009 at 5:04 PM, Richard Guenther rguent...@suse.de wrote:
We have been asked by the SC to not branch for now but wait for
the wording for the new runtime license to arrive from the FSF and
that being put in place.
This is the saddest thing that I have
Hi,
I'm new to GCC project so let me know if this is the wrong place where I can
ask such a question.
I've found a bug in Gcc 4.3.3 (on machine Linux ubuntu 2.6.28-9-generic
#31-Ubuntu SMP Wed Mar 11 15:43:49 UTC 2009 x86_64 GNU/Linux) which I can
reliably reproduce (just running make) and
Francesco Montorsi f18m_cpp217...@yahoo.it writes:
I'm new to GCC project so let me know if this is the wrong place
where I can ask such a question.
The mailing list gcc-h...@gcc.gnu.org would be a better place.
I've found a bug in Gcc 4.3.3 (on machine Linux ubuntu
2.6.28-9-generic
I set up your patch and I get an internal error on this test program:
extern void foo(int, int);
extern int bar(void);
int startup;
void foobar()
{
int i;
while(1)
{
if (bar()) {
foo(0,0);
}
}
}
Here's the error:
Snapshot gcc-4.4-20090313 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20090313/
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/trunk
The following code cannot be compiled by GCC 4.3.3.
#include iostream
#include algorithm
#include functional
using namespace std;
int main()
{
class PrintOne : unary_functionint, void
{
public:
result_type operator()(argument_type i)
{
wcout i
--- Comment #12 from bonzini at gnu dot org 2009-03-13 07:28 ---
I think you need a matching memory constraint instead of just m or the bug
might resurface.
(define_memory_constraint H
@internal
(match_test cmpxchg8b_memory_operand (op, GET_MODE (op)))
--
--- Comment #13 from bonzini at gnu dot org 2009-03-13 07:32 ---
Nevermind.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39431
--- Comment #3 from gcc at cohi dot at 2009-03-13 07:33 ---
The bug is in both 4.3.3 and 4.3.2, however it isn't in 4.3.0 on a
sparcv9-sun-solaris2.10 box with 64bits. Haven't got any 4.3.1 to try.
If 4.4.0 is out before 4.3.4 (if there is such a thing), it might not really
not be
--- Comment #9 from rearnsha at gcc dot gnu dot org 2009-03-13 09:38
---
Now believed fixed.
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from rearnsha at gcc dot gnu dot org 2009-03-13 09:39
---
Fixed.
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #4 from paolo dot carlini at oracle dot com 2009-03-13 09:43
---
(In reply to comment #3)
The bug is in both 4.3.3 and 4.3.2, however it isn't in 4.3.0 on a
sparcv9-sun-solaris2.10 box with 64bits. Haven't got any 4.3.1 to try.
Ok. I went through the change which went in
--- Comment #5 from ebotcazou at gcc dot gnu dot org 2009-03-13 09:35
---
Works fine now, thanks for the quick turn around!
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from paolo dot carlini at oracle dot com 2009-03-13 09:54
---
This behaviour is conforming to the letter of the current C++ standard, which
is implemented by GCC. Not a bug.
--
paolo dot carlini at oracle dot com changed:
What|Removed
--- Comment #2 from jim_king_2000 at 163 dot com 2009-03-13 10:45 ---
So, is it possible that the error message could be made more meaningful? I
spent several hours to find out what the no matching function for call to
refers to. Thanks.
--
--- Comment #3 from ramana dot r at gmail dot com 2009-03-13 10:54 ---
(In reply to comment #2)
See Dara's comment.
Occurs even today .
foo:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
--- Comment #3 from jim_king_2000 at 163 dot com 2009-03-13 10:59 ---
And I'm still wondering which line in the C++ spec disallows the usage of local
class within the template function. Would you please figure it out?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39452
--with-cloog=/gcc-4.4/cloog --with-cloog-polylib=/gcc-4.4/polylib
Thread model: posix
gcc version 4.4.0 20090313 (experimental) (GCC)
{~/tmp}$gfortran -c sgbtrf.f -O3 -fselective-scheduling2
-fsel-sched-pipelining -fsel-sched-pipelining-outer-loops
sgbtrf.f: In function 'sgbtrf':
sgbtrf.f:437: internal
--- Comment #1 from linuxl4 at sohu dot com 2009-03-13 11:38 ---
Created an attachment (id=17454)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17454action=view)
the fortran source which is a part of lapack.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39453
--- Comment #4 from paolo dot carlini at oracle dot com 2009-03-13 11:48
---
3.5/8. The next Standard will be different, see:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2657.htm
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39452
Unfortunately only during profiledbootstrap I see a bootstrap failure on
sparcv9-linux, the ICEs look like:
error: unrecognizable insn:
(insn 86 30 87 6 /tmp/ccxt3Axa.out:5527 (set (reg:SI 24 %i0)
(and:SI (reg:SI 24 %i0 [ u ])
(const_int -65281 [0x00ff]))) -1 (nil))
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed|0 |1
Last
--- Comment #5 from d dot frey at gmx dot de 2009-03-13 12:23 ---
(In reply to comment #4)
The bug is in both 4.3.3 and 4.3.2, however it isn't in 4.3.0 on a
sparcv9-sun-solaris2.10 box with 64bits. Haven't got any 4.3.1 to try.
Ok. I went through the change which went in *the
--- Comment #6 from ramana dot r at gmail dot com 2009-03-13 12:28 ---
(In reply to comment #5)
Can an ARM maintainer please check this bug? Comment #4 suggests this bug is
fixed, but it needs re-checking now that IRA has been merged.
This is now fixed on mainline even after IRA .
=/gcc-4.4/cloog
Thread model: posix
gcc version 4.4.0 20090313 (experimental) (GCC)
{~/tmp}$gcc -O2 -fprefetch-loop-arrays -c sort.c
/svn/gcc/libiberty/sort.c: In function 'sort_pointers':
/svn/gcc/libiberty/sort.c:47: internal compiler error: in compare_values_warnv,
at tree-vrp.c:1073
Please
--- Comment #4 from ramana dot r at gmail dot com 2009-03-13 12:33 ---
With Mainline today it looks worse -
stmfd sp!, {r4, lr}
mov r4, r0
bl func
add r0, r4, r0
ldrbr3, [r0, #-4] @ zero_extendqisi2
cmp r3, #97
--- Comment #1 from linuxl4 at sohu dot com 2009-03-13 12:34 ---
Created an attachment (id=17456)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17456action=view)
the source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39455
--- Comment #2 from jakub at gcc dot gnu dot org 2009-03-13 12:38 ---
Created an attachment (id=17457)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17457action=view)
gcc44-pr39454-2.patch
Alternative simpler patch, in rtlanal.c just in case shift counts aren't
canonicalized
--- Comment #5 from jim_king_2000 at 163 dot com 2009-03-13 12:41 ---
Thank you very much.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39452
--- Comment #1 from jakub at gcc dot gnu dot org 2009-03-13 12:23 ---
Created an attachment (id=17455)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17455action=view)
gcc44-pr39454.patch
So far only very lightly tested fix (no bootstrap/regtest yet), actually either
the cse.c or
--- Comment #6 from d dot frey at gmx dot de 2009-03-13 12:49 ---
(In reply to comment #5)
More information on this:
The bug is in both 4.3.3 and 4.3.2, however it isn't in 4.3.0 on a
sparcv9-sun-solaris2.10 box with 64bits. Haven't got any 4.3.1 to try.
I've copied to header
--- Comment #16 from pault at gcc dot gnu dot org 2009-03-13 12:52 ---
Patch pending. See:
http://gcc.gnu.org/ml/fortran/2009-03/msg00050.html
Paul
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38538
--- Comment #7 from paolo dot carlini at oracle dot com 2009-03-13 13:00
---
It is a library change in the sense that it triggers a bug in the c++
front-end. Because of course the library afterwards remained the same and the
problem is not there anymore... We'll see, in case of a 4.3.4
--- Comment #8 from paolo dot carlini at oracle dot com 2009-03-13 13:02
---
Moreover, if we fix this issue at the library level without dealing with
the real C++ front-end issue, we regress on libstdc++/35637, of course.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39405
--- Comment #9 from paolo dot carlini at oracle dot com 2009-03-13 13:13
---
(In reply to comment #7)
It is a library change in the sense that it triggers a bug in the c++
front-end. Because of course the library afterwards remained the same and the
problem is not there anymore...
--- Comment #10 from d dot frey at gmx dot de 2009-03-13 13:14 ---
(In reply to comment #8)
Moreover, if we fix this issue at the library level without dealing with
the real C++ front-end issue, we regress on libstdc++/35637, of course.
OK, I see. So maybe not worth the effort to fix
--- Comment #11 from paolo dot carlini at oracle dot com 2009-03-13 13:22
---
(In reply to comment #10)
OK, I see. So maybe not worth the effort to fix in 4.3.x as long as 4.4.0 is
fine. To make sure, could you (Paolo) please add a testcase for this to the
testsuite for 4.4.0/trunk
--- Comment #6 from hjl at gcc dot gnu dot org 2009-03-13 13:24 ---
Subject: Bug 39451
Author: hjl
Date: Fri Mar 13 13:24:14 2009
New Revision: 144834
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=144834
Log:
2009-03-13 H.J. Lu hongjiu...@intel.com
PR testsuite/39451
--- Comment #7 from hjl at gcc dot gnu dot org 2009-03-13 13:26 ---
Subject: Bug 39451
Author: hjl
Date: Fri Mar 13 13:25:50 2009
New Revision: 144835
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=144835
Log:
2009-03-13 H.J. Lu hongjiu...@intel.com
Backport from
--- Comment #8 from hjl dot tools at gmail dot com 2009-03-13 13:28 ---
Fixed.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Just that I need to set each functions in a C file into different sections,
with section names I can link in different segments.
That can be done with:
__attribute__ ((section (sect1_fct1))) void fct1 (void) {}
__attribute__ ((section (sect1_fct2))) void fct2 (void) {}
But cannot unfortunately
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-03-13 14:03 ---
Confirmed. Works with 4.1 and 4.2.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-03-13 14:08 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from pault at gcc dot gnu dot org 2009-03-13 14:19 ---
(In reply to comment #5)
I think that the starting point should be a still further reduced testcase;
remove the function matmul_k21, or rename the module function SD to SD0 for
example, and you will get a segfault
--- Comment #7 from pault at gcc dot gnu dot org 2009-03-13 14:22 ---
See previous comment - this should be suspended with PR38471. It puts the
pressure on me to start on the array descriptor work:-(
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed
Attached testcase fails to compile on branches/ibm/power7-meissner.
./xgcc -B ./ -v
Reading specs from ./specs
Target: powerpc64-redhat-linux
Configured with: ../configure --enable-shared --enable-threads=posix
--enable-checking=release --enable-languages=c --disable-bootstrap
--enable-secureplt
--- Comment #1 from jakub at gcc dot gnu dot org 2009-03-13 14:25 ---
Created an attachment (id=17458)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17458action=view)
images_selector.i.bz2
Michael, can you please take a look at this? If there are more similar issues,
I'm afraid
--- Comment #3 from hjl dot tools at gmail dot com 2009-03-13 14:43 ---
(In reply to comment #2)
Confirmed. Works with 4.1 and 4.2.
I got
[...@gnu-16 rrs]$ gcc -O2 -fprefetch-loop-array pr39455.c -S
cc1: error: unrecognized command line option -fprefetch-loop-array
[...@gnu-16
1 - 100 of 144 matches
Mail list logo
