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 correct, hits
On 6/27/10, Gerald Pfeifer ger...@pfeifer.com 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
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/8/10, NightStrike nightstr...@gmail.com 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
On 6/7/10, NightStrike nightstr...@gmail.com wrote:
On Wed, Jun 2, 2010 at 3:17 PM, Diego Novillo dnovi...@google.com wrote:
On Wed, Jun 2, 2010 at 14:09, NightStrike nightstr...@gmail.com wrote:
threads that haven't been addressed. I offered to Ian to do the same
thing for the whole
On 4/25/10, Ian Lance Taylor i...@google.com wrote:
Martin Guy martinw...@gmail.com 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 patches in all and I
On 5/24/10, Mark Mitchell m...@codesourcery.com 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
On 5/7/10, Shaun Pinney shaun.pin...@bil.konicaminolta.us 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
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
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
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 might
On 2/21/10, Dave Korn dave.korn.cyg...@googlemail.com 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.
On 2/21/10, Steven Bosscher stevenb@gmail.com 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
On 2/21/10, Dave Korn dave.korn.cyg...@googlemail.com 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
On 2/21/10, Dave Korn dave.korn.cyg...@googlemail.com 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
On 2/12/10, Richard Guenther richard.guent...@gmail.com wrote:
On Fri, Feb 12, 2010 at 10:41 AM, Jakub Jelinek ja...@redhat.com 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
On 1/16/10, David Edelsohn dje@gmail.com 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
On 12/22/09, Daniel Jacobowitz d...@false.org 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
On 12/22/09, Daniel Jacobowitz d...@false.org 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.
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
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
On 8/12/09, Matthias Klose d...@debian.org 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-compiler hosted
On 8/12/09, Joel Sherrill joel.sherr...@oarcorp.com 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
On 7/24/09, Uros Bizjak ubiz...@gmail.com 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
On 6/5/09, Graham Reitz grahamre...@gmail.com 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
On 3/14/09, Paolo Bonzini bonz...@gnu.org 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
On 3/16/09, Paolo Bonzini bonz...@gnu.org 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
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
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
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 (eg, for a
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
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) sum
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:
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
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 silicon
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 whatever
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 for a
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[*].
The
39 matches
Mail list logo
