[Bug c++/111918] New: #pragma GCC diagnostic pop does not restore permerror status of -Wnarrowing

: diagnostic Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: fw at gcc dot gnu.org CC: dmalcolm at gcc dot gnu.org, jason at gcc dot gnu.org Target Milestone: --- Consider this test case

[Bug c++/111918] #pragma GCC diagnostic pop does not restore permerror status of -Wnarrowing

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111918 --- Comment #1 from Florian Weimer --- diagnostic_classify_diagnostic overwrites DK_UNSPECIFIED in context->classify_diagnostic[OPT_Wnarrowing] with DK_WARNING here: /* Record the command-line status, so we can reset it back on DK_POP. */

[Bug c++/111918] #pragma GCC diagnostic pop does not restore error status of -Wnarrowing

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111918 --- Comment #2 from Florian Weimer --- It does not work. I think the problem is the quoted reset code with old_kind. It was introduced in r5-2858 to fix PR59304. It's necessary because global warning options serve a dual purpose: recording the

[Bug middle-end/32667] block copy with exact overlap is expanded as memcpy

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667 --- Comment #32 from Florian Weimer --- There's this in standards.texi: Most of the compiler support routines used by GCC are present in @file{libgcc}, but there are a few exceptions. GCC requires the freestanding environment provide @code{memc

[Bug middle-end/32667] block copy with exact overlap is expanded as memcpy

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667 --- Comment #55 from Florian Weimer --- (In reply to post+gcc from comment #52) > For the point discussed earlier with the `restrict` in the musl memcpy, I > had another look at the definition of `restrict` and it's not entirely clear > to me any

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

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96284 Bug 96284 depends on bug 106416, which changed state. Bug 106416 Summary: -Wint-conversion should be an error, not a pedwarn https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106416 What|Removed |Added --

[Bug c/91092] Error on implicit function declarations by default

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

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

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

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96284 Bug 96284 depends on bug 91093, which changed state. Bug 91093 Summary: Error on implicit int by default https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91093 What|Removed |Added ---

[Bug c/108476] Please turn -Wreturn-type on by default for C

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

[Bug libgcc/109289] Conflicting types for built-in functions in libgcc/emutls.c

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109289 --- Comment #3 from Florian Weimer --- Jan, do you actually experience a build failure? The part you quoted only shows warnings. Thomas, the safe thing to do would be to use __builtin_calloc and __builtin_realloc in those spots because it avoid

[Bug libgcc/109289] Conflicting types for built-in functions in libgcc/emutls.c

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109289 --- Comment #4 from Florian Weimer --- What I can I do here to help? What's an easy emutls target to build?

[Bug tree-optimization/112831] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in type_has_mode_precision_p, at tree.h:6767

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

[Bug tree-optimization/112831] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in type_has_mode_precision_p, at tree.h:6767

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112831 --- Comment #2 from Florian Weimer --- Created attachment 56776 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56776&action=edit valgrind output

[Bug c/112954] New: Spelling hint for typos in parameter types in function prototypes

Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: fw at gcc dot gnu.org Target Milestone: --- This is used to be accepted with a warning as a function declaration without a prototype, treating “int32t” as

[Bug preprocessor/110558] __has_include argument expansion results in unexpected filename

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110558 --- Comment #3 from Florian Weimer --- It tries to read "my. header.h" for some reason, even though the MAKE_INCLUDE_PATH macro produces "my.header.h" in other contexts (not just in #include directives). I doubt this is related to bug 80753.

[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 --- Comment #7 from Florian Weimer --- (In reply to Jakub Jelinek from comment #6) > I think aarch64 defaults to -fno-omit-frame-pointer anyway. > /* Disable fomit-frame-pointer by default. */ > { OPT_LEVELS_ALL, OPT_fomit_frame_pointer

[Bug c++/110000] GCC should implement exclude_from_explicit_instantiation

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

[Bug c++/110000] GCC should implement exclude_from_explicit_instantiation

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=11 --- Comment #7 from Florian Weimer --- (In reply to Nikolas Klauser from comment #6) > Does that make sense? Not quite. I was trying to suggest that you also need to suppress all inter-procedural analysis. This will inhibit quite a few useful o

[Bug libgcc/109712] Segmentation fault in linear_search_fdes

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

[Bug libgcc/109712] Segmentation fault in linear_search_fdes

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109712 --- Comment #23 from Florian Weimer --- (In reply to Thomas Neumann from comment #21) > It must be something more complex. value is small here (more precisely: 1888 > in the crashes later), which is not a valid pointer address. We probably > hav

[Bug libgcc/109712] Segmentation fault in linear_search_fdes

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109712 --- Comment #24 from Florian Weimer --- (With the missing ; added, of course.)

[Bug libgcc/109712] [13/14 Regression] Segmentation fault in linear_search_fdes

dot gnu.org |fw at gcc dot gnu.org Status|REOPENED|ASSIGNED --- Comment #27 from Florian Weimer --- Patch posted: [PATCH] libgcc: Fix eh_frame fast path in find_fde_tail <https://gcc.gnu.org/pipermail/gcc-patches/2023-June/620731.html>

[Bug libgcc/109712] [13/14 Regression] Segmentation fault in linear_search_fdes

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109712 --- Comment #31 from Florian Weimer --- Will propose a backport to 13 in ~2 weeks.

[Bug analyzer/110172] Leak false positives from -fanalyzer with -fexceptions (even on C code)

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

[Bug c/110442] New: IFUNC resolvers which use __builtin_cpu_supports crash with -fsanitize=address

Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: fw at gcc dot gnu.org Target Milestone: --- With -O2 -fsanitize=address, this code: “ #include void f1 (void) { puts ("f1"); } void f2 (void) {

[Bug tree-optimization/110546] New: Function clone not treated as valid allocator with -Wmismatched-dealloc

: diagnostic Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: fw at gcc dot gnu.org Blocks: 99715 Target Milestone: --- If compiled with -Wall -Werror -O3, the code below produces

[Bug libgcc/109712] [13 Regression] Segmentation fault in linear_search_fdes

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109712 --- Comment #33 from Florian Weimer --- (In reply to Andrew Pinski from comment #32) > (In reply to Florian Weimer from comment #31) > > Will propose a backport to 13 in ~2 weeks. > > Any news on the backport? There is aim to release GCC 13.2.0

[Bug libgcc/110179] unwind-dw2-fde-dip.c:406: assignment makes integer from pointer without a cast

|ASSIGNED Last reconfirmed||2023-07-10 Assignee|unassigned at gcc dot gnu.org |fw at gcc dot gnu.org See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi

[Bug libgcc/110179] unwind-dw2-fde-dip.c:406: assignment makes integer from pointer without a cast

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

[Bug middle-end/110617] RFE: Add a diagnostic-only variant of nonnull attribute

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110617 --- Comment #9 from Florian Weimer --- (In reply to Xi Ruoyao from comment #6) > (In reply to Richard Biener from comment #5) > > I think a -f... option to disable the code generation effects would make > > more sense than adding another attribu

[Bug middle-end/110617] RFE: Add a diagnostic-only variant of nonnull attribute

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110617 --- Comment #11 from Florian Weimer --- (In reply to Xi Ruoyao from comment #10) > But Zack's reason against using __nonnull is __nonnull may cause unwanted > optimizations to *the user code*. GCC already offers options to control function call

[Bug target/110627] New: m68k: “Tried to convert PC relative branch to absolute jump” while building iconvdata/iso-2022-jp.c from glibc

: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: fw at gcc dot gnu.org Target Milestone: --- Target: m68k-linux-gnu-coldfire-soft Created attachment

[Bug libgcc/109712] [13 Regression] Segmentation fault in linear_search_fdes

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109712 --- Comment #35 from Florian Weimer --- Backport posted, along with the warning fix: [PATCH releases/gcc-13 1/2] libgcc: Fix eh_frame fast path in find_fde_tail [PATCH releases/

[Bug libgcc/109712] [13 Regression] Segmentation fault in linear_search_fdes

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

[Bug c/113050] -Wincompatible-pointer-types emitted as a warning, not an error, for __atomic_load

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113050 --- Comment #1 from Florian Weimer --- The warning should be -Wdiscared-qualifiers, which is not an error for C. What confused me is that the volatile qualifier is already accepted for the first argument. I believe it's valid for the second arg

[Bug c/113050] -Wincompatible-pointer-types emitted as a warning, not an error, for __atomic_load

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113050 --- Comment #3 from Florian Weimer --- (In reply to Florian Weimer from comment #1) > The warning should be -Wdiscared-qualifiers, which is not an error for C. > > What confused me is that the volatile qualifier is already accepted for the > fi

[Bug c/113050] __atomic_* builtins should use -Wdiscarded-qualifiers instead of -Wincompatible-pointer-types

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

[Bug middle-end/113082] builtin transforms do not honor errno

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113082 --- Comment #2 from Florian Weimer --- (In reply to Richard Biener from comment #1) > Joseph - I wonder if the standard folks can be convinced to amend most > library function documentation as to not altering 'errno' (like memcpy, > strlen, etc.

[Bug c/113050] __atomic_* builtins should use -Wdiscarded-qualifiers instead of -Wincompatible-pointer-types

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

[Bug target/113059] [14 regression] fftw fails tests for -O3 -m32 -march=znver2 since r14-6210-ge44ed92dbbe9d4

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

[Bug libstdc++/113159] More robust std::sort for silly comparator functions

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

[Bug target/110627] m68k: “Tried to convert PC relative branch to absolute jump” while building iconvdata/iso-2022-jp.c from glibc

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110627 Florian Weimer changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRM

[Bug target/103370] [12/13/14 Regression] Assembler error building glibc for ColdFire soft-float

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

[Bug target/113312] Update __attribute__((interrupt)) for Intel FRED

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

[Bug target/113401] New: Memory (resource) leak in -ftrampoline-impl=heap

Component: target Assignee: unassigned at gcc dot gnu.org Reporter: fw at gcc dot gnu.org Target Milestone: --- Target: x86_64-*, aarch64-* Consider this test program: #include #include #include static void *volatile compiler_barrier; void * thread_routine (void

[Bug libgcc/113402] New: Incorrect symbol versions for __builtin_nested_func_ptr_created, __builtin_nested_func_ptr

Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcc Assignee: unassigned at gcc dot gnu.org Reporter: fw at gcc dot gnu.org Target Milestone: --- The symbols are about to be added to GCC 14, but they use a GCC_7.0.0 symbol version in

[Bug libgcc/113403] New: __builtin_nested_func_ptr_created, __builtin_nested_func_ptr should be dynamically linked by default

Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcc Assignee: unassigned at gcc dot gnu.org Reporter: fw at gcc dot gnu.org Target Milestone: --- There are hidden definitions of __builtin_nested_func_ptr_created

[Bug libgcc/113402] Incorrect symbol versions for __builtin_nested_func_ptr_created, __builtin_nested_func_ptr in libgcc_s.so.1

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113402 --- Comment #1 from Florian Weimer --- I should say I have only tested this on x86-64, but it is likely that this impacts other supported ABIs as well.

[Bug libgcc/113401] Memory (resource) leak in -ftrampoline-impl=heap

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113401 --- Comment #2 from Florian Weimer --- (In reply to Iain Sandoe from comment #1) > (In reply to Florian Weimer from comment #0) > > > The fix is to register a TLS destructor to > > deallocate that page, too. On glibc, that also fixes another me

[Bug libgcc/113403] __builtin_nested_func_ptr_created, __builtin_nested_func_ptr should be dynamically linked by default

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113403 --- Comment #2 from Florian Weimer --- Weak symbols have no meaning for ELF DSOs, so this wouldn't work for libgcc_s on ELF targets. Instead we automatically link against dynamic libgcc_s if certain symbols not in libgcc.a are referenced. Source

[Bug libgcc/113403] [14 Regression] __builtin_nested_func_ptr_created, __builtin_nested_func_ptr should be dynamically linked by default

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113403 --- Comment #8 from Florian Weimer --- In the current implementation, as far as I understand it, avoiding multiple objects is just an optimization, not a correctness issue. STB_GNU_UNIQUE is for correctness (although I don't think we'd implement

[Bug libgcc/113403] [14 Regression] __builtin_nested_func_ptr_created, __builtin_nested_func_ptr should be dynamically linked by default

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113403 --- Comment #12 from Florian Weimer --- (In reply to Jakub Jelinek from comment #11) > Or put it in libgcc_eh.a and libgcc_s.so.1? Yes, that's what I came up with as well (conceptually, not a patch, and I only have a background in ELF), but Iai

[Bug c++/112293] Enhance error reporting with fix-it for missing in gcc 14

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

[Bug libgcc/113401] Memory (resource) leak in -ftrampoline-impl=heap

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113401 --- Comment #4 from Florian Weimer --- (In reply to Iain Sandoe from comment #3) > for platforms using pthreads as the underlying resource, then perhaps we can > do this without thread_atexit (which I do not see in many places) by using > pthrea

[Bug libgcc/113401] Memory (resource) leak in -ftrampoline-impl=heap

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113401 --- Comment #6 from Florian Weimer --- Sorry, pthread_cleanup_push is purely scope-based, like the existing handler. It cannot be used to push a handler to some unscoped cleanup function list that persists even after the current function returns

[Bug libgcc/113401] Memory (resource) leak in -ftrampoline-impl=heap

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113401 --- Comment #8 from Florian Weimer --- Which version of the manual page are you looking at? https://man7.org/linux/man-pages/man3/pthread_cleanup_push.3.html seems pretty clear about the scope-based nature (search for discussion of break/return

[Bug sanitizer/113728] New: libasan uses incorrect prctl prototype

: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: fw at gcc dot gnu.org CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org, jakub at gcc dot gnu.org, kcc at gcc dot gnu.org Target Milestone: --- Target: powerpc64le

[Bug libgcc/113803] New: libgcc unwinder stops at calls to null function pointer on some targets

: normal Priority: P3 Component: libgcc Assignee: unassigned at gcc dot gnu.org Reporter: fw at gcc dot gnu.org Target Milestone: --- Originally reported as a glibc bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31349 If a null pointer is called, the

[Bug libgcc/113803] libgcc unwinder stops at calls to null function pointer on some targets

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113803 --- Comment #6 from Florian Weimer --- I we knew that the last successfully executed instruction was an indirect call or branch (assumed to be tail call), we could use the return address at the top of the stack, for architectures where call inst

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425 --- Comment #74 from Florian Weimer --- (In reply to Zdenek Sojka from comment #73) > See MISRA C:2012 Rule 17.7: > "... If the return value of a function is intended not to be used > explicitly, it should be cast to the void type. ..." > > It

[Bug target/116887] Section type conflict on loongarch with .data.rel.ro section attribute

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116887 --- Comment #21 from Florian Weimer --- (In reply to chenglulu from comment #20) > (In reply to Florian Weimer from comment #18) > > (In reply to chenglulu from comment #17) > > > I don't think it can be completely avoided. But I don't understan

[Bug target/116887] Section type conflict on loongarch with .data.rel.ro section attribute

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116887 --- Comment #11 from Florian Weimer --- I'm surprised that you can load from .data.rel.ro using la.local. Isn't it possible for RELRO data (which is writable at first, so separate from code) very far away from any text section? I'm going by the

[Bug libgcc/115242] libgcc unwinder does not handle vector registers, even if the target machine supports them.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115242 --- Comment #6 from Florian Weimer --- (In reply to Alisa Sireneva from comment #4) > I think this is a wider issue. The root of the problem is that > __builtin_unwind_init() affects what it _thinks_ are _callee-saved_ > registers. I think this

[Bug target/116887] Section type conflict on loongarch with .data.rel.ro section attribute

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116887 --- Comment #18 from Florian Weimer --- (In reply to chenglulu from comment #17) > I don't think it can be completely avoided. But I don't understand why the > public code does not set the SECTION_RELRO flag when putting decl into > ".data.rel.r

[Bug middle-end/116884] New: Bogus strcpy -Warray-bounds warning following memset of destination after r13-455

Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: fw at gcc dot gnu.org Target Milestone: --- Starting with r13-455, this test case char *stpcpy (char *, const char *); char *f (void); void g (void) { const

[Bug target/116887] New: Section type conflict on loongarch with .data.rel.ro section attribute

: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: fw at gcc dot gnu.org Target Milestone: --- The attached reproducer when compiled with -c fPIC fails to build (with some additional diagnostics added not available upstream

[Bug target/116887] Section type conflict on loongarch with .data.rel.ro section attribute

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116887 --- Comment #3 from Florian Weimer --- Created attachment 59222 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59222&action=edit bug.i

[Bug target/116887] Section type conflict on loongarch with .data.rel.ro section attribute

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116887 --- Comment #1 from Florian Weimer --- Seen with: gcc version 13.3.1 20240929 [releases/gcc-13 3fdb1fd69] (GCC)

[Bug c++/82209] Compile error "X causes a section type conflict with Y" should provide more information

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

[Bug c/53769] [C11]: Macros __STDC_NO_THREADS__ / __STDC_NO_ATOMIC__ missing.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53769 --- Comment #21 from Florian Weimer --- (In reply to Jakub Jelinek from comment #20) > It is not that easy. __STDC_NO_THREADS__ is a predefined macro, so it would > mean (at least on targets without stdc-predef.h, with that header one would > ho

[Bug c/53769] [C11]: Macros __STDC_NO_THREADS__ / __STDC_NO_ATOMIC__ missing.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53769 --- Comment #18 from Florian Weimer --- (In reply to Vincent Lefèvre from comment #17) > (In reply to Jonathan Wakely from comment #16) > > As explained above, this is not something that can be fixed in GCC. > > I'm wondering why this bug was ma

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95445 --- Comment #4 from Florian Weimer --- Patch posted: [PATCH] c: Implement -Wdeprecated-non-prototype This is what the new warning produces for the input from th

[Bug middle-end/87403] [Meta-bug] Issues that suggest a new warning

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87403 Bug 87403 depends on bug 95445, which changed state. Bug 95445 Summary: diagnose incompatible calls to functions declared without prototype [-Wdeprecated-non-prototype] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95445 What|Remov

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

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

[Bug target/118541] Incorrect transformation to xscmpgtdp for Unordered Operations

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118541 --- Comment #2 from Florian Weimer --- This is about these glibc test suite failures, right? FAIL: math/test-double-acospi FAIL: math/test-float-acospi FAIL: math/test-float32-acospi FAIL: math/test-float32x-acospi FAIL: math/test-float64-acosp

[Bug c/119950] __builtin_constant_p warning with -Wdeprecated-non-prototype inconsistent

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119950 --- Comment #1 from Florian Weimer --- Patch posted: [PATCH] c: Suppress -Wdeprecated-non-prototype warnings for builtins

[Bug c/119950] __builtin_constant_p warning with -Wdeprecated-non-prototype inconsistent

||fw at gcc dot gnu.org Last reconfirmed||2025-04-26 Assignee|unassigned at gcc dot gnu.org |fw at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED

[Bug c/120055] [16 Regression] ice in convert_arguments with recent compiler

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

[Bug c/119950] __builtin_constant_p warning with -Wdeprecated-non-prototype inconsistent

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119950 Bug 119950 depends on bug 120055, which changed state. Bug 120055 Summary: [16 Regression] ice in convert_arguments with recent compiler https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120055 What|Removed |Added

[Bug c/120055] [16 Regression] ice in convert_arguments with recent compiler

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120055 --- Comment #3 from Florian Weimer --- Patch posted: [PATCH] c: Fix crash in c-typeck.cc convert_arguments with indirect calls

[Bug c/120055] [16 Regression] ice in convert_arguments with recent compiler

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120055 Florian Weimer changed: What|Removed |Added Status|NEW |ASSIGNED

[Bug c/120055] [16 Regression] ice in convert_arguments with recent compiler

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

[Bug c/120060] [16 Regression] bash-5.2 ICE

||fw at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #2 from Florian Weimer --- I'm on it, sorry. *** This bug has been marked as a duplicate of bug 120055 ***

[Bug target/46942] x86_64 parameter passing unnecessary sign/zero extends

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46942 --- Comment #13 from Florian Weimer --- (In reply to Jakub Jelinek from comment #12) > (In reply to Florian Weimer from comment #11) > > The ABI document was updated: > > > > Clarify the unspecified nature of excess bits in INTEGER type argument

[Bug target/46942] x86_64 parameter passing unnecessary sign/zero extends

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

[Bug target/46942] x86_64 parameter passing unnecessary sign/zero extends

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46942 --- Comment #15 from Florian Weimer --- (In reply to Jakub Jelinek from comment #14) > > I think this means that the implementation of f must extend (if needed) > > because g did not sign-extend or zero-extend. > > If I read your psABI change r

[Bug target/120592] XMM register is used across ___tls_get_addr

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

[Bug libgcc/120653] Hardened glibc (-z now) compiled with GCC 14.3 will crash when unwinding stack

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120653 --- Comment #15 from Florian Weimer --- Jakub, thanks for the really helpful analysis! In glibc, we do additional gymnastics to self-relocate the dynamic linker earlier, with a compiler barrier, but only for HIDDEN_VAR_NEEDS_DYNAMIC_RELOC archi

[Bug target/119628] Need better mechanisms to manage register saves in callee for tail calls (inc. preserve_none for x86_64?)

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

[Bug c++/63164] unnecessary calls to __dynamic_cast

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63164 --- Comment #8 from Florian Weimer --- There's this big comment in typeinfo: // Determine whether typeinfo names for the same type are merged (in which // case comparison can just compare pointers) or not (in which case strings // must be compar

[Bug target/120933] Turn on -mtls-dialect=gnu2 by default on x86-64

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

[Bug libgcc/115242] libgcc unwinder does not handle vector registers, even if the target machine supports them.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115242 --- Comment #9 from Florian Weimer --- (In reply to Segher Boessenkool from comment #8) > Can we have a testcase please? The test case in glibc: https://sourceware.org/bugzilla/show_bug.cgi?id=26566 > It sounds like the glibc you used was misc

<    1   2   3   4   5