why C++ cannot alias an inline function, C can ?

2018-04-01 Thread Jason Vas Dias 
Good day -

I'm trying to understand why this code compiles fine
in  'gcc   -std=gnu11' mode, but not in
 'g++  -std=g++11' mode
(so far tried with gcc/g++ 5.4.0 , 7.3.1 on x86_64 linux) :

'
 static inline __attribute__((always_inline))
 void foo(void){}

 static inline __attribute__((always_inline,alias("foo")))
 void bar(void);

 static
 void f(void) { foo(); }
 // must have a usage to generate any code
 '

In C mode , no problems - I can invoke foo() or bar() to
reference the same inline, and it is always inlined .

In C++ however, it does not compile :

  $ g++ -g -std=gnu++11 -x c++ -c t.c
t.c:5:8: error: 'void bar()' aliased to undefined symbol 'foo'
   void bar(void);
^

Even though, if I compile the object with the declaration
of bar() commented out , I can see C++ is not mangling
the name "foo" :

$ objdump -g t.o

t.o: file format elf64-x86-64

Contents of the .debug_info section:

  Compilation Unit @ offset 0x0:
   Length:0x4d (32-bit)
   Version:   4
   Abbrev Offset: 0x0
   Pointer Size:  8
 <0>: Abbrev Number: 1 (DW_TAG_compile_unit)
   DW_AT_producer: (indirect string, offset: 0x0): GNU
C++11 5.4.0 -mtune=haswell -march=x86-64 -g -std=gnu++11
<10>   DW_AT_language: 4(C++)
<11>   DW_AT_name: t.c
<15>   DW_AT_comp_dir: (indirect string, offset: 0x43): /tmp
<19>   DW_AT_low_pc  : 0x0
<21>   DW_AT_high_pc : 0x7
<29>   DW_AT_stmt_list   : 0x0
 <1><2d>: Abbrev Number: 2 (DW_TAG_subprogram)
<2e>   DW_AT_name: foo
<32>   DW_AT_decl_file   : 1
<33>   DW_AT_decl_line   : 2
<34>   DW_AT_inline  : 3(declared as inline and inlined)
 <1><35>: Abbrev Number: 3 (DW_TAG_subprogram)
<36>   DW_AT_external: 1
<36>   DW_AT_name: f
<38>   DW_AT_decl_file   : 1
<39>   DW_AT_decl_line   : 10
<3a>   DW_AT_linkage_name: (indirect string, offset: 0x3d): _Z1fv
<3e>   DW_AT_low_pc  : 0x0
<46>   DW_AT_high_pc : 0x7
<4e>   DW_AT_frame_base  : 1 byte block: 9c (DW_OP_call_frame_cfa)
<50>   DW_AT_GNU_all_call_sites: 1
 <1><50>: Abbrev Number: 0

So there is a symbol "foo" declared, even though it is only a debug symbol .

Why does C++ not let me alias it ?  There appears to be no mangled name
for it .

And even worse, the obvious workaround does not work:

'
static inline __attribute__((always_inline))
void foo(void) {}

//  static inline __attribute__((always_inline, alias("foo")))
//  void bar(void);

static inline __attribute__((always_inline))
void (&bar)(void) = foo;

   void f(void)
   { bar();
   }
'
Fails to compile with:

t.c:8:19: error: 'bar' declared as an 'inline' variable
   void (&bar)(void) = foo;


So one has to do just
static
void (&bar) ( void ) = foo;

So now foo() has lost its inline-ness:

$ nm -C t.o
0007 T f()
 r bar
 t foo()

ie. the compiler did not warn that foo
has been made into an ordinary symbol:

'
$ cat t.c
static inline __attribute__((always_inline))
void foo(void) {}
static
void (&bar)(void) = foo;
void f(void){ bar();}
$ g++ -std=gnu++11 -x c++ -Wall -Wextra -c t.c
$
 '
I think g++ should have warned that it is not treating
an always inline function as inline here !

This problem is causing me grief in more real-world scenarios -
any advice on how to create an alias that is inline-able in C++
would be much appreciated.

Thanks & Best Regards,
Jason

Re: why C++ cannot alias an inline function, C can ?

2018-04-01 Thread Jason Vas Dias 
On 01/04/2018, Max Filippov  wrote:
> On Sun, Apr 1, 2018 at 4:34 AM, Jason Vas Dias 
> wrote:
>> In C++ however, it does not compile :
>>
>>   $ g++ -g -std=gnu++11 -x c++ -c t.c
>> t.c:5:8: error: 'void bar()' aliased to undefined symbol 'foo'
>>void bar(void);
>> ^
>>
>> Even though, if I compile the object with the declaration
>> of bar() commented out , I can see C++ is not mangling
>> the name "foo" :
>


> gcc manual says the follwing about the alias attribute:
>  "In C++, the mangled name for the target must be used."
>
> so with the following modification your example compiles:
>
>  static inline __attribute__((always_inline,alias("_ZL3foov")))
>  void bar(void);
>
> --
> Thanks.
> -- Max
>


Aha!  But how to determine the mangled name beforehand ?

Even if I compile the object without the alias, then inspect
the object with objdump, there is no mangled symbol
_ZL3foov defined in the object file .

So I have to form the mangled name string beforehand,
even for symbols for which there is no linkage ?

ie. there should never be any symbol table entry for 'foo' -
only in the debuginfo there will be information about it .

So I must run some name mangler /  generator as a
pre-processing step to get the correct mangled name
string ?

Like, if I compile just :

static inline __attribute__((always_inline))
void foo(void) {}
void f(void)
{ foo();
}

Then both
   $ nm -a t.o | grep  ZL3foov
 and
   $ objdump -t t.o | grep ZL3foov
 and
   $ objdump -g t.o | grep ZL3foov

produce no output. So how does one determine that mangled name
a-priori ? There seems to be no way of getting cpp to do it, anyway ,
which is what it would have to do to be an acceptable solution -
there must be a string literal constant argument to '__attribute__(alias()))'.

I think some kind of new pragma is needed , to allow one to say
something like:

#define _S(_X) #X
#define QUOTED_STRING(_X) _S(_X)

static inline __attribute__((always_inline, alias(
QUOTED_STRING(
#pragma symbol_name(foo)
// insert mangled symbol name here
)
)));

I'm going to investigate patching GCC to support
something like that.

I think it is unacceptable to be forced to used
mangled symbol names for objects which are
not symbols (pure inline functions) .

Thanks & Regards,
Jason

))
 void bar(void) ;

bug ? : -Wpedantic -Wconversion 'short a=1; a-=1;' complaint

2018-04-23 Thread Jason Vas Dias 

I really do not think a '-Wpedantic -Wconversion' warning should
be generated for the following code, but it is
(with GCC 6.4.1 and 7.3.1 on RHEL-7.5 Linux) :

 $ echo '
 typedef unsigned short U16_t;
 static void f(void)
 { U16_t a = 1;
   a-=1;
 }' > t.C;

 $ g++ -std=c++14 -Wall -Wextra -pedantic -Wc++11-compat \
   -Wconversion -Wcast-align -Wcast-qual -Wfloat-equal \
   -Wmissing-declarations -Wlogical-op -Wpacked -Wundef \
   -Wuninitialized -Wvariadic-macros -Wwrite-strings \
   -c t.C -o /dev/null
 t.C:4:8: conversion to 'U16_t' {aka short unsigned int} from 'int' may \
  alter its value.

I don't control the warning flags, as shown above,
that my code must compile against without warnings.

But I think the warning issued above is a GCC bug -
when I look at the code generated, (compile with -S -o t.S),
I see it actually does generate a 16-bit subtraction, which
is what I wanted:

.file   "t.C"
.text
.globl  _Z1fv
.type   _Z1fv, @function
_Z1fv:
.LFB0:
.cfi_startproc
pushq   %rbp
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
movq%rsp, %rbp
.cfi_def_cfa_register 6
movw$1, -2(%rbp)
subw$1, -2(%rbp)
#    this is a two-byte word subtract
nop
popq%rbp
.cfi_def_cfa 7, 8
ret
.cfi_endproc
.LFE0:
.size   _Z1fv, .-_Z1fv
.ident  "GCC: (GNU) 6.4.1 20180321"
.section.note.GNU-stack,"",@progbits



So why is it generating a warning about conversion from 'int' ?

I don't see any conversion going on in assembler output -
(cast 'a' to a temporary int, do 32-bit integer subtraction of  '1'
 from it, and store sign-extended low 16 bits in 'a' - this is NOT
 what is going on here ) .

I'd like to remove either '-pedantic' or '-Wconversion' from the
warning flags, but this is not an option .

Please can GCC fix this warning bug eventually - I have to wade
through code that generates thousands of them per compilation.

Thanks & Best Regards,
Jason

gcc-6-branch test failures: g++ c-c++-common/asan/pr59063-2.c

2018-05-21 Thread Jason Vas Dias 

Good day -

Attempts to build latest GCC gcc-6-branch version from SVN ( Revision
260441 ), with the GCC 6.4.1 from the last time I built it ( git
commit starting '4f2cbe2' ), now fail in 'make check' , on a Linux
x86_64 host (RHEL 7.5, glibc 2.17) :

When 'pr59063-2.c' is built with the '-static-libasan' option and
WITHOUT any '-lasan' option being the first DT_NEEDED shared library,
(ie. being the FIRST -l option)
then the program produced emits the message:
'==$pid==ASan runtime does not come first in initial library list; \
 you should either link runtime to your application or manually preload \
 it with LD_PRELOAD.
' .

Then all tests that run that program fail.

So, if I modify gcc/testsuite/lib/asan-dg.exp to add '-lasan' as the
first '-l' argument, OR I set libasan to be preloaded, the program loads,
but coredumps, as shown in this gdb session:

Reading symbols from ./pr59063-2.exe...done.
(gdb) b sigaction
Breakpoint 1 at 0x42d800: file 
../../.././libsanitizer/asan/asan_interceptors.cc, line 287.
(gdb) b real_sigaction
Breakpoint 2 at 0x4ac710: file 
../../.././libsanitizer/asan/asan_interceptors.cc, line 297.
(gdb) c
The program is not being run.
(gdb) run
Starting program: /tmp/pr59063-2.exe 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib64/libthread_db.so.1".

Breakpoint 2, __sanitizer::real_sigaction (signum=11, act=0x7fffe230, 
oldact=0x0) at ../../.././libsanitizer/asan/asan_interceptors.cc:297
297  (struct sigaction *)oldact);
(gdb) n

Breakpoint 1, __interceptor_sigaction (signum=11, act=0x7fffe230, 
oldact=0x0) at ../../.././libsanitizer/asan/asan_interceptors.cc:287
287 struct sigaction *oldact) {
(gdb) 
288   if (!IsDeadlySignal(signum) || 
common_flags()->allow_user_segv_handler) {
(gdb) 
289 return REAL(sigaction)(signum, act, oldact);
(gdb) 
292 }
(gdb) 
289 return REAL(sigaction)(signum, act, oldact);
(gdb) 
292 }
(gdb) 
289 return REAL(sigaction)(signum, act, oldact);
(gdb) 
0x in ?? ()
(gdb) c
Continuing.

Program received signal SIGSEGV, Segmentation fault.
0x in ?? ()
(gdb) where
#0  0x in ?? ()
#1  0x004d02a2 in __sanitizer::MaybeInstallSigaction (signum=11, 
handler=0x4c6880 <__asan::AsanOnDeadlySignal(int, void*, void*)>) at 
../../.././libsanitizer/sanitizer_common/sanitizer_posix_libcdep.cc:178
#2  0x004d0603 in __sanitizer::InstallDeadlySignalHandlers 
(handler=0x4c6880 <__asan::AsanOnDeadlySignal(int, void*, void*)>) at 
../../.././libsanitizer/sanitizer_common/sanitizer_posix_libcdep.cc:187
#3  0x004cd50d in __asan::AsanInitInternal () at 
../../.././libsanitizer/asan/asan_rtl.cc:502
#4  0x77de8d83 in _dl_init_internal () from /lib64/ld-linux-x86-64.so.2
#5  0x77dda0ba in _dl_start_user () from /lib64/ld-linux-x86-64.so.2
#6  0x0001 in ?? ()
#7  0x7fffe5ab in ?? ()
#8  0x in ?? ()
(gdb)


It appears that the '__interception::PTR_TO_REAL' mechanism
REAL(sigaction) is using to resolve address of sigaction is
being foxed by the fact that libasan.a is statically linked,
AND the libasan.so is also linked to, but hardly any
symbols are resolved to it.

When I remove '-static-libasan', and supply only '-lasan',
in the build command line generated by asan-dg.exp, 
the test compiles and runs fine .

I am not using libasan for my project, just trying to build
latest GCC 6.4.1 with latest retpoline backports & bugfixes
into a version that passes its test suite, and I noticed this
problem - this is the main 'unexpected failure' source .

I guess I should class this an 'unexpected but don't care' failure ?

I just thought I should let the GCC developers know .

Thanks & Best Regards,
Jason





'

Re: gcc-6-branch test failures: g++ c-c++-common/asan/pr59063-2.c

2018-05-21 Thread Jason Vas Dias 

To me it looks like the definition of 'real_sigaction'
in 'asan_interceptors.cc' is actually going to
recursively call itself - so I tried patching
libsanitizer:

{BEGIN PATCH:
Index: asan/asan_interceptors.cc
===
--- asan/asan_interceptors.cc   (revision 260441)
+++ asan/asan_interceptors.cc   (working copy)
@@ -293,8 +293,8 @@
 
 namespace __sanitizer {
 int real_sigaction(int signum, const void *act, void *oldact) {
-  return REAL(sigaction)(signum, (const struct sigaction *)act,
- (struct sigaction *)oldact);
+  return ::sigaction(signum, (const struct sigaction *)act,
+ (struct sigaction *)oldact);
 }
 } // namespace __sanitizer
 
Index: sanitizer_common/sanitizer_common_interceptors.inc
===
--- sanitizer_common/sanitizer_common_interceptors.inc  (revision 260441)
+++ sanitizer_common/sanitizer_common_interceptors.inc  (working copy)
@@ -2446,7 +2446,7 @@
 INTERCEPTOR(uptr, ptrace, int request, int pid, void *addr, void *data) {
   void *ctx;
   COMMON_INTERCEPTOR_ENTER(ctx, ptrace, request, pid, addr, data);
-  __sanitizer_iovec local_iovec;
+  __sanitizer_iovec local_iovec {};
 
   if (data) {
 if (request == ptrace_setregs)

END PATCH}

The second patch line removes a warning about local_iovec being
used uninitialized.

With the patch applied, the program does not coredump
and shows more what is going on:

$ ./pr59063-2.exe
==5898==Shadow memory range interleaves with an existing memory mapping. ASan 
cannot proceed correctly. ABORTING.
==5898==ASan shadow was supposed to be located in the 
[0x7fff7000-0x10007fff7fff] range.
==5898==Process memory map follows:
0x0040-0x00522000   /tmp/pr59063-2.exe
0x00721000-0x00723000   /tmp/pr59063-2.exe
0x00723000-0x00726000   /tmp/pr59063-2.exe
0x00726000-0x01398000   
0x7fff7000-0x8fff7000   
0x8fff7000-0x02008fff7000   
0x02008fff7000-0x10007fff8000   
0x6000-0x6400   
0x6400-0x64003000   
0x7f05baec2000-0x7f05bb566000   
0x7f05bb566000-0x7f05bb72f000   /usr/lib64/libc-2.17.so
0x7f05bb72f000-0x7f05bb92f000   /usr/lib64/libc-2.17.so
0x7f05bb92f000-0x7f05bb933000   /usr/lib64/libc-2.17.so
0x7f05bb933000-0x7f05bb935000   /usr/lib64/libc-2.17.so
0x7f05bb935000-0x7f05bb93a000   
0x7f05bb93a000-0x7f05bb95   
/home/devel/OS/gcc-6-branch/host-x86_64-linux-gnu/gcc/libgcc_s.so.1
0x7f05bb95-0x7f05bbb4f000   
/home/devel/OS/gcc-6-branch/host-x86_64-linux-gnu/gcc/libgcc_s.so.1
0x7f05bbb4f000-0x7f05bbb5   
/home/devel/OS/gcc-6-branch/host-x86_64-linux-gnu/gcc/libgcc_s.so.1
0x7f05bbb5-0x7f05bbb51000   
/home/devel/OS/gcc-6-branch/host-x86_64-linux-gnu/gcc/libgcc_s.so.1
0x7f05bbb51000-0x7f05bbb69000   /usr/lib64/libpthread-2.17.so
0x7f05bbb69000-0x7f05bbd68000   /usr/lib64/libpthread-2.17.so
0x7f05bbd68000-0x7f05bbd69000   /usr/lib64/libpthread-2.17.so
0x7f05bbd69000-0x7f05bbd6a000   /usr/lib64/libpthread-2.17.so
0x7f05bbd6a000-0x7f05bbd6e000   
0x7f05bbd6e000-0x7f05bbd7   /usr/lib64/libdl-2.17.so
0x7f05bbd7-0x7f05bbf7   /usr/lib64/libdl-2.17.so
0x7f05bbf7-0x7f05bbf71000   /usr/lib64/libdl-2.17.so
0x7f05bbf71000-0x7f05bbf72000   /usr/lib64/libdl-2.17.so
0x7f05bbf72000-0x7f05bbf79000   /usr/lib64/librt-2.17.so
0x7f05bbf79000-0x7f05bc178000   /usr/lib64/librt-2.17.so
0x7f05bc178000-0x7f05bc179000   /usr/lib64/librt-2.17.so
0x7f05bc179000-0x7f05bc17a000   /usr/lib64/librt-2.17.so
0x7f05bc17a000-0x7f05bc27b000   /usr/lib64/libm-2.17.so
0x7f05bc27b000-0x7f05bc47a000   /usr/lib64/libm-2.17.so
0x7f05bc47a000-0x7f05bc47b000   /usr/lib64/libm-2.17.so
0x7f05bc47b000-0x7f05bc47c000   /usr/lib64/libm-2.17.so
0x7f05bc47c000-0x7f05bc5f6000   
/home/devel/OS/gcc-6-branch/x86_64-linux-gnu/libstdc++-v3/src/.libs/libstdc++.so.6.0.22
0x7f05bc5f6000-0x7f05bc7f6000   
/home/devel/OS/gcc-6-branch/x86_64-linux-gnu/libstdc++-v3/src/.libs/libstdc++.so.6.0.22
0x7f05bc7f6000-0x7f05bc80   
/home/devel/OS/gcc-6-branch/x86_64-linux-gnu/libstdc++-v3/src/.libs/libstdc++.so.6.0.22
0x7f05bc80-0x7f05bc802000   
/home/devel/OS/gcc-6-branch/x86_64-linux-gnu/libstdc++-v3/src/.libs/libstdc++.so.6.0.22
0x7f05bc802000-0x7f05bc806000   
0x7f05bc806000-0x7f05bc92f000   
/home/devel/OS/gcc-6-branch/x86_64-linux-gnu/libsanitizer/asan/.libs/libasan.so.3.0.0
0x7f05bc92f000-0x7f05bcb2e000   
/home/devel/OS/gcc-6-branch/x86_64-linux-gnu/libsanitizer/asan/.libs/libasan.so.3.0.0
0x7f05bcb2e000-0x7f05bcb31000   
/home/devel/OS/gcc-6-branch/x86_64-linux-gnu/libsanitizer/asan/.libs/

Re: gcc-6-branch test failures: g++ c-c++-common/asan/pr59063-2.c

2018-05-22 Thread Jason Vas Dias 


This problem turned out to be because the objects in
libasan.a of gcc-6-branch are built with -fPIC / -DPIC :
if 'PIC' is defined, the code in asan_linux.c is
assuming it has been dynamically loaded , and so
does not allow libasan.so NOT to be the first
required dynamic library. But adding '-lasan'
is a bad idea, since then the
   dlsym(RTLD_NEXT,"sigaction")
actually resolves to __interception::sigaction
which ends up calling itself until stack is exhausted.

For some reason (which I am trying to figure out, but
which is not obvious) the gcc-7-branch libasan build
does build all the libasan.a objects without -fPIC -DPIC
correctly, and so does not have this problem.

It looks like use of 'static-libasan' in GCC 6 builds
is thoroughly disabled and broken because of libasan.a
objects ARE built with -fPIC / -DPIC .

Maybe I should raise a bug about this?

Thanks & Regards,
Jason

4.7.2 TLS on AIX 6.1 (ppc) ?

2013-03-11 Thread Jason Vas Dias 
Hi - I wonder if anyone could please tell me if gcc's thread local
storage support is meant to be enabled on AIX or not -
I've built gcc-4.7.2 on AIX 6.1 OK,   with "---enable-threads" ,
using the AIX system /usr/ccs/bin ld and as ,  both of which
claim to provide TLS support , but now this test program is getting
the same address for its  __thread variable in different threads -
 it is compiled and linked without warnings or error, and prints three
different addresses at the end on Linux, Solaris x86 & SPARC, and
HP-UX,
but not on AIX 6.1 .  This also happens with the IBM freeware
gcc-4.4.6.  Yet 4.7.2's libgomp was built OK ... doesn't this depend
on TLS?

Must I use --enable-tls as well as --enable-threads in configuration
options and rebuild GCC ? Is this likely to work ?

gcc-4.7.2 is reporting its thread model as 'aix' - shouldn't this be
'posix' ( the system /usr/lib/libpthread.a is installed and the
pthread_* headers look POSIX compatible ).
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/data/gnu/bin/../libexec/gcc/powerpc-ibm-aix6.1.0.0/4.7.2/lto-wrapper
Target: powerpc-ibm-aix6.1.0.0
Configured with: ../configure --enable-languages=c,c++
--prefix=/usr/gnu --enable-threads
--enable-version-specific-runtime-libs --disable-nls
--enable-decimal-float=dpd --with-as=/usr/ccs/bin/as
--with-ld=/usr/ccs/bin/ld --with-gmp=/usr/gnu --with-mpfr=/usr/gnu
--with-mpc=/usr/gnu powerpc-ibm-aix6.1.0.0
Thread model: aix
gcc version 4.7.2 (GCC)

Shouldn't GCC be terminating compilation with an error if it
encounters use of __thread when TLS is not enabled ?
Is there an option to enable this / if not , could one be added ?
Is there an option to make GCC tell the user if TLS is enabled or not
- again, if not, could there be one ?

I don't think gcc should be allowing programmers to assume TLS is in
use when it is not - this is dangerous!

If GCC does not support TLS with AIX 'ld' + 'as' (which seems likely),
 could this not be documented somewhere in the installation
documentation (it does not appear to be) ?   Any plans to enable it in
near future ?

Thanks in advance for any replies,
Jason Vas Dias 


#include 
#include 

struct state
{
unsigned char
 bit1:1   , bit2:1   , bit3:1   , bit4:1
   , bit5:1   , bit6:1   , bit7:1   , bit8:1
;
} ;

__thread struct state my_bits;

void* t1(void *arg)
{return (*((void**)arg)=&my_bits);
}

void* t2(void *arg)
{return (*((void**)arg)=&my_bits);
}

int main( int argc , char **argv )
{
pthread_t pth1={0}, pth2={0};
void *mb1=0, *mb2 =0;
pthread_attr_t pthrat={0};
pthread_attr_init(&pthrat);
pthread_attr_setstacksize(&pthrat, 1<<20);
unsigned int n_pth=0;
if( pthread_create( &pth1, &pthrat, t1,&mb1) == 0)
n_pth += 1;
if( pthread_create( &pth2, &pthrat, t2,&mb2) == 0)
n_pth += 1;
if( n_pth > 0 )
pthread_join( pth1, &mb1 );
if( n_pth > 1 )
pthread_join( pth2, &mb2 );
pthread_attr_destroy(&pthrat);

fprintf(stderr,"main : %p %p %p\n", &my_bits, mb1, mb2);
}


So only on AIX does this program print :

$ ./ttls
main : 20213aac 20213aac 20213aac

On Linux / Solaris / HP-UX, it prints 3 different addresses:
Solaris:
main : ff382a38 ff1e0238 ff1e0a38
Linux:
main : 0x7f3c033f96ff 0x7f3c033f76ff 0x7f3c02c246ff

Re: 4.7.2 TLS on AIX 6.1 (ppc) ?

2013-03-12 Thread Jason Vas Dias 
Thanks for your informative response, David!  This is what I really
wanted to know:
> All previous and current releases of GCC do not support
> native TLS on AIX.  GCC 4.8 will provide TLS on AIX, as listed in the
> announcements for the release.
Great! I'll look forward to testing with 4.8 when it becomes GA .
Thanks for comments on configuration options - points noted -  but I
was only copying
the options used for the IBM freeware GCC distribution.

But why didn't the compiler complain that TLS was not supported ?
Shouldn't it be doing so ?  It is definitely not OK in my book for gcc
to finish compilation and linkage with no errors or warnings, when
it has encountered a __thread usage that it must know will have no
effect.

And isn't there an easier way to determine if TLS is enabled or not
than by compiling a test program ?

Thanks & Regards,
Jason

On Mon, Mar 11, 2013 at 10:07 PM, David Edelsohn  wrote:
> On Mon, Mar 11, 2013 at 3:46 PM, Jason Vas Dias
>  wrote:
>> Hi - I wonder if anyone could please tell me if gcc's thread local
>> storage support is meant to be enabled on AIX or not -
>> I've built gcc-4.7.2 on AIX 6.1 OK,   with "---enable-threads" ,
>> using the AIX system /usr/ccs/bin ld and as ,  both of which
>> claim to provide TLS support , but now this test program is getting
>> the same address for its  __thread variable in different threads -
>>  it is compiled and linked without warnings or error, and prints three
>> different addresses at the end on Linux, Solaris x86 & SPARC, and
>> HP-UX,
>> but not on AIX 6.1 .  This also happens with the IBM freeware
>> gcc-4.4.6.  Yet 4.7.2's libgomp was built OK ... doesn't this depend
>> on TLS?
>>
>> Must I use --enable-tls as well as --enable-threads in configuration
>> options and rebuild GCC ? Is this likely to work ?
>>
>> gcc-4.7.2 is reporting its thread model as 'aix' - shouldn't this be
>> 'posix' ( the system /usr/lib/libpthread.a is installed and the
>> pthread_* headers look POSIX compatible ).
>
>> Shouldn't GCC be terminating compilation with an error if it
>> encounters use of __thread when TLS is not enabled ?
>> Is there an option to enable this / if not , could one be added ?
>> Is there an option to make GCC tell the user if TLS is enabled or not
>> - again, if not, could there be one ?
>>
>> I don't think gcc should be allowing programmers to assume TLS is in
>> use when it is not - this is dangerous!
>>
>> If GCC does not support TLS with AIX 'ld' + 'as' (which seems likely),
>>  could this not be documented somewhere in the installation
>> documentation (it does not appear to be) ?   Any plans to enable it in
>> near future ?
>
> First, because of the way that AIX supports pthreads, GCC requires
> different libraries for pthread and non-pthread code.  GCC -pthread
> links with the pthread version of the libraries.  This is why thread
> model is reported as "aix" and not "posix".
>
> Second, when native TLS is not available, GCC emulates TLS using
> pthread keys.  All previous and current releases of GCC do not support
> native TLS on AIX.  GCC 4.8 will provide TLS on AIX, as listed in the
> announcements for the release.
>
> Third, one should not add configuration options like "--enable-tls" or
> "--enable-threads".  The defaults are correct and will enable the
> appropriate features for the system.  No one chose to implement a
> feature but leave it disabled by default.  No one is hiding features
> and one should not approach the configuration process by trying to
> force override options.
>
> Compiling your example with GCC 4.8 snapshot from last night produces
> the following on AIX 7.1:
>
> $ ./xgcc -B./ -O2 -pthread code.c
> $ ./a.out
> main : 200080d0 20112000 20218000
> $ ./xgcc -B./ -O2 -pthread -maix64 code.c
> $ ./a.out
> main : 11000de20 11011a000 110221000
>
> Thanks, David

4.9.4 release latest tag does not build - ICE in gcj

2021-09-11 Thread Jason Vas Dias via Gcc 


Hi -

 I am trying to build GCC 4.9.4, with originally only GCC 4.4.7, on
 a Linux RHEL6 (i686) lxc container under x86_64 Centos-7 -
 so I cloned and built:
  https://github.com/gcc-mirror/gcc/tree/releases/gcc-4.9
 
 with configure flags:
   Target: i686-redhat-linux
Configured with: ../configure --prefix=/usr/local --enable-bootstrap 
--enable-shared --enable-threads=posix --enable-checking=release 
--with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions 
--enable-gnu-unique-object 
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk 
--disable-dssi --with-java-home=/usr/local/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre 
--enable-libgcj-multifile --enable-java-maintainer-mode 
--with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib 
--with-gmp=/usr/local --with-mpfr=/usr/local --with-mpc=/usr/local 
--with-tune=native --with-arch=i686 --build=i686-redhat-linux 
--enable-serial-configure
Thread model: posix
gcc version 4.9.4 (GCC)
  
 All other compiler components built fine except libjava .

 I see in :
   i686-redhat-linux/libjava/classpath/config.log :

configure:25378: 
/home/adm-jason/rpmbuild/BUILD/gcc-releases-gcc-4.9/host-i686-redhat-linux/gcc/gcj
 -B/home/adm-jason/rpmbuild/BUILD/gcc-releases
-gcc-4.9/i686-redhat-linux/libjava/ 
-B/home/adm-jason/rpmbuild/BUILD/gcc-releases-gcc-4.9/i686-redhat-linux/libjava/
 -B/home/adm-jason/rpmbuild/B
UILD/gcc-releases-gcc-4.9/host-i686-redhat-linux/gcc/ 
-B/usr/local/i686-redhat-linux/bin/ -B/usr/local/i686-redhat-linux/lib/ 
-isystem /usr/local
/i686-redhat-linux/include -isystem /usr/local/i686-redhat-linux/sys-include -C 
-g  -fsource=1.5 -ftarget=1.5 Object.java
libgcj failure: gcj linkage error.
Incorrect library ABI version detected.  Aborting.

gcj: internal compiler error: Aborted (program ecj1)
0x8050bd4 execute
../.././gcc/gcc.c:2854
0x8050fa4 do_spec_1
../.././gcc/gcc.c:4658
0x80527d2 do_spec_2
../.././gcc/gcc.c:4359
0x8053cef do_spec(char const*)
../.././gcc/gcc.c:4326
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
configure:25381: $? = 4
configure:25385: error: The Java compiler 
/home/adm-jason/rpmbuild/BUILD/gcc-releases-gcc-4.9/host-i686-redhat-linux/gcc/gcj
 -B/home/adm-jason/rp
mbuild/BUILD/gcc-releases-gcc-4.9/i686-redhat-linux/libjava/ 
-B/home/adm-jason/rpmbuild/BUILD/gcc-releases-gcc-4.9/i686-redhat-linux/libjava/
 -B/
home/adm-jason/rpmbuild/BUILD/gcc-releases-gcc-4.9/host-i686-redhat-linux/gcc/ 
-B/usr/local/i686-redhat-linux/bin/ -B/usr/local/i686-redhat-linux
/lib/ -isystem /usr/local/i686-redhat-linux/include -isystem 
/usr/local/i686-redhat-linux/sys-include -C -g failed (see config.log, check 
the CLA
SSPATH?)

##  ##
## Cache variables. ##
##  ##




If I move i686-redhat-linux/libjava/Makefile to 
i686-redhat-linux/libjava/Makefile.orig,
and 
  $ echo
  $'all:\n\t/bin/true\ninstall:\n\t/bin/true\ncheck:\n\t/bin/true' \
   > i686-redhat-linux/libjava/Makefile 
,
then 'make DESTDIR=/tmp/$X install' does work and 'make check' does look
OK (except Java parts).
But I'd like to be able to do a clean build including gcj + Java.

I had followed the instructions at:
  https://github.com/spack/spack/issues/8165
to first get 'ecj1' to build successfully:
$ gcj -oecj1 --main=org.eclipse.jdt.internal.compiler.batch.GCCMain \
  /usr/share/java/ecj-4.5.2.jar -L/usr/lib/gcc/i686-redhat-linux/4.4.7/

I then copied this ecj1 successfully built to ~/bin, which is in my
$PATH.

The only gcj + libjava I have is from GCC 4.4.7 - the gcj I run in the
above command is the gcj built from GCC 4.9.4 , which does not have its
libjava (this is what I am trying and failing to build).

The CLASSPATH I had to use to get the above command to work is :

/usr/share/java/ecj-4.5.2.jar:/usr/share/java/eclipse-ecj-4.5.2.jar:/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre/lib/jaas.jar:/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre/lib/jce.jar:/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre/lib/jdbc-stdext.jar:/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre/lib/jndi-cos.jar:/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre/lib/jndi-dns.jar:/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre/lib/jndi-ldap.jar:/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre/lib/jndi-rmi.jar:/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre/lib/jndi.jar:/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre/lib/jsse.jar:/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre/lib/sasl.jar:/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre/lib/rt.jar:/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/lib/tools.jar:

The repeatable reconfigure command I had to use in
i686-redhat-linux/libjava, to get it to attempt to reconfigure
classpath, after first failing because it did not have a copy
of its source directory's 'libltdl' subdirectory, after I then
copied it, was:

$ CFLAGS='-g -O2' LDFLAGS='' CPPFLAGS=''
CXX='/home/adm-jason/rpmbuild/BUILD/gcc-releases-gcc-4.9/