Re: GCC libatomic ABI specification draft

[Gabriel Paubert]

On Thu, Dec 01, 2016 at 11:13:37AM -0800, Bin Fan at Work wrote:
> Hi Szabolcs,
> 
> > On Nov 29, 2016, at 3:11 AM, Szabolcs Nagy  wrote:
> > 
> > On 17/11/16 20:12, Bin Fan wrote:
> >> 
> >> Although this ABI specification specifies that 16-byte properly aligned 
> >> atomics are inlineable on platforms
> >> supporting cmpxchg16b, we document the caveats here for further 
> >> discussion. If we decide to change the
> >> inlineable attribute for those atomics, then this ABI, the compiler and 
> >> the runtime implementation should be
> >> updated together at the same time.
> >> 
> >> 
> >> The compiler and runtime need to check the availability of cmpxchg16b to 
> >> implement this ABI specification.
> >> Here is how it would work: The compiler can get the information either 
> >> from the compiler flags or by
> >> inquiring the hardware capabilities. When the information is not 
> >> available, the compiler should assume that
> >> cmpxchg16b instruction is not supported. The runtime library 
> >> implementation can also query the hardware
> >> compatibility and choose the implementation at runtime. Assuming the user 
> >> provides correct compiler options
> > 
> > with this abi the runtime implementation *must* query the hardware
> > (because there might be inlined cmpxchg16b in use in another module
> > on a hardware that supports it and the runtime must be able to sync
> > with it).
> 
> Thanks for the comment. Yes, the ABI requires libatomic must query the 
> hardware. This is 
> necessary if we want the compiler to generate inlined code for 16-byte 
> atomics. Note that 
> this particular issue only affects x86. 

Why? Power (at least recent ones) has 128 bit atomic instructions
(lqarx/stqcx.) and Z has 128 bit compare and swap. 

Gabriel

Re: [PING][RFC] Assertions as optimization hints

[Vincent Lefevre]

On 2016-11-28 18:49:55 +, Yuri Gribov wrote:
> On Mon, Nov 28, 2016 at 4:03 PM, Vincent Lefevre  
> wrote:
> > Concerning the "per-project decision", I'm not sure that's a good
> > idea: as soon as one includes a header file, __ASSUME_ASSERTS__
> > could potentially break code.
> 
> Sorry, not sure I understood. __ASSUME_ASSERTS__ is supplied via
> cmdline when compiling project's shared libraries and executables to
> treat assertions as hints (effectively similar to MS __assume
> directives). It does not propagate to project's public header files.

What I was thinking of is that header files can contain calls to
assert(), e.g. via macros or inlined function (or classes in C++). For
instance, I can see the use of assert() in the following header files:

  /usr/include/ncursesw/cursesf.h
  /usr/include/ncursesw/cursesm.h

So, if the behavior of assert() is globally changed for a project that
uses ncursesw, this is bad as this would affect ncursesw too. Now, if
__ASSUME_ASSERTS__ does not propagate to "external" header files,
that's fine. But I wonder how this is implemented, i.e. to know which
header files should be affected which of them shouldn't, and how macro
definitions are affected, so that macros are expanded with the
expected behavior. This doesn't seem to be simple.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

compile template question

[chenzero]

Hello,

I have following code,

in gcc 4.8.4, the code can NOT compile, because of an error:
error: need ‘typename’ before ‘std::map::iterator’ because 
‘std::map’ is a dependent scope


however, I can compile the same code in other C++ compiler(borland c++),

whether there are some differences between gcc template syntax?

Thank you very much!

c.z.


// code
//---

#include 

#include 
#include 
using namespace std;

/**
 * get all keys of the map into vector
 */
template
static void getKeySet(std::map& m, std::vector& ks) {
std::map::iterator iter = m.begin();
for(iter=m.begin();iter!=m.end();iter++) {
ks.push_back(iter->first);
}
}

int main() {
map m1;
//m1[1] = 1;
vector ks;
getKeySet(m1, ks);
printf("key size: %d\n", ks.size());
return 0;
}

Re: compile template question

[Nathan Sidwell]

On 12/02/2016 07:12 AM, chenzero wrote:

Hello,

I have following code,

in gcc 4.8.4, the code can NOT compile, because of an error:
error: need ‘typename’ before ‘std::map::iterator’ because
‘std::map’ is a dependent scope

however, I can compile the same code in other C++ compiler(borland c++),

whether there are some differences between gcc template syntax?


Your code requires the typename. See 14.6.2 of the std for reasons.

nathan

--
Nathan Sidwell

Re: compile template question

[Jonathan Wakely]

N.B. This has already been answered on gcc-help, where it belongs.
Sorry for not updating this list to say so.

I've also now added this topic to the isocpp.org FAQ:
https://isocpp.org/wiki/faq/templates#dependent-name-lookup-types

On 2 December 2016 at 12:12, chenzero wrote:
> Hello,
>
> I have following code,
>
> in gcc 4.8.4, the code can NOT compile, because of an error:
> error: need ‘typename’ before ‘std::map::iterator’ because
> ‘std::map’ is a dependent scope
>
> however, I can compile the same code in other C++ compiler(borland c++),
>
> whether there are some differences between gcc template syntax?
>
> Thank you very much!
>
> c.z.
>
>
> // code
> //---
>
> #include 
>
> #include 
> #include 
> using namespace std;
>
> /**
>  * get all keys of the map into vector
>  */
> template
> static void getKeySet(std::map& m, std::vector& ks) {
> std::map::iterator iter = m.begin();
> for(iter=m.begin();iter!=m.end();iter++) {
> ks.push_back(iter->first);
> }
> }
>
> int main() {
> map m1;
> //m1[1] = 1;
> vector ks;
> getKeySet(m1, ks);
> printf("key size: %d\n", ks.size());
> return 0;
> }
>
>
>

arm.c bug in handling of TARGET_ASM_INIT_SECTIONS

[Jeff Law]

Trying to build arm-netbsdelf:

g++ -fno-PIE -c   -g -O2 -DIN_GCC  -DCROSS_DIRECTORY_STRUCTURE 
-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall 
-Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute 
-Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros 
-Wno-overlength-strings -Werror -fno-common  -DHAVE_CONFIG_H -I. -I. 
-I/home/cygnus/law/gcc-testing/gcc/gcc 
-I/home/cygnus/law/gcc-testing/gcc/gcc/. 
-I/home/cygnus/law/gcc-testing/gcc/gcc/../include 
-I/home/cygnus/law/gcc-testing/gcc/gcc/../libcpp/include 
-I/opt/cfarm/mpc/include 
-I/home/cygnus/law/gcc-testing/gcc/gcc/../libdecnumber 
-I/home/cygnus/law/gcc-testing/gcc/gcc/../libdecnumber/dpd 
-I../libdecnumber -I/home/cygnus/law/gcc-testing/gcc/gcc/../libbacktrace 
  -o arm.o -MT arm.o -MMD -MP -MF ./.deps/arm.TPo 
/home/cygnus/law/gcc-testing/gcc/gcc/config/arm/arm.c
/home/cygnus/law/gcc-testing/gcc/gcc/config/arm/arm.c:600:0: error: 
"TARGET_ASM_INIT_SECTIONS" redefined [-Werror]

 #define TARGET_ASM_INIT_SECTIONS arm_asm_init_sections

In file included from 
/home/cygnus/law/gcc-testing/gcc/gcc/target-def.h:106:0,
 from 
/home/cygnus/law/gcc-testing/gcc/gcc/config/arm/arm.c:69:
./target-hooks-def.h:86:0: note: this is the location of the previous 
definition

 #define TARGET_ASM_INIT_SECTIONS hook_void_void


It's referring to this section of code.  Note the placement of the 
#endif.  Looks weird, not sure if it's in the right place, should be a 
line earlier or a line later:


#if ARM_UNWIND_INFO
#undef TARGET_ASM_UNWIND_EMIT
#define TARGET_ASM_UNWIND_EMIT arm_unwind_emit

/* EABI unwinding tables use a different format for the typeinfo tables.  */
#undef TARGET_ASM_TTYPE
#define TARGET_ASM_TTYPE arm_output_ttype

#undef TARGET_ARM_EABI_UNWINDER
#define TARGET_ARM_EABI_UNWINDER true

#undef TARGET_ASM_EMIT_EXCEPT_PERSONALITY
#define TARGET_ASM_EMIT_EXCEPT_PERSONALITY arm_asm_emit_except_personality

#undef TARGET_ASM_INIT_SECTIONS
#endif /* ARM_UNWIND_INFO */
#define TARGET_ASM_INIT_SECTIONS arm_asm_init_sections