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
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
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: david at westcontrol dot com
Target Milestone: ---
I am getting strange results with an empty inline assembly line, used as an
optimisation barrier. This is the test code I've tried
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
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
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
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
: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: david at westcontrol dot com
Target Milestone: ---
This is an enhancement idea, rather than a bug, and would require linker
support as well as compiler support.
In C
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
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
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
: c
Assignee: unassigned at gcc dot gnu.org
Reporter: david at westcontrol dot com
Target Milestone: ---
With C++ and -fsanitize=return, the code :
int foo(void) { }
generates a call to __ubsan_handle_missing_return.
For C, there is no sanitizer call - just a simple &quo
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: david at westcontrol dot com
Target Milestone: ---
Given this code :
int sign(int x) {
if (x < 0) return -1;
if (x == 0) return 0;
if (x > 0) return 1;
}
and compiled with "-O2 -Wall"
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
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
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: david at westcontrol dot com
Target Milestone: ---
Sometimes it can be useful to use __builtin_unreachable() to give the compiler
hints that can improve optimisation. For example
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: david at westcontrol dot com
Target Milestone: ---
A std::optional is fundamentally like a std::pair, but with nice
access features, type safety, etc. But for simple functions
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
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
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
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
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
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
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: david at westcontrol dot com
Target Milestone: ---
struct S { int a[1000]; };
struct X { struct S s; int b[2];};
extern int foobar(struct X * p);
int foo(struct S *s)
{
struct X x = { *s };
return foobar
Assignee: unassigned at gcc dot gnu.org
Reporter: david at westcontrol dot com
Target Milestone: ---
I recently looked at some of gcc's "if-conversions" and other optimisations of
expressions involving relational operators - something people might use when
tryin
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.)
: c
Assignee: unassigned at gcc dot gnu.org
Reporter: david at westcontrol dot com
Target Milestone: ---
The "-Woverflow" warning only works with constant expressions. Should it not
also work in cases where the compiler knows the value at compile
Assignee: unassigned at gcc dot gnu.org
Reporter: david at westcontrol dot com
Target Milestone: ---
When using many function attributes, the attributes only apply when the
function is not inlined. And in some cases, they actively disable inlining
which would normally
ty: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: david at westcontrol dot com
Target Milestone: ---
The C standard library has a family of functions for calculating the division
and remainder as a pair - "div&q
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.
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: david at westcontrol dot com
Target Milestone: ---
Incorrect code like this example relies on two's complement wrapping to do what
the programmer wanted:
void foo(int *a)
{
int i;
for (i=0; i
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.
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
++
Assignee: unassigned at gcc dot gnu.org
Reporter: david at westcontrol dot com
Target Milestone: ---
Empty "tag" structs (or classes) are useful for strong typing, function
options, and so on. The rules of C++ require these to have a non-zero size (so
that
Assignee: unassigned at gcc dot gnu.org
Reporter: david at westcontrol dot com
Target Milestone: ---
The gcc __attribute__((cleanup)) feature can be useful for making the
equivalent of a C++ destructor in C code, as a way of ensuring resources are
freed even if you exit a function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96284
--- Comment #6 from David Brown ---
(In reply to Eric Gallager from comment #5)
> (In reply to David Brown from comment #0)
> > Could this be made an error by default
> > (-Werror=implicit-function-declarations) ? Let those who want to compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61579
David Brown changed:
What|Removed |Added
CC||david at westcontrol dot com
--- Comment
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: david at westcontrol dot com
Target Milestone: ---
While C has tried to remain backwards compatible with each new standards
revision, some changes have been made so that particularly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85678
David Brown changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
++
Assignee: unassigned at gcc dot gnu.org
Reporter: david at westcontrol dot com
Target Milestone: ---
While playing with lambdas for higher order functions (in particular, functions
that manipulate functions and return new ones), I saw some differences in the
optimisations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92727
--- Comment #8 from David Brown ---
I don't think there is anything more I can add at the moment. Thank you for
your efforts.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92727
--- Comment #6 from David Brown ---
I can see it is a challenge to get enough detail in the messages to be good for
the more advanced users, and still simple enough and clear enough for more
casual or inexperienced users.
The static assertion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92727
--- Comment #3 from David Brown ---
I may not have been very clear here. Let me try and take a step back here.
>From the user's viewpoint, the problem is that they have made a class that
can't be copied, and they have written code that tries
++
Assignee: unassigned at gcc dot gnu.org
Reporter: david at westcontrol dot com
Target Milestone: ---
Consider this code:
#include
#include
class Y {int i;};
class X {
std::unique_ptr sp;
int i;
};
int main() {
std::vector v;
X x;
v.push_back(x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92659
--- Comment #6 from David Brown ---
(In reply to Xi Ruoyao from comment #3)
> (In reply to Jonny Grant from comment #2)
> > (In reply to Xi Ruoyao from comment #1)
> > > Is it appropriate?
> > >
> > > Though on both 32-bit and 64-bit x86 "1ul"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92659
David Brown changed:
What|Removed |Added
CC||david at westcontrol dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85678
--- Comment #11 from David Brown ---
Reliance on -fcommon has not been correct or compatible with any C standard (I
don't think it was even right for K C). If the code is written correctly
(with at most one definition of all externally linked
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92507
--- Comment #2 from David Brown ---
I am aware that "n" here is not a constant integer expression - it should not
need to be for a compiler warning. What the compiler needs in order to
eliminate the false positive is a knowledge of the ranges
Assignee: unassigned at gcc dot gnu.org
Reporter: david at westcontrol dot com
Target Milestone: ---
The -Wsign-compare warning is useful for spotting potentially dangerous code.
It is not always easy to know how the operands of a comparison will be
promoted, and whether
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60523
--- Comment #10 from David Brown ---
(In reply to Eric Gallager from comment #9)
> (In reply to Eric Gallager from comment #8)
> > *** Bug 70952 has been marked as a duplicate of this bug. ***
>
> While this was a mistake, it still might be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90404
--- Comment #3 from David Brown ---
Yes, false positives are always a risk with warnings. We already have a
warning here that would catch pretty much any case, but with a big risk of
false positives - "-Wcast-qual". My hope is for a warning
Assignee: unassigned at gcc dot gnu.org
Reporter: david at westcontrol dot com
Target Milestone: ---
The compiler knows that you can't change an object declared "const", even via a
pointer cast. And it (rightfully and helpfully) uses that knowledge for
op
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89035
--- Comment #2 from David Brown ---
Yes, "int x = x;" does give an unspecified value without a warning. But to me,
this looks much more like a workaround - while "int x =
__builtin_unspecified();" is clear in its intentions.
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: david at westcontrol dot com
Target Milestone: ---
Occasionally it is useful to have an unspecified or arbitrary value in C (and
C++) programming. For example, you might want to have a function
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: david at westcontrol dot com
Target Milestone: ---
Sometimes it would be very useful to have "tags" on functions, which can be
used to restrict the kinds of functions that can call them or be called by
them. I
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: david at westcontrol dot com
Target Milestone: ---
I am always wary of saying there might be a compiler bug - usually it is a bug
in the user code. But this time I am very suspicious. The example here comes
from
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: david at westcontrol dot com
Target Milestone: ---
gcc supports many different targets. For some of these, there can be special
attributes (variable, type, function) for particular
Assignee: unassigned at gcc dot gnu.org
Reporter: david at westcontrol dot com
Target Milestone: ---
The use of a "common" section to match up tentative object definitions in
different translation units in a program is contrary to the C standards
(section 6.9p5 in C99 and C11, s
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: david at westcontrol dot com
Target Milestone: ---
There are a number of features of C that are still legal code even in C11, but
have been obsolete for many generations of C because
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892
--- Comment #37 from David Brown ---
(In reply to Martin Sebor from comment #35)
> Here are the proposed changes:
>
> Pointer Provenance:
> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2219.htm#proposed-technical-
> corrigendum
>
> Trap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892
--- Comment #36 from David Brown ---
(In reply to Martin Sebor from comment #34)
> I think in the use case below:
>
>struct { int i; char buf[4]; } s, r;
>*(float *)s.buf = 1.;
>r = s;
>
> the aggregate copy has to be viewed as a
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: david at westcontrol dot com
Target Milestone: ---
This is a missed optimisation opportunity. In a discussion about the "best"
way to break out of a nested loop, I tested
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70952
David Brown changed:
What|Removed |Added
CC||david at westcontrol dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82845
David Brown changed:
What|Removed |Added
Resolution|DUPLICATE |FIXED
--- Comment #2 from David Brown
NCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: david at westcontrol dot com
Target Milestone: ---
(I have tested this using several gcc versions, including x86_64 and arm ports,
up to an 8.0.0 trunk te
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82602
--- Comment #16 from David Brown ---
(In reply to Xi Ruoyao from comment #8)
> (In reply to David Brown from comment #7)
>
> > There is no intention to make "asm volatile" a barrier, as you get with a
> > memory clobber. The intention is to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82602
--- Comment #7 from David Brown ---
(In reply to Xi Ruoyao from comment #3)
There is no intention to make "asm volatile" a barrier, as you get with a
memory clobber. The intention is to stop it moving past other volatile code
(such as other asm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82602
David Brown changed:
What|Removed |Added
CC||david at westcontrol dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892
David Brown changed:
What|Removed |Added
CC||david at westcontrol dot com
--- Comment
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: david at westcontrol dot com
Target Milestone: ---
Would it be possible to add warnings on accidental infinite loops, such as:
void foo(void) {
for (int i = 0; i <= 0x7fff; i++) {
// ...
}
}
The compi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79346
--- Comment #1 from David Brown ---
Some more white-list suggestions for C++ :
__STDCPP_DEFAULT_NEW_ALIGNMENT__
__STDCPP_STRICT_POINTER_SAFETY__
__STDCPP_THREADS__
C++14 also has "Whether __STDC__ is predefined and if so, what its value is,
Assignee: unassigned at gcc dot gnu.org
Reporter: david at westcontrol dot com
It would be nice if there were a warning flag that triggered on octal literals.
Octal literals are rarely used in modern C and C++ code, but can easily be
introduced by mistake - int x = 050; appears
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60523
--- Comment #5 from David Brown david at westcontrol dot com ---
I agree that warnings to match something like the MISRA coding standards would
be best done as a plugin.
But I believe that in this case, warning on octal literals would be quite
--- Comment #1 from david at westcontrol dot com 2010-02-16 10:46 ---
There are many other cases where 8-bit optimisation is missing - C's integer
promotion gets in the way. This is particularly common when dealing with a
compile-time constant - there is no way in C to say that 0x3f
at westcontrol dot com
GCC target triplet: avrgcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34789
: gcc
Version: 4.2.2
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: david at westcontrol dot com
GCC target triplet: avrgcc
http://gcc.gnu.org/bugzilla
at gcc dot gnu dot org
ReportedBy: david at westcontrol dot com
GCC target triplet: avrgcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34790
--- Comment #1 from david at westcontrol dot com 2008-01-15 08:34 ---
(Sorry - I committed the bug before entering the description!)
Sibling calls are not optimised on avrgcc, even with -foptimize-sibling-calls
enabled (such as for -Os):
extern void foo(void);
void bar(void
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: david at westcontrol dot com
GCC target triplet: avrgcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34792
84 matches
Mail list logo
