[Bug libgcc/108433] canadian cross aarch64/x86_64/aarch64 fails to build

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108433 Florian Weimer changed: What|Removed |Added CC||fw at gcc dot gnu.org --- Comment #1

[Bug tree-optimization/107608] [13 Regression] Failure on fold-overflow-1.c and pr95115.c

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107608 --- Comment #35 from Florian Weimer --- I backported the fixes for building glibc to 2.34 last week, I really expect the testsuite to be clean there (on x86-64), and on later releases as well.

[Bug libgcc/71744] Concurrently throwing exceptions is not scalable

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71744 Florian Weimer changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|---

[Bug middle-end/108278] [13 Regression] runtime error with -O1 -Wall

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108278 --- Comment #8 from Florian Weimer --- I believe the revert in 455acc43518744b89d6a795bbba5045bd228060b should have fixed this? I also brought up the initialization issue on the gcc list: Default initialization of poly-ints

[Bug target/108267] [13 Regression] Bootstrap failure on aarch64-linux since r13-4953

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108267 Florian Weimer changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |fw at gcc dot gnu.org

[Bug target/108267] [13 Regression] Bootstrap failure on aarch64-linux since r13-4953

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108267 --- Comment #2 from Florian Weimer --- Fixed with the revert in commit 455acc43518744b89d6a795bbba5045bd228060b.

[Bug target/104688] gcc and libatomic can use SSE for 128-bit atomic loads on Intel and AMD CPUs with AVX

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104688 --- Comment #28 from Florian Weimer --- (In reply to Peter Cordes from comment #27) > (In reply to Alexander Monakov from comment #26) > > Sure, the right course of action seems to be to simply document that atomic > > types and built-ins are

[Bug c/107805] [12/13 Regression] Spurious “type defaults to ‘int’” warning after redefinition of type

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107805 Florian Weimer changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |fw at gcc dot gnu.org

[Bug c/107805] [12/13 Regression] Spurious “type defaults to ‘int’” warning after redefinition of type

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107805 --- Comment #4 from Florian Weimer --- Patch posted: [PATCH] c: Propagate erroneous types to declaration specifiers [PR107805]

[Bug c/107805] [12/13 Regression] Spurious “type defaults to ‘int’” warning after redefinition of type

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107805 Florian Weimer changed: What|Removed |Added CC||roger at nextmovesoftware dot com

[Bug c/107805] New: Spurious warning after redefinition of type

Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: fw at gcc dot gnu.org Target Milestone: --- With gcc-11.3.1-3.fc35.x86_64, this program typedef int t; typedef struct { double a; int b; } t; t x; produces: t.c:2:37: error: conflicting types

[Bug libstdc++/107675] [13 Regression] GCC-13 is significantly slower to startup on C++ programs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107675 --- Comment #8 from Florian Weimer --- (In reply to Tamar Christina from comment #4) > /opt/buildAgent/work/5c94c4ced6ebfcd0/libgcc/unwind-dw2-fde.c:111 > #6 __register_frame_info (begin=, ob=0x48cfe8 ) at >

[Bug libstdc++/107675] [13 Regression] GCC-13 is significantly slower to startup on C++ programs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107675 --- Comment #3 from Florian Weimer --- Would you please put a breakpoint on fde_single_encoding_compare and report the backtrace? Which target are you testing?

[Bug target/107606] rs6000: Option not to use parameter save area in variadic function implementations

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107606 --- Comment #2 from Florian Weimer --- (In reply to Segher Boessenkool from comment #1) > Or what else is the intention? Do you have an example of something that was > hard to debug, maybe? The prctl(2) manual page documents the prctl

[Bug target/107606] New: rs6000: Option not to use parameter save area in variadic function implementations

Severity: enhancement Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: fw at gcc dot gnu.org CC: bergner at gcc dot gnu.org Target Milestone: --- Target: powerpc64le-*-linux-gnu Programmers tend

[Bug c/82922] Request: add -Wstrict-prototypes to -Wextra as K style is obsolescent

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82922 --- Comment #11 from Florian Weimer --- (In reply to David Brown from comment #9) > Could -Wstrict-prototypes be added to -Wall, or even considered enabling by > default? The next C standard will make "void foo()" mean the same as "void >

[Bug target/80878] -mcx16 (enable 128 bit CAS) on x86_64 seems not to work on 7.1.0

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80878 --- Comment #39 from Florian Weimer --- (In reply to Jakub Jelinek from comment #38) > Please see PR104688 . We got a response from Intel, where they guaranteed > atomicity of certain 16-byte load instructions for Intel CPUs with AVX > support.

[Bug target/55522] -funsafe-math-optimizations is unexpectedly harmful, especially w/ -shared

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55522 --- Comment #25 from Florian Weimer --- (In reply to H.J. Lu from comment #24) > Dropping crtfastmath.o with -shared makes sense. Are you going to send a patch? I can give it a try as well (although I'm not familiar with the GCC specs

[Bug target/55522] -funsafe-math-optimizations is unexpectedly harmful, especially w/ -shared

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55522 Florian Weimer changed: What|Removed |Added CC||fw at gcc dot gnu.org --- Comment #21

[Bug c/91093] Error on implicit int by default

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91093 --- Comment #2 from Florian Weimer --- It seems that auto x = 1.0; will change meaning in C2X (as implemented by GCC) and use type double instead of int for x. We are probably way too late to fix this (by rejecting the construct in earlier

[Bug c/106416] -Wint-conversion should be an error, not a pedwarn

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106416 Florian Weimer changed: What|Removed |Added CC||fw at gcc dot gnu.org --- Comment #1

[Bug lto/105727] __builtin_constant_p expansion in LTO

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105727 Florian Weimer changed: What|Removed |Added CC||fw at gcc dot gnu.org --- Comment #2

[Bug target/104208] -mlong-double-64 should override a previous -mabi=ibmlongdouble

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104208 --- Comment #13 from Florian Weimer --- Thanks, I can confirm that we can build the glibc test suite once more in Fedora rawhide. (Fedora only needs the GCC 12 fix, it's our first GCC version with the float128 default).

[Bug target/104208] -mlong-double-64 should override a previous -mabi=ibmlongdouble

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104208 --- Comment #8 from Florian Weimer --- (In reply to Peter Bergner from comment #7) > Florian, can you confirm that -mlong-double-64 comes after the > -mabi=ibmlongdouble option in the problematical glibc build? The mailing list post referenced

[Bug target/104688] gcc and libatomic can use SSE for 128-bit atomic loads on Intel CPUs with AVX

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104688 --- Comment #3 from Florian Weimer --- I feel we should give AMD some time to comment here. If they can commit supporting it like Intel did, that alters the design space somewhat.

[Bug c/85487] Support '#pragma region' and '#pragma endregion' to allow code folding with Visual Studio

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85487 Florian Weimer changed: What|Removed |Added CC||fw at gcc dot gnu.org --- Comment #11

[Bug libgcc/104207] [12 Regression] Crash in _Unwind_Find_FDE if object lacks unwind information

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104207 Florian Weimer changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED

[Bug libgcc/104207] [12 Regression] Crash in _Unwind_Find_FDE if object lacks unwind information

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104207 --- Comment #2 from Florian Weimer --- Patch posted: https://gcc.gnu.org/pipermail/gcc-patches/2022-January/589177.html

[Bug libgcc/104207] [12 Regression] Crash in _Unwind_Find_FDE if object lacks unwind information

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104207 Florian Weimer changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |fw at gcc dot gnu.org

[Bug target/104208] -mlong-double-64 should override a previous -mabi=ibmlongdouble

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104208 Florian Weimer changed: What|Removed |Added Priority|P3 |P1 --- Comment #1 from Florian Weimer

[Bug target/104208] New: -mlong-double-64 should override a previous -mabi=ibmlongdouble

Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: fw at gcc dot gnu.org Target Milestone: --- Build: powerpc64le-*-linux-gnu We have trouble building glibc 2.35 with GCC 12 because -mlong-double-64 and -mabi

[Bug libgcc/104207] New: [12 Regression] Crash in _Unwind_Find_FDE if object lacks unwind information

: normal Priority: P3 Component: libgcc Assignee: unassigned at gcc dot gnu.org Reporter: fw at gcc dot gnu.org Target Milestone: --- Build: *-*-linux-gnu r12-6210 lacks a NULL check for dlfo_eh_frame. This causes crashes when unwinding through

[Bug tree-optimization/103964] [9/10/11/12 Regression] OVS miscompilation since r0-92313-g5006671f1aaa63cd

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103964 Florian Weimer changed: What|Removed |Added CC||fw at gcc dot gnu.org --- Comment #1

[Bug rtl-optimization/103762] [12 Regression] glibc master branch is miscompiled by r12-897

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103762 Florian Weimer changed: What|Removed |Added CC||fw at gcc dot gnu.org --- Comment #9

[Bug testsuite/101751] asan_test.C fails with excess error with glibc-2.34

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101751 --- Comment #3 from Florian Weimer --- Patch posted: [PATCH] Avoid expecting nonzero size for access none void* arguments [PR101751] https://gcc.gnu.org/pipermail/gcc-patches/2021-November/585377.html

[Bug target/103395] [9/10/11/12 Regression] ICE on qemu in arm create_fix_barrier

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103395 Florian Weimer changed: What|Removed |Added CC||fw at gcc dot gnu.org --- Comment #13

[Bug libstdc++/103133] Binary built with -static using std::thread crashes

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103133 Florian Weimer changed: What|Removed |Added CC||fw at gcc dot gnu.org --- Comment #2

[Bug target/102625] [meta-bug] -mcmodel=large can't link

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102625 Florian Weimer changed: What|Removed |Added CC||fw at gcc dot gnu.org --- Comment #2

[Bug tree-optimization/102329] pointer "maybe uninitialized" right after assignment

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102329 Florian Weimer changed: What|Removed |Added See Also||https://sourceware.org/bugz

[Bug libstdc++/102567] Missing noexcept specialization of std::function

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102567 --- Comment #3 from Florian Weimer --- (In reply to Jonathan Wakely from comment #1) > This is not a libstdc++ bug, we implement what the standard says. > > Maybe it used to compile, but it was meaningless. You could say it was a > function of

[Bug libstdc++/102567] New: Missing noexcept specialization of std::function

Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: fw at gcc dot gnu.org Target Milestone: --- When C++17 made noexcept part of the type system, std::function was not updated accordingly. As a result, this program fails to compile: #include std::function f

[Bug target/101761] Random hang with 29_atomics/atomic_ref/wait_notify.cc

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101761 --- Comment #7 from Florian Weimer --- (In reply to Jonathan Wakely from comment #6) > (In reply to Florian Weimer from comment #4) > > a.wait(aa); > > This line is undefined and needs to be a.wait(va) anyway. Yes, that's what I meant.

[Bug target/101761] Random hang with 29_atomics/atomic_ref/wait_notify.cc

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101761 Florian Weimer changed: What|Removed |Added CC||fw at gcc dot gnu.org --- Comment #4

[Bug ipa/102059] Incorrect always_inline diagnostic in LTO mode with #pragma GCC target("cpu=power10")

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102059 --- Comment #12 from Florian Weimer --- (In reply to Richard Biener from comment #10) > As of HTM it would make the testcase a user error - when using -mcpu=power10 > it would require building with -mcpu=power8 -mno-htm? Or -mcpu=power8 should

[Bug lto/102059] New: Incorrect always_inline diagnostic in LTO mode with #pragma GCC target("cpu=power10")

NCONFIRMED Keywords: diagnostic, rejects-valid Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: fw at gcc dot gnu.org CC: marxin at gcc dot gnu.org Target Milestone: --- Targe

[Bug testsuite/101751] asan_test.C fails with excess error with glibc-2.34

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101751 Florian Weimer changed: What|Removed |Added CC||fw at gcc dot gnu.org --- Comment #1

[Bug middle-end/101415] New: [12 Regression] Bogus -Warray-bounds warning with stpcpy

Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: fw at gcc dot gnu.org Target Milestone: --- This (derived from the glibc function of the same name): char * nis_local_group (char *cptr) { static char

[Bug target/100811] Consider not omitting frame pointers by default on targets with many registers

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100811 Florian Weimer changed: What|Removed |Added CC||fw at gcc dot gnu.org --- Comment #2

[Bug tree-optimization/98512] [11/12 Regression] “#pragma GCC diagnostic ignored” ineffective in conjunction with alias attribute

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98512 --- Comment #8 from Florian Weimer --- This glibc commit works around the GCC issue: commit 044e603b698093cf48f6e6229e0b66acf05227e4 Author: Florian Weimer Date: Fri Feb 19 13:29:00 2021 +0100 string: Work around GCC PR 98512 in

[Bug libstdc++/100117] FAIL testsuite/17_intro/headers/c++1998/49745.cc with trunk glibc

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100117 --- Comment #3 from Florian Weimer --- I was looking at the 17_intro/headers/c++1998/49745.cc file contents and can't make sense of the error message in that context. There's no in it.

[Bug libstdc++/100117] FAIL testsuite/17_intro/headers/c++1998/49745.cc with trunk glibc

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100117 --- Comment #1 from Florian Weimer --- This looks like the old C++ _GNU_SOURCE issue. But I do not really see why includes . Is this some PCH test? Should really include all the C headers?

[Bug c/99587] warning: ‘retain’ attribute ignored while __has_attribute(retain) is 1

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99587 --- Comment #4 from Florian Weimer --- For retain, something along these lines might work: diff --git a/gcc/c-family/c-attribs.c b/gcc/c-family/c-attribs.c index c1f652d1dc9..cdae464ab8a 100644 --- a/gcc/c-family/c-attribs.c +++

[Bug c/99587] warning: ‘retain’ attribute ignored while __has_attribute(retain) is 1

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99587 --- Comment #2 from Florian Weimer --- The problem is that if GCC is not configured for SHF_GNU_RETAIN, __has_attribute (retain) should not be true. That is, __has_attribute needs to reflect the actual attribute support status, and not what

[Bug ada/99264] Ada doesn't build against latest glibc

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99264 --- Comment #5 from Florian Weimer --- (In reply to Eric Botcazou from comment #4) > This looks like a serious compatibility breakage on the glibc side though. POSIX does not require that the constant is usable in preprocessor macros, so the

[Bug ada/99264] Ada doesn't build against latest glibc

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99264 --- Comment #3 from Florian Weimer --- As a stop-gap measure, it might be possible to replace the preprocessor check with a run-time check during initialization.

[Bug ada/99264] Ada doesn't build against latest glibc

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99264 Florian Weimer changed: What|Removed |Added CC||hjl.tools at gmail dot com --- Comment

[Bug libstdc++/66146] call_once not C++11-compliant on ppc64le

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66146 --- Comment #45 from Florian Weimer --- Statically linking libstdc++ into shared objects is also not too uncommon. With luck, the libstdc++ symbols are hidden, but operating on globally shared across multiple libstdc++s exposes similar issues

[Bug sanitizer/98920] [10/11 Regression] uses regexec without support for REG_STARTEND with -fsanitize=address

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98920 --- Comment #9 from Florian Weimer --- (In reply to Jakub Jelinek from comment #8) > Even if it does, exporting regexec@@GLIBC_2.3.4 from libsanitizer when glibc > doesn't support that symbol looks wrong. I think all the interceptors use

[Bug sanitizer/98920] [10/11 Regression] uses regexec without support for REG_STARTEND with -fsanitize=address

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98920 Florian Weimer changed: What|Removed |Added CC||fw at gcc dot gnu.org --- Comment #7

[Bug c++/33661] template methods forget explicit local register asm vars

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33661 Florian Weimer changed: What|Removed |Added CC||nate at verse dot com --- Comment #20

[Bug c++/58118] Local variables specified with asm("reg") may not work

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58118 Florian Weimer changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|---

[Bug tree-optimization/98512] [11 Regression] “#pragma GCC diagnostic ignored” ineffective in conjunction with alias attribute

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98512 --- Comment #5 from Florian Weimer --- Note, patch has been superseded: https://gcc.gnu.org/pipermail/gcc-patches/2021-January/564060.html

[Bug target/97683] [11 Regression] nios2 assembler branch offset errors building glibc

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97683 Florian Weimer changed: What|Removed |Added See Also||https://sourceware.org/bugz

[Bug target/97683] [11 Regression] nios2 assembler branch offset errors building glibc

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97683 --- Comment #3 from Florian Weimer --- Thanks. The -Werror failure you reported is due to PR98512. Martin has posted a patch: https://gcc.gnu.org/pipermail/gcc-patches/2021-January/564060.html Should I open a binutils bug with the generated .s

[Bug rtl-optimization/98788] simplify_replace_fn_rtx crash on riscv64-glibc-linux-gnu for glibc sincos32.c

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98788 --- Comment #2 from Florian Weimer --- Indeed, thanks, seems to be working again.

[Bug target/97683] [11 Regression] nios2 assembler branch offset errors building glibc

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97683 Florian Weimer changed: What|Removed |Added CC||fw at gcc dot gnu.org --- Comment #1

[Bug rtl-optimization/98788] New: simplify_replace_fn_rtx crash on riscv64-glibc-linux-gnu for glibc sincos32.c

: ice-on-valid-code Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: fw at gcc dot gnu.org Target Milestone: --- Created attachment 50026 --> https://gcc.gnu.org/bugzilla/attachment.cgi

[Bug target/98618] aarch64: oob adrp offset causes relocation truncated to fit: R_AARCH64_ADR_PREL_PG_HI21

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98618 --- Comment #1 from Florian Weimer --- Is the test case really valid? It involves an out-of-bounds array access, after all.

[Bug tree-optimization/98512] New: “#pragma GCC diagnostic ignored” ineffective in conjunction with alias attribute

: diagnostic Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: fw at gcc dot gnu.org CC: msebor at gcc dot gnu.org Target Milestone: --- The following test case has been

[Bug other/98121] __attribute__ ((used)) should not imply SHF_RETAIN_SECTION

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98121 --- Comment #6 from Florian Weimer --- (In reply to Jozef Lawrynowicz from comment #4) > GAS merges the "R" flag state in .section declarations, silently, and with > logical OR, and GCC should do the same. So if you have: > > int

[Bug tree-optimization/98110] [11 Regression] dl-lookup.c in glibc is miscompiled by r11-5029

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98110 Florian Weimer changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|---

[Bug target/98121] New: __attribute__ ((used)) should not imply SHF_RETAIN_SECTION

Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: fw at gcc dot gnu.org Target Milestone: --- The used attribute has already a defined meaning. I think it's wrong to cause it to change section attributes because people use it to interface

[Bug tree-optimization/98110] [11 Regression] dl-lookup.c in glibc is miscompiled by r11-5029

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98110 --- Comment #17 from Florian Weimer --- Jakub's glibc test failures were due to --prefix=/usr/local, so that glibc wouldn't find the installed system libgcc_s in /usr/lib64.

[Bug tree-optimization/98110] [11 Regression] dl-lookup.c in glibc is miscompiled by r11-5029

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98110 --- Comment #12 from Florian Weimer --- (In reply to Jakub Jelinek from comment #11) > Ah, RTL loop_invariant. Perhaps because the inline asm is buggy? > asm ("mov %%fs:%c1,%0" : "=r" (__self) : "i" (__builtin_offsetof (struct > pthread,

[Bug tree-optimization/98110] [11 Regression] dl-lookup.c in glibc is miscompiled by r11-5029

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98110 --- Comment #9 from Florian Weimer --- And we should not end up in the add_dependency part, either because l_type won't be lt_loaded and the DL_LOOKUP_ADD_DEPENDENCY flag hasn't been set, either. The inline asm is marked as volatile, and that

[Bug tree-optimization/98110] [11 Regression] dl-lookup.c in glibc is miscompiled by r11-5029

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98110 --- Comment #8 from Florian Weimer --- (In reply to Jakub Jelinek from comment #6) > on the mov %fs:0x10,%rax perhaps %fs isn't initialized yet? Yes, that's why the access is guarded by flags & DL_LOOKUP_GSCOPE_LOCK. During initial relocation,

[Bug tree-optimization/97424] Warn on invalid shift amount after inlining

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97424 --- Comment #6 from Florian Weimer --- (In reply to David Malcolm from comment #5) > The above commit implements it as an analyzer warning. Should I close this > out, or should we keep it open for the __builtin_warning approach? Thanks for the

[Bug tree-optimization/97424] Warn on invalid shift amount after inlining

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97424 --- Comment #2 from Florian Weimer --- Indeed, Martin Sebor has suggested that it would have to be coupled with __builtin_warning: https://gcc.gnu.org/legacy-ml/gcc-patches/2019-10/msg01015.html

[Bug tree-optimization/97424] New: Warn on invalid shift amount after inlining

Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: fw at gcc dot gnu.org Target Milestone: --- Consider this program: #include static inline uint32_t _dl_hwcaps_subdirs_build_bitmask (int subdirs, int active) { /* Leading

[Bug target/97250] Implement -march=x86-64-v2, -march=x86-64-v3, -march=x86-64-v4 for x86-64

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97250 --- Comment #7 from Florian Weimer --- (In reply to H.J. Lu from comment #6) > (In reply to Florian Weimer from comment #5) > > (In reply to H.J. Lu from comment #4) > > > x86-64-v2 includes CMPXCHG16B, aka CX16. But -mcx16 doesn't define > > >

[Bug target/97250] Implement -march=x86-64-v2, -march=x86-64-v3, -march=x86-64-v4 for x86-64

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97250 --- Comment #5 from Florian Weimer --- (In reply to H.J. Lu from comment #4) > x86-64-v2 includes CMPXCHG16B, aka CX16. But -mcx16 doesn't define __CX16__. It's called __GCC_HAVE_SYNC_COMPARE_AND_SWAP_16, I think. Is this good enough?

[Bug target/97250] Implement -march=x86-64-v2, -march=x86-64-v3, -march=x86-64-v4 for x86-64

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97250 Florian Weimer changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|---

[Bug target/97250] Implement -march=x86-64-v2, -march=x86-64-v3, -march=x86-64-v4 for x86-64

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97250 --- Comment #1 from Florian Weimer --- First patch committed (preparatory only): https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=92e652d8c21bd7e66c Second patch posted: https://gcc.gnu.org/pipermail/gcc-patches/2020-September/555174.html

[Bug target/97250] Implement -march=x86-64-v2, -march=x86-64-v3, -march=x86-64-v4 for x86-64

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97250 Florian Weimer changed: What|Removed |Added Last reconfirmed||2020-09-30

[Bug target/97250] New: Implement -march=x86-64-v2, -march=x86-64-v3, -march=x86-64-v4 for x86-64

: normal Priority: P3 Component: target Assignee: fw at gcc dot gnu.org Reporter: fw at gcc dot gnu.org Target Milestone: --- Target: x86_64-*-* x86-64-v2, x86-64-v3, x86-64-v4 have been added to the psABI as new micro-architecture levels: https

[Bug tree-optimization/40770] Vectorization of complex types, vectorization of sincos missing

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40770 Florian Weimer changed: What|Removed |Added CC||fw at gcc dot gnu.org --- Comment #16

[Bug tree-optimization/96951] strncpy truncation warning does not recognize truncation check

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96951 --- Comment #4 from Florian Weimer --- Thanks. Checking for the null byte at the end (as in comment 0) currently seems the most convenient way. Writing those additional null bytes is not entirely free. As an industry standard, the strlcpy

[Bug preprocessor/96952] __builtin_thread_pointer support cannot be probed

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96952 Florian Weimer changed: What|Removed |Added CC||fw at gcc dot gnu.org See

[Bug tree-optimization/96951] strncpy truncation warning does not recognize truncation check

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96951 --- Comment #2 from Florian Weimer --- Then the warning should recommend to use memccpy, perhaps? if (memccpy (p->string, s, '\0', sizeof (p->string)) == NULL) return -1; return 0; -- Red Hat GmbH, https://de.redhat.com/ , Registered

[Bug tree-optimization/96951] New: strncpy truncation warning does not recognize truncation check

Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: fw at gcc dot gnu.org Target Milestone: --- This code example produces a warning: #include struct buffer { char string[10]; }; int f

[Bug middle-end/96200] Implement __builtin_thread_pointer() and __builtin_set_thread_pointer() if TLS is supported

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96200 --- Comment #8 from Florian Weimer --- (In reply to H.J. Lu from comment #7) > Give that the tcb field is setup by the C run-time on Linux/x86, should > it be provided by a run-time header file? Yes, it seems reasonable to me. Ideally, it would

[Bug middle-end/96200] Implement __builtin_thread_pointer() and __builtin_set_thread_pointer() if TLS is supported

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96200 --- Comment #6 from Florian Weimer --- (In reply to H.J. Lu from comment #4) > On Linux/i386 and Linux/x86-64, thread pointer access is done via syscall. > On Linux/x86-64, __builtin_thread_pointer and __builtin_set_thread_pointer > may be

[Bug c/96832] Wrong assumption for -Werror=nonnull check

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96832 Florian Weimer changed: What|Removed |Added CC||fw at gcc dot gnu.org --- Comment #2

[Bug c/96460] Warn about signed modulo that is converted to unsigned value

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96460 --- Comment #4 from Florian Weimer --- (In reply to Eric Gallager from comment #3) > There already is a warning from -Wsign-conversion for it: It's for the conversion, not the modulo. My hypothesis is that for the modulo, the warning is much

[Bug c++/96500] enum of underlying type bool does not accept enumerators with integer constant values other than 0 and 1

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96500 Florian Weimer changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|---

[Bug c++/96500] New: enum of underlying type bool do not

Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: fw at gcc dot gnu.org Target Milestone: --- I believe this needs to be accepted: enum E : bool { One, Two, Three }; See <http://eel.is/c++draft/dcl.enum#5>, “If the underlying type is fixed, th

[Bug c++/96496] New: Conversion to enum with underlying type bool produces wrong result

Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: fw at gcc dot gnu.org Target Milestone: --- enum E : bool { One, Two }; int f1 (int x) { return (E) x; } The conversion must first be to type bool

[Bug c/96460] Warn about signed module that is converted to unsigned value

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96460 --- Comment #2 from Florian Weimer --- (In reply to Richard Biener from comment #1) > It's perfectly valid code ... guess similar to -Wconversion though. If the modulo result is never negative, it's not *perfectly* valid because GCC has to add

[Bug middle-end/96460] New: Warn about signed module that is converted to unsigned value

Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: fw at gcc dot gnu.org Target Milestone: --- I do not know how many warnings it would generate to warn for code like this (if i is not known to be non

[Bug c/96284] Outdated C features should be made errors with newer standards

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96284 --- Comment #7 from Florian Weimer --- (In reply to David Brown from comment #6) > I'm not bothered about my own code - I have makefiles with the relevant > options set in case I make mistakes. My hope is for gcc to be able to have > stricter

<    1   2   3   4   5   >