libstdc++ test case ext/headers.cc failed on arm-none-eabi
Hi, I spotted case ext/headers.cc failed on arm-none-eabi with below information: In file included from /home/build/work/gcc-build/arm-none-eabi/armv7-m/libstdc++-v3/include/arm-none-eabi/bits/gthr.h:148:0, from /home/build/work/gcc-build/arm-none-eabi/armv7-m/libstdc++-v3/include/ext/atomicity.h:33, from /home/build/work/src/gcc/libstdc++-v3/testsuite/ext/headers.cc:28: /home/build/work/gcc-build/arm-none-eabi/armv7-m/libstdc++-v3/include/arm-none-eabi/bits/gthr-default.h:37:30: warning: non-static data member initializers only available with -std=c++11 or -std=gnu++11 [enabled by default] #define __GTHREAD_MUTEX_INIT 0 ^ /home/build/work/gcc-build/arm-none-eabi/armv7-m/libstdc++-v3/include/arm-none-eabi/bits/gthr-default.h:37:30: warning: non-static data member initializers only available with -std=c++11 or -std=gnu++11 [enabled by default] #define __GTHREAD_MUTEX_INIT 0 ^ output is: In file included from /home/build/work/gcc-build/arm-none-eabi/armv7-m/libstdc++-v3/include/arm-none-eabi/bits/gthr.h:148:0, from /home/build/work/gcc-build/arm-none-eabi/armv7-m/libstdc++-v3/include/ext/atomicity.h:33, from /home/build/work/src/gcc/libstdc++-v3/testsuite/ext/headers.cc:28: /home/build/work/gcc-build/arm-none-eabi/armv7-m/libstdc++-v3/include/arm-none-eabi/bits/gthr-default.h:37:30: warning: non-static data member initializers only available with -std=c++11 or -std=gnu++11 [enabled by default] #define __GTHREAD_MUTEX_INIT 0 ^ /home/build/work/gcc-build/arm-none-eabi/armv7-m/libstdc++-v3/include/arm-none-eabi/bits/gthr-default.h:37:30: warning: non-static data member initializers only available with -std=c++11 or -std=gnu++11 [enabled by default] #define __GTHREAD_MUTEX_INIT 0 ^ FAIL: ext/headers.cc (test for excess errors) Excess errors: /home/build/work/gcc-build/arm-none-eabi/armv7-m/libstdc++-v3/include/arm-none-eabi/bits/gthr-default.h:37:30: warning: non-static data member initializers only available with -std=c++11 or -std=gnu++11 [enabled by default] /home/build/work/gcc-build/arm-none-eabi/armv7-m/libstdc++-v3/include/arm-none-eabi/bits/gthr-default.h:37:30: warning: non-static data member initializers only available with -std=c++11 or -std=gnu++11 [enabled by default] The cases failed both on trunk and 4.8, but ok for 4.7. Any ideas? Thanks. -- Best Regards.
Re: libstdc++ test case ext/headers.cc failed on arm-none-eabi
The same error occurs on AIX because the tests are run without pthreads. - David On Wed, Aug 7, 2013 at 6:22 AM, Bin.Cheng wrote: > Hi, > I spotted case ext/headers.cc failed on arm-none-eabi with below information: > > In file included from > /home/build/work/gcc-build/arm-none-eabi/armv7-m/libstdc++-v3/include/arm-none-eabi/bits/gthr.h:148:0, > from > /home/build/work/gcc-build/arm-none-eabi/armv7-m/libstdc++-v3/include/ext/atomicity.h:33, > from > /home/build/work/src/gcc/libstdc++-v3/testsuite/ext/headers.cc:28: > /home/build/work/gcc-build/arm-none-eabi/armv7-m/libstdc++-v3/include/arm-none-eabi/bits/gthr-default.h:37:30: > warning: non-static data member initializers only available with > -std=c++11 or -std=gnu++11 [enabled by default] > #define __GTHREAD_MUTEX_INIT 0 > ^ > /home/build/work/gcc-build/arm-none-eabi/armv7-m/libstdc++-v3/include/arm-none-eabi/bits/gthr-default.h:37:30: > warning: non-static data member initializers only available with > -std=c++11 or -std=gnu++11 [enabled by default] > #define __GTHREAD_MUTEX_INIT 0 > ^ > output is: > In file included from > /home/build/work/gcc-build/arm-none-eabi/armv7-m/libstdc++-v3/include/arm-none-eabi/bits/gthr.h:148:0, > from > /home/build/work/gcc-build/arm-none-eabi/armv7-m/libstdc++-v3/include/ext/atomicity.h:33, > from > /home/build/work/src/gcc/libstdc++-v3/testsuite/ext/headers.cc:28: > /home/build/work/gcc-build/arm-none-eabi/armv7-m/libstdc++-v3/include/arm-none-eabi/bits/gthr-default.h:37:30: > warning: non-static data member initializers only available with > -std=c++11 or -std=gnu++11 [enabled by default] > #define __GTHREAD_MUTEX_INIT 0 > ^ > /home/build/work/gcc-build/arm-none-eabi/armv7-m/libstdc++-v3/include/arm-none-eabi/bits/gthr-default.h:37:30: > warning: non-static data member initializers only available with > -std=c++11 or -std=gnu++11 [enabled by default] > #define __GTHREAD_MUTEX_INIT 0 > ^ > > FAIL: ext/headers.cc (test for excess errors) > Excess errors: > /home/build/work/gcc-build/arm-none-eabi/armv7-m/libstdc++-v3/include/arm-none-eabi/bits/gthr-default.h:37:30: > warning: non-static data member initializers only available with > -std=c++11 or -std=gnu++11 [enabled by default] > /home/build/work/gcc-build/arm-none-eabi/armv7-m/libstdc++-v3/include/arm-none-eabi/bits/gthr-default.h:37:30: > warning: non-static data member initializers only available with > -std=c++11 or -std=gnu++11 [enabled by default] > > The cases failed both on trunk and 4.8, but ok for 4.7. > > Any ideas? Thanks. > > > -- > Best Regards.
Re: libstdc++ test case ext/headers.cc failed on arm-none-eabi
On 7 August 2013 14:10, David Edelsohn wrote: > The same error occurs on AIX because the tests are run without pthreads. We moved the thread to the libstdc++ list, where I pointed out that is missing the "#pragma GCC system_header" that would suppress the warnings.
Re: [RFC] gcc feature request: Moving blocks into sections
On Wed, 2013-08-07 at 07:06 +0200, Ondřej Bílka wrote: > Add short_counter,long_counter and before increment counter before each > jump. That way we will know how many short/long jumps were taken. That's not trivial at all. The jump is a single location (in an asm goto() statement) that happens to be inlined through out the kernel. The assembler decides if it will be a short or long jump. How do you add a counter to count the difference? The output I gave is from the boot up code that converts the jmp back to a nop (or in this case, the default nop to the ideal nop). It knows the size by reading the op code. This is a static analysis, not a running one. It's no trivial task to have a counter for each jump. There is a way though. If we enable all the jumps (all tracepoints, and other users of jumplabel), record the trace and then compare the trace to the output that shows which ones were short jumps, and all others are long jumps. I'll post the patches soon and you can have fun doing the compare :-) Actually, I'm working on the 4 patches of the series that is more about clean ups and safety checks than the jmp conversion. That is not controversial, and I'll be posting them for 3.12 soon. After that, I'll post the updated patches that have the conversion as well as the counter, for RFC and for others to play with. -- Steve
Re: [RFC] gcc feature request: Moving blocks into sections
* Steven Rostedt (rost...@goodmis.org) wrote: > On Wed, 2013-08-07 at 07:06 +0200, Ondřej Bílka wrote: > > > Add short_counter,long_counter and before increment counter before each > > jump. That way we will know how many short/long jumps were taken. > > That's not trivial at all. The jump is a single location (in an asm > goto() statement) that happens to be inlined through out the kernel. The > assembler decides if it will be a short or long jump. How do you add a > counter to count the difference? You might want to try creating a global array of counters (accessible both from C for printout and assembly for update). Index the array from assembly using: (2f - 1f) 1: jmp ...; 2: And put an atomic increment of the counter. This increment instruction should be located prior to the jmp for obvious reasons. You'll end up with the sums you're looking for at indexes 2 and 5 of the array. Thanks, Mathieu > > The output I gave is from the boot up code that converts the jmp back to > a nop (or in this case, the default nop to the ideal nop). It knows the > size by reading the op code. This is a static analysis, not a running > one. It's no trivial task to have a counter for each jump. > > There is a way though. If we enable all the jumps (all tracepoints, and > other users of jumplabel), record the trace and then compare the trace > to the output that shows which ones were short jumps, and all others are > long jumps. > > I'll post the patches soon and you can have fun doing the compare :-) > > Actually, I'm working on the 4 patches of the series that is more about > clean ups and safety checks than the jmp conversion. That is not > controversial, and I'll be posting them for 3.12 soon. > > After that, I'll post the updated patches that have the conversion as > well as the counter, for RFC and for others to play with. > > -- Steve > > -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com
Re: [RFC] gcc feature request: Moving blocks into sections
On Wed, 2013-08-07 at 12:03 -0400, Mathieu Desnoyers wrote: > You might want to try creating a global array of counters (accessible > both from C for printout and assembly for update). > > Index the array from assembly using: (2f - 1f) > > 1: > jmp ...; > 2: > > And put an atomic increment of the counter. This increment instruction > should be located prior to the jmp for obvious reasons. > > You'll end up with the sums you're looking for at indexes 2 and 5 of the > array. After I post the patches, feel free to knock yourself out. -- Steve
Распродажа реплик Vertu по бросовым ценам
В связи с ликвидацией склада предлагаю телефоны Верту в розницу и оптом. Скажите, есть ли у Вас интерес в приобретении телефонов?
Re: Pointer arithmetic
On Tue, 2013-07-09 at 09:37 -0700, Hendrik Greving wrote: > On a machine with ABI ILP32LL64: > > (insn 123 122 124 (nil) (set (reg:SI 392) > (mem:SI (plus:SI (reg/v:SI 386) > (reg/v:SI 349)) [0 sec 0 space 0, cmsmode 0 S4 A32])) -1 (nil) > (nil)) > > If we support legitimate memory addresses like [r1+r2] (e.g. indexed > addresses), can the above RTL match such a load? On 32 bit address machines it should match. > I am asking because > of overflows, I am not sure how that part is defined, and where the > Spec is. What do I need to check in the backend for such a definition? > Is this POINTER_SIZE? E.g. what if the machine supports > 32 bits, who > is responsible to make sure that there is no overflow > 32 bits in > this case? Compiler? Assembler? Or even the user? AFAIK overflow is undefined and thus anything can happen. Induction variable and loop optimizations may produce interesting things if addresses overflow. For example, see http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55190 Cheers, Oleg
Re: Pointer arithmetic
Yes I guess otherwise you could never produce a complex address like that. Actually I think I remember that day that I found that C explicitly leaves it undefined and to the machine. Thanks Hendrik On Wed, Aug 7, 2013 at 1:40 PM, Oleg Endo wrote: > On Tue, 2013-07-09 at 09:37 -0700, Hendrik Greving wrote: >> On a machine with ABI ILP32LL64: >> >> (insn 123 122 124 (nil) (set (reg:SI 392) >> (mem:SI (plus:SI (reg/v:SI 386) >> (reg/v:SI 349)) [0 sec 0 space 0, cmsmode 0 S4 A32])) -1 >> (nil) >> (nil)) >> >> If we support legitimate memory addresses like [r1+r2] (e.g. indexed >> addresses), can the above RTL match such a load? > > On 32 bit address machines it should match. > >> I am asking because >> of overflows, I am not sure how that part is defined, and where the >> Spec is. What do I need to check in the backend for such a definition? >> Is this POINTER_SIZE? E.g. what if the machine supports > 32 bits, who >> is responsible to make sure that there is no overflow > 32 bits in >> this case? Compiler? Assembler? Or even the user? > > AFAIK overflow is undefined and thus anything can happen. Induction > variable and loop optimizations may produce interesting things if > addresses overflow. For example, see > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55190 > > Cheers, > Oleg >
Re: [x86-64 psABI] RFC: Extend x86-64 PLT entry to support MPX
Here is the proposal to add Tag_GNU_X86_EXTERN_BRANCH and
NT_X86_FEATURE_PLT_BND. Any comments?
--
H.J.
---
Intel MPX:
http://software.intel.com/sites/default/files/319433-015.pdf
introduces 4 bound registers, which will be used for parameter passing
in x86-64. Bound registers are cleared by branch instructions. Branch
instructions with BND prefix will keep bound register contents. This leads
to 2 requirements to 64-bit MPX run-time:
1. Dynamic linker (ld.so) should save and restore bound registers during
symbol lookup.
2. Extend the current 16-byte PLT entry:
ff 25 00 00 00 00jmpq *name@GOTPCREL(%rip)
68 00 00 00 00 pushq $index
e9 00 00 00 00 jmpq PLT0
which clears bound registers, to 32-byte to add BND prefix to branch
instructions:
f2 ff 25 00 00 00 00bnd jmpq *name@GOTPCREL(%rip)
68 00 00 00 00pushq $index
f2 e9 00 00 00 00 bfd jmpq PLT0
0f 1f 80 00 00 00 00nopl 0(%rax)
0f 1f 80 00 00 00 00nopl 0(%rax)
We use the .gnu_attribute directive to record an object attribute:
enum
{
Tag_GNU_X86_EXTERN_BRANCH = 4,
};
for the types of external branch instructions in relocatable files.
enum
{
/* All external branch instructions are legacy. */
Val_GNU_X86_EXTERN_BRANCH_LEGACY = 0,
/* There is at lease one external branch instruction with BND prefix. */
Val_GNU_X86_EXTERN_BRANCH_BND = 1,
};
An x86 feature note section, .note.x86-feature, is used to indicate
features in executables and shared library. The contents of this note
section are:
.section.note.x86-feature
.align 4
.long .L1 - .L0
.long .L3 - .L2
.long 1
.L0:
.asciz "x86 feature"
.L1:
.align 4
.L2:
.longFeatureFlag (Feature flag)
.L3:
The current valid bits in FeatureFlag are
#define NT_X86_FEATURE_PLT_BND(0x1 << 0)
It should be set if PLT entry has BND prefix to preserve bound registers.
The remaining bits in FeatureFlag are reserved.
When merging Tag_GNU_X86_EXTERN_BRANCH, if any input relocatable
file has Tag_GNU_X86_EXTERN_BRANCH set to Val_GNU_X86_EXTERN_BRANCH_BND,
the resulting Tag_GNU_X86_EXTERN_BRANCH value should be
Val_GNU_X86_EXTERN_BRANCH_BND.
When generating executable or shared library, if PLT is needed and
Tag_GNU_X86_EXTERN_BRANCH value is Val_GNU_X86_EXTERN_BRANCH_BND,
the 32-byte PLT entry should be used and the feature note section should
be generated with the NT_X86_FEATURE_PLT_BND bit set to 1 and the feature
note section should be included in PT_NOTE segment. The benefit of the
note section is it is backward compatible with existing run-time and tools.
