https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118330
--- Comment #2 from David Brown ---
(In reply to Andrew Pinski from comment #1)
> Note you could also work with the upstream arm eabi definition here:
> https://github.com/ARM-software/abi-aa
Yes, that is certainly a possibility I considered.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118331
Bug ID: 118331
Summary: Poor code when passing small structs around on 32-bit
ARM
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Pri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118330
Bug ID: 118330
Summary: Improving calling convention for 32-bit ARM target
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Componen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114532
--- Comment #11 from David Brown ---
(In reply to Zhaohaifeng from comment #8)
> (In reply to David Brown from comment #7)
> > (In reply to Xi Ruoyao from comment #6)
> > Anyway, I cannot see any reason while -fno-common should result in the
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114532
--- Comment #7 from David Brown ---
(In reply to Xi Ruoyao from comment #6)
> (In reply to Zhaohaifeng from comment #5)
>
> > Does gcc implement -fsection-anchors like function in -fcommon option for
> > x86? In general concept, gcc should has
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114532
--- Comment #4 from David Brown ---
I'm not personally particularly interested in performance on x86 systems - my
work is in embedded microcontroller programming. But I did push for
"-fno-common" to be the default in gcc because "-fcommon" grea
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113280
--- Comment #12 from David Brown ---
(In reply to Segher Boessenkool from comment #11)
> (In reply to David Brown from comment #8)
> > As for using "=X" in the "opt == 3" case, I worry that that could lead to
> > errors as the two assembly lines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113280
--- Comment #8 from David Brown ---
(In reply to Segher Boessenkool from comment #4)
> Nothing has changed here.
>
> opt == 2 and opt == 3 should use "=X", not "+X", btw.
>
I realise (since you told me - thanks) that
asm ("" : "+X" (x))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113280
--- Comment #7 from David Brown ---
Yes, the goal is an optimisation barrier with the least possible impact on the
code. For most uses, asm("" : "+g" (x)) has been ideal, as far as I have
tested. Typically it ensures "x" is evaluated in a regi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113280
Bug ID: 113280
Summary: Strange error for empty inline assembly with +X
constraint
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56888
--- Comment #51 from David Brown ---
(In reply to M Welinder from comment #48)
> It's your (1). gcc is changing a program that can rely on errno not being
> changed to one where the C library can change it. (The current C library or
> any futur
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56888
--- Comment #47 from David Brown ---
(In reply to M Welinder from comment #46)
> Should "-std=c99" imply turning off these optimizations?
>
> Creating calls to, say, strlen is incompatible with the C99 standard and
> perhaps better limited to "-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96284
--- Comment #16 from David Brown ---
Thank you for making these changes. There's always a trade-off between
supporting code that "has always compiled fine and works in testing", and
making it harder for people to write new poor quality code with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111769
--- Comment #4 from David Brown ---
(In reply to Richard Biener from comment #1)
> If you compile with debug info enabled the info should be already there,
> just nothing looks at this (and mismatches) at link time.
Perhaps I should file this a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111769
--- Comment #3 from David Brown ---
(In reply to Andrew Pinski from comment #2)
> IIRC there was a bug about this specific thing which was closed as fixed
> with the use of LTO ...
Certainly if you use LTO, then this is not necessary. But LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111769
Bug ID: 111769
Summary: Annotate function definitions and calls to facilitate
link-time checking
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111399
--- Comment #2 from David Brown ---
Would it be possible to have the "-Wreturn-type" warning pass not issue a
warning immediately, but inject a warning into the code that could then be
removed later by optimisation?
What I mean, is to have some
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111400
--- Comment #4 from David Brown ---
(In reply to Andreas Schwab from comment #3)
> You already have -W[error=]return-type.
Yes, and that is what I normally use - I am a big fan of gcc's static warnings.
Sometimes, however, there are false posi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111400
--- Comment #2 from David Brown ---
(In reply to Richard Biener from comment #1)
> Confirmed. Note C17 disallows a return wotihout an expression for a funcion
> that returns a value, not sure if that means falling off the function
> without a r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111400
Bug ID: 111400
Summary: Missing return sanitization only works in C++
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111399
Bug ID: 111399
Summary: Sanitizer code generation smarter than warnings
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Componen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110249
--- Comment #4 from David Brown ---
Yes, __builtin_assume_aligned is the best way to write things in this
particular case (and optimises fine for -O1 and -O2). It is also clearer in
the source code (IMHO), as it shows the programmer's intention
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110249
--- Comment #2 from David Brown ---
My apologies - it does not optimise the code to a single aligned load at -O1
(at least, not with the combinations I have now tried). The code was
originally C++, with a reference, which /does/ exhibit this be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110249
Bug ID: 110249
Summary: __builtin_unreachable helps optimisation at -O1 but
not at -O2
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109631
Bug ID: 109631
Summary: Simple std::optional types returned on stack, not
registers
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105523
--- Comment #25 from David Brown ---
(In reply to Andrew Pinski from comment #24)
> (In reply to LIU Hao from comment #22)
> > Yes, GCC should be told to shut up about dereferencing artificial address
> > values.
>
> NO.
> Take:
> ```
> static
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105523
--- Comment #23 from David Brown ---
(In reply to LIU Hao from comment #22)
> Yes, GCC should be told to shut up about dereferencing artificial address
> values.
One possibility is to have the warnings disabled whenever you are using a
volatile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105523
--- Comment #21 from David Brown ---
(In reply to Andrew Pinski from comment #1)
> --param=min-pagesize= should be set to 0 for avr as zero is a valid address.
Is there any convenient description of "min-pagesize" ? The user manual is
unhelpfu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105523
--- Comment #20 from David Brown ---
(In reply to Georg-Johann Lay from comment #19)
> Created attachment 54912 [details]
> pr105532.diff: Proposed patch for the AVR backend
>
> Here is a proposed, untested patch.
>
> gcc/
> PR target/10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105523
David Brown changed:
What|Removed |Added
CC||david at westcontrol dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82922
--- Comment #9 from David Brown ---
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(void)", like in C++, which makes the scope for confusi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101279
--- Comment #7 from David Brown ---
(In reply to rguent...@suse.de from comment #6)
> > Am 28.06.2022 um 14:53 schrieb david at westcontrol dot com
> > :
> >
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101279
> >
> > --- Comment #5 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101279
--- Comment #5 from David Brown ---
(In reply to Richard Biener from comment #4)
> (In reply to frankhb1989 from comment #3)
> > There is a more specific instance here: can_inline_edge_by_limits_p in
> > ipa-inline.cc treats flags and "optimize"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105343
Bug ID: 105343
Summary: Inefficient initialisation in some kinds of structs
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Comp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103660
Bug ID: 103660
Summary: Sub-optimal code with relational operators
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102427
--- Comment #2 from David Brown ---
Runtime detection is good - compile-time detection is much, much better when it
is possible. (IMHO, of course.)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102427
Bug ID: 102427
Summary: -Woverflow only works in constant expressions
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101279
Bug ID: 101279
Summary: Function attributes often block inlining
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100890
Bug ID: 100890
Summary: The "div" standard library functions could be
optimised as builtins
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100702
--- Comment #2 from David Brown ---
Runtime diagnostics can be very useful - but they are a different kind of
warning. In particular, they only show what errors have occurred during your
testing - they don't show what errors /might/ occur.
The
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100702
Bug ID: 100702
Summary: Strict overflow warning regression in gcc 8 onwards
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Comp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98884
--- Comment #6 from David Brown ---
(In reply to Jakub Jelinek from comment #3)
> If GCC and Clang are ABI incompatible on this, then one of the two compilers
> is buggy. So, it is needed to look at the EABI and find out which case it
> is.
I'v
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98884
--- Comment #5 from David Brown ---
(In reply to Jakub Jelinek from comment #4)
> Note, for ABI compatibility or incompatibility it might be better to check
> what happens when some argument is passed after the empty structs. Because
> at least
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98884
--- Comment #2 from David Brown ---
Yes, ABI issues were my initial thought too. If so, then optimising away the
assignments while leaving the stack manipulation (and possibly register
allocations) in place would still be a significant improveme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98884
Bug ID: 98884
Summary: Implement empty struct optimisations on ARM
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98313
Bug ID: 98313
Summary: Allow __attribute__((cleanup)) in types
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
46 matches
Mail list logo
