https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109365
--- Comment #1 from David Malcolm ---
(In reply to Benjamin Priour from comment #0)
[...]
> (Note: sorry David, I've binged through bugzilla doc and gcc bugs page yet I
> cannot seem to find the way to add this to the 'analyzer-c++' block, nor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109361
--- Comment #1 from David Malcolm ---
Some existing SARIF properties we could generate:
3.20.7 startTimeUtc property
An invocation object MAY contain a property named
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: dmalcolm at gcc dot gnu.org
Target Milestone: ---
My integration tests for -fanalyzer don't yet track how long the analyzer takes
on the real-world cases.
It would be nice for the .sarif
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109163
David Malcolm changed:
What|Removed |Added
Resolution|--- |FIXED
Status|WAITING
: normal
Priority: P3
Component: testsuite
Assignee: unassigned at gcc dot gnu.org
Reporter: dmalcolm at gcc dot gnu.org
Target Milestone: ---
Created attachment 54798
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54798=edit
WIP progress patch
I h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105273
David Malcolm changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108733
David Malcolm changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108704
David Malcolm changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106325
--- Comment #10 from David Malcolm ---
Should be fixed on gcc 12 branch by the above (for the eventual gcc 12.3
release).
Still affects GCC 11 and GCC 10.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107582
David Malcolm changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107345
David Malcolm changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108562
Bug 108562 depends on bug 107345, which changed state.
Bug 107345 Summary: -Wanalyzer-null-dereference false positive with giving
weird path infomation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107345
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105784
David Malcolm changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109094
David Malcolm changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107002
David Malcolm changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107002
--- Comment #4 from David Malcolm ---
Created attachment 54778
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54778=edit
Untested patch
(In reply to Jakub Jelinek from comment #3)
> David, any progress here?
I've currently testing the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109266
--- Comment #4 from David Malcolm ---
(In reply to David Malcolm from comment #3)
> (In reply to Jonny Grant from comment #2)
[...]
> >
> > I wondered if you know how to turn on that "cc1plus: note: source object is
> > likely at address zero?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109266
--- Comment #3 from David Malcolm ---
(In reply to Jonny Grant from comment #2)
> Thank you for your reply David. Your analyzer is very good already.
>
> I played around a bit, a base of nullptr doesn't give a warning. But
> changing to 0x10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109098
--- Comment #9 from David Malcolm ---
(In reply to Hans-Peter Nilsson from comment #8)
> (In reply to David Malcolm from comment #7)
> > The invalid UTF-8 in the patch seems to have broken the server-side script:
>
> Maybe the not-really-utf8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109266
--- Comment #1 from David Malcolm ---
Thanks for filing this bug.
We probably want to allow accesses to hard-coded addresses, for the case of
embedded development, so we presumably need some way to distinguish between
accesses of:
((struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109098
David Malcolm changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105959
David Malcolm changed:
What|Removed |Added
Resolution|--- |FIXED
Status|WAITING
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: dmalcolm at gcc dot gnu.org
Target Milestone: ---
Currently the analyzer uses its widening_svalue and complexity limits on
svalues/regions to attempt
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: dmalcolm at gcc dot gnu.org
Target Milestone: ---
Created attachment 54734
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54734=edit
Reduced reprodu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109239
David Malcolm changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
: UNCONFIRMED
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: dmalcolm at gcc dot gnu.org
Target Milestone: ---
Created attachment 54724
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54724=e
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: dmalcolm at gcc dot gnu.org
Target Milestone: ---
https://gcc.gnu.org/pipermail/gcc/2023-March/240928.html reports:
> there is no error or warning whe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105959
David Malcolm changed:
What|Removed |Added
Keywords||patch
URL|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109199
David Malcolm changed:
What|Removed |Added
Summary|GCC Static Analyzer |GCC Static Analyzer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109191
--- Comment #2 from David Malcolm ---
It is valid in the embedded space to do things like
*(SOME_CONSTANT_ADDRESS) = SOME_VALUE;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109197
David Malcolm changed:
What|Removed |Added
Summary|GCC Static Analyzer does|Analyzer gets confused
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109196
David Malcolm changed:
What|Removed |Added
Resolution|--- |WONTFIX
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109195
David Malcolm changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104940
--- Comment #3 from David Malcolm ---
*** Bug 109195 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104940
--- Comment #2 from David Malcolm ---
*** Bug 109194 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109194
David Malcolm changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104940
David Malcolm changed:
What|Removed |Added
CC||geoffreydgr at icloud dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109193
David Malcolm changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109194
--- Comment #1 from David Malcolm ---
Well, strictly speaking not all of these are true; consider
a == INT_MAX
b == INT_MAX - 1
Then a > b, but:
* a + 1 is, I believe, undefined, but we may want to treat it as INT_MIN
* b + 1 is INT_MAX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109191
--- Comment #1 from David Malcolm ---
GCC does emit a -Wint-to-pointer-cast warning on this code, for the int to void
* conversion.
Is this reduced from a real-world example, or just synthesized by hand?
I suppose in theory the analyzer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99669
David Malcolm changed:
What|Removed |Added
CC||geoffreydgr at icloud dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109201
David Malcolm changed:
What|Removed |Added
Resolution|--- |DUPLICATE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109200
David Malcolm changed:
What|Removed |Added
Resolution|--- |DUPLICATE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109201
--- Comment #2 from David Malcolm ---
*** Bug 109200 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109201
--- Comment #1 from David Malcolm ---
The division by zero warning on:
if ((d.b = 1) / 0)
is from -Wdiv-by-zero, which isn't from the analyzer (
https://godbolt.org/z/433PhKhvM )
The analyzer currently only implements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109094
David Malcolm changed:
What|Removed |Added
Keywords|ice-checking|
Target Milestone|13.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109094
--- Comment #8 from David Malcolm ---
Created attachment 54700
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54700=edit
Patch that I'm about to put through full testing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109094
--- Comment #7 from David Malcolm ---
Trunk: https://godbolt.org/z/MKh4h1ccP
12.2: https://godbolt.org/z/73EY4TMcx (no ICE, but assertions likely disabled)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109094
David Malcolm changed:
What|Removed |Added
Attachment #54637|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109163
David Malcolm changed:
What|Removed |Added
URL||https://gcc.gnu.org/piperma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105959
--- Comment #13 from David Malcolm ---
Created attachment 54698
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54698=edit
Patch that I'm about to put through full testing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105959
--- Comment #12 from David Malcolm ---
Thanks for the ideas. If I hack in the following into dg-scan (to force the
scanned file to be treated as UTF-8 as it is read), then the existing case
works with both:
LC_ALL=C
LC_ALL=en_US.UTF-8
so
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105959
--- Comment #11 from David Malcolm ---
(In reply to Hans-Peter Nilsson from comment #10)
> (I see an identifier using ideographs?
> Wouldn't want to review that code... Might as well use Linear A -which you
> indeed can in UTF-8- - it's all
||2023-03-16
Assignee|unassigned at gcc dot gnu.org |dmalcolm at gcc dot
gnu.org
Ever confirmed|0 |1
--- Comment #2 from David Malcolm ---
I'm working on a fix for this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109163
--- Comment #1 from David Malcolm ---
This would also help with one of the requests from a SARIF expert's review of
GCC's output:
https://github.com/oasis-tcs/sarif-spec/issues/531#issuecomment-1181191100
which is that the "version" property
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105959
--- Comment #9 from David Malcolm ---
(In reply to David Malcolm from comment #7)
[...snip...]
> There some variation due to json::object using a hash_map for the key/value
> pairs, which means (annoyingly) it outputs things in arbitrary
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: dmalcolm at gcc dot gnu.org
Target Milestone: ---
gcc/json.cc's json::object uses a hash_map for tracking the key/value pairs,
and object::print iterates through them in arbitrary order, so
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105959
--- Comment #8 from David Malcolm ---
Note that section 3.1 ("File Format" > "General") specifies:
"A SARIF log file SHALL be encoded in UTF-8 [RFC3629]."
https://docs.oasis-open.org/sarif/sarif/v2.1.0/sarif-v2.1.0.html
Though I suppose it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105959
David Malcolm changed:
What|Removed |Added
Last reconfirmed|2023-01-30 00:00:00 |2023-03-16
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109094
David Malcolm changed:
What|Removed |Added
Last reconfirmed||2023-03-16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109094
--- Comment #4 from David Malcolm ---
(In reply to Martin Liška from comment #3)
> Fixed?
Sadly no, the comment above is just to mention that at least the crash is now
captured in the .sarif dump.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109097
David Malcolm changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105909
--- Comment #1 from David Malcolm ---
Perhaps via 3.58 notification object:
https://docs.oasis-open.org/sarif/sarif/v2.1.0/os/sarif-v2.1.0-os.html#_Toc34317894
which: "describes a condition encountered during the execution of an analysis
tool
: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: dmalcolm at gcc dot gnu.org
Target Milestone: ---
Created attachment 54664
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54664=edit
Reduced reproducer
Tr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109120
--- Comment #6 from David Malcolm ---
Note to self: there's a usage example in the glibc manual here:
https://www.gnu.org/software/libc/manual/html_node/iconv-Examples.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109120
--- Comment #5 from David Malcolm ---
Potentially could be worked around from the gcc side by adding a known_function
implementation for iconv_{open,close}.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109120
--- Comment #4 from David Malcolm ---
...and thus presumably glibc 2.36 onwards uses the attribute on iconv_open.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109120
--- Comment #3 from David Malcolm ---
(In reply to David Malcolm from comment #2)
> Looks like the attribute was added to iconv_open in glibc in this commit:
>
> https://sourceware.org/git/?p=glibc.git;a=commitdiff;
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109120
--- Comment #2 from David Malcolm ---
Looks like the attribute was added to iconv_open in glibc in this commit:
https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=260a430dd841072020c4dae91468322e619e7330
Unfortunately, as currently
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109120
--- Comment #1 from David Malcolm ---
Thanks for filing this bug. Seems to affect GCC 11 onwards, as GCC 10 didn't
support the 2nd argument to __attribute__((malloc)):
Trunk: https://godbolt.org/z/MbWezaxrz
GCC 12.2:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105959
--- Comment #4 from David Malcolm ---
Created attachment 54653
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54653=edit
Generated diagnostic-format-sarif-file-4.c.sarif output file on my machine
(In reply to Hans-Peter Nilsson from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105906
--- Comment #3 from David Malcolm ---
(In reply to David Malcolm from comment #2)
> Looks like this is fixed on trunk for GCC 13; seem to have been via
> 688fc162b76dc6747a30fcfd470f4770da0f4924
aka r13-5113-g688fc162b76dc6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105906
--- Comment #2 from David Malcolm ---
Looks like this is fixed on trunk for GCC 13; seem to have been via
688fc162b76dc6747a30fcfd470f4770da0f4924
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107017
David Malcolm changed:
What|Removed |Added
CC||geoffreydgr at icloud dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109106
David Malcolm changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109098
--- Comment #4 from David Malcolm ---
(In reply to Andrew Pinski from comment #2)
> So I think there is a bug in that code ...
The issue is in sarif_builder::maybe_make_artifact_content_object, which uses;
char *text_utf8 = maybe_read_file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109098
--- Comment #3 from David Malcolm ---
(In reply to Andrew Pinski from comment #1)
> I would have assumed you need -finput-charset= for the non-utf8 ones really
> if your LANG/LANGUAGE is not set to C/UTF8 really.
Yeah, but when complaining
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109098
David Malcolm changed:
What|Removed |Added
Last reconfirmed||2023-03-11
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: dmalcolm at gcc dot gnu.org
Target Milestone: ---
I've run into issues with -fanalyzer integration testing when a diagnostic
occurs in a source file with non-UTF-8 bytes
Assignee: dmalcolm at gcc dot gnu.org
Reporter: dmalcolm at gcc dot gnu.org
Target Milestone: ---
If an ICE occurs inside cc1 with -fdiagnostics-format=sarif-file, then no
.sarif file is written out.
This is a nuisance e.g. for my integration testing of -fanalyzer, which I'm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109094
--- Comment #1 from David Malcolm ---
Created attachment 54637
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54637=edit
Unreduced reproducer
: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: dmalcolm at gcc dot gnu.org
Target Milestone: ---
Trunk ICEs on the attached:
$ ./xgcc -B. -fanalyzer -S ../../src/target_i386_tcg_translate.c \
-Wall -Wno-array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109059
David Malcolm changed:
What|Removed |Added
Last reconfirmed||2023-03-10
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109060
David Malcolm changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108475
David Malcolm changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109058
--- Comment #2 from David Malcolm ---
(In reply to David Malcolm from comment #0)
> Seen on a diagnostic in haproxy's cfgparse-global.c: cfg_parse_global
For reference, see cfg_parse_global in:
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: dmalcolm at gcc dot gnu.org
Target Milestone: ---
Created attachment 54603
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54603=edit
Reprodu
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: dmalcolm at gcc dot gnu.org
Target Milestone: ---
Given:
/* Reduced from haproxy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109058
--- Comment #1 from David Malcolm ---
Even better would be for the event condition to express the string, when it's a
string literal, so that it reads:
../../src/gcc/testsuite/gcc.dg/analyzer/strcmp-path-1.c:27:5: note: path
27 |
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: dmalcolm at gcc dot gnu.org
Target Milestone: ---
Seen on a diagnostic in haproxy's cfgparse-global.c: cfg_parse_global
Consider
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108988
--- Comment #8 from David Malcolm ---
(In reply to Jakub Jelinek from comment #6)
> Fixed.
Thanks!
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: dmalcolm at gcc dot gnu.org
Target Milestone: ---
Created attachment 54581
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54581=edit
Work in progress patch
Currently the analyzer does
: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: dmalcolm at gcc dot gnu.org
Target Milestone: ---
Created attachment 54580
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54580=edit
Work in progress patch
Currently the analyzer doesn't recognize atomic built
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109014
--- Comment #1 from David Malcolm ---
I believe the issue here is that:
* display_properties partially initializes the "found" buffer, writing a -1
terminator at the end of the initialized part at:
fv[m] = -1;
* display_properties then
: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: dmalcolm at gcc dot gnu.org
Target Milestone: ---
Created attachment 54579
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54579=edit
Partially reducer reproducer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107999
David Malcolm changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108968
--- Comment #18 from David Malcolm ---
Looks like it doesn't even need the asm stmt at line 32 to consider that it
could take the false-then-true path.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108968
--- Comment #17 from David Malcolm ---
...where trunk emits:
test.c:35:22: warning: dereference of NULL 'ptr' [CWE-476]
[-Wanalyzer-null-dereference]
35 | ptr[0] = ~ptr[0];
| ~~~^~~
'foo': events 1-6
|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108968
--- Comment #16 from David Malcolm ---
Minimized version of attachment 54572:
struct cpu_info {
/* [...snip...] */
struct vcpu *current_vcpu;
/* [...snip...] */
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108968
--- Comment #12 from David Malcolm ---
(In reply to Andrew Cooper from comment #9)
[...snip...]
> Our code does fundamentally rely on get_cpu_info() always returning the same
> pointer (on a single CPU). For example, `current` is defined as
>
301 - 400 of 3226 matches
Mail list logo
