https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111080
--- Comment #2 from sagebar at web dot de ---
@Andrew Pinski
Of course: yes. I did make a mistake there, but only for this case:
> int (*fun_t)(struct foo *); // Leak (even w/o restrict!)
asm:
...
.globl fu
Assignee: unassigned at gcc dot gnu.org
Reporter: sagebar at web dot de
Target Milestone: ---
The the following code example, debug information is retained for `struct foo`
even though that structure doesn't end up used:
Compile as `gcc -g -S -o - in.c | grep field_number
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110607
--- Comment #2 from sagebar at web dot de ---
@Andrew Pinski
Sorry if this is a known bug. I simply checked the current gcc master
(https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=Makefile.tpl;h=d0fe7e2fb778b3c3fa2cc8742e06cf1f78fdc5f2;hb=HEAD#l183
Priority: P3
Component: driver
Assignee: unassigned at gcc dot gnu.org
Reporter: sagebar at web dot de
Target Milestone: ---
This part in the main makefile:
> 177 # These variables must be set on the make command line for directories
> 178 # built for the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105682
--- Comment #8 from sagebar at web dot de ---
(In reply to Jan Hubicka from comment #6)
> I think the conlcusion here is correct. callee has pure attribute and that
> means that it has no side effects except for reading global memo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105684
--- Comment #3 from sagebar at web dot de ---
>The issue is that 'result->data0.a' is (*result).data0.a, and so to GCC you are
>accessing an object of type 'obj' for which there isn't enough allocated space.
Technically true
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: sagebar at web dot de
Target Milestone: ---
The following code wrongly produces a warning `[-Wstringop-overflow=`:
Compile (using `gcc -c -O
Severity: normal
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: sagebar at web dot de
CC: marxin at gcc dot gnu.org
Target Milestone: ---
I would re-open https://gcc.gnu.org/bugzilla/show_bug.cgi?id
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: sagebar at web dot de
Target Milestone: ---
Accessing the fields of a partially allocated struct results in
`-Warray-bounds`, even when all accessed fields lie within the allocated
portion of the struct (a fact
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: sagebar at web dot de
Target Milestone: ---
The following example causes both a `-Wsuggest-attribute=pure` and
`-Wsuggest-attribute=const` warning for the same function
: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: sagebar at web dot de
Target Milestone: ---
When compiling with `-Wsuggest-attribute=pure`, gcc warns about missing
`__attribute__((pure))` on functions declared
: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: sagebar at web dot de
Target Milestone: ---
g++ has a list of *special* function names that it recognizes as builtins. This
includes things like `memcpy` or `strlen`.
The problem is that this list includes information
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96516
--- Comment #4 from sagebar at web dot de ---
(In reply to sagebar from comment #3)
> ..., _any_ attribute that
> can be inherited via copy() can be made template-conditional in c++:
Also note that I've tested if gcc (`-x c') allows mu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96516
--- Comment #3 from sagebar at web dot de ---
No problem. Also: What you just said made me realize that once
__attribute__((copy)) works correctly with templates, _any_ attribute that can
be inherited via copy() can be made template-conditional
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: sagebar at web dot de
Target Milestone: ---
Created attachment 49016
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49016=edit
Same code as already seen in the bug description
Us
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: sagebar at web dot de
Target Milestone: ---
Created attachment 48982
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48982=edit
Compile me with and with
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: sagebar at web dot de
Target Milestone: ---
Created attachment 48130
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48130=edit
Is
: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: sagebar at web dot de
Target Milestone: ---
Created attachment 47939
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47939=edit
Inefficient code generation, simi
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: sagebar at web dot de
Target Milestone: ---
Created attachment 47555
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47555=edit
Issue demonstration
L
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92641
--- Comment #2 from sagebar at web dot de ---
(In reply to Andrew Pinski from comment #1)
> The big question comes, where should the VLA type be finalized, at the use
> or at the beginning of the statement.
>
> Statement expressions
Assignee: unassigned at gcc dot gnu.org
Reporter: sagebar at web dot de
Target Milestone: ---
Created attachment 47339
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47339=edit
Listing of problematic code, and similar code that works correctly
Given something l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92438
--- Comment #2 from sagebar at web dot de ---
The c++ standard may not cover it, however in the interest of compatibility
with other compilers, g++ for cygwin actually defines the following predefined
macros (among others):
g++ -dM -E -x c
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: sagebar at web dot de
Target Milestone: ---
Created attachment 47204
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47204=edit
Demonstration of incorrect parsing + several work-arou
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91655
--- Comment #2 from sagebar at web dot de ---
Of course. I understand, am sorry to have bothered you, and totally agree that
those macros are extremely bad (but sadly are being used by programs that I'm
trying to provide compatibility for).
Have
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: sagebar at web dot de
Target Milestone: ---
After building libstdc++ for a custom toolchain that tries to form a hybrid of
both linux/gnu system headers, as well as headers normally only
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: sagebar at web dot de
Target Milestone: ---
Created attachment 46517
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46517=edit
Minimal code that triggers the problem
Using a branch-dependent ret
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90710
--- Comment #2 from sagebar at web dot de ---
(In reply to Jeffrey A. Law from comment #1)
> We focus most of our effort on avoiding false positives with -O2
> optimization levels. As you lower the optimization level (-Og) you will
&g
: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: sagebar at web dot de
Target Milestone: ---
Created attachment 46442
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46442=edit
Copy of the code alre
28 matches
Mail list logo
