Hello everybody!
We've just pointed out a strange problem with gcc 3.4.0: we use it for
generating ARM 7 processor thumb code.
This strange behavior was pointed out with a function taking 5 parameters (the
fifth one is passed through stack according to the abi spec).
We use the following
Mick CORNUT writes:
>
> We've just pointed out a strange problem with gcc 3.4.0: we use it
> for generating ARM 7 processor thumb code. This strange behavior
> was pointed out with a function taking 5 parameters (the fifth one
> is passed through stack according to the abi spec).
Can y
hello everyone,
I have the following 2 patterns which are consecutive. (from shorten
rtl dump file)
(insn 69 34 70 (set (reg:SQ 0 d0)
(reg:SQ 18 f2)) 79 {movsq} (nil)
(nil))
(insn 70 69 35 (set (reg:SQ 16 f0 [orig:38 D.3693 ] [38])
(reg:SQ 0 d0)) 79 {movsq} (nil)
(nil))
Fo
Hi Andrew,
As I've mentionned it, I've built gcc 3.4.6 for ARM yesterday (with binutils
2.17), and the same problem occurs!
Ps: I've just tried with gcc 4.1.1, but the problem doesn't occur since gcc
removes the temporary buffer allocation on the stack, furthermore, we want to
keep gcc 3.4.x!
Please don't top-post.
Mick CORNUT writes:
> >
> > - Message d'origine
> > De : Andrew Haley <[EMAIL PROTECTED]>
> >
> > Mick CORNUT writes:
> >
> > > We've just pointed out a strange problem with gcc 3.4.0: we use it
> > > for generating ARM 7 processor thumb code. This str
On 4/12/07, Mick CORNUT <[EMAIL PROTECTED]> wrote:
Hi Andrew,
As I've mentionned it, I've built gcc 3.4.6 for ARM yesterday (with
binutils 2.17), and the same problem occurs!
Andrew meant to say that GCC 3.4.* is no longer being maintained. You
should not post a bug, and if you do so anyway it
"Mohamed Shafi" <[EMAIL PROTECTED]> writes:
> hello everyone,
>
> I have the following 2 patterns which are consecutive. (from shorten
> rtl dump file)
>
> (insn 69 34 70 (set (reg:SQ 0 d0)
>(reg:SQ 18 f2)) 79 {movsq} (nil)
>(nil))
>
> (insn 70 69 35 (set (reg:SQ 16 f0 [orig:38 D.3693
On 4/12/07, Andreas Schwab <[EMAIL PROTECTED]> wrote:
"Mohamed Shafi" <[EMAIL PROTECTED]> writes:
> hello everyone,
>
> I have the following 2 patterns which are consecutive. (from shorten
> rtl dump file)
>
> (insn 69 34 70 (set (reg:SQ 0 d0)
>(reg:SQ 18 f2)) 79 {movsq} (nil)
>(nil)
On 12 April 2007 10:10, Steven Bosscher wrote:
> On 4/12/07, Mick CORNUT <[EMAIL PROTECTED]> wrote:
>> Hi Andrew,
>>
>> As I've mentionned it, I've built gcc 3.4.6 for ARM yesterday (with
>> binutils 2.17), and the same problem occurs!
>
> Andrew meant to say that GCC 3.4.* is no longer being ma
Claudio Scordino wrote:
Kai Ruottu wrote:
Claudio Scordino wrote:
I'm looking for a toolchain capable of compiling floating point
operations for the Maverick Crunch Math engine of Cirrus EP93xx
processors.
Cirrus provides some scripts to build a gcc-3.4 toolchain with such
support, but un
Hi,
M16C has 20 bit physical address bus, but the address registers are
only 16 bit. It has a 16 bit data pointer. ROM memory region starts
at memory location "0x000A" (i.e. 20 bit address). As the pointer
size for GCC M16C is two bytes, it fails to access the memory region
that is greater tha
On Thu, 2007-04-12 at 08:59 +, Mick CORNUT wrote:
> Hi Andrew,
> Ps: I've just tried with gcc 4.1.1, but the problem doesn't occur
> since gcc removes the temporary buffer allocation on the stack,
> furthermore, we want to keep gcc 3.4.x!
Changing the testcase to
void trace(int p1, int p2,
On Thu, 2007-04-12 at 14:16 +0300, Kai Ruottu wrote:
> Things seem to be that the '-mcpu=ep9312 -mhard-float' combination will
> crash the GCC build in both gcc-4.1.2 and gcc-4.2.0-20070316 prerelease
> like :
-mhard-float doesn't do what you think it does...
I think you should be using:
Is anyone using svk? I tried to create a local depot by updating the
one pointed on the wiki. Unfortunately it is trying to use too much
ram and crashing.
I crashes just after stating to work on revision 121126.
Cheers,
--
Rafael Avila de Espindola
Google Ireland Ltd.
Gordon House
Barrow Street
Rafael Espindola wrote:
Is anyone using svk? I tried to create a local depot by updating the
one pointed on the wiki. Unfortunately it is trying to use too much
ram and crashing.
Yes, we keep a local mirror of trunk and sel-sched branch using svk. As
far as I remember, I did the setup from scr
http://code.google.com/soc/gcc/about.html
Best of luck with your projects!
--
Laurynas, GSoC 2006 participant
On Thu, 2007-04-12 at 14:12 +0100, Rafael Espindola wrote:
> Is anyone using svk? I tried to create a local depot by updating the
> one pointed on the wiki. Unfortunately it is trying to use too much
> ram and crashing.
>
> I crashes just after stating to work on revision 121126.
There are a numb
When bootstrapping a mainline compiler on i386-apple-darwin8.8.1, we
are linking libstdc++.dylib incorrectly. My understanding of the
build machinery behind libstdc++ is very poor, so here's what I've
found.
The symptom of the problem is a warning from the Darwin linker when
trying to bui
Steven Bosscher wrote:
On 4/12/07, Vladimir Makarov <[EMAIL PROTECTED]> wrote:
SPECFp2000 compilation time (user time):
machine mainline branch change
-
x86_64 104.8s117.7s +12.3%
ppc64312.3s367.8s +17.8%
ia64 377.6s502.9s +33.2%
Hi
> Currently the complete ".rodata" section is copied from load address
> (ROM) to RAM, that is by treating it similar to ".data" section.
Right, the linker scripts know which chips have accessible flash and
which don't.
> We went through the discussion in the following link and realized
> that t
On 4/12/07, Vladimir Makarov <[EMAIL PROTECTED]> wrote:
> Thanks for testing this. Do you also have per benchmark compilation
> times, perhaps?
>
Not really. I don't do that because runtest startup is about 0.4s (on
ppc64) and a few fp tests are compiled for 1.5s. If you are interesting
in anal
On Thursday 12 April 2007 14:02, Richard Earnshaw wrote:
> On Thu, 2007-04-12 at 14:16 +0300, Kai Ruottu wrote:
> > Things seem to be that the '-mcpu=ep9312 -mhard-float' combination will
> > crash the GCC build in both gcc-4.1.2 and gcc-4.2.0-20070316 prerelease
> > like :
>
> -mhard-float doesn't
Steven Bosscher wrote:
On 4/12/07, Vladimir Makarov <[EMAIL PROTECTED]> wrote:
> Thanks for testing this. Do you also have per benchmark compilation
> times, perhaps?
>
Not really. I don't do that because runtest startup is about 0.4s (on
ppc64) and a few fp tests are compiled for 1.5s. If y
On 12 April 2007 15:59, Thomas Neumann wrote:
> Hi,
>
> the attached patch adds missing casts in gengtype-lex.l (i.e. missing in
> C++, recommended by GCC Coding Conventions in C). Please apply it if you
> find it useful.
>
> Thomas
>
> * gengtype-lex.l: Cast from void* to the proper type.
I
> However, bundling them all up into big patches would probably run over the
> size limit for "small patches that don't require paperwork".
The size limit for non-copyrightable changes is accumulative. ie. it applies
the same whether changes are submitted one by one or all at once.
Paul
On 12 April 2007 16:31, Paul Brook wrote:
>> However, bundling them all up into big patches would probably run over the
>> size limit for "small patches that don't require paperwork".
>
> The size limit for non-copyrightable changes is accumulative. ie. it applies
> the same whether changes are s
Dave Korn schrieb:
> Maybe it would make more sense to bundle them up into two tranches,
one for
> all the gen* utilities, one for the compiler core itself. That would
be much
> more practical to do the full bootstrap-and-regtest procedure.
indeed. To get a full C++ compliant compiler I would prob
Hello,
> 2. Right now I am inserting a __builting_prefetch(...) call immediately
> before the actual read, getting something like:
> D.1117_12 = &A[D.1101_14];
> __builtin_prefetch (D.1117_12, 0, 1);
> D.1102_16 = A[D.1101_14];
>
> However, if I enable the instruction scheduler pass, it doesn
On 12 April 2007 16:39, Thomas Neumann wrote:
>> However,
>> bundling them all up into big patches would probably run over the size
>> limit for "small patches that don't require paperwork". Do you have an
>> assignment on file with the FSF?
> no, and this is the reason why I send tiny patches.
On Thursday 12 April 2007 16:35, Dave Korn wrote:
> On 12 April 2007 16:31, Paul Brook wrote:
> >> However, bundling them all up into big patches would probably run over
> >> the size limit for "small patches that don't require paperwork".
> >
> > The size limit for non-copyrightable changes is acc
On 12 April 2007 17:00, Paul Brook wrote:
> On Thursday 12 April 2007 16:35, Dave Korn wrote:
>> On 12 April 2007 16:31, Paul Brook wrote:
However, bundling them all up into big patches would probably run over
the size limit for "small patches that don't require paperwork".
>>>
>>> The
Zdenek Dvorak wrote:
2. Right now I am inserting a __builting_prefetch(...) call immediately
before the actual read, getting something like:
D.1117_12 = &A[D.1101_14];
__builtin_prefetch (D.1117_12, 0, 1);
D.1102_16 = A[D.1101_14];
However, if I enable the instruction scheduler pass, it does
> >> However, bundling them all up into big patches would probably run over the
> >> size limit for "small patches that don't require paperwork".
On 12 April 2007 16:31, Paul Brook wrote:
>> The size limit for non-copyrightable changes is accumulative. ie. it applies
>> the same whether change
On 4/12/07, Vladimir Makarov <[EMAIL PROTECTED]> wrote:
An interesting observation is that the more hard registers the processor
has, the bigger slowdown is. Although it might be a coincidence.
Yes, I noticed this too. I don't believe this is a coincidence. It's
the first thing I was plannin
On Apr 12, 2007, at 8:39 AM, Thomas Neumann wrote:
no, and this is the reason why I send tiny patches. But I could try to
fill the required paperwork (although I think I read it takes ages
to be
processed).
If you never again plain to submit a change, sure, just ignore it.
If you think yo
Dave Korn wrote:
> Maybe it would make more sense to bundle them up into two tranches, one for
> all the gen* utilities, one for the compiler core itself. That would be much
> more practical to do the full bootstrap-and-regtest procedure.
I agree. I know about the 1-idea-per-patch doctrine,
I am working SSE4.1/4.2 support. I need to add -msse4.1, -msse4.2
and -msse4. But i386 is running out target mask bits. I got
./options.h:368:2: error: #error too many target masks
Does anyone have suggestions to resolve this? Why not use structure
of bitfields instead of int for target_flags?
I've added a collection of scripts that I have gathered over time to
test compile time and memory usage when making changes to the compiler.
http://gcc.gnu.org/wiki/PerformanceTesting
If you have other scripts or tests that could be used for this, please
add them to this page.
Thanks.
"H. J. Lu" <[EMAIL PROTECTED]> writes:
> Does anyone have suggestions to resolve this? Why not use structure
> of bitfields instead of int for target_flags?
Years ago I added an option to support multi-way options using the
switch table and default values. I'm not sure how that translated
into t
On Thu, 12 Apr 2007, H. J. Lu wrote:
> I am working SSE4.1/4.2 support. I need to add -msse4.1, -msse4.2
> and -msse4. But i386 is running out target mask bits. I got
>
> ./options.h:368:2: error: #error too many target masks
>
> Does anyone have suggestions to resolve this? Why not use structu
On Thu, Apr 12, 2007 at 06:41:06PM +, Joseph S. Myers wrote:
> On Thu, 12 Apr 2007, H. J. Lu wrote:
>
> > I am working SSE4.1/4.2 support. I need to add -msse4.1, -msse4.2
> > and -msse4. But i386 is running out target mask bits. I got
> >
> > ./options.h:368:2: error: #error too many target
On Thu, Apr 12, 2007 at 02:40:31PM -0400, DJ Delorie wrote:
>
> "H. J. Lu" <[EMAIL PROTECTED]> writes:
> > Does anyone have suggestions to resolve this? Why not use structure
> > of bitfields instead of int for target_flags?
>
> Years ago I added an option to support multi-way options using the
>
On Thu, 12 Apr 2007, H. J. Lu wrote:
> > You can specify Var together with Mask in .opt files; that allows you to
> > create a second variable for flag bits as a smaller patch for now.
> >
>
> How will it work with
>
>/* Turn on SSSE3 builtins for -msse4.1. */
> if (TARGET_SSE4_1)
>
On Thu, Apr 12, 2007 at 06:58:29PM +, Joseph S. Myers wrote:
> On Thu, 12 Apr 2007, H. J. Lu wrote:
>
> > > You can specify Var together with Mask in .opt files; that allows you to
> > > create a second variable for flag bits as a smaller patch for now.
> > >
> >
> > How will it work with
>
On Thu, 12 Apr 2007, H. J. Lu wrote:
> Are there any documents/examples for a second variable for flag bits?
config/linux.opt uses Mask and InverseMask with Var.
--
Joseph S. Myers
[EMAIL PROTECTED]
On 4/12/07, H. J. Lu <[EMAIL PROTECTED]> wrote:
I am working SSE4.1/4.2 support. I need to add -msse4.1, -msse4.2
and -msse4. But i386 is running out target mask bits. I got
./options.h:368:2: error: #error too many target masks
Does anyone have suggestions to resolve this? Why not use structur
On Thu, 2007-04-12 at 16:00 +0200, Laurynas Biveinis wrote:
> http://code.google.com/soc/gcc/about.html
>
> Best of luck with your projects!
For GSoC participants needing always on machines (for crontab jobs or
launching multiple compilations/tests at once or whatever), remember
that you can get
George Caragea wrote:
So my initial question remains: is there any way to tell the scheduler
not to place the prefetch instruction after the actual read?
You can try changing sched_analyze_2 in sched-deps.c to handle PREFETCH
specially.
You could perhaps handle it similarly to how PRE_DEC is
There are a number of memory leaks in various SVK 1.x releases[1]. SVK
2.0.1 should fix most (all?) of those, plus it has a much more efficient
method available that can be used to mirror the gcc repo (using svn
replay).
I am giving svk 2.0.1 a try. Compiling it was a bit painful, but now
it is
Mohamed Shafi wrote:
even i wrote define_peephole2 which is similar to the above.
But the above patterns are not matched at all. But i can find these
patterns in the rtl dumps.
Run cc1 under gdb. Put a breakpoint in the peephole function. Step
through the code to see what is wrong.
--
Jim W
Hello,
> Well, the target architecture is actually quite peculiar, it's a
> parallel SPMD machine. The only similarity with MIPS is the ISA. The
> latency I'm trying to hide is somewhere around 24 cycles, but because it
> is a parallel machine, up to 1024 threads have to stall for 24 cycles in
Hi all,
I reviewed this afternoon the postings from the gcc-testresults
mailing-list for the past month, and we have a couple of gfortran
testsuite failures showing up on various targets. Could people with
access to said targets (possibly maintainers) please file PRs in
bugzilla for each
wrt to the Subject of the mail, I'm not sure "Call to arms" means
what I thought it meant, after all... I really wanted it to sound
like "call for help" or "call for more arms". Sorry if there was any
confusion in the tone.
FX
On Thu, Apr 12, 2007 at 07:03:34PM +, Joseph S. Myers wrote:
> On Thu, 12 Apr 2007, H. J. Lu wrote:
>
> > Are there any documents/examples for a second variable for flag bits?
>
> config/linux.opt uses Mask and InverseMask with Var.
i386.c has many
static const struct builtin_description bd
On Thu, 12 Apr 2007, H. J. Lu wrote:
> On Thu, Apr 12, 2007 at 07:03:34PM +, Joseph S. Myers wrote:
> > On Thu, 12 Apr 2007, H. J. Lu wrote:
> >
> > > Are there any documents/examples for a second variable for flag bits?
> >
> > config/linux.opt uses Mask and InverseMask with Var.
>
> i386.
On Thu, Apr 12, 2007 at 02:35:10PM -0700, H. J. Lu wrote:
> i386.c has many
>
> static const struct builtin_description bdesc_comi[] =
> {
> { MASK_SSE, CODE_FOR_sse_comi,
Yes, and you could move all of the ones specifically related to
the ISA to it's own variable.
r~
On Thu, Apr 12, 2007 at 02:48:43PM -0700, Richard Henderson wrote:
> On Thu, Apr 12, 2007 at 02:35:10PM -0700, H. J. Lu wrote:
> > i386.c has many
> >
> > static const struct builtin_description bdesc_comi[] =
> > {
> > { MASK_SSE, CODE_FOR_sse_comi,
>
> Yes, and you could move all of the
I would recommend using the system libstdc++ and system libgcc_s
rather than one you build yourself from FSF sources, unless you're
actually developing libstdc++. The FSF libstdc++ is, I believe,
binary incompatible with the system one, and since system libraries
use the system one there is no way
Hi Richard,
After tracing GCC 4.x to see why MADD is not generated for MIPS32,
I found out the main issue is that the pattern "adddi3"
is not available for MIPS32. Because the missing
of adddi3, GCC 4.x needs to split 64-bit addition to 4 separate
RTL insns. This leads to that the combining ph
That said, though, there's something weird going on in your build that
should probably be tracked down. It didn't happen to me last time I
built...
Here's a patch that fixes it though it doesn't fix the testsuite
results yet and is likely not quite what Daniel will want...
Dan?
The basic
FX Coudert wrote:
wrt to the Subject of the mail, I'm not sure "Call to arms" means
what I thought it meant, after all... I really wanted it to sound
like "call for help" or "call for more arms". Sorry if there was any
confusion in the tone.
The literal meaning of "call to arms" is a call
On Thu, Apr 12, 2007 at 03:09:55PM -0700, H. J. Lu wrote:
> BTW, I noticed that there are 2 bits
>
> NO_PUSH_ARGS
> SVR3_SHLIB
>
> defined in i386 backend. But they aren't checked at all. Can we remove
> them?
I don't see why SVR3_SHLIB can't be removed. Probably from
some port that got depreca
On Thu, Apr 12, 2007 at 05:25:45PM -0700, Richard Henderson wrote:
> On Thu, Apr 12, 2007 at 03:09:55PM -0700, H. J. Lu wrote:
> > BTW, I noticed that there are 2 bits
> >
> > NO_PUSH_ARGS
> > SVR3_SHLIB
> >
> > defined in i386 backend. But they aren't checked at all. Can we remove
> > them?
>
>
On Thu, Apr 12, 2007 at 04:43:23PM -0700, Eric Christopher wrote:
> The basic idea is that the darwin code uses slibdir to set the install name
> of
> the library - including full path. Yes, this is dumb, but it's the way that
> darwin does things at the moment. :(
That much is reasonable but..
I didn't just pull this out of a hat, you know :-) Where do you think
it's going to install the library if you do that?
Yeah, I know. I said it wasn't a good patch, but I was on my way out
of the office for the evening and wanted to get Doug something and
have you look at the code too :)
On 12 Apr 2007 15:14:01 -0700, Geoffrey Keating <[EMAIL PROTECTED]> wrote:
I would recommend using the system libstdc++ and system libgcc_s
rather than one you build yourself from FSF sources, unless you're
actually developing libstdc++.
The FSF libstdc++ is, I believe,
binary incompatible wit
On Apr 12, 2007, at 10:17 PM, Daniel Berlin wrote:
On 12 Apr 2007 15:14:01 -0700, Geoffrey Keating <[EMAIL PROTECTED]>
wrote:
I would recommend using the system libstdc++ and system libgcc_s
rather than one you build yourself from FSF sources, unless you're
actually developing libstdc++.
T
On 4/12/07, Steven Bosscher <[EMAIL PROTECTED]> wrote:
On 4/12/07, Vladimir Makarov <[EMAIL PROTECTED]> wrote:
> An interesting observation is that the more hard registers the processor
> has, the bigger slowdown is. Although it might be a coincidence.
Yes, I noticed this too. I don't believe
FX Coudert wrote:
wrt to the Subject of the mail, I'm not sure "Call to arms" means what I
thought it meant, after all... I really wanted it to sound like "call
for help" or "call for more arms". Sorry if there was any confusion in
the tone.
FX
I thought it was great!
Jerry
I just found out that just running "automake" is not enough if you have
installed Autoconf 2.59 as "autoconf-2.59", and a newer Autoconf as just
"autoconf".
You have to do
AUTOM4TE=autom4te-2.59 automake
(possibly something like "AUTOM4TE=autom4te-2.59 automake-1.9").
I thought that shari
70 matches
Mail list logo
