Potential Bug in GCC5?

2017-06-10 Thread Yubin Ruan
Hi,
I don't know whether this bug has been reported(I have check GCC Bugzillia
though) or has been resolved:

This program:

#include 
int main()
{
  char a = 'a';
  printf("Size of char : %d\n",sizeof(a));
  printf("Size of char : %d\n",sizeof('a'));
  return 0;
}

when compiled with:

gcc -Wall testgcc.c -o testgcc -fexec-charset=utf-16

will triggers GCC's bug report reminder:

  ...
  internal compiler error: character 0xa is not unibyte in execution character 
set
  ...
  Please submit a full bug report...

I think the problem comes with the "-fexec-character=utf-16" flag. And my GCC
version is (compiling with "gcc -v -Wall testgcc.c -o testgcc 
-fexec-charset=utf-16")

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/5/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 
5.4.0-6ubuntu1~16.04.4' --with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs 
--enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr 
--program-suffix=-5 --enable-shared --enable-linker-build-id 
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix 
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu 
--enable-libstdcxx-debug --enable-libstdcxx-time=yes 
--with-default-libstdcxx-abi=new --enable-gnu-unique-object 
--disable-vtable-verify --enable-libmpx --enable-plugin --with-system-zlib 
--disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo 
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-amd64/jre --enable-java-home 
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-amd64 
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-amd64 
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar 
--enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686 
--with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib 
--with-tune=generic --enable-checking=release --build=x86_64-linux-gnu 
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4) 
COLLECT_GCC_OPTIONS='-fno-common' '-v' '-Wall' '-o' 'testgcc' 
'-fexec-charset=utf-16' '-mtune=generic' '-march=x86-64'
 /usr/lib/gcc/x86_64-linux-gnu/5/cc1 -quiet -v -imultiarch x86_64-linux-gnu 
testgcc.c -quiet -dumpbase testgcc.c -mtune=generic -march=x86-64 -auxbase 
testgcc -Wall -version -fno-common -fexec-charset=utf-16 
-fstack-protector-strong -Wformat-security -o /tmp/ccVA6bpI.s
GNU C11 (Ubuntu 5.4.0-6ubuntu1~16.04.4) version 5.4.0 20160609 
(x86_64-linux-gnu)
compiled by GNU C version 5.4.0 20160609, GMP version 6.1.0, MPFR 
version 3.1.4, MPC version 1.0.3
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory 
"/usr/lib/gcc/x86_64-linux-gnu/5/../../../../x86_64-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc/x86_64-linux-gnu/5/include
 /usr/local/include
 /usr/lib/gcc/x86_64-linux-gnu/5/include-fixed
 /usr/include/x86_64-linux-gnu
 /usr/include
End of search list.
GNU C11 (Ubuntu 5.4.0-6ubuntu1~16.04.4) version 5.4.0 20160609 
(x86_64-linux-gnu)
compiled by GNU C version 5.4.0 20160609, GMP version 6.1.0, MPFR 
version 3.1.4, MPC version 1.0.3
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 78b6f8b2ed219a71c67c16db887e4800
testgcc.c: In function ‘main’:
testgcc.c:4:12: warning: multi-character character constant [-Wmultichar]
   char a = 'a';
^
testgcc.c:4:12: warning: overflow in implicit constant conversion 
[-Woverflow]
testgcc.c:5:10: warning: embedded ‘\0’ in format [-Wformat-contains-nul]
   printf("Size of char : %d\n",sizeof(a));
  ^
testgcc.c:5:10: warning: too many arguments for format [-Wformat-extra-args]
testgcc.c:6:39: warning: multi-character character constant [-Wmultichar]
   printf("Size of char : %d\n",sizeof('a'));
   ^
testgcc.c:6:10: warning: embedded ‘\0’ in format [-Wformat-contains-nul]
   printf("Size of char : %d\n",sizeof('a'));
  ^
testgcc.c:6:10: warning: too many arguments for format [-Wformat-extra-args]
testgcc.c:8:0: internal compiler error: character 0xa is not unibyte in 
execution character set
 }
 ^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Is it appropriate for me to create a bug report on GCC's bugzillia?

--
Yubin


Re: Potential Bug in GCC5?

2017-06-10 Thread Gerald Pfeifer
Hi Yubin,

On Sun, 11 Jun 2017, Yubin Ruan wrote:
> I don't know whether this bug has been reported(I have check GCC 
> Bugzillia though) or has been resolved:
> 
> This program:
> 
> #include 
> int main()
> {
>   char a = 'a';
>   printf("Size of char : %d\n",sizeof(a));
>   printf("Size of char : %d\n",sizeof('a'));
>   return 0;
> }
> 
> when compiled with:
> 
> gcc -Wall testgcc.c -o testgcc -fexec-charset=utf-16
> 
> will triggers GCC's bug report reminder:
> 
>   ...
>   internal compiler error: character 0xa is not unibyte in execution 
> character set

as a user / bug reporter I quite like internal compiler errors in
that there is no argument of whether there is a bug here or not. ;-)

(The question is whether it is what we call "ICE on valid", that is,
an internal compiler error on valid input, or "ICE on invalid", where
the latter is a bug as well, but clearly not as severe as the former.)

> Is it appropriate for me to create a bug report on GCC's bugzillia?

Yes.  We prefer that you reproduce with a current version of GCC,
since for GCC 5 (let alone older) most new bug reports likely won't
be fixed any more, and newer versions may have fixed an issue already
after all, but in principle also accept reports against older versions.

I reproduced this with GCC 7.1.1 and filed a bug report:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81050

Gerald

PS: GCC 7.1.1 shows the following with -Wall, though -Wall is not
necessary to reproduce the issue:

x.c: In function ‘main’:
x.c:4:16: warning: multi-character character constant [-Wmultichar]
   char a = 'a';
^~~
x.c:4:16: warning: overflow in implicit constant conversion [-Woverflow]
x.c:5:14: warning: embedded ‘\0’ in format [-Wformat-contains-nul]
   printf("Size of char : %d\n",sizeof(a));
  ^
x.c:5:14: warning: too many arguments for format [-Wformat-extra-args]
x.c:6:43: warning: multi-character character constant [-Wmultichar]
   printf("Size of char : %d\n",sizeof('a'));
   ^~~
x.c:6:14: warning: embedded ‘\0’ in format [-Wformat-contains-nul]
   printf("Size of char : %d\n",sizeof('a'));
  ^
x.c:6:14: warning: too many arguments for format [-Wformat-extra-args]
x.c:8:0: internal compiler error: character 0xa is not unibyte in 
execution character set
 }

PPS: The warnings added with -Wall here don't appear to be helpful, 
either.  In fact, "embedded ‘\0’ in format" appears confusing/incorrect 
to me?

Re: TLS run-time requirements on x86, etc.

2017-06-10 Thread Joel Sherrill



On 1/12/2017 11:25 AM, Jakub Jelinek wrote:

On Thu, Jan 12, 2017 at 11:22:58AM -0600, Joel Sherrill wrote:

I am looking at the RTEMS x86 TLS support. When -fPIC is
specified, gcc generates calls to ___tls_get_addr(). But
when it is not specified, there are no external calls.
To make sure we are doing the right thing, I have a
few questions:

+ What is expected for "get TLS" when __tls_get_addr()
is not called?

+ Can we force all RTEMS i386 gcc configurations to make the
function call to __tls_get_addr()? We have an implementation
of it for ARM so it would be the same. So this would
be a simple solution for us.


Please read:
https://www.akkadia.org/drepper/tls.pdf


Resurrecting this thread. That document covers a small
subset of the targets supported by GCC. We have now
implemented TLS on most of the ones in the document.
But how (and if) it is implemented on the at least
dozen other architectures GCC and RTEMS support is
a mystery.

We would like to have the option of just setting an
option in the GCC backend where it generates calls to
a known name subroutine exactly the same on all targets
that set the option. This would make it much simpler
for us to support across all architectures.

The ARM already has a mode where it generates subroutine
calls to get the TLS.

Is there a way to do this?



Jakub