[Bug target/36381] preprocessing, fortran: register include paths and framework
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 --- Comment #2 from Eric Gallager --- (In reply to Eric Gallager from comment #1) > (In reply to Daniel Franke from comment #0) > > Follow up to PR36348: > > > > "[darwin-f.c] need[s] to implement darwin_register_frameworks, as well as > > the -iframework option implemented by handle_c_option in darwin-c.c. I > > suggest splitting that part of darwin-c.c into a new file darwin-cpp.c that > > is included in all three of c_target_objs, cxx_target_objs, > > fortran_target_objs. > > > > Furthermore, given that the target hook TARGET_HANDLE_C_OPTION is > > implemented only by darwin-c.c, it makes sense to rename it to > > TARGET_HANDLE_CPP_OPTION and call it from the Fortran front-end too." > > > > Reference: http://gcc.gnu.org/ml/fortran/2008-05/msg00348.html > > Are you still working on this? If so, the status can be ASSIGNED, otherwise, > it'd make sense to remove yourself as the assignee. No reply, so I'll take that as implying you're no longer working on this.
[Bug c/17426] Emit mandatory warning for manual expansions of offsetof
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 --- Comment #7 from Eric Gallager --- (In reply to Eric Gallager from comment #6) > (In reply to Giovanni Bajo from comment #3) > > (In reply to comment #2) > > > > > it's only where an integer constant expression is > > > required, as in bug 17396 (static array dimension) or for case labels, > > > enum values, bit-field widths, null pointer constants, designators for > > > array initializers, that there's a problem. > > > > Thanks for the list. I will try to activate the warning in these contexts, > > but > > I do not know the C frontend, so maybe I'll need to do this incrementally. > > > > > fits the long-established > > > GCC extension of symbolic difference constant expressions if being used > > > in > > > a static initializer > > > > This could be a pedwarn, then, right? > > Are you still working on this? No reply; taking that as a no.
[Bug tree-optimization/33915] iv folding fails with pointer iterations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33915 Eric Gallager changed: What|Removed |Added Status|WAITING |RESOLVED CC||rakdver at kam dot mff.cuni.cz Resolution|--- |WORKSFORME Assignee|rakdver at kam dot mff.cuni.cz |unassigned at gcc dot gnu.org --- Comment #11 from Eric Gallager --- (In reply to Eric Gallager from comment #10) > (In reply to Eric Gallager from comment #9) > > (In reply to Zdenek Dvorak from comment #3) > > > It does not reproduce for me on i686-linux, either. Do you pass any > > > special > > > flags to configure? > > > > If it didn't reproduce for you does it make sense for you still to be the > > assignee for this? > > WAITING on a reply No reply; since nobody could actually reproduce this to confirm it, I'm going to close this bug.
[Bug other/44803] LIBRARY_PATH should work on cross-compilers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44803 Eric Gallager changed: What|Removed |Added Status|WAITING |RESOLVED Last reconfirmed|2018-06-02 00:00:00 | Resolution|--- |WONTFIX Assignee|felipe.contreras at gmail dot com |unassigned at gcc dot gnu.org --- Comment #6 from Eric Gallager --- (In reply to Eric Gallager from comment #5) > (In reply to Eric Gallager from comment #4) > > (In reply to Felipe Contreras from comment #3) > > > Is this not clear? > > > > > > It would be useful to cross-compile like this: > > > > > > export C_INCLUDE_PATH=/opt/arm/ffmpeg/include > > > export LIBRARY_PATH=/opt/arm/ffmpeg/lib > > > > > > But LIBRARY_PATH is ignored. > > > > this bug showed up in my Assignee_but_not_ASSIGNED saved search. Are you > > still working on this? > > WAITING on a reply No reply; closing
[Bug target/67246] MIPS: lw (load word) is generated for byte bitfield, leading to unaligned access
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?
[Bug lto/87187] New: FAIL: gfortran.dg/short_circuiting_3.f90 -g -flto (internal compiler error) on darwin
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 Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: dominiq at lps dot ens.fr CC: marxin at gcc dot gnu.org Target Milestone: --- Host: x86_64-apple-darwin17 Target: x86_64-apple-darwin17 Build: x86_64-apple-darwin17 The new test gfortran.dg/short_circuiting_3.f90 fails with -g -flto -O2 on 8.2 and trunk (9.0): lto1: internal compiler error: in gen_subprogram_die, at dwarf2out.c:22682
[Bug lto/87187] FAIL: gfortran.dg/short_circuiting_3.f90 -g -flto (internal compiler error) on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87187 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-09-02 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- libgomp.fortran/taskloop3.f90 is failing the same way: FAIL: libgomp.fortran/taskloop3.f90 -g -flto (internal compiler error) lto1: internal compiler error: in gen_subprogram_die, at dwarf2out.c:22731 dwarf2out.c:22682 is when the tests are compiled with 8.2, dwarf2out.c:22731 are when the tests are compiled with 9.0.
[Bug tree-optimization/87186] Does not inline constant to simplify bitwise expression
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.
[Bug c++/87185] ICE in prune_lambda_captures()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87185 Nathan Sidwell changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-09-02 Assignee|unassigned at gcc dot gnu.org |nathan at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Nathan Sidwell --- Thanks Padraig, I'll give your patch a try
[Bug middle-end/87188] New: Function pointer canonicalization optimized away
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: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: danglin at gcc dot gnu.org Target Milestone: --- Host: hppa*-*-* (32-bit) Target: hppa*-*-* (32-bit) Build: hppa*-*-* (32-bit) Created attachment 44647 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44647&action=edit c++ testcase This is debian bug #907586 reported by Mattias Ellert: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=907586 Compilation is as follows: g++ -O2 -g -c -o main.o main.cpp g++ -O2 -g -fPIC -c -o S.o S.cpp g++ -shared -fPIC -o libS.so S.o g++ -o main main.o -L. -lS g++ -o altmain main.o S.o -- Running using shared library LD_LIBRARY_PATH=. ./main not OK -- Running using static build ./altmain OK If S.cpp is compiled at -O0, the test passes. The problem in the optimized code is here: .align 4 .LC0: .word P%_ZNK2SVneERKS_ .text .align 4 .globl _ZNK2SR4findEv .type _ZNK2SR4findEv, @function .LFB1721: .cfi_startproc _ZNK2SR4findEv: .PROC .CALLINFO FRAME=0,NO_CALLS .ENTRY ldw 0(%r26),%r21 comb,=,n %r26,%r21,.L14 ldw 12(%r21),%r20 ldw 8(%r21),%r28 addil LT'.LC0,%r19 ldw RT'.LC0(%r1),%r31 ldw 0(%r31),%r22 comclr,<> %r22,%r28,%r28 ldi 1,%r28 The comclr instruction compares the function pointer at .LC0 with the one indirectly passed via this. The code needs to call __canonicalize_funcptr_for_compare().
[Bug middle-end/87157] [9 regression] gcc.dg/vect/costmodel/ppc/costmodel-vect-33.c fails starting with r263981
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-test/gcc/ /home/wschmidt/gccgit/gcc/gcc/testsuite/gcc.dg/vect/costmodel/ppc/costmodel-vect-33.c -m64 -fno-diagnostics-show-caret -fdiagnostics-color=never -O2 -ftree-vectorize -fvect-cost-model=dynamic -fno-common -maltivec -fdump-tree-vect-details -S -o costmodel-vect-33.s One valid configuration triple would be powerpc64le-linux-gnu, using either --with-cpu=power8 or --with-cpu=power9. I can post the vectorization dump information after I have time to build a new compiler.
[Bug libgcc/87189] New: libgcc/gthr-posix.h (__gthread_active_p) makes unwarranted assumptions about libpthread.a
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
Severity: normal
Priority: P3
Component: libgcc
Assignee: unassigned at gcc dot gnu.org
Reporter: ppluzhnikov at google dot com
Target Milestone: ---
Redirected here from GLIBC bug:
https://sourceware.org/bugzilla/show_bug.cgi?id=21777
A trivial program using pthread_key_create but not pthread_mutex_lock will
crash on GLIBC, when linked statically.
Current code in libgcc/gthr-posix.h:
#ifdef __GLIBC__
__gthrw2(__gthrw_(__pthread_key_create),
__pthread_key_create,
pthread_key_create)
# define GTHR_ACTIVE_PROXY __gthrw_(__pthread_key_create)
assumes that if __pthread_key_create is linked in, then
pthread_mutex_{lock,unlock} will also be (__gthread_active_p() returns 1).
As attached test demonstrates, that is not necessarily the case.
Workaround: add -Wl,-u,pthread_mutex_lock -Wl,-u,pthread_mutex_unlock to the
link line.
Confirmed with current GLIBC trunk (a6e8926f8d49a213a9abb1a61f6af964f612ab7f)
and GCC @264043.
P.S. Why would a program use pthread_key_create but not pthread_mutex_lock?
Suppose you have a piece of data you want to memoize between calls to a certain
function, and that the data needs to be modifiable. It's convenient to make
that data thread-local, so the function is both thread-safe and parallelizable.
--- test.c ---
/* Link with "gcc -pthread test.c -static" */
#include
pthread_key_t k;
int
main (int argc, char *argv[])
{
pthread_key_create (&k, NULL);
pthread_setspecific (k, NULL);
return 0;
}
[Bug libgcc/87189] libgcc/gthr-posix.h (__gthread_active_p) makes unwarranted assumptions about libpthread.a
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=0x6a7380 ) at ./gthr-default.h:748 #2 __register_frame_info_bases (begin=, ob=0x6a2300 , tbase=, dbase=) at ../../../libgcc/unwind-dw2-fde.c:103 #3 0x00400acd in frame_dummy () #4 0x0001 in ?? () #5 0x0040194c in __libc_csu_init (argc=-9472, argc@entry=1, argv=argv@entry=0x7fffdc78, envp=0x7fffdc88) at elf-init.c:88 #6 0x00401170 in __libc_start_main (main=0x400add , argc=1, argv=0x7fffdc78, init=0x4018d0 <__libc_csu_init>, fini=0x401970 <__libc_csu_fini>, rtld_fini=0x0, stack_end=0x7fffdc68) at ../csu/libc-start.c:264 #7 0x004009fa in _start () at ../sysdeps/x86_64/start.S:120
[Bug tree-optimization/87188] Function pointer canonicalization optimized away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87188 John David Anglin changed: What|Removed |Added Component|middle-end |tree-optimization --- Comment #1 from John David Anglin --- Things are wrong at expand.
[Bug tree-optimization/87188] Function pointer canonicalization optimized away
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
[Bug web/87190] New: Feedback on documentation for symbol visibility
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: web
Assignee: unassigned at gcc dot gnu.org
Reporter: noloader at gmail dot com
Target Milestone: ---
This is general feedback on symbol visibility documentation. I feel like the
docs are lacking some important information and it makes a resulting shared
object appear to not meet expectations.
The docs I am referring to:
* https://gcc.gnu.org/wiki/Visibility
* https://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html
At the highest level, the docs say to use -fvisibility=hidden (and perhaps
-fvisibility-inlines-hidden) to hide all symbols. Then the user is expected to
use DLL_PUBLIC (from the Visibility wiki) to unhide symbols and create a public
API.
This works as expected when a shared object does not depend on other libraries.
Something like:
$ cat bar.c
extern "C" DLL_PUBLIC
int DoBar(int n)
{
...
return 0;
}
$ gcc -fvisibility=hidden -shared bar.c -o libbar.so
The result is something like the following, which is expected. It is consistent
with the documents.
$ nm -gCD libbar.so | grep ' T '
$ 000184e8 T _fini
$ 69d0 T _init
$ 95b0 T DoBar
Now, here's where the problem crops in. Suppose Bar depends on Foo and Foo was
not built with visibility. This is very common, even among some distro provided
libraries. Remember the docs say _all_ symbols are private (not _some_
symbols).
$ gcc -fvisibility=hidden -shared bar.c ./libfoo.a -o libbar.so
The results will be similar to the following. Notice the count grows from 3 to
the number of symbols available in libfoo.a.
$ nm -gCD libbar.so | grep ' T ' | wc -l
816
In the second example GCC drove compile and link but not all symbols were
private. To make them private we have to add linker options:
$ gcc -fvisibility=hidden -shared bar.c ./libfoo.a -o libbar.so
-Wl,--exclude-libs,All
This is the point of contention for me because the docs say all symbols are
private unless DLL_PUBLIC is used (from the Visibility wiki) to unhide symbols.
I think the docs could be more clear on both the GCC options page and the
Visibility wiki. I think two ro three things should be stated for completeness.
First, instead of saying all symbols are private when using the options, maybe
the docs should say "symbols in the translation unit being compiled are
private, and not all symbols in the program or library".
Second, the docs might clearly state -fvisibility=hidden (and friends) only
applies to the compiler. The compiler does not pass down
"-fvisibility=hidden"-like options to the linker.
Third, the docs should say something like "additional linker switches may be
required to hide all symbols in a shared object. For the GNU linker LD, LDFLAGS
should include -Wl,--exclude-libs,All. Other linkers may require additional
options."
The second suggestion may seem obvious but it is not. We are told to use the
compiler to drive link, and the compiler doing so with -fsanitize=undefined or
-fsanitize=address works as expected. That is we don't need to manually add
libraries by hand.
I was looking for some past/similar issues but I did not find a good one. Maybe
no one is using the feature or no one noticed. I did find this one, which seems
to be a symptom of the confusion:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=20218.
It is fascinating reading Andrew Pinski and H.J. Lu discussing the behavior and
externalities like the ELF specs (I did not even consider the effects of the
ELF specification). But at the end of the day the GCC docs say all the symbols
are private but it is possible to arrive at a program or shared library where
some symbols are private.
If someone is willing to make the leap that GCC should take the
-fvisibility=hidden compiler option and turn it into a linker option like
-Wl,--exclude-libs,All (when driving link), then this could be a GCC issue. I'd
personally like to see it happen, but I am not willing to go that far and make
the leap.
[Bug web/87190] Feedback on documentation for symbol visibility
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 visibility to the specified option—all symbols are marked with this unless overridden within the code. Using this feature can very substantially improve linking and load times of shared object libraries, produce more optimized code, provide near-perfect API export and prevent symbol clashes. It is strongly recommended that you use this in any shared objects you distribute...
[Bug middle-end/87157] [9 regression] gcc.dg/vect/costmodel/ppc/costmodel-vect-33.c fails starting with r263981
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.
[Bug c++/53972] array constant expression not valid as template argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53972 Eric Gallager changed: What|Removed |Added CC||jason at redhat dot com, ||nathan at acm dot org --- Comment #2 from Eric Gallager --- cc-ing c++ FE maintainers
[Bug c++/87178] Compilation failure when program contains multiple variables allocated in particular section, and at least one variable is C++17 "inline"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87178 Jonathan Wakely changed: What|Removed |Added Keywords||rejects-valid Status|UNCONFIRMED |NEW Last reconfirmed||2018-09-02 Ever confirmed|0 |1
[Bug c++/87178] Compilation failure when program contains multiple variables allocated in particular section, and at least one variable is C++17 "inline"
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.
[Bug web/87190] Feedback on documentation for symbol visibility
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87190 Alexander Monakov changed: What|Removed |Added CC||amonakov at gcc dot gnu.org --- Comment #2 from Alexander Monakov --- In the future please consider making reports more concise and to the point. > $ gcc -fvisibility=hidden -shared bar.c ./libfoo.a -o libbar.so Here a good solution is to ensure libfoo's symbols have hidden visibility in the first place, not have the linker downgrade it. I agree the documentation could be improved with examples to better showcase good practices. > If someone is willing to make the leap that GCC should take the > -fvisibility=hidden compiler option and turn it into a linker option like > -Wl,--exclude-libs,All Please no. -fvisiblity= takes 4 different values, and having some of them implicitly turn on a linker option, but only on gnu-compatible linkers, is ridiculous. Orthogonal, easy-to-explain options are good.
[Bug web/87190] Feedback on documentation for symbol visibility
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=hidden, the call to foo goes via the PLT, with the
corresponding speed and code size penalties on 32-bit x86 and other archs where
PLT calls need some setup on caller side.
[Bug c/87191] New: UBSan doesn't catch invalid pointer arithmetic outside known object bounds
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: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: bugdal at aerifal dot cx
Target Milestone: ---
Test case:
void bar(void *);
int foo()
{
char a[10];
bar(&a+2);
}
The function bar is just there as a compiler barrier.
My expectation is that -fsanitize=undefined should produce an unconditional
trap, since the only value constants to add to &a are 0 or 1 (and only 0 if the
result is dereferenced). Instead, GCC versions prior to 8 generate no sanitizer
check at all, and GCC 8 and clang both generate what I would characterize as a
wrong check: they look to see if (uintptr_t)a+20 overflows past the end of the
address space, rather than past the end of the object size (which is clearly
available here via __builtin_object_size).
My understanding is that -fsanitize=object-size, included in
-fsanitize=undefined, is supposed to catch exactly this case.
[Bug target/68178] [arm] Relative address expressions bind at as-time, even if symbol is weak
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.
[Bug c/87192] New: -Warray-bounds (even =2) does not work on struct members
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
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: bugdal at aerifal dot cx
Target Milestone: ---
Minimal test case:
void bar(void *);
void foo()
{
struct {
int a[10];
} s;
bar(s.a+12);
}
Compiles without warning with -O2 -Warray-bounds=2. Tested on gcc 7.3.
[Bug c/87191] UBSan doesn't catch invalid pointer arithmetic outside known object bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87191 Alexander Monakov changed: What|Removed |Added CC||amonakov at gcc dot gnu.org --- Comment #1 from Alexander Monakov --- It seems a bit strange to me to frame this in terms of ubsan. This is can be reasonably diagnosed at compile time, so I'd prefer to frame this as missing compile-time diagnostic first, and ubsan issue second (you'd need ubsan if the offset was variable, but here it's a compile-time constant). It may be appropriate to split the issue in two. (note: we should diagnose regardless if 'a' is an array or not, in the example it's an array to show how a mistake could be easy to make, in 'char a; bar(&a+2);' the erroneous pointer of course looks unlikely to appear in real practice) At a minimum we should diagnose if offsetting a pointer to a toplevel object not by 0/1 (ideally also if not by 0 and then dereferencing?), e.g.: warning: creating out-of-bounds pointer based on complete object 'a' If 'a' is not a toplevel object, but a field of a toplevel struct, invalid pointer arithmetic still should be diagnosed when the resulting pointer is out of bounds.
[Bug c/87192] -Warray-bounds (even =2) does not work on struct members
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.
[Bug c/87192] -Warray-bounds (even =2) does not work on struct members
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.
[Bug c/87192] -Warray-bounds (even =2) does not work on struct members
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? Shouldn't "=2" disable that exception?
[Bug web/87050] Bump wwwdocs to html5
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 our main page, which requires a bit more work, but that doesn't appear pressing. And I'll need to improve one or the other page a bit still in the coming days. (In reply to Janne Blomqvist from comment #0) > So apart from the headers, little work ought to be needed for the > conversion itself. Well, no. :-} https://gcc.gnu.org/ml/gcc-patches/2018-09/ speaks a different language, and that's just part of it, after all I did the last year(s) already.
[Bug middle-end/87157] [9 regression] gcc.dg/vect/costmodel/ppc/costmodel-vect-33.c fails starting with r263981
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 main1, so the count in the test case is off. But this change to sreal seems very unlikely to cause that. Are we sure about the bisection to r263981? I'll build with r263981 next to verify.
[Bug c/87192] -Warray-bounds (even =2) does not work on struct members
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 alternatives to flexible array members Yes, due to C89 not having flexible array members, it is to support them in older code. There are many pre C99 code floating around that needs to be supported.
[Bug tree-optimization/87186] Does not inline constant to simplify bitwise expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87186 --- Comment #3 from Andrew Pinski --- Can you provide a full testcase that can compile?
[Bug middle-end/87157] [9 regression] gcc.dg/vect/costmodel/ppc/costmodel-vect-33.c fails starting with r263981
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 & inliner. If something was really off we however would likely see it in performance results which seems OK. I will try to take look tomorrow as well. Honza
[Bug middle-end/87157] [9 regression] gcc.dg/vect/costmodel/ppc/costmodel-vect-33.c fails starting with r263981
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!
[Bug c/87192] -Warray-bounds (even =2) does not work on struct members
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 for catching errors in modern code. In any case it seems unrelated to this bug report since it happens with or without the affected member being at the end.
[Bug libstdc++/87193] New: symbols in have inconsistent types
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++ Assignee: unassigned at gcc dot gnu.org Reporter: webrown.cpp at gmail dot com Target Milestone: --- In the new header, most symbols are given a value of type int, rather than a value of type long as mandated by [support.limits.general] Table 35 of N4762. For example, we find these consecutive macro def'ns: #define __cpp_lib_is_final 201402L #define __cpp_lib_make_reverse_iterator 201402 in which the values are to be identical, yet have distinct types. Code such as: #include static_assert( std::is_same_v ); static_assert( std::is_same_v ); will detect the difference.
[Bug c/87191] UBSan doesn't catch invalid pointer arithmetic outside known object bounds
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 affected by. However, UB of this form is a dynamic condition at runtime, and any static tests will have either false negatives or false positives, e.g. when the code is reachable only conditionally on the size of the array and the conditional is not locally visible. In my case I tried UBSan as a fallback since I was surprised that no warning was being generated, and when I found the UBSan also failed to catch the problem, I reported this bug.
[Bug c/87192] -Warray-bounds (even =2) does not work on struct members
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).
[Bug c++/87178] Compilation failure when program contains multiple variables allocated in particular section, and at least one variable is C++17 "inline"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87178 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #3 from Andrew Pinski --- GCC is correct, this is similar in the way you put a inline function in a section. Clang is wrong in accepting it.
[Bug c/87192] -Warray-bounds (even =2) does not work on struct members
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);
}
[Bug libstdc++/87194] New: Associative container cannot be inserted from move iterators that refer to elements implicitly convertible to value_type
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
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: kariya_mitsuru at hotmail dot com
Target Milestone: ---
The sample code below is failed to compile by GCC HEAD (Sep 1, 2018).
=== sample code ===
#include
#include
#include
#include
#include
struct S {
S(const char* s) : s(s) {}
operator std::string() && { return std::move(s); }
std::string s;
};
int main()
{
std::array a{ "abc", "def", "ghi" };
std::set s;
s.insert(std::make_move_iterator(a.begin()),
std::make_move_iterator(a.end()));
}
=== sample code ===
cf. https://wandbox.org/permlink/c8rASYAgPKxRBUt0
The C++17 standard [associative.reqmts] says,
p.8: ..., i and j satisfy input iterator requirements and refer to elements
implicitly convertible to value_type, ...
a.insert(i,j) in Table 90: Requires: value_type shall be EmplaceConstructible
into X from *i.
So, I think that the sample code should be coumpiled successfully.
The unordered_set has the same problem.
cf. https://wandbox.org/permlink/Q4pVJkFVSS2Qijrg
But I don't know why, [unord.req] says that
p.8: ..., i and j denote input iterators that refer to value_type, ...
So, I am not sure that the unordered_set should be too.
[Bug tree-optimization/87186] Does not inline constant to simplify bitwise expression
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);
return ~(t|x)|~(t|s);
}
int f4 (int x, int s) {
const int t = ~x&~s;
return ~(t|x)|~(t|s);
}
Tree output (f1 has the expected output, others
should have had the same output):
;; Function f1 (null)
;; enabled by -tree-original
{
return s ^ x;
}
;; Function f2 (null)
;; enabled by -tree-original
{
const int t = x | s;
const int t = x | s;
return ~((int) ~t | x & s);
}
;; Function f3 (null)
;; enabled by -tree-original
{
const int t = ~(x | s);
const int t = ~(x | s);
return ~(x & s | (int) t);
}
;; Function f4 (null)
;; enabled by -tree-original
{
const int t = ~(x | s);
const int t = ~(x | s);
return ~(x & s | (int) t);
}
[Bug tree-optimization/87186] Does not inline constant to simplify bitwise expression
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.
[Bug target/87195] New: ICE in simplify_binary_operation_1, at simplify-rtx.c:3637
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
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
CC: segher at gcc dot gnu.org
Target Milestone: ---
Host: x86_64-linux-gnu
Target: ppc64le-linux-gnu
Following causes an ICE:
$ ./xgcc -B.
/home/marxin/Programming/gcc/gcc/testsuite/gcc.target/powerpc/fold-vec-splat-floatdouble.c
-O2 -ffloat-store
during RTL pass: fwprop1
/home/marxin/Programming/gcc/gcc/testsuite/gcc.target/powerpc/fold-vec-splat-floatdouble.c:
In function ‘testf_08’:
/home/marxin/Programming/gcc/gcc/testsuite/gcc.target/powerpc/fold-vec-splat-floatdouble.c:14:1:
internal compiler error: in simplify_binary_operation_1, at simplify-rtx.c:3637
14 | vector float testf_08 (vector float x) { return vec_splat (x, 0b01000); }
| ^~
0xfbcfb2 simplify_binary_operation_1
/home/marxin/Programming/gcc/gcc/simplify-rtx.c:3637
0xfb simplify_binary_operation(rtx_code, machine_mode, rtx_def*, rtx_def*)
/home/marxin/Programming/gcc/gcc/simplify-rtx.c:2167
0xfaef1a simplify_gen_binary(rtx_code, machine_mode, rtx_def*, rtx_def*)
/home/marxin/Programming/gcc/gcc/simplify-rtx.c:194
0x19c4257 propagate_rtx_1
/home/marxin/Programming/gcc/gcc/fwprop.c:508
0x19c4159 propagate_rtx_1
/home/marxin/Programming/gcc/gcc/fwprop.c:494
0x19c4c2a propagate_rtx
/home/marxin/Programming/gcc/gcc/fwprop.c:692
0x19c674f forward_propagate_and_simplify
/home/marxin/Programming/gcc/gcc/fwprop.c:1355
0x19c6967 forward_propagate_into
/home/marxin/Programming/gcc/gcc/fwprop.c:1414
0x19c6c77 fwprop
/home/marxin/Programming/gcc/gcc/fwprop.c:1503
0x19c6cf4 execute
/home/marxin/Programming/gcc/gcc/fwprop.c:1534
