Consider the following code segment:
voidfoo( const char * const m[] );
char*bar( void );
voidbaz( void )
{
char*m[ 2 ];
m[ 0 ] = bar();
m[ 1 ] = bar();
foo( m );
}
gcc 8.2.0 (and 7.4.1 as well) with -Wall gives a warning, for Intel or
ARM target:
for inline
asm stuff. Maybe even write the info pages that describe them, so
that others can make use of them...
Thanks again,
Best Regards,
Zoltan
On Sun, 25 Jul 2021 14:19:56 +0200 (CEST)
Marc Glisse wrote:
> On Sun, 25 Jul 2021, Zoltán Kócsi wrote:
>
> > [...]
> > doub
I try to write a one-liner inline function to create a double form
a 64-bit integer, not converting it to a double but the integer
containing the bit pattern for the double (type spoofing).
The compiler is arm-eabi-gcc 8.2.0.
The target is a Cortex-A9, with NEON.
According to the info page the
Who'd be the best person to contact regarding to libgcc for ARM 4T, 6M and 7M
targets?
Thanks,
Zoltan
Now that the new C standard is out, is there any chance that gcc's behaviour
regarding to volatile lhs in an assignment changes?
This is what it does today:
volatile int a, b;
a = b = 0;
translates to
b = 0;
a = b;
because the standard (up to and including C99) stated that the value of
David Brown david.br...@hesbynett.no wrote:
Until gcc gets a feature allowing it to whack the programmer on the back
of the head with Knuth's The Art of Computer Programming for writing
such stupid code that relies on the behaviour of volatile a = b = 0;,
then a warning seems like a good
paul_kon...@dell.com wrote:
I would prefer this to generate a warning. The C language standard change
you refer to is a classic example of a misguided change, and any code whose
behavior depends on this deserves a warning message, NOT an option to work
one way or the other.
Sure. However, a
On Tue, 31 Jan 2012 00:38:15 +0100
Georg-Johann Lay a...@gjlay.de wrote:
A warning would be much of a help to write unambiguous, robust code.
So the question is rather why user refuses to write robust code in the
first place once there is a warning.
The user (me, in this case) does not
On Mon, 30 Jan 2012 19:51:47 -0600
Gabriel Dos Reis g...@integrable-solutions.net wrote:
On Mon, Jan 30, 2012 at 4:59 PM, Zoltán Kócsi zol...@bendor.com.au wrote:
David Brown david.br...@hesbynett.no wrote:
Until gcc gets a feature allowing it to whack the programmer on the back
I found something very strange, although it might be just a misunderstanding.
As far as I know, the IEEE-754 standard defines round-to-nearest, tie-to-even
as follows:
- For rounding purposes, the operation must be performed as if it were done
with infinite precision
- Then, if the bit right
On Thu, 27 Oct 2011 23:31:14 -0400
Robert Dewar de...@adacore.com wrote:
- I am missing a gcc flag
probably you should avoid extra precision and all the
issues it brings, as well as speed up your program, by
using SSE 64-bit arithmetic (using the appropriate gcc
flags)
Indeed. -mpc64
I came across some very interesting behavior regarding to built-in functions:
int __builtin_popcount( unsigned x ); is a gcc bult-in, which actually
returns the number of 1 bits in x.
int foo( unsigned x )
{
return __builtin_popcount( x );
}
generates a call to the __popcountsi2
If one writes a bit of code like this:
int foo( void )
{
register int x asm( Rn );
asm volatile ( INSN_A %0 \n\t : =r (x) );
bar();
asm volatile ( INSN_B %0,%0 \n\t : =r (x) : 0 (x) );
return x;
}
and Rn is a register not saved over function calls, then gcc does not save it
but allows
Am I doing something wrong or there's a problem with libgcc?
I'm compiling code for an ARM based micro. I'm using gcc 4.5.1,
configured for arm-eabi-none, C compiler only. The target is a
standalone embedded device, no OS, nothing, not even a C library, just
bare metal. The compiler (and linker,
On Thu, 16 Sep 2010 00:50:07 -0700
J Decker d3c...@gmail.com wrote:
[...]
int main(void)
{
void *(*func)(void **);
func;
strange that this does anything... since it also requires a pointer to
a pointer...
I think the compiler is right: func is a pointer to a function.
Since the
Is there a documentation of the various magic letters that you can
apply to an operand in inline assembly? What I mean is this:
asm volatile (
some_insn %X[operand] \n
: [operand] =r (expr)
);
What I look for is documentation of 'X'. In particular, when (expr) is
a multi-register object,
I wonder if there would be at least a theoretical support by the
developers to a proposal for volatile bitfields:
When a HW register (thus most likely declared as volatile) is defined as
a bitfield, as far as I know gcc treats each bitfield assignment as a
separate read-modify-write operation.
On the ARM every instruction can be executed conditionally. GCC very
cleverly uses this feature:
int bar ( int x, int a, int b )
{
if ( x )
return a;
else
return b;
}
compiles to:
bar:
cmp r0, #0 // test x
movne r0, r1 // retval = 'a'
Here it seems GCC is retaining the left hand side type of arr to be
array of 10 ints whereas on the right hand side
it has changed its type from array to pointer to integer. I tried
And rightly so.
searching the relevant sections in the standard ISO C
document number WG14/N1124 justifying
This question would be more appropriate for the mailing list
gcc-h...@gcc.gnu.org than for g...@gcc.gnu.org. Please take any
followups to gcc-help. Thanks.
Virtual tables will normally be placed in the .rodata section which
holds read-only data. All you should need to do it arrange for
On Mon, 16 Feb 2009 10:17:36 -0500
Daniel Jacobowitz d...@false.org wrote:
On Mon, Feb 16, 2009 at 12:19:52PM +0100, Vincent R. wrote:
00011000 WinMainCRTStartup:
[...]
Notice how many more registers used to be pushed? I expect the new
code is faster.
Assuming an ARM7 core with 0
On Thu, 5 Feb 2009 10:58:40 -0200
Alexandre Pereira Nunes alexandre.nu...@gmail.com wrote:
On Wed, Feb 4, 2009 at 11:05 PM, Zoltán Kócsi zol...@bendor.com.au
wrote: [cut]
If I compile the above with -O2 or -Os, then if the target is AVR or
x86_64 then the result is what I expected, func
I have various constants. If I define them in a header file like this:
static const int my_thing_a = 3;
static const int my_thing_b = 12345;
then everything is nice, if I use them the compiler knows their value
and uses them as literals and it doesn't actually put them into the
.rodata section
This sounds like a genuine bug in gcc, then. As far as I can see,
Andrew is right -- if the ARM hardware requires a legitimate object
to be placed at address zero, then a standard C compiler has to use
some other value for the null pointer.
I think changing that would cause more trouble than
On Thu, 29 Jan 2009 08:53:10 +
Andrew Haley a...@redhat.com wrote:
Erik Trulsson wrote:
On Wed, Jan 28, 2009 at 04:39:39PM +, Andrew Haley wrote:
6.3.2.3 Pointers
If a null pointer constant is converted to a pointer type, the
resulting pointer, called a null pointer, is
On Tue, 27 Jan 2009 07:08:51 -0500
Robert Dewar de...@adacore.com wrote:
James Dennett wrote:
I don't know how much work it would be to disable this optimization
in gcc.
To me, it is always troublesome to talk of disable this optimization
in a context like this. The program in question
No, this is since C90; nothing has changed in this area. NULL
doesn't mean address 0, it means nothing. The C statement
if (ptr)
doesn't mean if ptr does not point to address zero, it means if ptr
points to something.
A question then:
How can I make a pointer to point to the integer
On Wed, 21 Jan 2009 09:49:00 +
Richard Earnshaw rearn...@arm.com wrote:
[...]
No, this shouldn't be happening unless a) you are doing something
wrong; b) the options you are supplying to the compiler/linker are
suggesting some sort of stubs are necessary.
It was case a), an option
I have a question with regards to ARM interworking. The target is
ARM7TDMI-S, embedded system with no OS. The compiler is arm-elf-gcc,
4.3.1 with binutils maybe 3 months old.
It seems that when interworking is enabled then when a piece of THUMB
code calls an other piece of THUMB code in a
[...]
I have made a few optimized functions myself and published them as a
multi-platform library (www.agner.org/optimize/asmlib.zip). It is
faster than most other libraries on an Intel Core2 and up to ten
times faster than gcc using builtin functions. My library is
published with GPL
30 matches
Mail list logo
