https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101727
--- Comment #3 from zhan3299 at purdue dot edu ---
(In reply to Jakub Jelinek from comment #2)
> Note, the documentation talks about it:
> https://gcc.gnu.org/onlinedocs/gcc-11.2.0/gcc/Basic-Asm.html#Basic-Asm
> Under certain circumsta
: inline-asm
Assignee: unassigned at gcc dot gnu.org
Reporter: zhan3299 at purdue dot edu
Target Milestone: ---
Following code can be successfully compiled with O0 optimization enabled, but
not O2.
Example code:
---
#include
int func() {
int filter;
asm volatile
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: zhan3299 at purdue dot edu
Target Milestone: ---
GCC fails to compile the attached code: https://godbolt.org/z/sdqq3M
One interesting thing is that, only when we override __builtin_clzll this issue
will occur. If we
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: zhan3299 at purdue dot edu
Target Milestone: ---
Following code behaves differently with different optimizations.
$ cat test.c
#pragma pack(1)
struct {
char a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99168
--- Comment #4 from zhan3299 at purdue dot edu ---
(In reply to Martin Liška from comment #3)
> Very interesting issue, the failure is caused by IPA ICF that merges 2
> variables with different alignments. I've got a patch candidate
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: zhan3299 at purdue dot edu
Target Milestone: ---
Following code is reduced by c-reduce and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99156
--- Comment #2 from zhan3299 at purdue dot edu ---
(In reply to Martin Liška from comment #1)
> Yes, I can confirm the issue. Thanks for the report.
Many thanks for your prompt reply. Additionally, I have to give credit to
Richard Smith
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99168
--- Comment #1 from zhan3299 at purdue dot edu ---
If we resolved the conflicts on "aligned", it would behave normally. I feel
like the ASAN is confused by the "aligned" somehow.
Should it have thrown some warnings?
: c
Assignee: unassigned at gcc dot gnu.org
Reporter: zhan3299 at purdue dot edu
Target Milestone: ---
I am not sure whether the following problem is caused by ASAN or O2.
Following code has different behaviors between "-fsanitize=address -O0" and
"-fsanitize=a
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: zhan3299 at purdue dot edu
Target Milestone: ---
I hope it does not bother. I try to refer to a bug in llvm which may also
affect gcc.
Following are copied-and-pasted from the discussion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99015
--- Comment #1 from zhan3299 at purdue dot edu ---
It seems clang at any optimization level can compile this. GCC at -O0 can also
compile it.
Priority: P3
Component: inline-asm
Assignee: unassigned at gcc dot gnu.org
Reporter: zhan3299 at purdue dot edu
Target Milestone: ---
Another inline-asm issue causes an ICE.
--- poc.c starts ---
int main() {
asm("" : : "fq"(.100
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98991
--- Comment #4 from zhan3299 at purdue dot edu ---
Seems '-fpermissive' is useless. I can reproduce the ICE simply via 'gcc
poc.cc'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98991
--- Comment #3 from zhan3299 at purdue dot edu ---
(In reply to Martin Liška from comment #1)
> Is it a valid or invalid code, please?
Hi, sorry for the confusion. I used a simple delta debugging to reduce the
test-case, and it seems v
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: zhan3299 at purdue dot edu
Target Milestone: ---
Created attachment 50141
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50141&action=edit
poc.cc
Hi all,
Hope I do not bother too much.
I got a
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: zhan3299 at purdue dot edu
Target Milestone: ---
Created attachment 50140
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50140&action=edit
poc.cc
Hi all,
I am n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98972
--- Comment #3 from Zhuo Zhang ---
I reduced the test-case, and the simplest test-case should be:
--- crash1.cc starts ---
constexpr p([](register const signed struct s;
--- crash1.cc ends ---
The bug is also reproduced on the commit
8d0737d8f4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98972
--- Comment #2 from Zhuo Zhang ---
(In reply to Martin Liška from comment #1)
> Thank you for the report. Actually, it's an invalid code and we do have a
> lot of error recovery ICEs.
> Or do you have an original test-case that is a valid C++ cod
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: zhan3299 at purdue dot edu
Target Milestone: ---
Hi,
I have a crafted .cc program named crash1.cc. When I use both gcc-10 and g++-10
compile it, an internal compiler
: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: zhan3299 at purdue dot edu
Target Milestone: ---
For secure programing, sensitive information located at heap, e.g password,
should be cleared before
20 matches
Mail list logo
