Re: [PATCH] (Re: Splitting up 27_io/basic_istream/ignore/wchar_t/94749.cc (takes too long))

Hi, I have noticed that in gcc-13, test05 (in the 94749.cc testcase) is still enabled for simulators, and I have noticed that because of test05, the 27_io/basic_istream/ignore/char/94749.cc execution test is not terminating on our simulator for armv8.1-m.main+mve, even after 3 hours. The

Re: [PATCH] middle-end/114070 - folding breaking VEC_COND expansion

Hi, I have found that this patch has introduced a regression in the arm-none-eabi toolchain for a testcase, which was previously passing: PASS->FAIL: gcc.dg/tree-ssa/andnot-2.c scan-tree-dump-not forwprop3 "_expr" The toolchain was built with: Build = x86_64-none-linux-gnu Host =

Re: [pushed][PR114415][scheduler]: Fixing wrong code generation

Hi, I have found that this patch has introduced a regression in the arm-none-eabi toolchain for a testcase in the libstdc++ testsuite, which was previously passing: FAIL: 27_io/basic_istream/ignore/char/94749.cc execution test The toolchain was built with: Build = x86_64-none-linux-gnu Host =

Re: [pushed] aarch64: Define out-of-class static constants

Hi Richard, I think this patch is breaking the build of aarch64-none-elf and aarch64-none-linux-gnu targets, when building with GCC 4.8. This is not an issue when building with GCC 7.5. Kind regards, Vasee From: Richard Sandiford Sent: 06 March 2024

Re: [PATCH v7] libgfortran: Replace mutex with rwlock

Hi Lipeng, It looks like your draft patch to fix the builds for arm-none-eabi target is not merged yet, because our arm-none-eabi builds are still broken. Are you waiting for additional information, or would you be able to fix this issue? Kind regards, Vasee

Re: [PATCH] tree-optimization/107672 - avoid vector mode type_for_mode call

Hi, I am seeing an internal compiler error, related to this patch: during GIMPLE pass: slp options-save.cc: In function 'void cl_optimization_restore(gcc_options*, gcc_options*, cl_optimization*)': options-save.cc:1292:1: internal compiler error: in supportable_widening_operation, at

Re: V3 [PATCH 1/2] Switch to a new section if the SECTION_RETAIN bit doesn't match

This patch fixes the section type conflict that I have been seeing. I have tested this patch using : Build: x86_64 Host: x86_64 Target: aarch64-none-linux-gnu On 08/12/2020, 12:52, "Gcc-patches on behalf of H.J. Lu via Gcc-patches" wrote: When definitions marked with used attribute and

Re: Fix handling of stores in modref_summary::useful_p

Hi, After this patch, I am noticing that some glibc crypto tests get stuck in scanf which goes into busy loop. My build/host/target setup is: Build: aarch64-none-linux-gnu Host: aarch64-none-linux-gnu Target: aarch64-none-linux-gnu Kind regards Vasee On 27/09/2020, 22:46, "Gcc-patches on

Re: [PING 2][PATCH 2/5] C front end support to detect out-of-bounds accesses to array parameters

After this patch, I am seeing this -Warray-parameter error: In file included from ../include/pthread.h:1, from ../sysdeps/nptl/thread_db.h:25, from ../nptl/descr.h:32, from ../sysdeps/aarch64/nptl/tls.h:44, from

Re: [PATCH] arm: Fix up gcc.target/arm/lto/pr96939_* FAIL

I am seeing this unused parameter 'opts' error when building for this configuration: Build: arm-none-linux-gnueabihf Host: arm-none-linux-gnueabihf Target: arm-none-linux-gnueabihf In function 'void arm_option_restore(gcc_options*, gcc_options*, cl_target_option*)':

Re: [PATCH] configure: Require C++11 for building code generation tools

Hi Tobias, This patch fixes the issue that I was seeing, thanks. I will also now try your updated patch from https://gcc.gnu.org/pipermail/gcc-patches/2020-August/552330.html Kind Regards Vasee On 20/08/2020, 17:29, "Tobias Burnus" wrote: Hi, how about my (unreviewed) patch for PR

Re: [PATCH] configure: Require C++11 for building code generation tools

Hi Szabolcs, In the top level gcc config.log, I see: configure:5541: checking whether aarch64-none-linux-gnu-g++ supports C++11 features by default configure:5837: aarch64-none-linux-gnu-g++ -c -g -O2 conftest.cpp >&5 configure:5837: $? = 0 configure:5844: result: yes configure:6542: checking