https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93993
David Malcolm changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94028
--- Comment #2 from David Malcolm ---
Yes, the ICE was fixed by r10-7023-g3d66e153b40ed000af30a9e569a05f34d5d576aa.
It's a similar issue to the reproducer for PR analyzer/93993.
I'll add your reproducer as a further regression test; thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94028
David Malcolm changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94047
--- Comment #2 from David Malcolm ---
Fixed by g:787477a226033e36be3f6d16b71be13dd917e982; I'll add a regression
test.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94047
--- Comment #3 from David Malcolm ---
(In reply to David Malcolm from comment #2)
> Fixed by g:787477a226033e36be3f6d16b71be13dd917e982; I'll add a regression
> test.
Sorry; that should be g:90f7c3007d58c5cb538d00351c038f3f2cfcaf67.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94099
David Malcolm changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94105
David Malcolm changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94047
David Malcolm changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94230
--- Comment #6 from David Malcolm ---
I'm not sure this has a changed a lot "recently"; I did 2-3 years ago IIRC.
The warning occurs when we have location_t > LINE_MAP_MAX_LOCATION_WITH_COLS
which means that we've run out of values for expressin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94350
--- Comment #3 from David Malcolm ---
Also, which version of the compiler? I've fixed a few similar-looking problems
to this recently.
normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: dmalcolm at gcc dot gnu.org
Target Milestone: ---
Created attachment 48134
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48134&action=edit
Reduced test case
https://githu
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: dmalcolm at gcc dot gnu.org
Target Milestone: ---
The default -fdiagnostics-path-format=inline-events prints each macro expansion
for every event in the path that's from a macro expa
Assignee: dmalcolm at gcc dot gnu.org
Reporter: dmalcolm at gcc dot gnu.org
Target Milestone: ---
Consider e.g.:
struct foo
{
int *v;
};
int test (void)
{
struct foo f = {};
return *f.v;
}
This currently reports
t.c: In function ‘test’:
t.c:9:10: warning: use of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94378
David Malcolm changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94378
--- Comment #4 from David Malcolm ---
Can you attach the analyzer report please?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94378
--- Comment #6 from David Malcolm ---
Thanks Simon. The second diagnostic definitely looks like a false positive; am
not sure about the first. Please can you file a separate bug about this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94503
--- Comment #2 from David Malcolm ---
Appears to be due to return slot optimization.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94382
David Malcolm changed:
What|Removed |Added
CC||dmalcolm at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92830
David Malcolm changed:
What|Removed |Added
CC||dmalcolm at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92830
David Malcolm changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94754
David Malcolm changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94732
David Malcolm changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94447
--- Comment #2 from David Malcolm ---
r10-8012-g78b9783774bfd3540f38f5b1e3c7fc9f719653d7 removes the false positive,
but we should still handle CONSTRUCTOR tree nodes. Keeping this open.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94639
David Malcolm changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94714
David Malcolm changed:
What|Removed |Added
Target Milestone|--- |11.0
--- Comment #1 from David Malcolm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94816
David Malcolm changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: dmalcolm at gcc dot gnu.org
Depends on: 94447, 94639, 94732, 94754
Target Milestone: ---
I removed -Wanalyzer-use-of-uninitialized-value in
r10-8012
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94447
David Malcolm changed:
What|Removed |Added
CC||tommy-gccbugs at thorn dot ws
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94999
David Malcolm changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95006
Bug 95006 depends on bug 94999, which changed state.
Bug 94999 Summary: internal compiler error: in saved_diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94999
What|Removed |Added
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94999
--- Comment #2 from David Malcolm ---
Actually, it's possibly failing to realize that calloc zeroes the memory.
Either way it makes a good test case for when reintroducing
-Wanalyzer-use-of-uninitialized-value; thanks.
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: dmalcolm at gcc dot gnu.org
Target Milestone: ---
(Motivated by PR analyzer/95000, which has a false-positive path to a write to
a string literal)
Consider:
void test (void)
{
char
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95000
--- Comment #3 from David Malcolm ---
Thanks for filing this bug.
I've filed PR analyzer/95007 to track the RFE for a warning about writes to a
string literal.
Clearly there's a bug somewhere in the handling for the path condition for the
warni
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95000
David Malcolm changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94851
David Malcolm changed:
What|Removed |Added
Summary|-fanalyzer erroniously |-fanalyzer erroneously
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94458
David Malcolm changed:
What|Removed |Added
Last reconfirmed||2020-05-08
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95007
--- Comment #2 from David Malcolm ---
I guess I'm thinking about the case where a string literal has been exposed as
a non-const "char *": the RFE here is for -fanalyzer to be able to detect if we
ever write to such a string (with interprocedural
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95043
--- Comment #1 from David Malcolm ---
Please note that C++ isn't supported in the GCC 10 implementation of -fanalyzer
(I hope to do so for GCC 11, but there's a lot of work to do).
In particular, I haven't implemented exceptions yet.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95031
--- Comment #2 from David Malcolm ---
Please note that C++ isn't supported in the -fanalyzer implementation in GCC
10. I hope to get it working for GCC 11 (but there's a lot of work to do).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95296
David Malcolm changed:
What|Removed |Added
Last reconfirmed||2020-05-24
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95314
--- Comment #1 from David Malcolm ---
Thanks for reporting it; this sounds like a bug.
Please can you use attach a reproducer (e.g. using
gcc_jit_context_dump_reproducer_to_file).
Looking at the backtrace, it looks like a bad interaction with i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95314
--- Comment #3 from David Malcolm ---
Thanks Jakub, that sounds like the problem: I'm creating a tree per
playback::rvalue (m_inner), and I need to unshare them.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95314
--- Comment #6 from David Malcolm ---
Sorry about that; thanks for trying. I think I can figure out a reproducer,
and will try tomorrow.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95296
David Malcolm changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95306
David Malcolm changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87005
David Malcolm changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95314
--- Comment #7 from David Malcolm ---
Created attachment 48615
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48615&action=edit
Non-reproducing attempt at a reproducer
I attempted to reproduce this, but was unsuccessful. I'm attaching wha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95314
David Malcolm changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91330
David Malcolm changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95314
David Malcolm changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95415
--- Comment #1 from David Malcolm ---
Perhaps, but it looks non-trivial.
Notes to self:
c/c-tree.h: struct c_declspecs has:
/* Whether "__thread" or "_Thread_local" was specified. */
BOOL_BITFIELD thread_p : 1;
/* Whether "__thread" rath
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95426
--- Comment #1 from David Malcolm ---
gcc_jit_context_dump_reproducer_to_file runs in the testsuite, and I see it
generating sane-looking reproducers (with non-empty create_code functions).
Are you calling gcc_jit_context_dump_reproducer_to_file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95426
--- Comment #3 from David Malcolm ---
Aha - thanks.
Re-reading
https://gcc.gnu.org/onlinedocs/jit/topics/contexts.html#debugging
it looks like the documentation for these entrypoints could use some
clarification on whether each one relates to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95426
David Malcolm changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95426
--- Comment #5 from David Malcolm ---
Created attachment 48657
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48657&action=edit
Reduced test case
I've reduced the reproducer you posted to this test case.
Seems to require a call to __built
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95426
--- Comment #7 from David Malcolm ---
This seems like a bug with how libgccjit interacts with __builtin_unreachable,
sorry.
As a workaround, try removing the __builtin_unreachable calls for now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95426
--- Comment #8 from David Malcolm ---
Looks like the way libgccjit sets up attributes (such as "noreturn") on
builtins has somehow become a no-op. Am investigating.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95426
David Malcolm changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87291
--- Comment #3 from David Malcolm ---
Note to self: GCC's documentation for using asm from C:
https://gcc.gnu.org/onlinedocs/gcc/Using-Assembly-Language-with-C.html
Thanks for the suggestions.
I'm not seeing how the proposed entrypoints in co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95306
--- Comment #6 from David Malcolm ---
I've added the type; hopefully the builtin works as expected.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87291
--- Comment #7 from David Malcolm ---
(In reply to Andrew Pinski from comment #5)
> (In reply to bouanto from comment #4)
> > So, an example like this:
> >
> > ```c
> > bool old;
> > __asm__ ("btsl %2,%1\n\t" // Turn on zero-based bit #Offset in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87291
--- Comment #8 from David Malcolm ---
Reading the docs for extended asm, I think the API entrypoint would need to
look something like:
extern void
gcc_jit_block_add_extended_asm (gcc_jit_block *block,
int is_volat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95521
--- Comment #2 from David Malcolm ---
(In reply to Andrew Pinski from comment #1)
> >libgccjit.so: error: in build2, at tree.c:4743
>
> This means the PLUS_EXPR is being used when adding a pointer and an integer
> together. It needs to be POINT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95521
--- Comment #3 from David Malcolm ---
(In reply to bouanto from comment #0)
> The reproducer is very big, so tell me if you want me to try to make it
> smaller.
Yes please!
The attachment reproduces the ICE for me, but is too big for me to work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87291
--- Comment #13 from David Malcolm ---
An alternative approach that reduces the number of params by splitting it into
successive calls:
extern gcc_jit_extended_asm *
gcc_jit_block_add_extended_asm (gcc_jit_block *block,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87291
--- Comment #14 from David Malcolm ---
Or even move the flags to API calls:
extern gcc_jit_extended_asm *
gcc_jit_block_add_extended_asm (gcc_jit_block *block,
const char *asm_template);
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95521
David Malcolm changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87291
--- Comment #16 from David Malcolm ---
Created attachment 48677
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48677&action=edit
Work-in-progress patch
I had a go at implementing this; attached is a work-in-progress prototype.
It works fo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87291
--- Comment #17 from David Malcolm ---
(also uploaded to
https://dmalcolm.fedorapeople.org/gcc/2020-06-04/0001-FIXME-WIP-on-extended-asm-support.patch
)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87291
--- Comment #19 from David Malcolm ---
(In reply to bouanto from comment #18)
> (In reply to David Malcolm from comment #16)
> > Created attachment 48677 [details]
> This API looks good.
Thanks.
[...snip...]
> > "Basic" asm
> > ===
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87291
--- Comment #21 from David Malcolm ---
(In reply to bouanto from comment #20)
> Well, there's syntax for assembly at the top-level so the user can enter
> anything he wants, like in C.
> I can craft you an example if you need to, though.
I could
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87291
David Malcolm changed:
What|Removed |Added
Attachment #48677|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87291
--- Comment #24 from David Malcolm ---
(In reply to bouanto from comment #23)
> Created attachment 48685 [details]
> Example of global assembly
[...snip; thanks for the feedback]
> I attached an example of global assembly.
Thanks.
> I don
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87291
--- Comment #26 from David Malcolm ---
(there's also -fno-toplevel-reorder which makes me wonder if we do need to
preserve ordering with such constructs)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87291
David Malcolm changed:
What|Removed |Added
Attachment #48684|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87291
--- Comment #28 from David Malcolm ---
Generated HTML for docs (albeit without css) here:
https://dmalcolm.fedorapeople.org/gcc/2020-06-06/asm-v3.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95498
--- Comment #2 from David Malcolm ---
Try putting a breakpoint on add_error (there are a few classes with add_error
methods; a sufficiently smart gdb ought to put the breakpoint on all of them).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87291
David Malcolm changed:
What|Removed |Added
Last reconfirmed||2020-06-08
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87291
David Malcolm changed:
What|Removed |Added
Attachment #48694|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86904
David Malcolm changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84889
David Malcolm changed:
What|Removed |Added
Target Milestone|10.3|---
Status|WAITING
: UNCONFIRMED
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: dmalcolm at gcc dot gnu.org
Target Milestone: ---
Analyzer fails to find a path to the __analyzer_dump_path call:
#include "analyzer-decls.h&
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96374
--- Comment #1 from David Malcolm ---
This is likely to be associated with "merger" exploded_nodes (where we have
merged state to help the exploded graph converge). Perhaps if we fail to find
a feasible path on the first try we could retry, find
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96395
--- Comment #1 from David Malcolm ---
Thanks for filing this.
FWIW I've spent the last 4 months rewriting the state-tracking heart of the
analyzer, with a patch kit I hope to land next month. Along with many other
changes, explode-2.c changes b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93032
David Malcolm changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93938
David Malcolm changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94011
David Malcolm changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
||dmalcolm at gcc dot gnu.org
Status|UNCONFIRMED |RESOLVED
--- Comment #1 from David Malcolm ---
The leak false positive should be fixed by
g:808f4dfeb3a95f50f15e71148e5c1067f90a126d (for GCC 11). Marking this as
fixed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94458
David Malcolm changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94640
David Malcolm changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94839
Bug 94839 depends on bug 94640, which changed state.
Bug 94640 Summary: false-positive leaking FILE pointer assigned to function
passed pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94640
What|Removed |A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94503
David Malcolm changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94688
David Malcolm changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94689
David Malcolm changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94858
Bug 94858 depends on bug 94839, which changed state.
Bug 94839 Summary: False positive with -fanalyzer and direct field assignment
from calloc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94839
What|Removed |Ad
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94839
David Malcolm changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95026
David Malcolm changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95042
David Malcolm changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95240
David Malcolm changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96598
David Malcolm changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
1 - 100 of 3373 matches
Mail list logo
