,
||ndesaulniers at google dot com
--- Comment #7 from Nick Desaulniers ---
It looks like Keith took a stab at this back in 2021. Guessing that didn't
land though.
https://patchwork.sourceware.org/project/gcc/patch/20211102211458.10233-1-kei...@keithp.com/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77882
Nick Desaulniers changed:
What|Removed |Added
CC||ndesaulniers at google dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78512
Nick Desaulniers changed:
What|Removed |Added
CC||ndesaulniers at google dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111219
--- Comment #2 from Nick Desaulniers ---
Ah ok that makes sense.
Would it be possible to get that behavior documented on this page?
https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wformat-truncation
We can probably modify clang
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: ndesaulniers at google dot com
Target Milestone: ---
I noticed that -Wformat-truncation was disabled in the linux kernel.
commit bd664f6b3e37 ("disable new gcc-7.1.1 warnings for now")
I was curious s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65213
Nick Desaulniers changed:
What|Removed |Added
CC||ndesaulniers at google dot com
: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: ndesaulniers at google dot com
Target Milestone: ---
Via:
https://lore.kernel.org/all/CAKwvOd=8kxkD9p+WW-F047ShN=r32slyyfpgzhydw3bxtdd...@mail.gmail.com/
I'm looking to e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110728
--- Comment #10 from Nick Desaulniers ---
(In reply to Michael Matz from comment #9)
> That has to do with how we need to (possibly)
> split
> critical edges, which changes label identity, which in turn might actually
> be the thing that's requi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91951
Nick Desaulniers changed:
What|Removed |Added
CC||ndesaulniers at google dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110728
--- Comment #7 from Nick Desaulniers ---
(In reply to Andrew Pinski from comment #1)
> I suspect PR 91951 is the same really.
PR 91951 seems to be about a missing diagnostic dependent on optimization
level. This bug report is more so a questio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37722
Nick Desaulniers changed:
What|Removed |Added
CC||ndesaulniers at google dot com
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: ndesaulniers at google dot com
Target Milestone: ---
Consider the following test case:
```c
void test4cleanup(int*);
// No errors expected.
void test4(void) {
l0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896
Nick Desaulniers changed:
What|Removed |Added
CC||ndesaulniers at google dot com
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: ndesaulniers at google dot com
CC: eli.friedman at gmail dot com, foom at fuhm dot net
Target Milestone: ---
https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html#Volatile mentions:
> GCC’s optimiz
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: ndesaulniers at google dot com
CC: isanbard at gmail dot com
Target Milestone: ---
I was playing around with adding support for outputs along indirect edges
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65372
Nick Desaulniers changed:
What|Removed |Added
CC||ndesaulniers at google dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100593
Nick Desaulniers changed:
What|Removed |Added
CC||ndesaulniers at google dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104236
--- Comment #3 from Nick Desaulniers ---
Thanks for the feedback. I guess I was expecting these two to be somewhat
equivalent:
void x (int a) {
if (a)
asm("# %0"::"i"(__COUNTER__));
else
asm("# %0"::"i"(__COUNTER__));
}
Priority: P3
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: ndesaulniers at google dot com
CC: bp at alien8 dot de, jpoimboe at redhat dot com,
pinskia at gcc dot gnu.org, segher at kernel dot
crashing.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98096
--- Comment #5 from Nick Desaulniers ---
While the changes to gcc/stmt.c and the second asm goto statement in
gcc/testsuite/gcc.c-torture/compile/pr98096.c in
https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=72d78655a91bb2f89ac4432cfd6374380d6f9987
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: ndesaulniers at google dot com
CC: foom at fuhm dot net, segher at gcc dot gnu.org, vmakarov
at redhat dot com
Target Milestone: ---
Consider the following input:
void
Priority: P3
Component: libgcc
Assignee: unassigned at gcc dot gnu.org
Reporter: ndesaulniers at google dot com
Target Milestone: ---
LLVM's compiler-rt has support for 3 functions for doing multiplication with
overflow checks (__muloti4/__mulodi4/__mu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91432
--- Comment #5 from Nick Desaulniers ---
> Not warning in this case is a very intentional part of those design decisions.
Can you provide a link to the discussion about this specific case?
Is re-evaluating the decision out of the question?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
Nick Desaulniers changed:
What|Removed |Added
CC||ndesaulniers at google dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80223
--- Comment #23 from Nick Desaulniers ---
(In reply to Fangrui Song from comment #18)
> I
> think a similar topic may need to be raided on llvm-dev side as I feel this
> is the tip of the iceberg - more attributes can be similarly leveraged. So,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80223
--- Comment #16 from Nick Desaulniers ---
Clang patch (no_profile -> no_profile_instrument_function):
https://reviews.llvm.org/D104658
Kernel patches v2:
https://lore.kernel.org/lkml/20210621231822.2848305-1-ndesaulni...@google.com/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80223
--- Comment #15 from Nick Desaulniers ---
(In reply to Fangrui Song from comment #14)
> Can a no_profile_instrument_function function be inlined into a function
> without the attribute? This may be controversial but I'd argue that it can.
> GCC n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80223
--- Comment #12 from Nick Desaulniers ---
Ah, perfect!
commit 1225d6b1134b ("Introduce no_profile_instrument_function attribute")
LGTM: https://godbolt.org/z/779xzndY6
Looks like it landed in GCC 7.1.
Let me change over the attribute identifi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80223
--- Comment #10 from Nick Desaulniers ---
Link to kernel patches:
https://lore.kernel.org/lkml/20210618233023.1360185-1-ndesaulni...@google.com/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80223
--- Comment #9 from Nick Desaulniers ---
(In reply to Fangrui Song from comment #8)
> I am thinking of __attribute__((no_profile)).
>
> In Clang,
> -fprofile-generate(-fcs-profile-generate)/-fprofile-instr-generate/-fprofile-
> arcs are all diff
,
||isanbard at gmail dot com,
||kees at outflux dot net,
||maskray at google dot com,
||ndesaulniers at google dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100363
Nick Desaulniers changed:
What|Removed |Added
CC||ndesaulniers at google dot com
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: ndesaulniers at google dot com
CC: richard-gccbugzilla at metafoo dot co.uk
Target Milestone: ---
Consider the following code:
struct dummy {
const struct {
int a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94722
--- Comment #10 from Nick Desaulniers ---
(In reply to Jakub Jelinek from comment #9)
> I've said in that thread that I don't really like disabling the inlining, if
> we wanted to make sure everything is stack protected, we'd need to disable
> al
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96907
--- Comment #5 from Nick Desaulniers ---
No preferences either way. I was just comparing differences between compilers
for __has_builtin and noticed GCC returns true for those two. Is that ok?
Assignee: unassigned at gcc dot gnu.org
Reporter: ndesaulniers at google dot com
CC: rv at rasmusvillemoes dot dk, segher at kernel dot
crashing.org
Target Milestone: ---
In https://reviews.llvm.org/D86508, I'm going through and working on improving
Cl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95588
--- Comment #1 from Nick Desaulniers ---
In https://bugs.llvm.org/show_bug.cgi?id=41467#c4, the code owner for Clang
seems to indicate that we could move the warnings for narrowing prints (ie.
printing an `int` with `%hh`) to a new warning flag w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91432
Nick Desaulniers changed:
What|Removed |Added
CC||ndesaulniers at google dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94986
--- Comment #4 from Nick Desaulniers ---
(In reply to nsz from comment #2)
> on arm the -pg abi is
>
> func:
> push {lr}
> bl _gnu_mcount_nc
> ...
>
> so no frame pointer is involved, -pg implying
> -fno-omit-frame-pointer is a historical
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94722
--- Comment #3 from Nick Desaulniers ---
Ah, sorry, just was sent:
https://lore.kernel.org/lkml/20200316180303.GR2156@tucnak/ which is also
relevant regarding naming. Still happy to buy the beers though.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94722
--- Comment #2 from Nick Desaulniers ---
Also note this post in the thread [0]:
https://lore.kernel.org/lkml/20200422192113.gg26...@zn.tnic/T/#m88641fe74bdffe7beaa925dfe2d8146a08a47bac,
also
https://lore.kernel.org/lkml/20200422192113.gg26...@zn.
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: ndesaulniers at google dot com
CC: jakub at redhat dot com, mliska at suse dot cz
Target Milestone: ---
There's a couple of places in the Linux kernel where the plac
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92424
Nick Desaulniers changed:
What|Removed |Added
CC||ndesaulniers at google dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91961
--- Comment #4 from Nick Desaulniers ---
Thanks for the report. I noticed we had
https://bugs.llvm.org/show_bug.cgi?id=38653 on file, so I cc'ed Clang folks who
might have some thoughts.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91206
Nick Desaulniers changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91206
--- Comment #2 from Nick Desaulniers ---
Ah, I did file a bug for this in LLVM's issue tracker:
https://bugs.llvm.org/show_bug.cgi?id=41467
y: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: ndesaulniers at google dot com
Target Milestone: ---
The linux kernel currently disables -Wformat when built with Clang (see
scripts/Makefile.extrawarn).
When looking into why the warning was disabled, I noticed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66970
--- Comment #15 from Nick Desaulniers ---
Any progress Martin? Just to keep beating the dead horse...
Forgetting other compilers for a minute, __has_builtin allows for feature
detection which is much better than compiler version checks which ar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87435
Nick Desaulniers changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80868
--- Comment #7 from Nick Desaulniers ---
Forked: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87435
ty: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: ndesaulniers at google dot com
Target Milestone: ---
Forked from https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80868.
Test case: https://godbolt.org/z/jjstcx
typedef const int t;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80868
--- Comment #5 from Nick Desaulniers ---
Oh, note in the typedef case:
typedef const int t;
const t x;
It seems that for -std=c89 (non pedantic, non GNU), GCC does not warn. That
seems to violate C90 6.5.3 constraints: "The same type qualifier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80868
--- Comment #4 from Nick Desaulniers ---
We can close this bug. LLVM will match GCC here:
https://reviews.llvm.org/D52248
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58670
Nick Desaulniers changed:
What|Removed |Added
CC||ndesaulniers at google dot com
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: ndesaulniers at google dot com
Target Milestone: ---
Developing a patch for the Linux kernel, I hit a -Wmisleading-indentation
warning for a particular configuration in gcc 6, 7, and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85927
--- Comment #4 from Nick Desaulniers ---
Thanks for the clarification.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85927
--- Comment #2 from Nick Desaulniers ---
Sorry, probably:
__attribute__((naked))
unsigned long save_flags4(void) {
asm volatile("pushf; pop %rax;ret;");
}
is a better example:
:
0: 9c pushfq
1
: c
Assignee: unassigned at gcc dot gnu.org
Reporter: ndesaulniers at google dot com
Target Milestone: ---
From: https://lkml.org/lkml/2018/5/25/636
It seems that:
__attribute__((naked))
unsigned long save_flags(void) {
unsigned long flags;
asm volatile("pushf; p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80868
Nick Desaulniers changed:
What|Removed |Added
CC||ndesaulniers at google dot com
59 matches
Mail list logo
