https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36381
Eric Gallager changed:
What|Removed |Added
Assignee|dfranke at gcc dot gnu.org |unassigned at gcc dot
gnu.org
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=17426
Eric Gallager changed:
What|Removed |Added
Assignee|giovannibajo at gmail dot com |unassigned at gcc dot
gnu.org
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33915
Eric Gallager changed:
What|Removed |Added
Status|WAITING |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44803
Eric Gallager changed:
What|Removed |Added
Status|WAITING |RESOLVED
Last reconfirmed|2018-06-02 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67246
--- Comment #10 from Jeff Hansen ---
So you're recommending that we add __attribute__((packed)) to the struct?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87187
Bug ID: 87187
Summary: FAIL: gfortran.dg/short_circuiting_3.f90 -g -flto
(internal compiler error) on darwin
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Sev
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87187
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87186
--- Comment #2 from Marc Glisse ---
How did you check? Looking at the .optimized dump or the asm, it is optimized
to a simple xor.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87185
Nathan Sidwell changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87188
Bug ID: 87188
Summary: Function pointer canonicalization optimized away
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87157
--- Comment #3 from Bill Schmidt ---
I don't have a recently built gcc lying around, but from an earlier version,
here's the command line from the testsuite log:
/home/wschmidt/gcc/build/gccgit-test/gcc/xgcc
-B/home/wschmidt/gcc/build/gccgit-tes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87189
Bug ID: 87189
Summary: libgcc/gthr-posix.h (__gthread_active_p) makes
unwarranted assumptions about libpthread.a
Product: gcc
Version: unknown
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87189
--- Comment #1 from Paul Pluzhnikov ---
Crash stack for reference:
Program received signal SIGSEGV, Segmentation fault.
0x in ?? ()
(gdb) bt
#0 0x in ?? ()
#1 0x00477f7c in __gthread_mutex_lock (__mutex=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87188
John David Anglin changed:
What|Removed |Added
Component|middle-end |tree-optimization
--- Comment #1 fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87188
--- Comment #2 from John David Anglin ---
Created attachment 44648
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44648&action=edit
Preprocessed source
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87190
Bug ID: 87190
Summary: Feedback on documentation for symbol visibility
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87190
--- Comment #1 from Jeffrey Walton ---
In case it is needed, here's the citation for "Remember the docs say all
symbols are private (not some symbols)":
https://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html:
Set the default ELF image symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87157
--- Comment #4 from Bill Schmidt ---
Created attachment 44649
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44649&action=edit
vect details dump for r264043
Here's the requested dump information.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53972
Eric Gallager changed:
What|Removed |Added
CC||jason at redhat dot com,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87178
Jonathan Wakely changed:
What|Removed |Added
Keywords||rejects-valid
Status|UNCON
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87178
--- Comment #2 from Jakub Jelinek ---
I believe it is rejects-invalid instead.
comdat works at the section granularity, so can't really work if you force
inline vars with other vars into the same section.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87190
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87190
--- Comment #3 from Alexander Monakov ---
Remember that -fvisibility is not a perfect substitute to proper annotations
via the visibility pragma and attributes. If you do
extern void foo(void);
void bar()
{
foo();
}
then with -fvisibility=hi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87191
Bug ID: 87191
Summary: UBSan doesn't catch invalid pointer arithmetic outside
known object bounds
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68178
--- Comment #10 from Rich Felker ---
Was this ever fixed? I've been using -ffunction-sections -fdata-sections by
default for a long time now so it dropped off my radar.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87192
Bug ID: 87192
Summary: -Warray-bounds (even =2) does not work on struct
members
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Pri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87191
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87192
--- Comment #2 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #1)
> This is most likely due to the array being at the end of the struct.
There is most likely another bug about this same thing.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87192
--- Comment #1 from Andrew Pinski ---
This is most likely due to the array being at the end of the struct.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87192
--- Comment #3 from Rich Felker ---
Adding a second member int b; does not make it work. I'm not sure why the end
of the struct should be special anyway; is it for the sake of supporting code
with erroneous alternatives to flexible array members?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87050
--- Comment #10 from Gerald Pfeifer ---
Mostly done,
cf. https://gcc.gnu.org/ml/gcc/2018-09/msg5.html
And for the actual conversion,
cf. https://gcc.gnu.org/ml/gcc-patches/2018-09/msg00026.html
The sole page not labeled as HTML 5 now is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87157
--- Comment #5 from Bill Schmidt ---
So, the test case compiled with r264043 produces 3 functions: main1.part.0,
main1, and main. The test case compiled with r263980 produces only 1 function
(main). The loop is vectorized in both main and main
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87192
--- Comment #4 from Andrew Pinski ---
(In reply to Rich Felker from comment #3)
> Adding a second member int b; does not make it work.
Was that second member before or after the array?
> is it for the sake of supporting
> code with erroneous al
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87186
--- Comment #3 from Andrew Pinski ---
Can you provide a full testcase that can compile?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87157
--- Comment #6 from Jan Hubicka ---
> But this change to sreal seems very unlikely to cause that.
> Are we sure about the bisection to r263981?
Sreals are used to estimate profile which in turn may affect decision
of function splitting & inline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87157
--- Comment #7 from Bill Schmidt ---
OK, that makes sense. And I verified that r263981 does indeed introduce the
extra functions. Thanks for looking into it!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87192
--- Comment #5 from Rich Felker ---
By "second" I meant in membership order, i.e. after the array.
I understand the need for supporting some (albeit wrong, UB even in C89) legacy
code doing FAM hacks, but it should be possible to disable that fo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87193
Bug ID: 87193
Summary: symbols in have inconsistent types
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87191
--- Comment #2 from Rich Felker ---
This PR is about UBSan. I agree it's usually preferable to detect this type of
error statically by warnings, and I also filed #87192 for -Warray-bounds not
being able to catch the specific type of case I was af
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87192
--- Comment #6 from Marc Glisse ---
I think the warning is about *accessing* (read or write) out of bound, not just
creating a pointer. That sounds like a separate warning (clang calls it
-Warray-bounds-pointer-arithmetic).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87178
Andrew Pinski changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87192
--- Comment #7 from Rich Felker ---
Nope. If the array is not in a struct, the warning works, e.g.
void bar(void *);
void foo()
{
int a[10];
bar(a+12);
}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87194
Bug ID: 87194
Summary: Associative container cannot be inserted from move
iterators that refer to elements implicitly
convertible to value_type
Product: gcc
Versi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87186
--- Comment #4 from MCCCS ---
Flags: -O2 -fdump-tree-original
Code:
int f1 (int x, int s) {
return ~(~(x|s)|x)|~(~(x|s)|s);
}
int f2 (int x, int s) {
const int t = x|s;
return ~(~t|x)|~(~t|s);
}
int f3 (int x, int s) {
const int t = ~(x|s);
r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87186
--- Comment #5 from Andrew Pinski ---
Right, original is not the one to look at really. There are more passes later
on that will optimize it using the patterns that optimized the original one.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87195
Bug ID: 87195
Summary: ICE in simplify_binary_operation_1, at
simplify-rtx.c:3637
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
46 matches
Mail list logo
