Hi Kyrill,
you are right it's not easy to get its way among all those macros, my
main source of inspiration for ARM was the x86 implementation.
You can have a look at the ARM implementation to start with (on
gcc-patches, under review). That would be best not to diverge too much
aarch64 might hav
to clarify, my use case was slightly more different than the x86 that
requires a runtime cpu-check builtin. I was more focused on a link time
problem (so we don't even need to go thu a function ptr)
Christian
On 04/30/2015 08:45 AM, Christian Bruel wrote:
>
>
> On 04/29/2015 05
On 04/29/2015 05:36 PM, Ramana Radhakrishnan wrote:
>
>
> On 29/04/2015 09:24, Christian Bruel wrote:
>> Hi Ramana, Richard
>>
>> After playing with the attritute ((target ("[thumb,arm]")), during the
>> pending review, I added the "default
Hi Ramana, Richard
After playing with the attritute ((target ("[thumb,arm]")), during the
pending review, I added the "default" selector to neutralize
-mflip-thumb for the setjmp/longjmp based tests.
I was wondering it there would be an interest leverage on this to
implement multiprocessing, like
Hi Ramana,
any chance to get the attribute target support for ARM review in time
for stage 4 ?
Many thanks
Christian
On 01/08/2015 11:32 AM, Jakub Jelinek wrote:
The trunk is still in Stage 3 now, which means it is open for general
bugfixing, but will enter Stage 4 on Friday, 16th, end of d
On 05/11/2012 03:16 PM, Paulo J. Matos wrote:
> Hi,
>
> MULTILIB_OPTIONS containing options defined in DRIVER_SELF_SPEC seemed
> to be fine in GCC46 but fail in GCC47.
>
> For example, I have:
> xap.h:
> #define DRIVER_SELF_SPECS \
> "%{help:-v} % "%{mno-args-span-r
On 05/07/2012 03:11 PM, Christian Bruel wrote:
>
>
>> What about a generic name such as -fextension- (or both -fextension- and
>> -mextension-) for options that GCC itself will ignore, if -mbsp= is
>> considered inappropriate? I'd prefer that to delimiting
> What about a generic name such as -fextension- (or both -fextension- and
> -mextension-) for options that GCC itself will ignore, if -mbsp= is
> considered inappropriate? I'd prefer that to delimiting such options with
> --start-specs and --end-specs.
>
you mean, gcc would ignore options
> I think http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49858 is
> essentially this issue. It can probably be closed as "won't fix",
> though I notice the spec file format is still documented in the user
> manual.
>
> Peter
>
yes, same root problem, although BSP design is a different usage (yet
q
On 05/07/2012 12:09 PM, Joseph S. Myers wrote:
> On Mon, 7 May 2012, Christian Bruel wrote:
>
>> Making the driver aware about all possible user defined options seems
>> unpredictable. Was there any justification on removing this
>> functionality or did I miss a po
Hello,
There are a few EXTRA_SPECS rules that are used to custom target runtime
support. For instance, "ldruntime" is used on superh for board
configurations and dynamically support different runtime behaviors.
Illustration of this use with a silly reduced spec
*ldruntime:
+ %{mfoo: -lfoo}
The
On 11/13/2010 08:40 PM, Peter Bergner wrote:
On Sat, 2010-11-13 at 11:27 +0100, Paolo Bonzini wrote:
On 11/12/2010 03:25 PM, H.J. Lu wrote:
IRA may move instructions across an unspec_volatile,
Do you have a testcase?
Are you sure it's IRA and not our old friend update_equiv_regs()
which IRA
Joern Rennecke wrote:
Quoting Christian Bruel :
Using the ieee-sf.S + this patch
OK
Is this only a proof-of-concept, because you only change the ne[sd]f2
implementation?
I changed also the unordered comparison patterns. (cmpunsf_i1,
cmpundf_i1). But yes, the other functions that would
-run l.u ; echo $?
Original 4.6 fp-bit C model:
OK
Using the ieee-sf.S implementation:
FAIL
Using the ieee-sf.S + this patch
OK
same for sh4-linux.
Best Regards,
Christian
Christian Bruel wrote:
Christian Bruel wrote:
Hi Kaz,
Kaz Kojima wrote:
BTW, it looks that softfp __unord?f2
Joern Rennecke wrote:
Quoting Christian Bruel :
Edited to apply on top of latest Joern's patch. Certainly not optimal
but it fixes the QNaNs checks for builtins and inlined unordered
comparisons for -mieee or -fno-inite-math-only.
You are still on the wrong track; as I said in my ea
Christian Bruel wrote:
Hi Kaz,
Kaz Kojima wrote:
BTW, it looks that softfp __unord?f2 routines check signaling NaNs
only. This makes __builtin_isnan return false for quiet NaNs for
which current fp-bit ones return true when -mieee enabled. Perhaps
that change of behavior might be OK for
attached patch to handle the QNaNs in the assembly solf-fp.
Need to be updated for trunk (and update the dates in changelogs). Will do.
Cheers
Christian
2010-04-20 Christian Bruel
* gcc.dg/builtins-nan.c: New test.
2010-04-20 Christian Bruel
* config/sh/ieee-754-df.S
hello,
The documentation for -fno-branch-count-reg explains that a
dec-and-test-branch instruction is replaced by an equivalent sequence of
instruction that decrement a register, compare it against 0, and branch.
(see the use of the world *instead*)
This is not really true, since this option
Hello,
Looks like you are mixing ABIs. what is you fpscr setting ?
From my understanding, if the fpscr PR bit is set to 0 the 64-bit
operation behaves as 2 32 bit operations (paired single precision). so I
don't think you get an address error here.
The well defined behavior of the fmov instr
hello,
there is a difference between calling new and new (std::nothrow) from a
fno-exceptions context:
- new (std::nothrow) would return 0 in case of error
- new () would throw std::bad_alloc that would finish in
std::terminate() or abort()
so there is a possible difference in behavior if a
hello,
The example provided with the -fstrict-overflow description in the
http://gcc.gnu.org/gcc-4.2/changes.html page doesn't optimize as described.
Is it only a documentation bug ? The example is optimized as expected on
the trunk.
Regards,
-c
21 matches
Mail list logo
