[Bug c++/89237] New: Partial specialization incorrectly marked as ambiguous

2019-02-07 Thread delrieutheo at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89237

Bug ID: 89237
   Summary: Partial specialization incorrectly marked as ambiguous
   Product: gcc
   Version: 8.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: delrieutheo at gmail dot com
  Target Milestone: ---

Created attachment 45628
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45628=edit
Incorrectly marked ambiguous partial specialization

Hello,

There seems to be a bug in GCC's template partial ordering, the attached code
works with clang 3.8 up to latest trunk version, but fails with GCC 5 and 8 (I
have not tested other versions).

Here is the output of gcc -v:

Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/8/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 8.2.0-17'
--with-bugurl=file:///usr/share/doc/gcc-8/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr
--with-gcc-major-version-only --program-suffix=-8
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-bootstrap --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 --enable-default-pie
--with-system-zlib --with-target-system-zlib --enable-objc-gc=auto
--enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none --without-cuda-driver
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 8.2.1 20190204 (Debian 8.2.0-17)

[Bug c++/87282] Invalid use of 'void', in unevaluated context

2018-09-12 Thread delrieutheo at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87282

--- Comment #1 from delrieutheo at gmail dot com ---
Note that it fails with operator-=(void*, void*) as well.

[Bug c++/87282] New: Invalid use of 'void', in unevaluated context

2018-09-11 Thread delrieutheo at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87282

Bug ID: 87282
   Summary: Invalid use of 'void', in unevaluated context
   Product: gcc
   Version: 8.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: delrieutheo at gmail dot com
  Target Milestone: ---

Created attachment 44678
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44678=edit
void pointers substraction bug

Hello,

I've been playing around with the detected idiom lately, and I stumbled across
a bug in GCC 8.2.0, when substracting two void* in an unevaluated context.

Adding those two void* works as expected (as shown in the attachment).

The attachment compiles with Clang 5.0.2.

[Bug libstdc++/66855] New: codecvt wrong endianness in UTF-16 conversions

2015-07-13 Thread delrieutheo at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66855

Bug ID: 66855
   Summary: codecvt wrong endianness in UTF-16 conversions
   Product: gcc
   Version: 5.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: delrieutheo at gmail dot com
  Target Milestone: ---

Created attachment 35965
  -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35965action=edit
The buggy one

There is a problem with codecvt, the facet codecvt_utf8_utf16 should do
big-endian conversions with default template arguments.

However this is the output I get linking with libstdc++-5.1.1 :

UTF-16

[b098] [b294] [d0dc] [c624] 

UTF-16 to UTF-8

[eb] [82] [98] [eb] [8a] [94] [ed] [83] [9c] [ec] [98] [a4] 

Converting back to UTF-16

[98b0] [94b2] [dcd0] [24c6]

The same code gives the expected result on OS X with libc++ and on Windows.

When I specify the third template argument of codecvt_utf8_utf16 with
std::little_endian, it gives the expected output.