Joe Buck <[EMAIL PROTECTED]> wrote:
> I don't even think this qualifies as a bug. It's basically an
> enhancement request, to have a clean way of supporting glibc in
> an unusual place.
It works in previous versions going back to 2.95.3, so I'd think it
would be a bug, and a regression. But sinc
On Sat, May 12, 2007 at 12:32:25AM -0400, Paul Jarc wrote:
> Sorry to bring this up so late, but I just tried building the last
> 4.2.0 prerelease and hit what seems to be a build bug:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31906
I don't even think this qualifies as a bug. It's basically a
Sorry to bring this up so late, but I just tried building the last
4.2.0 prerelease and hit what seems to be a build bug:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31906
paul
Daniel Berlin wrote:
> On 5/11/07, Mark Mitchell <[EMAIL PROTECTED]> wrote:
>> Every time I think we're almost there with this release, I seem to
>> manage to get stuck. :-( However, we're very close: the only PRs that
>> I'm waiting for are:
>>
>> PR 31797: An infinite loop in the compiler while
On 5/11/07, Mark Mitchell <[EMAIL PROTECTED]> wrote:
Every time I think we're almost there with this release, I seem to
manage to get stuck. :-( However, we're very close: the only PRs that
I'm waiting for are:
PR 31797: An infinite loop in the compiler while building RTEMS.
Daniel, I see you'v
On May 11, 2007, at 5:28 PM, Mark Mitchell wrote:
Bill Wendling wrote:
Andrew Pinski wasn't able to reproduce the link error on Linux,
and I've
only seen it on Darwin. However, as Chris Lattner pointed out, this
indicates a fairly serious problem (which shows up even on the Linux
build) in
On Fri, May 11, 2007 at 05:21:01PM -0700, Bill Wendling wrote:
> On May 11, 2007, at 5:15 PM, Mark Mitchell wrote:
> >Bill Wendling wrote:
> >>This one was just filed against 4.2.0:
> >>
> >> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31903
> >>
> >>It is causing LLVM (at least) to fail to build
Bill Wendling wrote:
> Andrew Pinski wasn't able to reproduce the link error on Linux, and I've
> only seen it on Darwin. However, as Chris Lattner pointed out, this
> indicates a fairly serious problem (which shows up even on the Linux
> build) in that the symbols aren't getting internal linkage
On May 11, 2007, at 5:15 PM, Mark Mitchell wrote:
Bill Wendling wrote:
This one was just filed against 4.2.0:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31903
It is causing LLVM (at least) to fail to build. Do you think it's
worth
adding to the list?
Does it show up anywhere other tha
Bill Wendling wrote:
> This one was just filed against 4.2.0:
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31903
>
> It is causing LLVM (at least) to fail to build. Do you think it's worth
> adding to the list?
Does it show up anywhere other than Darwin? On the basis of Darwin
alone, I
> But for the following example
> int a = 1;
> int b = 2;
> int c = 3;
> c = c + a * b;
> the MAC pattern is not getting recognized, instead it is still using
> PLUS and MULT patterns.
Your example is bogus. This is optimized to "c = 5" well before we get to RTL.
Paul
On May 11, 2007, at 3:02 PM, Mark Mitchell wrote:
Every time I think we're almost there with this release, I seem to
manage to get stuck. :-( However, we're very close: the only PRs that
I'm waiting for are:
PR 30252: Wrong code generation, perhaps due to the C++ front end's
representation for
Snapshot gcc-4.3-20070511 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20070511/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.3 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/trunk
On 5/12/07, Mark Mitchell <[EMAIL PROTECTED]> wrote:
PR 31797: An infinite loop in the compiler while building RTEMS.
1. Can you localize its last output that stops in its internal infinite loop?
2. Or, is there an infinite outputting in the console?
Steven Bosscher wrote:
> On 5/12/07, Mark Mitchell <[EMAIL PROTECTED]> wrote:
>> PR 31797: An infinite loop in the compiler while building RTEMS.
>> Daniel, I see you've been commenting on this; are you working on the
>> fix? If so, do you have an ETA?
>
> Why are you waiting for this one? RTEMS
On Sat, May 12, 2007 at 12:05:49AM +0200, Steven Bosscher wrote:
> On 5/12/07, Mark Mitchell <[EMAIL PROTECTED]> wrote:
> >PR 31797: An infinite loop in the compiler while building RTEMS.
> >Daniel, I see you've been commenting on this; are you working on the
> >fix? If so, do you have an ETA?
>
On 5/12/07, Mark Mitchell <[EMAIL PROTECTED]> wrote:
PR 31797: An infinite loop in the compiler while building RTEMS.
Daniel, I see you've been commenting on this; are you working on the
fix? If so, do you have an ETA?
Why are you waiting for this one? RTEMS is not a primary or secondary
platf
Every time I think we're almost there with this release, I seem to
manage to get stuck. :-( However, we're very close: the only PRs that
I'm waiting for are:
PR 30252: Wrong code generation, perhaps due to the C++ front end's
representation for base classes. Jason, are you actively investigating
On Friday 11 May 2007, Dave Korn wrote:
> On 11 May 2007 19:27, Paul Brook wrote:
> >>> > result = __macf(operand1, operand2, operand3);
> >> After the builtin i want to have the following operations also to
> >> carried out operand3 = result ;
> >
> > Why do you want this to happen?
>
> I t
Rohit Arul Raj wrote:
When looking at the dwarf dump, the starting frame address for
function "fun" is given as
< 0><0:0xc>
Assuming you made a beginner mistake, I'd say the problem here is that
you ran dwarfdump on a .o file, and you failed to notice that dwarfdump
doesn't handle the reloca
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of
> Dave Korn
> Sent: Friday, May 11, 2007 11:32 AM
> To: 'Paul Brook'; gcc@gcc.gnu.org
> Cc: 'Mohamed Shafi'; 'Andrew Haley'
> Subject: RE: Updating an operand in RTL for a builtin function
>
>
> On 11 May 2
On 11 May 2007 19:27, Paul Brook wrote:
>>> > result = __macf(operand1, operand2, operand3); >
>>> > }
>>> >
>>> > Requirement : I need the value of operand3 and result to be same >
>>> after calling the builtin. > But this is not happening.
>>>
>>> What do you mean, exactly? C only ha
> > > result = __macf(operand1, operand2, operand3);
> > >
> > > }
> > >
> > > Requirement : I need the value of operand3 and result to be same
> > > after calling the builtin.
> > > But this is not happening.
> >
> > What do you mean, exactly? C only has call by value, and gcc's
> > bui
This is the beta release of binutils 2.17.50.0.16 for Linux, which is
based on binutils 2007 0511 in CVS on sourceware.org plus various
changes. It is purely for Linux.
All relevant patches in patches have been applied to the source tree.
You can take a look at patches/README to see what have been
The rules should be simple. Bits of the dest reg survive only if one of
the following is true.
- there is a STRICT_LOW_PART (of a SUBREG)
- there is a ZERO_EXTRACT (not necessarily of a SUBREG!)
- the subreg is part of a multiword subreg
So, this is a prototype patch that I would like to
Hi,
On Fri, 11 May 2007, Paolo Bonzini wrote:
> First of all, scrap my other message...
>
> > There was a debate several months ago on this issue: how much should the
> > df scanner be a theorem prover with respect to how many bits survive an
> > operation.
> > For instance, I could easily add t
On May 11, 2007, at 11:31, Andrew Haley wrote:
It shouldn't have. All args are ints, and if we are assuming (as the
C standard says) that int overflow is undefined, the transformation is
valid.
Aarghh..! I even quoted the part that mentioned ints, but still thought
it was about float. Sure,
Geert Bosch writes:
>
> On May 11, 2007, at 08:26, Rahul wrote:
> > But for the following example
> > int a = 1;
> > int b = 2;
> > int c = 3;
> > c = c + a * b;
> > the MAC pattern is not getting recognized, instead it is still using
> > PLUS and MULT patterns.
>
> In general, thi
On May 11, 2007, at 08:26, Rahul wrote:
But for the following example
int a = 1;
int b = 2;
int c = 3;
c = c + a * b;
the MAC pattern is not getting recognized, instead it is still using
PLUS and MULT patterns.
In general, this transformation is not valid, as it has
different rounding beha
On Fri, May 11, 2007 at 05:56:16PM +0530, Rahul wrote:
> I have PLUS, MULT and following MAC pattern, in my target.md file.
> (define_insn ""
> [(set (match_operand:SI 0 "data_reg" "=f")
> (plus:SI (mult:SI (match_operand:SI 1 "data_reg" "f")
> (match_ope
[EMAIL PROTECTED] wrote on 11/05/2007 15:26:16:
> Hello all,
>
> I am working on gcc v4.1.1 for a non-gcc target. I want to support
> 'MAC' instruction
> (mac OP1, OP2, OP3 => OP3 += OP1 * OP2).
>
http://gcc.gnu.org/ml/gcc/2007-05/msg00114.html seems relevant to your
problem.
Revital
>
>
> R
Hi,
On Fri, 11 May 2007, Kenneth Zadeck wrote:
> There was a debate several months ago on this issue: how much should the
> df scanner be a theorem prover with respect to how many bits survive an
> operation.
> For instance, I could easily add to your list, anding and oring
> operations which als
First of all, scrap my other message...
There was a debate several months ago on this issue: how much should the
df scanner be a theorem prover with respect to how many bits survive an
operation.
For instance, I could easily add to your list, anding and oring
operations which also preserve bits.
Hi,
On Fri, 11 May 2007, Rask Ingemann Lambertsen wrote:
>The first one is the insn pattern right below the mulsidi3 expander,
>right? Please give all insn patterns a name to make searches easier.
It's on the TODO list. :)
>May I ask why the original insn 7 isn't coded something lik
My opinion:
(set (subreg:SI (reg:DI) 4) ...
DF_REF_READ_WRITE|DF_REF_PARTIAL?
yep
(set (subreg:HI (reg:DI) 6) ...
DF_REF_READ_WRITE?
Also PARTIAL. you can rely on the content of the 0-3 word.
Likewise for:
(set (subreg:HI (reg:DI) 2) ...
here you can rely on the content of the 4-7 wo
On Thu, May 10, 2007 at 07:43:19PM +0200, Roman Zippel wrote:
> Looking closer at this I don't think strict_low_part should be required
> as splitting DI registers produces a lot of (subreg:SI (reg:DI)) even as
> destination, but they only set strictly part of the register. If I look
> through i38
Roman Zippel wrote:
> Hi,
>
> On Thu, 10 May 2007, I wrote:
>
>
>> I have a few problems with the m68k mulsidi3 pattern on the dataflow
>> branch.
>>
>
> To illustrate the problem here is what happens during combine:
>
> -(insn 7 28 8 2 ../gcc/gcc/testsuite/gcc.c-torture/execute/20001108-1.
Hello all,
I am working on gcc v4.1.1 for a non-gcc target. I want to support
'MAC' instruction
(mac OP1, OP2, OP3 => OP3 += OP1 * OP2).
I have PLUS, MULT and following MAC pattern, in my target.md file.
(define_insn ""
[(set (match_operand:SI 0 "data_reg" "=f")
(plus
On Fri, May 11, 2007 at 01:54:24PM +0200, Roman Zippel wrote:
>
> To illustrate the problem here is what happens during combine:
>
> -(insn 7 28 8 2 ../gcc/gcc/testsuite/gcc.c-torture/execute/20001108-1.c:4
> (parallel [
> -(set (subreg:SI (reg:DI 30 [ D.1547 ]) 4)
> -
Hi,
On Thu, 10 May 2007, I wrote:
> I have a few problems with the m68k mulsidi3 pattern on the dataflow
> branch.
To illustrate the problem here is what happens during combine:
-(insn 7 28 8 2 ../gcc/gcc/testsuite/gcc.c-torture/execute/20001108-1.c:4
(parallel [
-(set (subreg:SI (
On 5/4/07, Andrew Haley <[EMAIL PROTECTED]> wrote:
Mohamed Shafi writes:
> I am trying to implement a builtin function __macf for a private target.
> I have added the required target hooks for this.
> Say for the following code
>
> int main()
> {
> int operand1 = 2;
> int operand2 =
Hi Flavell
I am sorry for replying so late. If you can detail me the exact scenario where
program compiled using gcc3.3 crashes, then we can try to help you.
Tell us about the following:-
1: machine spec
2: OS with SP if any
3: program u are trying to compile
4: what options u are passing to comp
Although the file io.h from MinGW/include has a patch, I still have not be
able to use effectively the new build of gcc. I build it from a latop with a
semprom and execute it in a desktop pc with a core 2 duo. The result is the
same every time, there is a problem installation and it tells that cc1
43 matches
Mail list logo
