On 7/24/09, Uros Bizjak wrote:
> The source of gcc uses both, fputc and putc. I would like to do some
> janitorial work and change fputc to putc.
putc and fputc have different semantics:
fputc is guaranteed to be a function while putc may be a macro.
M
"He who has nothing to do, combs dog
On 8/12/09, Joel Sherrill wrote:
> So any ACATS results from any other ARM target would be
> appreciated.
I looked into gnat-arm for the new Debian port and the conclusion was
that it has never been bootstrapped onto ARM. The closest I have seen
is Adacore's GNATPro x86->xscale cross-compiler h
On 8/12/09, Matthias Klose wrote:
> On 12.08.2009 23:07, Martin Guy wrote:
> > I looked into gnat-arm for the new Debian port and the conclusion was
> > that it has never been bootstrapped onto ARM. The closest I have seen
> > is Adacore's GNATPro x86->xscale cross-c
Hi!
I'd appreciate some input on how to get the pipeline scheduler to
know about the bizarre MaverickCrunch timing characteristics.
Brief: Crunch is an asynchronous ARM coprocessor which has internal
operations from/to its own register set, transfers between its own
registers and the ARM integ
Yes, GCC is bigger and slower and for several architectures generates
bigger, slower code with every release, though saying so won't make
you very popular on this list! :)
One theory is that there are now so many different optimization passes
(and, worse, clever case-specific hacks hidden in the b
On 12/22/09, Daniel Jacobowitz wrote:
> in a patch I'm working on for ARM cmpdi patterns, I ended up needing
> "cmpdi_lhs_operand" and "cmpdi_rhs_operand" predicates because Cirrus
> and VFP targets accept different constants. Automatically generating
> that would be a bit excessive though.
On 12/22/09, Daniel Jacobowitz wrote:
> Interesting, I knew you had a lot of Cirrus patches but I didn't
> realize the state of the checked-in code was so bad.
>
> Is what's there useful or actively harmful?
Neither useful nor harmful except in that it adds noise to the arm backend.
It's useful
On 1/16/10, David Edelsohn wrote:
> > Is there a way to get GCC to only use the FPU when we explicitly want to
> use it (i.e. when we use doubles/floats)? Is -msoft-float my only option
> here? Is there any sort of #pragma that could do the same thing as
> -msoft-float (I didn't see one)?
>
On 2/12/10, Richard Guenther wrote:
> On Fri, Feb 12, 2010 at 10:41 AM, Jakub Jelinek wrote:
> > It seems pointers are sign extended to wider integers, is that intentional?
> Your program prints zero-extends for ICC.
>
> Probably the behavior is undefined and we get a warning anyway:
All C r
I disagree with the "default cpu should 95% of what is currently on
sale" argument.
The default affects naive users most strongly, so it should "just
work" on as many processors as is reasonable, not be as fast as
possible on most of the majority of the processors currently on sale.
Naive users mi
On 2/21/10, Dave Korn wrote:
> It makes perfect sense that configuring for i686-*-* should
> get you an i686 compiler and configuring for i586-*-* should get you an i586
> compiler and so on, rather than that you get an i386 compiler no matter what
> you asked for.
Agreed
M
On 2/21/10, Steven Bosscher wrote:
> It is interesting how this conflicts with your signature:
> > "You can't buy a computer these days with less that a gigabyte."
> > -- A.S.Tanenbaum, trying to defend Minix's fixed-size kernel arrays
> > at FOSDEM 2010
> I take it you disagree with this? B
On 2/21/10, Dave Korn wrote:
> I too am having a hard time envisaging exactly who would be in this class of
> users who are simultaneously so naive that they don't know about -march or
> -mcpu or think to read the manual, and yet so advanced that they are trying
> to
> write programs for and
On 2/21/10, Dave Korn wrote:
> On 21/02/2010 20:03, Martin Guy wrote:
> > The point about defaults is that the GCC default tends to filter down
> > into the default for distributions;
> I'd find it surprising if that was really the way it happens; don't
> di
OK, now that stage3 is over I'm thinking of updating the
MaverickCrunch FPU fixes (currently for 4.3) and merging them but
would appreciate some guidance.
There are 26 patches in all and I can't expect anyone to understand
them because they require a good understanding of the FPU and its
hardware
now that stage3 is over I'm thinking of updating the
MaverickCrunch FPU fixes (currently for 4.3) and merging them but
would appreciate some guidance.
There are 26 patches in all and I can't expect anyone to understand
them because they require a good understanding of the FPU and its
hardware bugs
On 10/1/08, Vladimir Sterjantov <[EMAIL PROTECTED]> wrote:
> Processor ARM920T, chip Atmel at91rm9200.
>
> char c[30];
> unsigned short *pN = &c[1];
>
> *pN = 0x1234;
Accesses to shorts on ARM need to be aligned to an even address, and
longs to a 4-byte address. Otherwise the access returns (e
Hi!
I'd appreciate help with my learner's questions about GCC machine
descriptions, about the ARM code generator.
I'm trying to fix code generation for the Cirrus MaverickCrunch FPU
by trying to understand several sets of patches, figure out which are
bogus which are buggy and which need reim
On 12/9/08, Joel Sherrill <[EMAIL PROTECTED]> wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37440
>
> Can Ada build on any Arm platform?
The only existing GNAT Ada compiler I could find for ARM (while
thinking about doing it for the new Debian eabi port) is Adacore's
Windows->Nucleus OS c
On 3/14/09, Paolo Bonzini wrote:
> Hans-Peter Nilsson wrote:
> > The answer to the question is "no", but I'd guess the more
> > useful answer is "yes", for different definitions of "truncate".
>
> Ok, after my patches you will be able to teach GCC about this definition
> of truncate.
I expect
On 3/16/09, Paolo Bonzini wrote:
>AND R1, R0, #31
>MOV R2, R2, SHIFT R1
>ANDS R1, R0, #32
>MOVNE R2, R2, SHIFT #31
>MOVNE R2, R2, SHIFT #1
>
> or
>
>ANDS R1, R0, #32
>MOVNE R2, R2, SHIFT #-32
>SUB R1, R1, R0 ; R1 = (x >= 32 ? 32 - x : -x)
>MOV R2,
On 6/5/09, Graham Reitz wrote:
> I have been working through sections 16 & 17 of the gccint.info
> document and also read through Hans' 'Porting GCC for Dunces'.
There is also "Incremental Machine Descriptions for GCC"
http://www.cse.iitb.ac.in/~uday/soft-copies/incrementalMD.pdf
which describes
On 5/7/10, Shaun Pinney wrote:
> Essentially, we have code which works fine on x86/PowerPC but fails on ARM
> due
> to differences in how misaligned accesses are handled. The failures occur in
> multiple large modules developed outside of our team and we need to find a
> solution. The best
On 5/11/10, Mark Mitchell wrote:
> Richard Earnshaw wrote:
>
> > Speaking of which, we should probably formally deprecate the old arm-elf
> > derived targets in 4.6 so that we can remove them in 4.7.
>
> > Similarly, we should deprecate support for the FPA on ARM.
>
> I agree.
No one seems to
On 5/24/10, Mark Mitchell wrote:
> > Certainly removing support for FPA (and any targets that require it) as
> > a first step would be an option; but we should also focus on where we
> > want to get to.
>
> I agree with that. But, it would also be interesting to know just how
> broken that c
On 4/25/10, Ian Lance Taylor wrote:
> Martin Guy writes:
>
> > now that stage3 is over I'm thinking of updating the
> > MaverickCrunch FPU fixes (currently for 4.3) and merging them but
> > would appreciate some guidance.
> >
> > There are 26 pa
On 6/7/10, NightStrike wrote:
> On Wed, Jun 2, 2010 at 3:17 PM, Diego Novillo wrote:
> > On Wed, Jun 2, 2010 at 14:09, NightStrike wrote:
> >
> >> threads that haven't been addressed. I offered to Ian to do the same
> >> thing for the whole mailing list if we can make it a policy that
> >>
On 6/8/10, NightStrike wrote:
> Are you volunteering to write that small script?
DUnno, are you volunteering to write that small script?
You're the only one here actually volunteering a forwardgoing
commitment of their time here to improve GCC's development in this
way, it seems (and mostly just
> > Still, we'll see...
>
> Apparently not :(
Why not? At most, you just need not to make sure nothing ever send
mail to people who think that kind of thing is bozoid...
M
On 6/27/10, Gerald Pfeifer wrote:
> On Mon, 24 May 2010, Richard Kenner wrote:
> > I think that's a critical distinction. I can't see removing a port just
> > because it's not used much (or at all) because it might be valuable for
> > historical reason or to show examples for how to do things.
> > > But in the C++ standard "integral expression" is more common.
"integral" is an adjective and "integer" is a noun.
"integer expression", though gramatically wrong (or, at best, an
elision of two nouns), is perfectly clear and unambiguous, whereas
"integral expression", though gramatically co
2006/6/12, Niklaus <[EMAIL PROTECTED]>:
int main()
{
return 3;
}
i compiled it using sparc-elf-gcc -c test.c.
./sparc-elf-ld --entry=main test.o -o a.out
when i executed a.out on sparc machine it segfaulted and dumped core.
I guess 'cos you set entrypoint=main instead of __start or whatever it
2008/1/31, Manuel López-Ibáñez <[EMAIL PROTECTED]>:
> Nonetheless, if someone decided to go through the hassle of collecting
> tutorials and hints for various cross-compiling configurations in the
> wiki, I think many users will appreciate it. It is still considered by
> many to be a "dark art"[*].
2008/2/29, J.C. Pizarro <[EMAIL PROTECTED]>:
> Here are the results of benchmarks of 3 compressors: 7z, bzip2 and gzip, and
> GCCs 3.4.6, 4.1.3-20080225, 4.2.4-20080227, 4.3.0-20080228 & 4.4.0-20080222.
Thanks, that's very interesting. I had noticed 4.2 producing 10%
larger and 10% slower code fo
Ok, so we all have dozens of these EP93xx ARM SoCs on cheap boards,
with unusable floating point hardware.
What do we have to do to get the best-working GCC support for Maverick
Crunch FPU?
Suggest: make open-source project with objective:."to get the
best-working GCC support for Maverick Crunch
On 3/30/08, Brian Austin <[EMAIL PROTECTED]> wrote:
> I am now doing Linux ALSA/SoC work for our low power audio codecs.
Good luck, look forward to using them... :)
> I have been given the freedom with this new
> position to allow access to this machine for outside people to
> contribute whate
> The company I work for is about to release a board to PCB fab
> with a Cirrus part on it. If this is the case we may want to hold back on
> the
> release and switch ARM parts.
If it's the EP93xx, you'd be well-advised to do so; I gather there is
one similar competitor that doesn't waste sili
Hi!
I'm about to lower the gangplanks to get a native gnat on ARM EABI
through an unholy succession of cross-compilers, with the object of
getting gnat-4.1 4.2 and 4.3 into the new Debian port for ARM EABI.
The only arm-targetted gnat I could find is adacore's Windows
cross-compiler for xscale
Many thanks for the input.
On 5/2/08, Joel Sherrill <[EMAIL PROTECTED]> wrote:
> Do you mean the gcc target is arm-eabi?
As well as the host - I need to end up with a native Ada compiler
running on arm-linux-gnueabi.
On 5/1/08, Laurent GUERBY <[EMAIL PROTECTED]> wrote:
> > http://www.rtems.com/w
On 5/9/08, Paolo Bonzini <[EMAIL PROTECTED]> wrote:
> The idea is to use integer arithmetic to compute the right exponent, and
> the lookup table to estimate the mantissa. I used something like this for
> square root:
>
> 1) shift the entire FP number by 1 to the right (logical right shift)
> 2
On 9/26/08, Sergei Poselenov <[EMAIL PROTECTED]> wrote:
> Hello all,
>
> I've built the above cross-compiler and ran the GCC testsuite.
> Noted a lot of c++ tests failed with the same output:
> ...
> terminate called after throwing an instance of 'int'
> terminate called recursively
Are you c
41 matches
Mail list logo
