[Bug c++/114962] New: For each iteration in static assert fails to compile

2024-05-06 Thread jdapena at igalia dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114962

Bug ID: 114962
   Summary: For each iteration in static assert fails to compile
   Product: gcc
   Version: 13.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jdapena at igalia dot com
  Target Milestone: ---

Created attachment 58109
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58109=edit
Test case

The attached example, that allows to make sure all members are defined in a
constexpr created std::array, fails in GCC (and works in Clang at least from
version 10.x and in current trunk).

I am not sure if this is a valid pattern, so reporting a bug to GCC for further
analysis.

[Bug c++/113074] New: requires requires should be SFINAE

2023-12-18 Thread jdapena at igalia dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113074

Bug ID: 113074
   Summary: requires requires should be SFINAE
   Product: gcc
   Version: 13.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jdapena at igalia dot com
  Target Milestone: ---

Created attachment 56904
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56904=edit
Test case from godbolt

Calling std::to_address in a requires requires function should be SFINAE.
Instead of it, it fails to compile.

This is breaking GCC build of Chromium in
https://chromium.googlesource.com/chromium/src.git/+/refs/tags/122.0.6193.2/mojo/public/cpp/bindings/type_converter.h#98
when the type does not support std::to_address because it fails to find
operator->.

Code is:
template 
  requires requires(const U& obj) {
not std::is_pointer_v;
{ mojo::ConvertTo(std::to_address(obj)) } -> std::same_as;
  }
inline T ConvertTo(const U& obj) {
  return mojo::ConvertTo(std::to_address(obj));
}

The code is designed to only declare ConvertTo in case it can convert from
std::to_address result.

A possible test case is attached. This case fails in Clang with the expected
outcome (it fails to resolve to a valid call).

[Bug libstdc++/112314] Missing index assertions in basic_string_view

2023-11-02 Thread jdapena at igalia dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112314

--- Comment #5 from Jose Dapena Paz  ---
(In reply to Jonathan Wakely from comment #4)
> (In reply to Jose Dapena Paz from comment #2)
> > In any case, the failing test is actually passing -1, my understanding is
> > that that one should always assert no matter what we are passing as const
> > char*.
> 
> Yes but I'm not going to add a check for -1 just to make some unit test
> pass. In real code (size_t)-2 or (size_t)(-some other value) is at least as
> likely.
> 
> __glibcxx_assert(not in chromium tests) doesn't seem useful.

Oh, I just checked the LLVM implementation and it is... interesting:
https://github.com/llvm/llvm-project/blob/main/libcxx/include/string_view#L311C1-L318C1

It checks two conditions:
- Length should be 0 OR pointer should not be null.
- The length is less than the possible pointer difference (checked with
numeric_limits).

[Bug libstdc++/112314] Missing index assertions in basic_string_view

2023-11-02 Thread jdapena at igalia dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112314

--- Comment #2 from Jose Dapena Paz  ---
(In reply to Jonathan Wakely from comment #1)
> For the second one, I did start work on a patch that attempts to verify that
> the provided length is not more than __builtin_object_size. I can't remember
> why I stopped working on that. There's no way to make that check 100%
> reliable, because __builtin_object_size depends on optimizations and whether
> the compiler can see enough data.

I guess in this case a "best-effort" approach could be good enough? Providing
there are no false positives asserting for actually valid calls. In the case of
Chromium unit test it is passing a predefined const char[] so, at least making
sure those cases are validated would add an extra layer of protection.

In any case, the failing test is actually passing -1, my understanding is that
that one should always assert no matter what we are passing as const char*.

[Bug libstdc++/112314] New: Missing index assertions in basic_string_view

2023-10-31 Thread jdapena at igalia dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112314

Bug ID: 112314
   Summary: Missing index assertions in basic_string_view
   Product: gcc
   Version: 12.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jdapena at igalia dot com
  Target Milestone: ---

While testing Chromium base unit tests with _GLIBCXX_ASSERTIONS=1, that include
checks for base::StringPiece, that wraps nowadays std::string_view, two unit
tests are failing because they are expected to assert and they don't.

One failing tests is:
  {
StringPiece piece;
ASSERT_DEATH_IF_SUPPORTED(piece.remove_suffix(1), "");
  }

In this case, std::basic_string_view::remove_suffix should check if the index
provided is valid.

Another failing test is:

  int length = -1;
  ASSERT_DEATH_IF_SUPPORTED({ StringPiece piece("hello", length); }, "");

In this case, std::basic_string_view::basic_string_view(const _CharT* __str,
size_type __len) is not validating that __len is a valid index for __str.

[Bug c++/64236] [c++11] last alignas overrides stricter on a class definition

2023-05-22 Thread jdapena at igalia dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64236

Jose Dapena Paz  changed:

   What|Removed |Added

 CC||jdapena at igalia dot com

--- Comment #7 from Jose Dapena Paz  ---
Still present in GCC 12.2.0. It is breaking Chromium build after these changes:
https://chromium-review.googlesource.com/c/chromium/src/+/4542940/4/base/allocator/partition_allocator/partition_address_space.h

[Bug c++/109505] Compiler loops forever to OOM while compiling evaluate_prg_hwy.cc in Chromium

2023-04-14 Thread jdapena at igalia dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109505

--- Comment #3 from Jose Dapena Paz  ---
Created attachment 54858
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54858=edit
evaluate_prg_hwy.ii (compressed with gzip)

[Bug c++/109505] Compiler loops forever to OOM while compiling evaluate_prg_hwy.cc in Chromium

2023-04-14 Thread jdapena at igalia dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109505

--- Comment #2 from Jose Dapena Paz  ---
Information collected:

### g++ -v

aarch64-poky-linux-g++ -v
Using built-in specs.
COLLECT_GCC=./home/dape/Development/yocto/meta-chromium/build/tmp/work/x86_64-linux/gcc-cross-aarch64/12.2.0-r0/recipe-sysroot-native/usr/bin/aarch64-poky-linux/aarch64-poky-linux-g++
COLLECT_LTO_WRAPPER=/home/dape/Development/yocto/meta-chromium/build/tmp/work/x86_64-linux/gcc-cross-aarch64/12.2.0-r0/image/home/dape/Development/yocto/meta-chromium/build/tmp/work/x86_64-linux/gcc-cross-aarch64/12.2.0-r0/recipe-sysroot-native/usr/bin/aarch64-poky-linux/../../libexec/aarch64-poky-linux/gcc/aarch64-poky-linux/12.2.0/lto-wrapper
Target: aarch64-poky-linux
Configured with:
../../../../../../work-shared/gcc-12.2.0-r0/gcc-12.2.0/configure
--build=x86_64-linux --host=x86_64-linux --target=aarch64-poky-linux
--prefix=/host-native/usr --exec_prefix=/host-native/usr
--bindir=/host-native/usr/bin/aarch64-poky-linux
--sbindir=/host-native/usr/bin/aarch64-poky-linux
--libexecdir=/host-native/usr/libexec/aarch64-poky-linux
--datadir=/host-native/usr/share --sysconfdir=/host-native/etc
--sharedstatedir=/host-native/com --localstatedir=/host-native/var
--libdir=/host-native/usr/lib/aarch64-poky-linux
--includedir=/host-native/usr/include --oldincludedir=/host-native/usr/include
--infodir=/host-native/usr/share/info --mandir=/host-native/usr/share/man
--disable-silent-rules --disable-dependency-tracking
--with-libtool-sysroot=/host-native --enable-clocale=generic --with-gnu-ld
--enable-shared --enable-languages=c,c++ --enable-threads=posix
--disable-multilib --enable-default-pie --enable-c99 --enable-long-long
--enable-symvers=gnu --enable-libstdcxx-pch
--program-prefix=aarch64-poky-linux- --without-local-prefix
--disable-install-libiberty --disable-libssp --enable-libitm --enable-lto
--disable-bootstrap --with-system-zlib --with-linker-hash-style=sysv
--enable-linker-build-id --with-ppl=no --with-cloog=no
--enable-checking=release --enable-cheaders=c_global --without-isl
--with-gxx-include-dir=/not/exist/usr/include/c++/12.2.0
--with-sysroot=/not/exist --with-build-sysroot=/host
--enable-standard-branch-protection --enable-poison-system-directories=error
--with-system-zlib --disable-static --disable-nls --with-glibc-version=2.28
--enable-initfini-array --enable-__cxa_atexit
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.2.0 (GCC) 

### Extracted information

 GCC version

12.2.0

 System type

Toolchain built by Yocto Langdale with the mentioned steps, on Ubuntu 22.10

 GCC configure options

Configured with:
../../../../../../work-shared/gcc-12.2.0-r0/gcc-12.2.0/configure
--build=x86_64-linux --host=x86_64-linux --target=aarch64-poky-linux
--prefix=/host-native/usr --exec_prefix=/host-native/usr
--bindir=/host-native/usr/bin/aarch64-poky-linux
--sbindir=/host-native/usr/bin/aarch64-poky-linux
--libexecdir=/host-native/usr/libexec/aarch64-poky-linux
--datadir=/host-native/usr/share --sysconfdir=/host-native/etc
--sharedstatedir=/host-native/com --localstatedir=/host-native/var
--libdir=/host-native/usr/lib/aarch64-poky-linux
--includedir=/host-native/usr/include --oldincludedir=/host-native/usr/include
--infodir=/host-native/usr/share/info --mandir=/host-native/usr/share/man
--disable-silent-rules --disable-dependency-tracking
--with-libtool-sysroot=/host-native --enable-clocale=generic --with-gnu-ld
--enable-shared --enable-languages=c,c++ --enable-threads=posix
--disable-multilib --enable-default-pie --enable-c99 --enable-long-long
--enable-symvers=gnu --enable-libstdcxx-pch
--program-prefix=aarch64-poky-linux- --without-local-prefix
--disable-install-libiberty --disable-libssp --enable-libitm --enable-lto
--disable-bootstrap --with-system-zlib --with-linker-hash-style=sysv
--enable-linker-build-id --with-ppl=no --with-cloog=no
--enable-checking=release --enable-cheaders=c_global --without-isl
--with-gxx-include-dir=/not/exist/usr/include/c++/12.2.0
--with-sysroot=/not/exist --with-build-sysroot=/host
--enable-standard-branch-protection --enable-poison-system-directories=error
--with-system-zlib --disable-static --disable-nls --with-glibc-version=2.28
--enable-initfini-array --enable-__cxa_atexit

 Complete command line that triggers the bug

aarch64-poky-linux-g++  -mcpu=cortex-a72 -march=armv8-a+crc
-fstack-protector-strong   -D_FORTIFY_SOURCE=2 -Wformat -Wformat-security
-Werror=format-security
--sysroot=/home/dape/Development/yocto/meta-chromium/build/tmp/work/cortexa72-poky-linux/chromium-dev/114.0.5696.0-r0/recipe-sysroot
-MMD -MF
obj/third_party/distributed_point_functions/distributed_point_functions/evaluate_prg_hwy.o.d
-DUSE_UDEV -DUSE_AURA=1 -DUSE_GLIB=1 -DUSE_OZONE=1 -DOFFICIAL_BUILD
-D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE
-DNO_UNWIND_TABLES -DNDEBUG -DNVALGRIND -DDYNAMIC_ANNOTATIONS_ENABLED=0
-DGLIB_VERSION_MAX_ALLOWED=GLIB_VERSION_2_56

[Bug c++/109505] New: Compiler loops forever to OOM while compiling evaluate_prg_hwy.cc in Chromium

2023-04-13 Thread jdapena at igalia dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109505

Bug ID: 109505
   Summary: Compiler loops forever to OOM while compiling
evaluate_prg_hwy.cc in Chromium
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jdapena at igalia dot com
  Target Milestone: ---

Steps to reproduce:
1. Install kas tool
2. Clone https://github.com/Igalia/meta-chromium
3. Kick checkout of repositories:
  kas checkout kas/chromium.yml:kas/commercial.yml
3. Kick build for raspberrypi4-64:

KAS_MACHINE=raspberrypi4-64 kas build kas/chromium.yml:kas/commercial.yml

Compilation will progress, but then fail on building Chromium:

FAILED:
obj/third_party/distributed_point_functions/distributed_point_functions/evaluate_prg_hwy.o
 
aarch64-poky-linux-g++  -mcpu=cortex-a72 -march=armv8-a+crc
-fstack-protector-strong   -D_FORTIFY_SOURCE=2 -Wformat -Wformat-security
-Werror=format-security
--sysroot=/home/dape/Development/yocto/meta-chromium/build/tmp/work/cortexa72-poky-linux/chromium-dev/114.0.5696.0-r0/recipe-sysroot
-MMD -MF
obj/third_party/distributed_point_functions/distributed_point_functions/evaluate_prg_hwy.o.d
-DUSE_UDEV -DUSE_AURA=1 -DUSE_GLIB=1 -DUSE_OZONE=1 -DOFFICIAL_BUILD
-D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE
-DNO_UNWIND_TABLES -DNDEBUG -DNVALGRIND -DDYNAMIC_ANNOTATIONS_ENABLED=0
-DGLIB_VERSION_MAX_ALLOWED=GLIB_VERSION_2_56
-DGLIB_VERSION_MIN_REQUIRED=GLIB_VERSION_2_56
-DBASE_USE_PERFETTO_CLIENT_LIBRARY=1 -DGOOGLE_PROTOBUF_NO_RTTI
-DGOOGLE_PROTOBUF_NO_STATIC_INITIALIZER
-DGOOGLE_PROTOBUF_INTERNAL_DONATE_STEAL_INLINE=0 -DHAVE_PTHREAD
-I../chromium-114.0.5696.0 -Igen
-I../chromium-114.0.5696.0/third_party/distributed_point_functions
-I../chromium-114.0.5696.0/third_party/distributed_point_functions/code
-Igen/third_party/distributed_point_functions
-I../chromium-114.0.5696.0/third_party/perfetto/include
-Igen/third_party/perfetto/build_config -Igen/third_party/perfetto
-I../chromium-114.0.5696.0/third_party/protobuf/src -Igen/protoc_out
-I../chromium-114.0.5696.0/third_party/abseil-cpp
-I../chromium-114.0.5696.0/third_party/highway/src
-I../chromium-114.0.5696.0/third_party/boringssl/src/include -fno-ident
-fno-strict-aliasing --param=ssp-buffer-size=4 -fstack-protector
-fno-unwind-tables -fno-asynchronous-unwind-tables -fPIC -pipe -pthread
-mbranch-protection=standard -O2 -fdata-sections -ffunction-sections
-fno-omit-frame-pointer -gdwarf-4 -g1 -fvisibility=hidden
-Wno-unused-local-typedefs -Wno-maybe-uninitialized
-Wno-deprecated-declarations -Wno-comments -Wno-packed-not-aligned
-Wno-missing-field-initializers -Wno-unused-parameter -Wno-psabi
-I/home/dape/Development/yocto/meta-chromium/build/tmp/work/cortexa72-poky-linux/chromium-dev/114.0.5696.0-r0/recipe-sysroot/usr/include/glib-2.0
-I/home/dape/Development/yocto/meta-chromium/build/tmp/work/cortexa72-poky-linux/chromium-dev/114.0.5696.0-r0/recipe-sysroot/usr/lib/glib-2.0/include
-std=gnu++2a -fno-exceptions -fno-rtti -fvisibility-inlines-hidden
-Wno-narrowing -Wno-class-memaccess   -feliminate-unused-debug-types
-fmacro-prefix-map=/home/dape/Development/yocto/meta-chromium/build/tmp/work/cortexa72-poky-linux/chromium-dev/114.0.5696.0-r0/chromium-114.0.5696.0=/usr/src/debug/chromium-dev/114.0.5696.0-r0

-fdebug-prefix-map=/home/dape/Development/yocto/meta-chromium/build/tmp/work/cortexa72-poky-linux/chromium-dev/114.0.5696.0-r0/chromium-114.0.5696.0=/usr/src/debug/chromium-dev/114.0.5696.0-r0

-fmacro-prefix-map=/home/dape/Development/yocto/meta-chromium/build/tmp/work/cortexa72-poky-linux/chromium-dev/114.0.5696.0-r0/build=/usr/src/debug/chromium-dev/114.0.5696.0-r0

-fdebug-prefix-map=/home/dape/Development/yocto/meta-chromium/build/tmp/work/cortexa72-poky-linux/chromium-dev/114.0.5696.0-r0/build=/usr/src/debug/chromium-dev/114.0.5696.0-r0

-fdebug-prefix-map=/home/dape/Development/yocto/meta-chromium/build/tmp/work/cortexa72-poky-linux/chromium-dev/114.0.5696.0-r0/recipe-sysroot=

-fmacro-prefix-map=/home/dape/Development/yocto/meta-chromium/build/tmp/work/cortexa72-poky-linux/chromium-dev/114.0.5696.0-r0/recipe-sysroot=

-fdebug-prefix-map=/home/dape/Development/yocto/meta-chromium/build/tmp/work/cortexa72-poky-linux/chromium-dev/114.0.5696.0-r0/recipe-sysroot-native=
 -fvisibility-inlines-hidden -c
../chromium-114.0.5696.0/third_party/distributed_point_functions/code/dpf/internal/evaluate_prg_hwy.cc
-o
obj/third_party/distributed_point_functions/distributed_point_functions/evaluate_prg_hwy.o
{standard input}: Assembler messages:
{standard input}: Error: open CFI at the end of file; missing .cfi_endproc
directive
aarch64-poky-linux-g++: fatal error: Killed signal terminated program cc1plus
compilation terminated.
ninja: build stopped: subcommand failed.
WARNING: exit code 1 from a shell command.

This is after exhausting all the 

[Bug c++/105996] New: reinterpret_cast in constexpr failure creating a pair with a function pointer of class parent

2022-06-16 Thread jdapena at igalia dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105996

Bug ID: 105996
   Summary: reinterpret_cast in constexpr failure creating a pair
with a function pointer of class parent
   Product: gcc
   Version: 12.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jdapena at igalia dot com
  Target Milestone: ---

Created attachment 53150
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53150=edit
Test case

When creating an std::pair with a parameter that is a function pointer of the
parent class (but declared as function pointer of the same class), libstdc++
implementation will try to forward the pointer, even if it is the same type
(see the attached example).

This code is valid in Clang and MSVC, and was valid in GCC 5.x-7.x.


This has been detected through Chromium development with errors to compile
https://chromium.googlesource.com/chromium/src.git/+/refs/tags/105.0.5123.1/pdf/pdf_view_web_plugin.cc#879

[Bug c++/102995] Template friend class declaration of same class with different template parameters fails to allow private methods access

2021-11-02 Thread jdapena at igalia dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102995

--- Comment #4 from Jose Dapena Paz  ---
Definitely the proposed approach fixes the issue in GCC. And it looks to me it
makes more sense (it looks to me the code in Chromium is reversing the expected
meaning of friend there).

I will propose a fix to Chromium to use same approach (just verified it works).

Before closing this ticket... Could anybody with more knowledge of the applying
rules in standard give me the reference? It would improve the commit to
actually refer to the standard reason why we will replace the code.

[Bug c++/102995] New: Template friend class declaration of same class with different template parameters fails to allow private methods access

2021-10-29 Thread jdapena at igalia dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102995

Bug ID: 102995
   Summary: Template friend class declaration of same class with
different template parameters fails to allow private
methods access
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jdapena at igalia dot com
  Target Milestone: ---

Created attachment 51698
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51698=edit
Test case

Declaring a template friend class to the same class fails to resolve the access
to private members in its methods.

The provided example fails with this error:

  $ g++ main.cc 
  main.cc: In instantiation of 'bool operator==(const First&, const 
  First&) [with C = void*; A = int; B = bool]':
  main.cc:23:15:   required from here
  main.cc:13:61: error: 'int First::GetId() const [with A = void*; B = 
  bool]' is private within this context
 13 |  return lhs.GetId() == rhs.GetId();
|~^~
  main.cc:6:9: note: declared private here
  6 | int GetId() const {
| ^


The same case works in Clang  (verified with Clang 9.0.1).

This issue is exposed in Chromium, compiling base/raw_ptr.h unit tests on GCC.
I created a simplified version of the problem. See:

https://chromium.googlesource.com/chromium/src/base/+/821f1e481ce7c51d31486f26a74d343ffe4cf70e/memory/raw_ptr.h#496
(declaration of the method that should have friend access to rhs private
methods).

https://chromium.googlesource.com/chromium/src/base/+/821f1e481ce7c51d31486f26a74d343ffe4cf70e/memory/raw_ptr.h#584
(the friend class declaration).

https://chromium.googlesource.com/chromium/src/base/+/821f1e481ce7c51d31486f26a74d343ffe4cf70e/memory/raw_ptr_unittest.cc#328
(failing test compilation).