Assignee: dmalcolm at gcc dot gnu.org
Reporter: pmatos at gcc dot gnu.org
Target Milestone: ---
On GCC tip of master from 20200814.
While static analyzing the racket source (github.com/racket/racket), it fails
on (reduced):
struct {
long a;
} * b;
void c();
int d() {
c();
c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94689
--- Comment #6 from pmatos at gcc dot gnu.org ---
Thanks - I will rerun the static analyzer on the codebase that previously
crashed the static analyzer and report back.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94689
--- Comment #4 from pmatos at gcc dot gnu.org ---
Unfortunately a fix for this didn't make it into 10.1. We can still not analyze
racket source code due to this issue.
: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: pmatos at gcc dot gnu.org
Target Milestone: ---
With head of git from today (2020.04.21), gcc with -fanalyzer return non-zero
exit code for
///
*a;
b;
c() { d((void (*)())a + b); }
///
using the command line:
gcc -O2 -g
Assignee: dmalcolm at gcc dot gnu.org
Reporter: pmatos at gcc dot gnu.org
Target Milestone: ---
While reducing a testcase for a separate bug I found an analyzer ice.
///
a, b;
c() { d((void (*)()) & a + b); }
///
Compiled with todays (2020.04.21) head:
gcc -O2 -g -fanalyzer -Wall
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93288
--- Comment #11 from pmatos at gcc dot gnu.org ---
(In reply to David Malcolm from comment #10)
> Should be fixed by the above commit.
David, does this mean the analyzer has C++ support now or just that this
specific bug is fixed in-tree?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93288
--- Comment #2 from pmatos at gcc dot gnu.org ---
(In reply to David Malcolm from comment #1)
> Note that C++ is out-of-scope for the analyzer for GCC 10.
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x
Assignee: dmalcolm at gcc dot gnu.org
Reporter: pmatos at gcc dot gnu.org
Target Milestone: ---
Great work with the analyzer! :)
I am running it on WebKit and I find a few issues. At the moment they all seem
to point to supergraph.cc:180. Here's a reduced example with todays
(16.01.2020
Assignee: unassigned at gcc dot gnu.org
Reporter: pmatos at gcc dot gnu.org
Target Milestone: ---
Created attachment 46455
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46455=edit
testcase
There's a bad out of bounds warning in gcc7 line which seems to be fixed in
gcc8 and la
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53917
pmatos at gcc dot gnu.org changed:
What|Removed |Added
CC||pmatos at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49884
pmatos at gcc dot gnu.org changed:
What|Removed |Added
CC||pmatos at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50582
pmatos at gcc dot gnu.org changed:
What|Removed |Added
CC||pmatos at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83071
--- Comment #5 from pmatos at gcc dot gnu.org ---
Thanks. It's working.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83071
--- Comment #2 from pmatos at gcc dot gnu.org ---
(In reply to Ian Lance Taylor from comment #1)
> This is of course a compiler bug, but it's a crash on invalid code. You
> can't write `input++` when `input` is a string type.
at airs dot com
Reporter: pmatos at gcc dot gnu.org
CC: cmang at google dot com
Target Milestone: ---
I have written a very simple program in Go and somehow I surprisingly managed
to crash the compiler.
This is my first Go program so maybe I am playing outside
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72818
pmatos at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72818
--- Comment #1 from pmatos at gcc dot gnu.org ---
Please disregard the -fsanitize=undefined in my initial comment. I didn't
expect -fsanitize=undefined to caught it. That was an artefact from my original
example. I expected a warning from GCC
: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: pmatos at gcc dot gnu.org
Target Milestone: ---
GCC appropriately generates a warning for:
void f(char c){*(unsigned*)=0;}
$ gcc -Wall -fsanitize=undefined -Os -c -ocast1.s cast1.c
cast1.c: In function ‘f’:
cast1.c:1:1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351
pmatos at gcc dot gnu.org changed:
What|Removed |Added
CC||pmatos at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351
--- Comment #27 from pmatos at gcc dot gnu.org ---
(In reply to Manuel López-Ibáñez from comment #26)
A good place to start is
https://gcc.gnu.org/bugzilla/buglist.
cgi?keywords=easyhacklist_id=116934order=bug_idquery_format=advanced
Thanks
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: pmatos at gcc dot gnu.org
enum xpto
{
A = 0,
B = 1,
X = 512
};
extern void print (unsigned int);
unsigned char bar (enum xpto a)
{
return a;
}
We don't get currently a warning for this return conversion
: unassigned at gcc dot gnu.org
Reporter: pmatos at gcc dot gnu.org
Created attachment 32259
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32259action=edit
Testcase for this bug (and pr55113 as well)
After fixing PR55113, I noticed that the testcase gcc.dg/lto/pr55113_0.c ICEs
x86_64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55113
pmatos at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55113
--- Comment #17 from pmatos at gcc dot gnu.org ---
Patch submitted to gcc-patches.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55113
--- Comment #16 from pmatos at gcc dot gnu.org ---
(In reply to Richard Biener from comment #14)
Well. At least to my theory (didn't try).
Theory and practice match. It seems to fix the bug and work fine. I will do
some further testing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55113
--- Comment #15 from pmatos at gcc dot gnu.org ---
(In reply to Richard Biener from comment #14)
See above - if that works I'd prefer that.
Makes sense. Thanks Richard. I will give that a try and if everything looks ok
I will prepare a patch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55113
--- Comment #13 from pmatos at gcc dot gnu.org ---
(In reply to Richard Biener from comment #11)
If double_type_node is FE dependent then it needs treatment in
tree-streamer.c:preload_common_nodes:
static void
preload_common_nodes (struct
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
pmatos at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58463
--- Comment #8 from pmatos at gcc dot gnu.org ---
Author: pmatos
Date: Fri Sep 27 14:54:43 2013
New Revision: 202976
URL: http://gcc.gnu.org/viewcvs?rev=202976root=gccview=rev
Log:
PR middle-end/58463
* gcc.dg/pr58463.c: New test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58463
--- Comment #9 from pmatos at gcc dot gnu.org ---
Author: pmatos
Date: Fri Sep 27 16:30:15 2013
New Revision: 202978
URL: http://gcc.gnu.org/viewcvs?rev=202978root=gccview=rev
Log:
Backport from mainline.
2013-09-27 Paulo Matos
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56716
--- Comment #11 from pmatos at gcc dot gnu.org ---
Author: pmatos
Date: Fri Sep 27 16:44:39 2013
New Revision: 202979
URL: http://gcc.gnu.org/viewcvs?rev=202979root=gccview=rev
Log:
Backport from mainline.
PR middle-end/58463
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58463
--- Comment #10 from pmatos at gcc dot gnu.org ---
Author: pmatos
Date: Fri Sep 27 16:44:39 2013
New Revision: 202979
URL: http://gcc.gnu.org/viewcvs?rev=202979root=gccview=rev
Log:
Backport from mainline.
PR middle-end/58463
32 matches
Mail list logo
