On Fri, 22 Nov 2013, Andrew MacLeod wrote:
> The target hook patch is checked into mainline, revision 205273.
Thanks!
The target patch is there too now; tested with the previous
version of the hook-patch. I'm confident my autotester will
yell at me if I goofed.
gcc:
* config/cris/cris.c
On 11/21/2013 06:40 PM, Hans-Peter Nilsson wrote:
On Thu, 21 Nov 2013, Hans-Peter Nilsson wrote:
with this/these patches
at least I'll be able to tell people that _Atomic for C11 works.
Oh right, gcc still doesn't remove target-introduced "manual"
alignment checks (when expanding atomic intrins
On Thu, 21 Nov 2013, Hans-Peter Nilsson wrote:
> Oh right, gcc still doesn't remove target-introduced "manual"
> alignment checks (when expanding atomic intrinsics), but at
> least gcc makes sure it's aligned on stack, when options doesn't
> say it's aligned. And a.c:plugh2 doesn't seem to perfor
On Thu, 21 Nov 2013, Hans-Peter Nilsson wrote:
> with this/these patches
> at least I'll be able to tell people that _Atomic for C11 works.
Oh right, gcc still doesn't remove target-introduced "manual"
alignment checks (when expanding atomic intrinsics), but at
least gcc makes sure it's aligned on
On 11/21/2013 06:23 PM, Hans-Peter Nilsson wrote:
On Thu, 21 Nov 2013, Andrew MacLeod wrote:
I can bootstrap and check this on x86 to make sure it doesnt affect anything,
and you can fool with it and see if you can get your desired results with your
port.
Success!
For the record, tested togeth
On Thu, 21 Nov 2013, Andrew MacLeod wrote:
> I can bootstrap and check this on x86 to make sure it doesnt affect anything,
> and you can fool with it and see if you can get your desired results with your
> port.
Success!
For the record, tested together with the attached patch for the
CRIS ports,
On 11/21/2013 06:05 AM, Hans-Peter Nilsson wrote:
On Tue, 5 Nov 2013, Joseph S. Myers wrote:
Thanks for doing this! However, without examples I have trouble
reading out the bits I need as a target maintainer, and I can't
read out the answers from the patch, so pardon a few questions.
Support
On 11/21/2013 11:32 AM, Joseph S. Myers wrote:
On Thu, 21 Nov 2013, Andrew MacLeod wrote:
I'm trying to avoid ABI breakage of course. I'd rather not have
to ask people not to use _Atomic with 4.9 for CRIS ports using
official releases or have ABI breakage with the next release.
Maybe there's o
On Thu, 21 Nov 2013, Andrew MacLeod wrote:
> > I'm trying to avoid ABI breakage of course. I'd rather not have
> > to ask people not to use _Atomic with 4.9 for CRIS ports using
> > official releases or have ABI breakage with the next release.
> > Maybe there's one other port in the same situatio
On Thu, 21 Nov 2013, Andrew MacLeod wrote:
> > Or is that part also required for
> > anything-other-than-ordinary-C-type alignment for the target;
> > say, natural 4-byte alignment of 4-byte-types for targets where
> > alignment is otherwise "packed"; where only 1-byte alignment of
> > the basic ty
On Thu, 21 Nov 2013, Andrew MacLeod wrote:
> If we add the hook for atomic_align_for_mode, and change the initalizers in
> tree.c, any target which doesnt need/use the hook should be unaffected. So
> everything remains as it is today.
>
> So Putting the hook in shouldn't be an issue. Then you can
On 11/21/2013 10:20 AM, Hans-Peter Nilsson wrote:
On Thu, 21 Nov 2013, Andrew MacLeod wrote:
Or is that part also required for
anything-other-than-ordinary-C-type alignment for the target;
say, natural 4-byte alignment of 4-byte-types for targets where
alignment is otherwise "packed"; where only
On Tue, 5 Nov 2013, Joseph S. Myers wrote:
Thanks for doing this! However, without examples I have trouble
reading out the bits I need as a target maintainer, and I can't
read out the answers from the patch, so pardon a few questions.
> This patch, relative to trunk and based on work done on the
> I doubt the patch affects Fortran (there are language-independent changes,
> but they are fairly small and shouldn't affect code not using _Atomic
> qualifiers).
The Fortran failures seem related to revision 204538.
Dominique
On Fri, 8 Nov 2013, Dominique Dhumieres wrote:
> This revision may also causes the failures of
> gfortran.dg/typebound_operator_9.f03 and
> FAIL: gfortran.fortran-torture/execute/forall_1.f90.
I doubt the patch affects Fortran (there are language-independent changes,
but they are fairly small a
On Fri, 8 Nov 2013, Uros Bizjak wrote:
> Can we introduce a target-dependant source here, in the same way as
Sure, that seems a reasonable thing to do. I think putting a file fenv.c
in an appropriate subdirectory of libatomic/config will result in it being
found automatically by the existing s
The tests introduced in revision 204544 fail with -m32
(see http://gcc.gnu.org/ml/gcc-regression/2013-11/msg00213.html
or http://gcc.gnu.org/ml/gcc-testresults/2013-11/msg00526.html ).
This revision may also causes the failures of
gfortran.dg/typebound_operator_9.f03 and
FAIL: gfortran.fortran-tor
On Thu, Nov 7, 2013 at 7:26 PM, Joseph S. Myers wrote:
>> Please note that following code form fenv.c won't generate overflow
>> exception on x87:
>>
>> if (excepts & FP_EX_OVERFLOW)
>> {
>> volatile float max = __FLT_MAX__;
>> r = max * max;
>> }
>
> r being volatile is int
On Thu, 7 Nov 2013, Uros Bizjak wrote:
> However, this insn also raised FE_INEXACT flag (also on x86_64),
> probably not what you wanted. Your code that generates FE_UNDERFLOW
> will also raise FE_INEXACT. (and FE_DENORMAL).
If the compound assignment raised overflow or underflow, it will also ha
On Thu, Nov 7, 2013 at 9:55 PM, Uros Bizjak wrote:
>>> > I see code of the form (testing compilation rather than execution):
>>> >
>>> > flds4(%esp)
>>> > flds8(%esp)
>>> > fmulp %st, %st(1)
>>> > fstps 12(%esp)
>>> >
>>> > where the fstps should result
On Thu, Nov 7, 2013 at 9:33 PM, Joseph S. Myers wrote:
>> > I see code of the form (testing compilation rather than execution):
>> >
>> > flds4(%esp)
>> > flds8(%esp)
>> > fmulp %st, %st(1)
>> > fstps 12(%esp)
>> >
>> > where the fstps should result in
On Thu, 7 Nov 2013, Uros Bizjak wrote:
> > I see code of the form (testing compilation rather than execution):
> >
> > flds4(%esp)
> > flds8(%esp)
> > fmulp %st, %st(1)
> > fstps 12(%esp)
> >
> > where the fstps should result in the exception, and glibc
On Thu, 7 Nov 2013, Uros Bizjak wrote:
> [uros@localhost test]$ gcc -lm -g fpex.c
> [uros@localhost test]$ ./a.out
> Floating point exception (core dumped)
> [uros@localhost test]$ gcc -lm -g -m32 fpex.c
> [uros@localhost test]$ ./a.out
> [uros@localhost test]$
I see code of the form (testing com
On Thu, Nov 7, 2013 at 7:26 PM, Joseph S. Myers wrote:
> On Thu, 7 Nov 2013, Uros Bizjak wrote:
>
>> Please note that following code form fenv.c won't generate overflow
>> exception on x87:
>>
>> if (excepts & FP_EX_OVERFLOW)
>> {
>> volatile float max = __FLT_MAX__;
>> r = max *
On Thu, 7 Nov 2013, Uros Bizjak wrote:
> Please note that following code form fenv.c won't generate overflow
> exception on x87:
>
> if (excepts & FP_EX_OVERFLOW)
> {
> volatile float max = __FLT_MAX__;
> r = max * max;
> }
r being volatile is intended to ensure that the re
On Thu, Nov 7, 2013 at 5:45 PM, Jakub Jelinek wrote:
> On Tue, Nov 05, 2013 at 11:21:56PM +, Joseph S. Myers wrote:
>> 2013-11-05 Andrew MacLeod
>> Joseph Myers
>>
>> * tree-core.h (enum cv_qualifier): Add TYPE_QUAL_ATOMIC.
>> (enum tree_index): Add TI_ATOMICQI_TYPE,
On Tue, Nov 05, 2013 at 11:21:56PM +, Joseph S. Myers wrote:
> 2013-11-05 Andrew MacLeod
> Joseph Myers
>
> * tree-core.h (enum cv_qualifier): Add TYPE_QUAL_ATOMIC.
> (enum tree_index): Add TI_ATOMICQI_TYPE, TI_ATOMICHI_TYPE,
> TI_ATOMICSI_TYPE, TI_ATOMICDI_TYP
On Wed, Nov 6, 2013 at 12:21 AM, Joseph S. Myers
wrote:
> This patch, relative to trunk and based on work done on the C11-atomic
> branch, adds support for C11 _Atomic. It is intended to include all
> the required language support.
>
> It does not include the header; there's a version on the
> b
On 11/05/2013 06:21 PM, Joseph S. Myers wrote:
This patch, relative to trunk and based on work done on the C11-atomic
branch, adds support for C11 _Atomic. It is intended to include all
the required language support.
Thanks for picking this up Joseph... It would have taken me months to do
the
29 matches
Mail list logo
