[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 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 unversi

[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 ev

[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 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 --- 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 cod

[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 rawmemch

[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 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 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/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 sanitizer/100114] libasan built against latest glibc doesn't work

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100114 --- Comment #13 from Florian Weimer --- (In reply to Alexander Enaldiev from comment #12) > But here I see status 'RESOLVED FIXED'. Do you presume, my today's issue > isn't connected? It could still be the same bug. It's supposed to be fixed in

[Bug c/108694] need a new warning option for preparing migration to ISO C 23

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

[Bug sanitizer/108777] Add support for --param asan-kernel-mem-intrinsic-prefix=1

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

[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 #30 from Florian Weimer --- (In reply to Segher Boessenkool from comment #29) > (In reply to Florian Weimer from comment #28) > > Maybe this belongs in the ABI manual? For example, the POWER ABI says that > > memcpy needs to work on

[Bug libstdc++/108969] [13 Regression] Initializing iostreams in the library needs a GLIBCXX_3.4.31 versioned symbol

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108969 --- Comment #6 from Florian Weimer --- (In reply to Jonathan Wakely from comment #2) > --- a/libstdc++-v3/src/c++98/globals_io.cc > +++ b/libstdc++-v3/src/c++98/globals_io.cc > @@ -43,6 +43,12 @@ > // In macro form: > // _GLIBCXX_ASM_SYMVER(cu

[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 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 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/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 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 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 lang

[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 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 language).

[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 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 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 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 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 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 Resolution|--- |FIXED Status|ASSIGNED

[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/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 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 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 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 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. O

[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 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 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 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 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 c/82922] Request: add -Wstrict-prototypes to -Wextra as K&R 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 > foo(vo

[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 to

[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 function

[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 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 > /opt/buildAgent/work/5c94c4ced6ebfcd

[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 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] [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 Assignee|unassigned at gcc dot gnu.org |fw at gcc dot gnu.org

[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 me

[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/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 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 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 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 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 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 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 target/113874] New: GNU2 TLS descriptor calls do not follow psABI on x86_64-linux-gnu

-code Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: fw at gcc dot gnu.org Target Milestone: --- Target: x86_64-linux-gnu Consider this test case: struct tls { long a, b, c, d

[Bug target/113874] GNU2 TLS descriptor calls do not follow psABI on x86_64-linux-gnu

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113874 --- Comment #1 from Florian Weimer --- Brought to the x86-64 ABI list: GCC and the GNU2 TLS descriptor call ABI

[Bug target/113874] GNU2 TLS descriptor calls do not follow psABI on x86_64-linux-gnu

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113874 --- Comment #6 from Florian Weimer --- > (In reply to H.J. Lu from comment #4) > > (In reply to H.J. Lu from comment #3) > > > Created attachment 57385 [details] > > > A patch > > > > > > Try this. > > > > This doesn't work properly. To work

[Bug target/113874] GNU2 TLS descriptor calls do not follow psABI on x86_64-linux-gnu

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113874 --- Comment #9 from Florian Weimer --- (In reply to H.J. Lu from comment #7) > > The __tls_get_addr call with the default approach potentially needs to solve > > the same problem, doesn't it? > > Isn't __tls_get_addr called via the PLT entry?

[Bug target/113874] GNU2 TLS descriptor calls do not follow psABI on x86_64-linux-gnu

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113874 --- Comment #11 from Florian Weimer --- (In reply to Richard Biener from comment #10) > I think a glibc fix would be very much preferred. It's a bit of a maintenance nightmare because we have to update the code slightly each time new registers

[Bug target/113874] GNU2 TLS descriptor calls do not follow psABI on x86_64-linux-gnu

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113874 --- Comment #18 from Florian Weimer --- (In reply to Richard Biener from comment #16) > I do wonder why __tls_get_addr would have to call the overloaded malloc, can > we just not force-bind it to the glibc local malloc (and make sure that's > co

[Bug target/113874] GNU2 TLS descriptor calls do not follow psABI on x86_64-linux-gnu

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113874 --- Comment #20 from Florian Weimer --- (In reply to H.J. Lu from comment #19) > (In reply to Florian Weimer from comment #9) > > (In reply to H.J. Lu from comment #7) > > > > The __tls_get_addr call with the default approach potentially needs t

[Bug sanitizer/113728] libasan uses incorrect prctl prototype

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113728 --- Comment #2 from Florian Weimer --- This has been worked around in glibc. Should we close this issue?

[Bug sanitizer/113728] libasan uses incorrect prctl prototype

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

[Bug libquadmath/114533] libquadmath: printf: fix misaligned access on args

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114533 --- Comment #4 from Florian Weimer --- This looks like a glibc bug to me.

[Bug target/110899] RFE: Attributes preserve_most and preserve_all

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

[Bug target/110899] RFE: Attributes preserve_most and preserve_all

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110899 --- Comment #5 from Florian Weimer --- (In reply to Michael Matz from comment #3) > For ABIs you generally want a good mix between caller- and callee-saved > registers. The x86-64 psABI didn't do that on the SSE regs for conscious, but > meanwhi

[Bug target/110899] RFE: Attributes preserve_most and preserve_all

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110899 --- Comment #8 from Florian Weimer --- (In reply to Michael Matz from comment #7) > > > Does the clang implementation take into account the various problematic > > > cases that arise when calling a normal function from a (say) preserve_all > > >

[Bug target/110899] RFE: Attributes preserve_most and preserve_all

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110899 --- Comment #10 from Florian Weimer --- (In reply to Michael Matz from comment #9) > > > I don't see how that helps. Imagine a preserve_all function foo that > > > calls > > > printf. How do you propose that 'foo' saves all parts of the SSE

[Bug c++/106310] [12/13 Regression] lookup after this-> seems wrong for dependent lookup since r12-6754-g30f2c22def739211

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

[Bug target/106101] [12 Regression] ICE in reg_bitfield_target_p since r12-4428-g147ed0184f403b

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

[Bug target/106101] [12 Regression] ICE in reg_bitfield_target_p since r12-4428-g147ed0184f403b

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106101 --- Comment #31 from Florian Weimer --- (In reply to Andrew Pinski from comment #30) > And you can even make it a pointer to a pointer of char to hit the same bug > to get around the even more fuzziness of freeing an int rather than a > pointer:

[Bug c/116313] -Wsequence-point false positive with auto and/or __auto_type

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116313 --- Comment #1 from Florian Weimer --- The warning for typeof in this context seems bogus as well because it follows the evaluation rules for sizeof: “ The operand of ‘typeof’ is evaluated for its side effects if and only if it is an expression

[Bug c/116313] -Wsequence-point false positive with auto and/or __auto_type

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116313 --- Comment #3 from Florian Weimer --- Right, missed that, sorry.

[Bug libstdc++/108969] [13/14 Regression] Initializing iostreams in the library needs a GLIBCXX_3.4.31 versioned symbol

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108969 --- Comment #23 from Florian Weimer --- (In reply to Jakub Jelinek from comment #20) > So, when the @@GLIBCXX_3.4.31 alias is weak, at least the F36 linker puts > into the binary not just one but both symbols and so the aliasing isn't > broken.

[Bug c/66425] (void) cast doesn't suppress __attribute__((warn_unused_result))

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425 --- Comment #50 from Florian Weimer --- (In reply to Jakub Jelinek from comment #49) > All that means is for APIs for which cast to void as silencing is meant to > be ok should be using [[nodiscard]] rather than > __attribute__((warn_unused_resul

[Bug libgcc/109540] Y2038: GCC gthr-posix.h weakref symbol invoking function has impact on time values

||a/show_bug.cgi?id=103133 CC||fw at gcc dot gnu.org --- Comment #13 from Florian Weimer --- (In reply to Jonathan Wakely from comment #11) > (In reply to Jonathan Wakely from comment #10) > > If you have g

[Bug c/109826] New: Incompatible pointer types in ?: not covered by -Wincompatible-pointer-types

: diagnostic Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: fw at gcc dot gnu.org Target Milestone: --- This: int *p; long *q; char * f (int x) { return x ? p : q; } warns as follows: warning

[Bug c/109827] New: Pointer/integer mismatch in ?: not covered by -Wint-conversion

Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: fw at gcc dot gnu.org Target Milestone: --- This: int p; long *q; void * f1 (int x) { return x ? p : q; } void * f2 (int x) { return x ? q : p

[Bug c/109826] Incompatible pointer types in ?: not covered by -Wincompatible-pointer-types

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109826 --- Comment #1 from Florian Weimer --- I guess the main issue here is that the common type void * for both the second and third operand is implicitly converted to many pointer types, including the original types of those operands. So while conve

[Bug c/95445] diagnose incompatible calls to functions declared without prototype

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

[Bug c/109835] -Wincompatible-function-pointer-types as a subset of -Wincompatible-pointer-types?

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109835 --- Comment #1 from Florian Weimer --- Presumably the idea is to enable -Werror=incompatible-function-pointer-types (in spirit) because it is more severe than -Wincompatible-pointer-types? I'm not sure this is actually true. Your first example

[Bug c/109836] New: -Wpointer-sign must be enabled by default

Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: fw at gcc dot gnu.org Target Milestone: --- Assignment between incompatible pointers is a constraint violation and has to be diagnosed in some way. If GCC does not want to error on

[Bug libfortran/114646] libgfortran doesn't work with static libpthread

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

[Bug libgcc/114646] libgcc's gthr.h still defines GTHREAD_USE_WEAK to 1 for newer glibc

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114646 --- Comment #8 from Florian Weimer --- (In reply to Andrew Pinski from comment #6) > What was done for libstdc++ was only specific to libstdc++ even though it > uses the same headers, it was not changed for the generic libgcc code which > is use

[Bug c/71255] Implement #pragma may_alias

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71255 --- Comment #31 from Florian Weimer --- Fixed via r7-1272. Thanks!

[Bug c/115310] Option -Werror=return-type is too aggressive with -std=gnu89

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115310 --- Comment #3 from Florian Weimer --- This is just following the previous GCC behavior. For example, with GCC 11: $ gcc -S -Werror=return-type -std=gnu89 t.c t.c:1:1: error: return type defaults to ‘int’ [-Werror=return-type] 1 | main () {

[Bug c/115310] Option -Werror=return-type is too aggressive with -std=gnu89

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115310 --- Comment #5 from Florian Weimer --- (In reply to Martin Jambor from comment #4) > No. Specifically in openSUSE, -Werror=return-type is part of the > default compiler flags. We would like to silence the new errors such > as implicit-int in p

[Bug c/115310] Option -Werror=return-type is too aggressive with -std=gnu89

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115310 --- Comment #7 from Florian Weimer --- (In reply to Richard Biener from comment #6) > But -Wreturn-mismatch doesn't diagnose the following, only -Wreturn-type > does. > IIRC we made -Werror=return-type the default mainly because of this. > > in

[Bug c/109827] Pointer/integer mismatch in ?: not covered by -Wint-conversion

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

[Bug c/109826] Incompatible pointer types in ?: not covered by -Wincompatible-pointer-types

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

[Bug c/109826] Incompatible pointer types in ?: not covered by -Wincompatible-pointer-types

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

[Bug other/44209] [meta-bug] Some warnings are not linked to diagnostics options

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44209 Bug 44209 depends on bug 109826, which changed state. Bug 109826 Summary: Incompatible pointer types in ?: not covered by -Wincompatible-pointer-types https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109826 What|Removed

[Bug other/44209] [meta-bug] Some warnings are not linked to diagnostics options

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44209 Bug 44209 depends on bug 109827, which changed state. Bug 109827 Summary: Pointer/integer mismatch in ?: not covered by -Wint-conversion https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109827 What|Removed |Added -

[Bug c/109827] Pointer/integer mismatch in ?: not covered by -Wint-conversion

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

<    1   2   3   4   5   >