On Mon, 2006-05-22 21:42:07 -0700, Andrew Pinski <[EMAIL PROTECTED]> wrote:
> On May 22, 2006, at 9:36 PM, H. J. Lu wrote:
> >on Linux/ia64. The last working revision is 113936. Linux/x86 and
> >Linux/x86-64 pass the same spot. Has anyone else seen it?
>
> Yes for hppa-linux-gnu, PR 27736.
>
> Th
Jan-Benedict Glaw wrote:
On Mon, 2006-05-22 21:42:07 -0700, Andrew Pinski <[EMAIL PROTECTED]> wrote:
On May 22, 2006, at 9:36 PM, H. J. Lu wrote:
on Linux/ia64. The last working revision is 113936. Linux/x86 and
Linux/x86-64 pass the same spot. Has anyone else seen it?
Yes for hppa-linux-gnu,
Hi,
could please someone help me with this one:
http://gcc.gnu.org/ml/gcc/2006-05/msg00337.html
Bye,
-Andreas-
On 22 May 2006 20:11, Gerald Pfeifer wrote:
> On Mon, 15 May 2006 [EMAIL PROTECTED] wrote:
>> The link crossgcc FAQ in the middle of the page:
>> "http://gcc.gnu.org/install/build.html"; doesn't seem to link to a page that
>> offers the cross-gcc faq. Instead it appears to be a site of a consulta
On 17 May 2006 19:48, Andreas Krebbel wrote:
>> Doesn't this mean that your insn patterns should be using numerical (aka
>> "matching") constraints?
>
> Oh we are using matching constraints. But of course nobody except reload
> does care about them. If the only constraints for an operand are mat
Hi,
> Hmm. I note that if you /were/ using match_dups, the problem would be
> solved because all four changes would go through the 'then' clause of the
> if...else construct. Maybe it would be more worthwhile for you to have
> separate patterns after all and find some other way of making reloa
On 23 May 2006 15:42, Andreas Krebbel wrote:
> Hi,
>
>> Hmm. I note that if you /were/ using match_dups, the problem would be
>> solved because all four changes would go through the 'then' clause of the
>> if...else construct. Maybe it would be more worthwhile for you to have
>> separate patt
Looking at assembly listings of the Linux kernel I see thousands of
places where function returns are checked to be non-zero to indicate
errors. For example something like this:
mov bx, 0
.L1
call foo
test ax,ax
jnz .Lerror
inc bx
cmp bx, 10
jne .L1
.Lerror
proc
On Tue, May 23, 2006 at 04:14:23PM +0100, Dave Korn wrote:
> (I don't think that prefixing
> "anddi3" with an asterisk will hide it from the compiler and prevent it being
> treated as the named pattern for anddi3; IIRC that doesn't work to protect the
> well-known names, and so neither can you hav
> Has work been done to evaluate a calling convention that takes error
> checks like this into account? Are there size/performance wins? Or am
> I just reinventing a variation on exception handling?
This introduces an extra stack push and will confuse a call-stack branch
predictor. If both the ca
I get this failure when trying to do a proifledbootstrap on amd64. This is
a gentoo Linux machine with gcc 3.4.4, glibc 2.35, binutils 2.16.1,
autoconf 2.59, etc, etc.
make[6]: Entering directory
`/home/matt/src/gcc-bin/x86_64-unknown-linux-gnu/libstdc++-v3'
if [ -z "32" ]; then \
true; \
else \
Hi,
> The x86 pattern is called "anddi_1_rex64", which is not one of the standard
> names: that means the compiler will never emit it directly.
Not necessarily. Someone simply could call gen_andidi_1_rex64 (e.g. from i386.c)
to emit this pattern. That the insn doesn't use a standard name only
On 5/23/06, Paul Brook <[EMAIL PROTECTED]> wrote:
> Has work been done to evaluate a calling convention that takes error
> checks like this into account? Are there size/performance wins? Or am
> I just reinventing a variation on exception handling?
This introduces an extra stack push and will co
> An insn matched by anddi_1_rex64 must not be emitted via the "anddi3"
> expander.
"must not" should be replaced here by "does not need to"
a common error for Germans ... or well at least for me ;-)
On Tue, May 23, 2006 at 07:29:59PM +0200, Andreas Krebbel wrote:
> > An insn matched by anddi_1_rex64 must not be emitted via the "anddi3"
> > expander.
> "must not" should be replaced here by "does not need to"
> a common error for Germans ... or well at least for me ;-)
A German colleague of mi
On May 23, 2006, at 8:21 AM, Jon Smirl wrote:
Or am I just reinventing a variation on exception handling?
:-)
DJ Delorie wrote:
> FYI m32c still doesn't build libssp due to the GCC_NO_EXECUTABLES
> thing. Works OK with it disabled, though, for C and C++. From whence
> will release notes be published?
I think there are several kinds of "release notes". One is the manually
prepared bug-summaries done by
> I'd imagine you might want to update bugs.html, in this case?
Or, perhaps, branch's install.texi's "Host/Target specific
installation notes for GCC" ?
DJ Delorie wrote:
>> I'd imagine you might want to update bugs.html, in this case?
>
> Or, perhaps, branch's install.texi's "Host/Target specific
> installation notes for GCC" ?
Yes, that's probably even better.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
* Jon Smirl:
> Is the callstack branch correctly predicted if the routine being
> called is complex?
At least the AMD CPUs have implemented a special return stack cache,
so the answer is probably "yes".
> This does eliminate the test./jmp after every function call.
Yes, but the test/jump now ha
On 5/23/06, Florian Weimer <[EMAIL PROTECTED]> wrote:
Yes, but the test/jump now happens in the callee, and you need to
maintain an additional stack slot. I wouldn't be surprised if the
The callee already had to implement the test/jmp in order to decide to
return the error. So this shouldn't i
On Tue, May 23, 2006 at 11:21:46AM -0400, Jon Smirl wrote:
> Has work been done to evaluate a calling convention that takes error
> checks like this into account? Are there size/performance wins? Or am
> I just reinventing a variation on exception handling?
It's fairly close to Fortran alternate r
> You're misunderstanding how this code works. In cfglayout mode,
> there is no "order" in the basic blocks such that
> BLOCK_FOR_INSN(NEXT_INSN(BB_END(BB)) ) == BB->next_bb. This means
> that you can fall through to other blocks than next_bb.
Thanks for the tip, I figured out what was really ha
On 5/23/06, DJ Delorie <[EMAIL PROTECTED]> wrote:
> You're misunderstanding how this code works. In cfglayout mode,
> there is no "order" in the basic blocks such that
> BLOCK_FOR_INSN(NEXT_INSN(BB_END(BB)) ) == BB->next_bb. This means
> that you can fall through to other blocks than next_bb.
> Sounds like you need a memory clobber constraint on the asm... ?
Yup, that looks like it would do the trick. Thanks!
On 5/23/06, Gabriel Paubert <[EMAIL PROTECTED]> wrote:
On Tue, May 23, 2006 at 11:21:46AM -0400, Jon Smirl wrote:
> Has work been done to evaluate a calling convention that takes error
> checks like this into account? Are there size/performance wins? Or am
> I just reinventing a variation on exce
>
> On 5/23/06, DJ Delorie <[EMAIL PROTECTED]> wrote:
> >
> > > You're misunderstanding how this code works. In cfglayout mode,
> > > there is no "order" in the basic blocks such that
> > > BLOCK_FOR_INSN(NEXT_INSN(BB_END(BB)) ) == BB->next_bb. This means
> > > that you can fall through to other
In building the current gcc trunk under fink on MacOS X, I noticed
that 'fink validate' reported...
Error: Libtool file points to fink build dir.
Offending file: /sw/lib/gcc4/lib/libstdc++.la
Offending file: /sw/lib/gcc4/lib/libsupc++.la
which alerted me to the fact that both l
>
>In building the current gcc trunk under fink on MacOS X, I noticed
> that 'fink validate' reported...
>
> Error: Libtool file points to fink build dir.
> Offending file: /sw/lib/gcc4/lib/libstdc++.la
> Offending file: /sw/lib/gcc4/lib/libsupc++.la
>
> which alerted me to t
GCC 4.1.1 RC1 is available from:
ftp://gcc.gnu.org/pub/gcc/prerelease-4.1.1-20060517
Please download, build, and test these packages -- not trees
checked out
from SVN -- so that we can detect packaging problems.
Please post test results here:
http://gcc.gnu.org/wiki/GCC%204.1.1%20RC%20S
Hi,
Our company had developed a new 32bit embedded processor many years age,
now we had ported GCC4.X for it(c/c++), and we want add its GCC4.x backend
to your GCC packages, can you tell me what should we do next?
Best Regards
Liqin
On May 23, 2006, at 6:01 PM, [EMAIL PROTECTED] wrote:
Our company had developed a new 32bit embedded processor many years
age,
now we had ported GCC4.X for it(c/c++), and we want add its GCC4.x
backend
to your GCC packages, can you tell me what should we do next?
First step, read our web si
I will be building the GCC 4.1.1 release later tonight, or, at latest,
tomorrow (Wednesday) in California. Please refrain from all check-ins
on the branch until I have announced the release.
Thanks,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
33 matches
Mail list logo
