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
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
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
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
>
>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
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
>
> 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
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
> 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, 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.
> 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 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
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
* 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
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
> 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:
> 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
On May 23, 2006, at 8:21 AM, Jon Smirl wrote:
Or am I just reinventing a variation on exception handling?
:-)
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
> 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 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
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
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 \
> 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
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
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 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
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 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
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
Hi,
could please someone help me with this one:
http://gcc.gnu.org/ml/gcc/2006-05/msg00337.html
Bye,
-Andreas-
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,
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
33 matches
Mail list logo
