[Bug middle-end/78703] -fprintf-return-value floating point handling incorrect in locales with a mulltibyte decimal point
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78703 --- Comment #3 from Jakub Jelinek --- For -fprintf-return-value, it is desirable to count with the worst case, but I'm not sure it is the right behavior for the warning. If we are aware of just 1 and 2 byte decimal points in the wild, forcing anyone that uses sprintf or snprintf to change the lengths of their buffers through warnings to reserve MB_LEN_MAX (e.g. for glibc 16) bytes for the decimal point just in case is IMHO just too much. It would be better to use (weak) maximum of 2 rather than 16. Otherwise people will just disable this warning as counting something that is totally off. Even the counting of 2 rather than 1 byte for the decimal point might upset people that always invoke *printf* in the C locale (on the other side, for programs that invoke it in user selected locale might point to real bugs that only show up in the Pashto locale).
[Bug tree-optimization/78706] New: [7 Regression] ICE in is_complex_reg (segfault)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78706
Bug ID: 78706
Summary: [7 Regression] ICE in is_complex_reg (segfault)
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: doko at gcc dot gnu.org
Target Milestone: ---
seen with r243219 when building tulip on ppc64el, works with -O2:
$ cat osiif.ii
class a {
public:
a();
};
class b {
int c;
int h;
double d;
virtual int e() { return f(c, h, &d); }
virtual int f(int &, int &, double *) const = 0;
};
class g : virtual b {
int f(int &, int &, double *) const;
};
int g::f(int &, int &, double *) const { throw a(); }
$ g++ -c -O3 osiif.ii
osiif.ii: In member function 'virtual int b::e()':
osiif.ii:9:38: internal compiler error: Segmentation fault
virtual int e() { return f(c, h, &d); }
^
0x108c4273 crash_signal
../../src/gcc/toplev.c:333
0x109114b4 is_complex_reg
../../src/gcc/tree-complex.c:177
0x109114b4 init_dont_simulate_again
../../src/gcc/tree-complex.c:231
0x109114b4 tree_lower_complex
../../src/gcc/tree-complex.c:1662
0x109114b4 execute
../../src/gcc/tree-complex.c:1788
Please submit a full bug report,
with preprocessed source if appropriate.
[Bug c++/78704] operator-> pointer return type is not recognized as pointer type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78704 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-12-07 CC||jakub at gcc dot gnu.org, ||jason at gcc dot gnu.org Target Milestone|--- |7.0 Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Doesn't seem to be a regression, since r185596 when -std=c++1y option has been added it has been rejected with: error: ‘operator->’ function uses ‘auto’ type specifier without trailing return type error: base operand of ‘->’ has non-pointer type ‘const Foo’ (like with -std=c++11) and starting with r185768 when return type C++14 auto deduction has been implemented it is rejected with just error: result of ‘operator->()’ yields non-pointer result clang++ accepts this. Either something should have deduced the return type of the operator-> earlier, or build_x_arrow should assume that if (processing_template_decl && type_uses_auto (TREE_TYPE (last_rval))) or something similar, then the return type could be a pointer and handle it as if expr has been type dependent from the beginning. Jason?
[Bug rtl-optimization/78626] [7 Regression] ICE in rtl_verify_bb_insns, at cfgrtl.c:2656 (error: flow control insn inside a basic block)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78626 --- Comment #6 from Arseny Solokha --- (In reply to Bernd Schmidt from comment #4) > Created attachment 40269 [details] > Candidate patch It fixes this particular issue. I didn't run regtest, though. Meanwhile, I have four additional snippets w/ the same ICE but w/ different backtrace. I'm going to file them as separate PRs tomorrow.
[Bug c++/71537] GCC rejects consetxpr boolean conversions and comparisons on the result of pointer arithmetic.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71537 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #16 from Jakub Jelinek --- Fixed.
[Bug c++/55004] [meta-bug] constexpr issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55004 Bug 55004 depends on bug 71537, which changed state. Bug 71537 Summary: GCC rejects consetxpr boolean conversions and comparisons on the result of pointer arithmetic. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71537 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/78706] [7 Regression] ICE in is_complex_reg (segfault)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78706 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jakub at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #1 from Jakub Jelinek --- Dup. *** This bug has been marked as a duplicate of bug 78692 ***
[Bug tree-optimization/78692] [7 Regression] ICE (segfault)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78692 --- Comment #3 from Jakub Jelinek --- *** Bug 78706 has been marked as a duplicate of this bug. ***
[Bug middle-end/78691] [7 Regression] ICE compiling Linux boot code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78691 --- Comment #6 from amker at gcc dot gnu.org --- Author: amker Date: Wed Dec 7 10:14:58 2016 New Revision: 243335 URL: https://gcc.gnu.org/viewcvs?rev=243335&root=gcc&view=rev Log: PR tree-optimization/78691 * match.pd ((convert1 (minmax ((convert2 (x) c -> minmax (x c)): Require integral type for the outer expression. gcc/testsuite PR tree-optimization/78691 * gcc.target/i386/pr78691-i386.c: New test. * gcc.target/powerpc/pr78691-ppc.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr78691-i386.c trunk/gcc/testsuite/gcc.target/powerpc/pr78691-ppc.c Modified: trunk/gcc/ChangeLog trunk/gcc/match.pd trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/71691] [6/7 Regression] wrong code at -O3 in both 32-bit and 64-bit modes on x86_64-linux-gnu (Floating point exception)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71691 Aldy Hernandez changed: What|Removed |Added CC||aldyh at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |aldyh at gcc dot gnu.org --- Comment #15 from Aldy Hernandez --- Mine for now.
[Bug middle-end/78468] [7 regression] libgomp.c/reduction-10.c and many more FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78468 Eric Botcazou changed: What|Removed |Added Component|libgomp |middle-end Severity|normal |major --- Comment #21 from Eric Botcazou --- > It does not break anything that wasn't broken before. The Sparc backend was > just _lucky_ that the allocation code in the middlend was _broken_. Yes, it does, it breaks tests that have been working for a decade! > The patch fixes the bug that causes dynamic stack allocation to overestimate > the needed space on the stack most of the time. To do this, it uses > information available from elsewhere in the middleend. > > It turns out that the backend (or middlend, depends on the point of view) > lies about the alignment of VIRTUAL_STACK_DYNAMIC_REGNUM. There may be > _other_ users users of that value that fail to do their job because they > think the stored alignment is correct. Such users may do worse things than > wasting some stack space - we may just have not noticed them yet. > > So, there is _another_ bug in the backends (or the middleend) that needs to > be fixed. It's not "one fix instead of another" - there are two bugs that > need two separate fixes. Then let's fix them, please. > It is also better to make the broken backends respect the STACK_BOUNDARY > alignment of VIRTUAL_STACK_DYNAMIC_REGNUM than make them tell the middleend > the real alignment: But these back-ends were not broken before your patch! It's your patch that broke the interface between the middle-end and the back-end without notice. > Making the middleend force STACK_BOUNDARY alignment of > VIRTUAL_STACK_DYNAMIC_REGNUM is also possible, but without any information > from the backend we'd have to generate run time code to do that alignment. > So, why not just use STACK_DYNAMIC_OFFSET et. al. to just guarantee that the > alignment is right? Because we have 50 architectures in the tree; are you going to audit them all and make the necessary adjustments? Just to save a couple of bytes?
[Bug tree-optimization/71691] [6/7 Regression] wrong code at -O3 in both 32-bit and 64-bit modes on x86_64-linux-gnu (Floating point exception)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71691 Aldy Hernandez changed: What|Removed |Added Status|NEW |WAITING --- Comment #16 from Aldy Hernandez --- This is no longer reproducible in trunk because of the patch below. Can we close this PR, or is the problem just latent now?: commit c2423c1d39514e05b710fe6a038cfe704c69860a Author: rguenth Date: Mon Oct 24 11:22:42 2016 + 2016-10-24 Richard Biener * tree-vrp.c (evrp_dom_walker::before_dom_children): Ignore backedges when identifying the single predecessor to take conditional info from. Use SCEV to get at ranges for loop IVs. * lto-streamer-out.c (lto_write_mode_table): CSE inner mode to avoid false warning. * gcc.dg/tree-ssa/cunroll-13.c: Disable EVRP. * gcc.dg/tree-ssa/pr21458.c: Likewise. * gcc.dg/tree-ssa/pr21458-2.c: New testcase for EVRP. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@241470 138bc75d-0d04-0410-961f-82ee72b054a4
[Bug middle-end/78691] [7 Regression] ICE compiling Linux boot code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78691 Markus Trippelsdorf changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from Markus Trippelsdorf --- fixed
[Bug middle-end/78707] New: [4.8/4.9/5/6 Regression: internal compiler error: in push_reload, at reload.c:1349
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78707 Bug ID: 78707 Summary: [4.8/4.9/5/6 Regression: internal compiler error: in push_reload, at reload.c:1349 Product: gcc Version: 6.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: gjl at gcc dot gnu.org Target Milestone: --- Created attachment 40274 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40274&action=edit sscanf_flt-f1.c. C test case The attached C test ICEs with v6, v5, v4.9 and v4.8: $ avr-gcc sscanf_flt-f1.c -Os -mmcu=atmega128 sscanf_flt-f1.c: In function 'main': sscanf_flt-f1.c:108:1: internal compiler error: in push_reload, at reload.c:1349 } ^ 0x8f9c87 push_reload(rtx_def*, rtx_def*, rtx_def**, rtx_def**, reg_class, machine_mode, machine_mode, int, int, int, reload_type) ../../../gcc.gnu.org/gcc-6-branch/gcc/reload.c:1348 0x8f7fde push_reload(rtx_def*, rtx_def*, rtx_def**, rtx_def**, reg_class, machine_mode, machine_mode, int, int, int, reload_type) ../../../gcc.gnu.org/gcc-6-branch/gcc/reload.c:1155 0x90057b find_reloads(rtx_insn*, int, int, int, short*) ../../../gcc.gnu.org/gcc-6-branch/gcc/reload.c:4035 0x90d7fd calculate_needs_all_insns ../../../gcc.gnu.org/gcc-6-branch/gcc/reload1.c:1484 0x90d7fd reload(rtx_insn*, int) ../../../gcc.gnu.org/gcc-6-branch/gcc/reload1.c:995 0x7fba39 do_reload ../../../gcc.gnu.org/gcc-6-branch/gcc/ira.c:5437 0x7fba39 execute ../../../gcc.gnu.org/gcc-6-branch/gcc/ira.c:5609 Please submit a full bug report, == configure == Configured with: ../../gcc.gnu.org/gcc-6-branch/configure --target=avr --prefix=/local/gnu/install/gcc-6 --disable-nls --disable-shared --with-dwarf2 --with-gnu-ld --with-gnu-as target_alias=avr --enable-languages=c,c++,lto --enable-checking=release Thread model: single gcc version 6.2.1 20161207 (GCC) $ svn info Path: . Working Copy Root Path: /srv/local/gnu/gcc.gnu.org/gcc-6-branch URL: svn+ssh://gcc.gnu.org/svn/gcc/branches/gcc-6-branch Relative URL: ^/branches/gcc-6-branch Repository Root: svn+ssh://gcc.gnu.org/svn/gcc Repository UUID: 138bc75d-0d04-0410-961f-82ee72b054a4 Revision: 243334
[Bug middle-end/78707] [4.8/4.9/5/6 Regression: internal compiler error: in push_reload, at reload.c:1349
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78707 Georg-Johann Lay changed: What|Removed |Added Keywords||ice-on-valid-code, ra Target||avr Status|UNCONFIRMED |NEW Last reconfirmed||2016-12-07 Known to work||4.7.4 Ever confirmed|0 |1 Known to fail||4.8.5, 4.9.4, 5.4.1, 6.2.1
[Bug c++/78655] gcc doesn't exploit the fact that the result of pointer addition can not be nullptr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78655 --- Comment #5 from Jonathan Wakely --- (In reply to Richard Biener from comment #1) > Of course I wonder why the check is here in the first place... Is placement > new valid for nullptr? It used to be, but is now UB, since http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1748 (There's more background in the PR Marc mentioned, PR 35878).
[Bug target/72717] [5/6/7 Regression] ICE: in emit_move_insn, at expr.c:3693 with vector shift @ powerpc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72717 --- Comment #4 from Segher Boessenkool --- That works I guess... Please test on BE and 32-bit as well. Oh, and no parens in a = (b) ? c : d; (for simple b at least).
[Bug sanitizer/78708] New: [ASAN][LTO] ICE in expand_ASAN_MARK, at internal-fn.c:380 - when compiling but not linking with ASAN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78708 Bug ID: 78708 Summary: [ASAN][LTO] ICE in expand_ASAN_MARK, at internal-fn.c:380 - when compiling but not linking with ASAN Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: burnus at gcc dot gnu.org CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org, jakub at gcc dot gnu.org, kcc at gcc dot gnu.org Target Milestone: --- Accidentally, I just compiled some files with "-c -flto -fsanitize=address" but forgot to add the "-fsanitize=address" when linking. Result: internal compiler error: in expand_ASAN_MARK, at internal-fn.c:380 0x8a3207 expand_ASAN_MARK ../../gcc/internal-fn.c:380 0x68af77 expand_call_stmt ../../gcc/cfgexpand.c:2569 0x68af77 expand_gimple_stmt_1 ../../gcc/cfgexpand.c:3571 0x68af77 expand_gimple_stmt ../../gcc/cfgexpand.c:3737 0x68cbbf expand_gimple_basic_block ../../gcc/cfgexpand.c:5744 0x6926d6 execute ../../gcc/cfgexpand.c:6358
[Bug middle-end/78153] strlen return value can be assumed to be less than PTRDIFF_MAX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78153 Thomas Schwinge changed: What|Removed |Added CC||tschwinge at gcc dot gnu.org --- Comment #4 from Thomas Schwinge --- (In reply to Andreas Schwab from comment #2) > raised STORAGE_ERROR : stack overflow or erroneous memory access > make[3]: *** [../../gcc/ada/gcc-interface/Make-lang.in:119: ada/osint.o] > Error 1 This presumably has been addressed in PR78501.
[Bug rtl-optimization/78626] [7 Regression] ICE in rtl_verify_bb_insns, at cfgrtl.c:2656 (error: flow control insn inside a basic block)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78626 --- Comment #7 from Segher Boessenkool --- (In reply to Bernd Schmidt from comment #4) > Created attachment 40269 [details] > Candidate patch That looks great :-)
[Bug rtl-optimization/78626] [7 Regression] ICE in rtl_verify_bb_insns, at cfgrtl.c:2656 (error: flow control insn inside a basic block)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78626 --- Comment #8 from Segher Boessenkool --- ... and works fine, too! ms: stwu 1,-32(1) lis 9,qs@ha lwz 9,qs@l(9) twnei 9,0 .L6: b .L6 Nice :-)
[Bug target/78633] [7 Regression] [SH] libgcc/fp-bit.c:944:1: error: invalid rtl sharing found in the insn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78633 --- Comment #13 from Oleg Endo --- (In reply to Kazumoto Kojima from comment #12) > Perhaps the splitter in problem > might have to take care of subreg case even when referencing > a reg rtx in the input operands. So it looks like a new rtx object should be created when referencing a subreg. That's ... a problem. I have been ignoring this for a while, so I guess there are several places which need patching. I can reproduce the error on sh-elf. I will look at it, but I'm very busy at the moment, so it will take some time.
[Bug fortran/77414] ICE in create_function_arglist, at fortran/trans-decl.c:2410
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77414 --- Comment #5 from Dominique d'Humieres --- > > The tests z7.f90, z8.f90, and z9.f90 compiles without error > > at revision r242002 although I think they are invalid. > > They give an ICE with r241962. > > This is due to r241972 (pr77596). This is wrong, it is due to patches for pr44265: see https://gcc.gnu.org/ml/fortran/2016-12/msg00055.html.
[Bug rtl-optimization/78626] [7 Regression] ICE in rtl_verify_bb_insns, at cfgrtl.c:2656 (error: flow control insn inside a basic block)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78626 --- Comment #9 from Bernd Schmidt --- I can't read that assembly language, but I'll take your word for it. I'm testing the patch on x86.
[Bug c++/78589] g++ prints instead of a function name when warning in an OpenMP outlined function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78589 --- Comment #7 from Martin Jambor --- Author: jamborm Date: Wed Dec 7 13:09:07 2016 New Revision: 243344 URL: https://gcc.gnu.org/viewcvs?rev=243344&root=gcc&view=rev Log: Use dump_function_name rather than emit 2016-12-07 Martin Jambor PR c++/78589 * error.c (dump_decl): Use dump_function_name to dump !DECL_LANG_SPECIFIC function decls with no or self-referencing abstract origin. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/error.c
[Bug target/78633] [7 Regression] [SH] libgcc/fp-bit.c:944:1: error: invalid rtl sharing found in the insn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78633 --- Comment #14 from Kazumoto Kojima --- No problem. I can continue nightly build&test with a minimal change diff --git a/gcc/config/sh/sh.md b/gcc/config/sh/sh.md index c6956a0..edadba7 100644 --- a/gcc/config/sh/sh.md +++ b/gcc/config/sh/sh.md @@ -858,7 +858,8 @@ operands of the tstsi_t insn, which is generally the case. */ if (dump_file) fprintf (dump_file, "cmpeqsi_t: replacing with tstsi_t\n"); - emit_insn (gen_tstsi_t (XEXP (op.set_src, 0), XEXP (op.set_src, 1))); + emit_insn (gen_tstsi_t (copy_rtx (XEXP (op.set_src, 0)), + copy_rtx (XEXP (op.set_src, 1; DONE; } added to my local git tree so as not to miss other breakages on trunk.
[Bug lto/71959] [OpenACC] #pragma acc parallel leads to segfault in x86_64-pc-linux-gnu-accel-nvptx-none-gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71959 Nathan Sidwell changed: What|Removed |Added Assignee|nathan at gcc dot gnu.org |unassigned at gcc dot gnu.org --- Comment #8 from Nathan Sidwell --- I am no longer working on openacc
[Bug bootstrap/21481] crtstuff.c should not include auto-host.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21481 Nathan Sidwell changed: What|Removed |Added Status|ASSIGNED|NEW Assignee|nathan at gcc dot gnu.org |unassigned at gcc dot gnu.org
[Bug tree-optimization/78709] New: Code size is bigger at -Os than at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78709
Bug ID: 78709
Summary: Code size is bigger at -Os than at -O3
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: erika.molnar at cyberthorstudios dot com
Target Milestone: ---
Created attachment 40275
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40275&action=edit
Build steps
Hello,
I've built gcc-6.2 using the RX target on Ubuntu 14.04, 64-bit. (I will attach
the exact build configurations I've used, in build.txt). When using:
memcpy_restrict.c
#include "string.h"
void *memcpy (void * __restrict__ s1, const void * __restrict__ s2, size_t n)
{
char *dst = (char *) s1;
char *src = (char *) s2;
char *v = s1;
while (n--)
{
*dst++ = *src++;
}
return v;
}
int main ()
{
char *a;
char *b;
int n;
memcpy (a, b, n);
return 0;
}
END
$ rx-elf-gcc memcpy_restrict.c -S -O3/-Os
The code generated by -O3 is smaller.
Can you please explain why?
__
Thank you,
Erika Molnar
[Bug c++/78710] New: suggest better exception text for stoi, stol, ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78710
Bug ID: 78710
Summary: suggest better exception text for stoi, stol, ...
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: nico at josuttis dot de
Target Milestone: ---
stoi("hello") currently throws an exception where what() only outputs "stoi"
(nothing else).
The reason is (if I analyzed it correctly):
- stoi etc. pass their name (just "stoi") to __stoa as __name
- __stoa calls:
std::__throw_invalid_argument(__name);
- which usually seems to call _GLIBCXX_THROW_OR_ABORT
Some component (either __stoa() or __throw_invalid_argument())
should extend the message at least a bit.
E.g. __stoa() might call
std::__throw_invalid_argument("invalid argument for " + __name)
(using a valid syntax of course).
[Bug c++/78710] suggest better exception text for stoi, stol, ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78710 --- Comment #1 from Nicolai Josuttis --- applies to any version AFAIK
[Bug other/78711] New: gcc-6.2.0:: libjavamath.so inconsistent gmp link
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78711 Bug ID: 78711 Summary: gcc-6.2.0:: libjavamath.so inconsistent gmp link Product: gcc Version: 6.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: edeveaud at pasteur dot fr Target Milestone: --- hello, whar I've done 1) extracted fresh gcc-4.9.4 archive 2) run contrib/download_prerequisites => gmp, mpfr and mpc are ok 3) run ./configure 4) make && make install 5) then check for linking and then found the following. ''' bigmess:/tmp/gcc-6.2.0 > find /tmp/6.2.0 -type f -name \*.so | xargs ldd /tmp/6.2.0/lib64/libgcj_bc.so: linux-vdso.so.1 => (0x7ffeec3eb000) libc.so.6 => /lib64/libc.so.6 (0x7fb99c49d000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x7fb99c287000) /lib64/ld-linux-x86-64.so.2 (0x003cb760) /tmp/6.2.0/lib64/gcj-6.2.0-17/libjvm.so: linux-vdso.so.1 => (0x7ffc26147000) libgcj.so.17 => /tmp/6.2.0/lib/../lib64/libgcj.so.17 (0x7f8ce17b3000) libpthread.so.0 => /lib64/libpthread.so.0 (0x7f8ce1587000) libdl.so.2 => /lib64/libdl.so.2 (0x7f8ce1383000) librt.so.1 => /lib64/librt.so.1 (0x7f8ce117b000) libc.so.6 => /lib64/libc.so.6 (0x7f8ce0de6000) libgcc_s.so.1 => /tmp/6.2.0/lib/../lib64/libgcc_s.so.1 (0x7f8ce0bd) /lib64/ld-linux-x86-64.so.2 (0x003cb760) /tmp/6.2.0/lib64/gcj-6.2.0-17/libjavamath.so: linux-vdso.so.1 => (0x7ffcded7b000) libgmp.so.3 => /usr/lib64/libgmp.so.3 (0x7f7af0c29000) librt.so.1 => /lib64/librt.so.1 (0x7f7af0a21000) libc.so.6 => /lib64/libc.so.6 (0x7f7af068c000) libpthread.so.0 => /lib64/libpthread.so.0 (0x7f7af046f000) /lib64/ld-linux-x86-64.so.2 (0x003cb760) ''' one can note that lib64/gcj-6.2.0-17/libjavamath.so is linked to system gmp not gcc "embeded" one. configure was run with the following arguments ''' configure --prefix=/local/gensoft2/exe/gcc/6.2.0 \ --enable-threads=posix \ --enable-__cxa_atexit \ --disable-multilib \ --disable-bootstrap \ --enable-java-home \ --with-jvm-root-dir=/local/gensoft2/exe/gcc/6.2.0/libexec/gcj \ --enable-languages=c,c++,fortran,java ''' FYI same problem with gcc-6.2.0 did I missed something ? best regards Eric
[Bug other/78712] New: gcc-4.9.4:: libjavamath.so inconsistent gmp link
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78712 Bug ID: 78712 Summary: gcc-4.9.4:: libjavamath.so inconsistent gmp link Product: gcc Version: 4.9.4 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: edeveaud at pasteur dot fr Target Milestone: --- hello, whar I've done 1) extracted fresh gcc-4.9.4 archive 2) run contrib/download_prerequisites => gmp, mpfr and mpc are ok 3) run ./configure 4) make && make install 5) then check for linking and then found the following. ''' bigmess:gcc/4.9.4 > find . -type f -name \*.so | xargs ldd ./lib64/libgcj_bc.so: linux-vdso.so.1 => (0x7fffe31f3000) libc.so.6 => /lib64/libc.so.6 (0x7f58383d7000) libgcc_s.so.1 => /local/gensoft2/exe/gcc/4.9.0/lib64/libgcc_s.so.1 (0x7f58381c) /lib64/ld-linux-x86-64.so.2 (0x003cb760) ./lib64/gcj-4.9.4-15/libjvm.so: linux-vdso.so.1 => (0x7fffd6396000) libgcj.so.15 => /local/gensoft2/exe/gcc/4.9.4/lib/../lib64/libgcj.so.15 (0x7f4be93b6000) libpthread.so.0 => /lib64/libpthread.so.0 (0x7f4be918a000) libdl.so.2 => /lib64/libdl.so.2 (0x7f4be8f86000) librt.so.1 => /lib64/librt.so.1 (0x7f4be8d7e000) libc.so.6 => /lib64/libc.so.6 (0x7f4be89e9000) libgcc_s.so.1 => /local/gensoft2/exe/gcc/4.9.4/lib/../lib64/libgcc_s.so.1 (0x7f4be87d3000) /lib64/ld-linux-x86-64.so.2 (0x003cb760) ./lib64/gcj-4.9.4-15/libjavamath.so: linux-vdso.so.1 => (0x7ffebcd91000) libgmp.so.3 => /usr/lib64/libgmp.so.3 (0x7f16cff73000) librt.so.1 => /lib64/librt.so.1 (0x7f16cfd6a000) libc.so.6 => /lib64/libc.so.6 (0x7f16cf9d6000) libpthread.so.0 => /lib64/libpthread.so.0 (0x7f16cf7b9000) /lib64/ld-linux-x86-64.so.2 (0x003cb760) ''' one can note that lib64/gcj-4.9.4-15/libjavamath.so is linked to system gmp not gcc "embeded" one. configure was run with the following arguments ''' configure --prefix=/local/gensoft2/exe/gcc/4.9.4 \ --enable-threads=posix \ --enable-__cxa_atexit \ --disable-multilib \ --disable-bootstrap \ --enable-java-home \ --with-jvm-root-dir=/local/gensoft2/exe/gcc/4.9.4/libexec/gcj \ --enable-languages=c,c++,fortran,java ''' FYI same problem with gcc-6.2.0 see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78711 did I missed something ? best regards Eric
[Bug tree-optimization/78713] New: [missed optimization] gcc doesn't use clobbers to optimize constructors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78713
Bug ID: 78713
Summary: [missed optimization] gcc doesn't use clobbers to
optimize constructors
Product: gcc
Version: 6.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: a...@cloudius-systems.com
Target Milestone: ---
Consider the following code
=== begin code ===
#include
using namespace std::experimental;
struct array_of_optional {
optional v[100];
};
array_of_optional
f(const array_of_optional& a) {
return a;
}
=== end code ===
Compiling with -O3 (6.2.1), I get:
:
0:48 8d 8f 20 03 00 00 lea0x320(%rdi),%rcx
7:48 89 f8 mov%rdi,%rax
a:48 89 fa mov%rdi,%rdx
d:0f 1f 00 nopl (%rax)
10:c6 42 04 00 movb $0x0,0x4(%rdx)
14:80 7e 04 00 cmpb $0x0,0x4(%rsi)
18:74 0aje 24
1a:44 8b 06 mov(%rsi),%r8d
1d:c6 42 04 01 movb $0x1,0x4(%rdx)
21:44 89 02 mov%r8d,(%rdx)
24:48 83 c2 08 add$0x8,%rdx
28:48 83 c6 08 add$0x8,%rsi
2c:48 39 ca cmp%rcx,%rdx
2f:75 dfjne10
31:f3 c3repz retq
However, because we're constructing into the return value, we're under no
obligation to leave the memory untouched (i.e. the memory can be considered
clobbered), so this can be optimized into a memcpy, which can be significantly
faster if the optionals are randomly engaged; but gcc doesn't notice that.
This is somewhat similar to using memcpy to copy a struct with holes.
[Bug rtl-optimization/78561] Constant pool size (offset) can become stale where constant pool entires become unused
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78561 --- Comment #18 from James Greenhalgh --- Author: jgreenhalgh Date: Wed Dec 7 14:01:59 2016 New Revision: 243345 URL: https://gcc.gnu.org/viewcvs?rev=243345&root=gcc&view=rev Log: [Patch PR78561 PowerPC] Revert to old behaviour for counting constant pools gcc/ PR rtl-optimization/78561 * config/rs6000/rs6000.c (rs6000_reg_live_or_pic_offset_p) Use constant_pool_empty_p in place of get_pool_size_upper_bound. (rs6000_stack_info): Likewise. (rs6000_emit_prologue): Likewise. (rs6000_elf_declare_function_name): Likewise. (rs6000_set_up_by_prologue): Likewise. (rs6000_can_eliminate): Likewise. * output.h (get_pool_size_upper_bound): Delete. (constant_pool_empty_p): New. * varasm.c (get_pool_size_upper_bound): Delete (constant_pool_empty_p): New. Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/rs6000.c trunk/gcc/output.h trunk/gcc/varasm.c
[Bug libobjc/78697] --with-target-bdw-gc-include shouldn't be required to be per multilib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78697
--- Comment #1 from Matthias Klose ---
well, it does make sense when the header files differ, however that is not the
case for the gc header files afaics. Is this what you are looking for? The
fallback directory should not override the values given in
--with-target-bdw-gc= from my point of view.
--- configure.ac(revision 243108)
+++ configure.ac(working copy)
@@ -256,16 +256,19 @@
for i in `echo $with_target_bdw_gc_include | tr ',' ' '`; do
case "$i" in
*=*) sd=${i%%=*}; d=${i#*=} ;;
- *) sd=.; d=$i ;;
+ *) sd=.; d=$i; fallback=$i ;;
esac
if test "$mldir" = "$sd"; then
bdw_val=$d
fi
done
- if test "x$bdw_val" = x; then
+ if test "x$bdw_val" = x && test "x$bdw_inc_dir" = x && test "x$fallback"
!= x; then
+bdw_inc_dir="$fallback"
+ else if test "x$bdw_val" = x; then
AC_MSG_ERROR([no multilib path ($mldir) found in
--with-target-bdw-gc-include])
+ else
+bdw_inc_dir="$bdw_val"
fi
- bdw_inc_dir="$bdw_val"
fi
bdw_val=
if test "x$with_target_bdw_gc_lib" != x; then
[Bug tree-optimization/78709] Code size is bigger at -Os than at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78709 --- Comment #1 from ErikaMolnar --- The code size is smaller because of -ftree-loop-distribute-patterns, this options has no effect on –Os. Could you make this optimization to work on –Os also? as it is quite useful.
[Bug c++/72775] [6/7 Regression] internal compiler error: in finish_expr_stmt, at cp/semantics.c:677
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72775 --- Comment #11 from Marek Polacek --- This patch seems to disable initialization of a flexible array member in a constructor, and, curiously, doesn't regress anything in C++ dg.exp. --- a/gcc/cp/init.c +++ b/gcc/cp/init.c @@ -800,6 +800,11 @@ perform_member_init (tree member, tree init) in that case. */ init = build_x_compound_expr_from_list (init, ELK_MEM_INIT, tf_warning_or_error); + else if (TREE_CODE (type) == ARRAY_TYPE + && TYPE_DOMAIN (type) == NULL_TREE + && DECL_CONSTRUCTOR_P (current_function_decl)) + error_at (DECL_SOURCE_LOCATION (member), + "initialization of a flexible array member in a constructor"); if (init) finish_expr_stmt (cp_build_modify_expr (input_location, decl,
[Bug c++/72775] [6/7 Regression] internal compiler error: in finish_expr_stmt, at cp/semantics.c:677
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72775
--- Comment #12 from Marek Polacek ---
(In reply to Matteo Bertello from comment #10)
> Just had the same internal compiler error on a different piece of code,
> using GCC 6.1.1 on Fedora 24.
> Might be useful to investigate the cause.
This code doesn't compile for me at all:
r3.cc: In function ‘int main(int, char**)’:
r3.cc:8:27: error: expected primary-expression before ‘(’ token
auto thread = std::thread([&, =val]() { func(val); });
^
r3.cc:8:32: error: expected identifier before ‘=’ token
auto thread = std::thread([&, =val]() { func(val); });
^
clang++ rejects it, too.
[Bug libobjc/78698] [7 regression] Using static PIC libgc fails when it has dependencies
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78698 --- Comment #1 from Matthias Klose --- didn't check a configuration with --disable-shared :-/ What about checking for a $bdw_lib_dir/libgc.la and in that case setting BDW_GC_LIBS to $bdw_lib_dir/libgc.la and skipping the compile and link tests? I assume we could do a file check for the header file as well for this case. --- configure.ac(revision 243108) +++ configure.ac(working copy) @@ -290,10 +293,19 @@ AC_MSG_ERROR([no multilib path ($mldir) found in --with-target-bdw-gc-lib]) fi BDW_GC_CFLAGS="-I$bdw_inc_dir" -BDW_GC_LIBS="-L$bdw_lib_dir -lgc" +if test -f $bdw_lib_dir/libgc.la; then + BDW_GC_LIBS="$bdw_lib_dir/libgc.la" +else + BDW_GC_LIBS="-L$bdw_lib_dir -lgc" +fi AC_MSG_RESULT([found]) fi + case "$BDW_GC_LIBS" in + *libgc.la) +use_bdw_gc=yes +;; + *) AC_MSG_CHECKING([for system boehm-gc]) save_CFLAGS=$CFLAGS save_LIBS=$LIBS @@ -329,6 +341,7 @@ use_bdw_gc=yes AC_MSG_RESULT([found]) fi + esac esac if test "$use_bdw_gc" = no; then
[Bug c++/78551] [5/6/7 Regression] Internal compiler error with constexpr initialization of union
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78551 --- Comment #11 from Nathan Sidwell --- Created attachment 40276 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40276&action=edit non-union crash Union is not necessary to trigger the ICE. All we need is to initialize a char array with a string constant, and then try and write an element of the array.
[Bug sanitizer/78708] [7 Regression][ASAN][LTO] ICE in expand_ASAN_MARK, at internal-fn.c:380 - when compiling but not linking with ASAN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78708
Tobias Burnus changed:
What|Removed |Added
Target Milestone|--- |7.0
Summary|[ASAN][LTO] ICE in |[7 Regression][ASAN][LTO]
|expand_ASAN_MARK, at|ICE in expand_ASAN_MARK, at
|internal-fn.c:380 - when|internal-fn.c:380 - when
|compiling but not linking |compiling but not linking
|with ASAN |with ASAN
--- Comment #1 from Tobias Burnus ---
Test case (works with GCC 6)
g++ -fsanitize=address -flto -o test.o -c test.ii
g++ test.o
gives the ICE from above. Using:
namespace std {
template < class _E > class initializer_list {
typedef const _E *iterator;
iterator _M_array;
long unsigned int _M_len;
};
}
struct Box { };
static void foo (Box * __restrict out2) {
Box b;
*out2 = b;
}
[Bug other/78711] gcc-6.2.0:: libjavamath.so inconsistent gmp link
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78711 Andreas Schwab changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Andreas Schwab --- The included gmp is host-only, only for use with the compiler, not the target libraries.
[Bug other/78712] gcc-4.9.4:: libjavamath.so inconsistent gmp link
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78712 Andreas Schwab changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Andreas Schwab --- dup *** This bug has been marked as a duplicate of bug 78711 ***
[Bug other/78711] gcc-6.2.0:: libjavamath.so inconsistent gmp link
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78711 --- Comment #2 from Andreas Schwab --- *** Bug 78712 has been marked as a duplicate of this bug. ***
[Bug libstdc++/78714] New: std::get_time does not accept full month name in %b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78714
Bug ID: 78714
Summary: std::get_time does not accept full month name in %b
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: cubbi at cubbi dot org
Target Milestone: ---
The standard says time_get calls get_time which follows "ISO/IEC 9945 function
strptime" ([locale.time.get.members]p8.4)
strptime defines the meaning of %b as "The month, using the locale's month
names; either the abbreviated or full name may be specified.":
http://pubs.opengroup.org/onlinepubs/9699919799/functions/strptime.html
however it appears libstdc++ only accepts abbreviated month name:
https://github.com/gcc-mirror/gcc/blob/master/libstdc%2B%2B-v3/include/bits/locale_facets_nonio.tcc#L673-L678
testcase:
#include
#include
#include
#include
#include
tm t;
int main()
{
assert(strptime("2011-Feb-18 23:12:34", "%Y-%b-%d %H:%M:%S", &t)); // pass
assert(strptime("2011-February-18 23:12:34", "%Y-%b-%d %H:%M:%S", &t)); //
pass
{
std::istringstream ss("2011-Feb-18 23:12:34");
assert(ss >> std::get_time(&t, "%Y-%b-%d %H:%M:%S")); // pass
}
{
std::istringstream ss("2011-February-18 23:12:34");
assert(ss >> std::get_time(&t, "%Y-%b-%d %H:%M:%S")); // FAIL
}
}
all asserts pass with clang's libc++ and with MSVC 2015
[Bug target/78694] [ARM] ICE with -mthumb -ftls-model=local-exec -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78694 --- Comment #7 from Sebastian Huber --- Are you able to reproduce the problem with this information? You need the attached test case. The arm-eabi GCC build itself works.
[Bug target/78695] [7 Regression] ICE (segfault) on powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78695 --- Comment #7 from Matthias Klose --- gcc configured with --enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-7 --program-prefix=powerpc64le-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-libquadmath --enable-plugin --enable-default-pie --with-system-zlib --enable-objc-gc=auto --enable-secureplt --with-cpu=power8 --enable-targets=powerpcle-linux --disable-multilib --enable-multiarch --disable-werror --with-long-double-128 --enable-checking=release --build=powerpc64le-linux-gnu --host=powerpc64le-linux-gnu --target=powerpc64le-linux-gnu I'll update my snapshot build, having only minimal patches for packaging, and recheck.
[Bug target/78694] [ARM] ICE with -mthumb -ftls-model=local-exec -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78694 --- Comment #8 from ktkachov at gcc dot gnu.org --- No, sorry. It doesn't ICE for me. Given that the ICE is an RTL sharing ICE, I believe it should only appear when RTL checking is enabled through --enable-checking=rtl but I don't see that in your configure line, so how can you be getting that ICE? I also built an arm-rtems4.12 cc1 toolchain (no libraries) and tried compiling the testcase and it worked
[Bug other/78711] gcc-6.2.0:: libjavamath.so inconsistent gmp link
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78711 --- Comment #3 from Eric --- (In reply to Andreas Schwab from comment #1) > The included gmp is host-only, only for use with the compiler, not the > target libraries. sorry if I don't understand correctly. what do you mean by "only for use with the compiler, not the target libraries." download_prerequisite grab gmp and compile gcc suite using this one, so why produced libraries are linked to external gmp ? IMHO produced gcc should linkk to "embeded" gmp downloaded by contrib/download_prerequisites this way one can compile on a build machine with a complete toolchain, tar the installed tree and deploy it on an other machine (same arch and so on) that does not have system gcc, gmp installed. currently this is not possible. please correct me if I am completely wrong Eric
[Bug other/78711] gcc-6.2.0:: libjavamath.so inconsistent gmp link
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78711 --- Comment #4 from Andreas Schwab --- The target libraries must always be built against the libraries of the target system. You have to populate the sysroot accordingly.
[Bug other/78711] gcc-6.2.0:: libjavamath.so inconsistent gmp link
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78711 --- Comment #5 from Eric --- (In reply to Andreas Schwab from comment #4) > The target libraries must always be built against the libraries of the > target system. You have to populate the sysroot accordingly. as during gcc build gmp is built vs the target system I'm compiling on I still don't understand.
[Bug libstdc++/51960] [DR 2127] Missing move-assignment operator in raw_storage_iterator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51960 --- Comment #7 from Jonathan Wakely --- Author: redi Date: Wed Dec 7 15:55:39 2016 New Revision: 243358 URL: https://gcc.gnu.org/viewcvs?rev=243358&root=gcc&view=rev Log: libstdc++/51960 move-construction for raw_storage_iterator Backport from mainline 2016-08-26 Jonathan Wakely PR libstdc++/51960 * doc/xml/manual/intro.xml: Document DR 2127 change. * doc/html/*: Regenerate. * include/bits/stl_raw_storage_iter.h (operator=(_Tp&&)): Add. (operator++(), operator++(int)): Use injected class name. * testsuite/20_util/raw_storage_iterator/dr2127.cc: New test. Added: branches/gcc-6-branch/libstdc++-v3/testsuite/20_util/raw_storage_iterator/dr2127.cc Modified: branches/gcc-6-branch/libstdc++-v3/ChangeLog branches/gcc-6-branch/libstdc++-v3/doc/html/manual/bugs.html branches/gcc-6-branch/libstdc++-v3/doc/xml/manual/intro.xml branches/gcc-6-branch/libstdc++-v3/include/bits/stl_raw_storage_iter.h
[Bug libstdc++/78565] undefined reference to `aligned_alloc' when building mingw-w64 cross-compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78565 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-12-07 Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- (In reply to Georg Koppen from comment #0) > git blame gives me r240187 as the culprit. Obviously not, because the call to aligned_alloc was already there.
[Bug libstdc++/55727] better support for dynamic allocation of over-aligned types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55727 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Target Milestone|--- |7.0 --- Comment #7 from Jonathan Wakely --- (In reply to Matthias Kretz from comment #1) > Created attachment 28992 [details] > simple testcase for std::vector This works as expected on trunk, now that we support aligned allocation.
[Bug target/77761] [7 Regression] wrong code with -fschedule-insns -mavx512f --param=max-pending-list-length=512
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77761 --- Comment #3 from Uroš Bizjak --- Author: vmakarov Date: Tue Dec 6 20:02:03 2016 New Revision: 243316 URL: https://gcc.gnu.org/viewcvs?rev=243316&root=gcc&view=rev Log: 2016-12-06 Vladimir Makarov target/77761 * lra-lives.c (process_bb_lives): Update biggest mode for implicitly used hard reg. 2016-12-06 Vladimir Makarov target/77761 * testsuite/gcc.target/i386/pr77761.c: New. Added: trunk/gcc/testsuite/gcc.target/i386/pr77761.c Modified: trunk/gcc/ChangeLog trunk/gcc/lra-lives.c trunk/gcc/testsuite/ChangeLog
[Bug target/77761] [7 Regression] wrong code with -fschedule-insns -mavx512f --param=max-pending-list-length=512
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77761 Uroš Bizjak changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Uroš Bizjak --- Fixed.
[Bug libobjc/78698] [7 regression] Using static PIC libgc fails when it has dependencies
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78698 Eric Gallager changed: What|Removed |Added CC||egall at gwmail dot gwu.edu --- Comment #2 from Eric Gallager --- (In reply to Matthias Klose from comment #1) > didn't check a configuration with --disable-shared :-/ What about checking > for a $bdw_lib_dir/libgc.la and in that case setting BDW_GC_LIBS to > $bdw_lib_dir/libgc.la and skipping the compile and link tests? I assume we > could do a file check for the header file as well for this case. > > --- configure.ac (revision 243108) > +++ configure.ac (working copy) > @@ -290,10 +293,19 @@ >AC_MSG_ERROR([no multilib path ($mldir) found in > --with-target-bdw-gc-lib]) > fi > BDW_GC_CFLAGS="-I$bdw_inc_dir" > -BDW_GC_LIBS="-L$bdw_lib_dir -lgc" > +if test -f $bdw_lib_dir/libgc.la; then > + BDW_GC_LIBS="$bdw_lib_dir/libgc.la" > +else > + BDW_GC_LIBS="-L$bdw_lib_dir -lgc" > +fi > AC_MSG_RESULT([found]) >fi > > + case "$BDW_GC_LIBS" in > + *libgc.la) > +use_bdw_gc=yes > +;; > + *) >AC_MSG_CHECKING([for system boehm-gc]) >save_CFLAGS=$CFLAGS >save_LIBS=$LIBS > @@ -329,6 +341,7 @@ > use_bdw_gc=yes > AC_MSG_RESULT([found]) >fi > + esac > esac > > if test "$use_bdw_gc" = no; then Note that some package managers automatically delete .la files as part of the installation process. I suppose it'd just fall through to the compile-and-link tests in that case, though, which might still work...
[Bug libstdc++/78326] incorrect c++ usage in experimental/vector and others? _X_max_align is inaccessible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78326 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Jonathan Wakely --- Fixed for 6.3 too now.
[Bug libstdc++/51960] [DR 2127] Missing move-assignment operator in raw_storage_iterator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51960 Jonathan Wakely changed: What|Removed |Added Target Milestone|7.0 |6.3
[Bug c++/64767] Could GCC warn when a pointer is compared against '\0'?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64767 Eric Gallager changed: What|Removed |Added CC||egall at gwmail dot gwu.edu --- Comment #8 from Eric Gallager --- (In reply to Marek Polacek from comment #7) > This code is now rejected in C++11. See r240707. What about in other standards? gcc built at the end of November still seems to reject the -Wpointer-compare flag that I thought was going to be added for this: $ /usr/local/bin/gcc -Wpointer-compare randomer.c gcc: error: unrecognized command line option ‘-Wpointer-compare’; did you mean ‘-Wnonnull-compare’?
[Bug sanitizer/78708] [7 Regression][ASAN][LTO] ICE in expand_ASAN_MARK, at internal-fn.c:380 - when compiling but not linking with ASAN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78708 --- Comment #2 from Jakub Jelinek --- Works? You mean it doesn't ICE? As soon as there are any libasan routine calls, it can't really link properly, at least not unless you g++ test.o -lasan Anyway, this is related to PR69254, probably when streaming in LTO bytecode and seeing there ASAN_MARK internal function with flag_sanitize & SANITIZE_ADDRESS not set we should set it. Similarly when streaming in the various UBSAN_* internal functions, so we don't ICE because sanopt pass has not been invoked. Of course, the result will not really link, but that is user fault.
[Bug libstdc++/78326] incorrect c++ usage in experimental/vector and others? _X_max_align is inaccessible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78326 --- Comment #7 from Jonathan Wakely --- Author: redi Date: Wed Dec 7 16:05:49 2016 New Revision: 243369 URL: https://gcc.gnu.org/viewcvs?rev=243369&root=gcc&view=rev Log: PR78326 fix incorrect access of data member in base class Backport from mainline 2016-11-13 Jonathan Wakely PR libstdc++/78326 * include/experimental/memory_resource (memory_resource::_S_max_align): Change access to protected. Modified: branches/gcc-6-branch/libstdc++-v3/ChangeLog branches/gcc-6-branch/libstdc++-v3/include/experimental/memory_resource
[Bug other/65254] libiberty produces using extended field designator is an extension warnings in clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65254 Eric Gallager changed: What|Removed |Added CC||egall at gwmail dot gwu.edu --- Comment #1 from Eric Gallager --- (In reply to Jack Howarth from comment #0) > The simple-object-xcoff.c file in libiberty produces a number of warnings of > the form... > > ./../../gcc-5-20150228/libiberty/simple-object-xcoff.c:330:12: warning: > using extended field designator is an extension [-Wextended-offsetof] > + offsetof (struct external_filehdr, > ^ > /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault. > xctoolchain/usr/bin/../lib/clang/6.0/include/stddef.h:87:24: note: expanded > from macro > 'offsetof' > #define offsetof(t, d) __builtin_offsetof(t, d) >^ > > under the clang compiler as "offsetof(T, field,subfield)" and "offsetof(T, > arr[3])" are C/C++ extensions and only "offsetof(T, field)" is standard. > Shouldn't these be recoded to use the standard form? Furthermore, it'd be a good idea if gcc supported the -Wextended-offsetof flag, too, like clang does.
[Bug tree-optimization/71691] [6/7 Regression] wrong code at -O3 in both 32-bit and 64-bit modes on x86_64-linux-gnu (Floating point exception)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71691 --- Comment #17 from Jeffrey A. Law --- It's just latent. We still need to fix it appropriately.
[Bug libobjc/78698] [7 regression] Using static PIC libgc fails when it has dependencies
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78698 --- Comment #3 from Matthias Klose --- On 07.12.2016 17:06, egall at gwmail dot gwu.edu wrote: > Note that some package managers automatically delete .la files as part of the > installation process. I suppose it'd just fall through to the compile-and-link > tests in that case, though, which might still work... yes, it will. And I think it will still fail a --disable-shared build without having a libgc.la. The alternative would be to run the to-be-generated LIBTOOL_COMPILE and LIBTOOL_LINK in the configure file. But I couldn't find any references how that could be done.
[Bug c++/62182] New warning wished: operator== and "equality comparison result unused [-Wunused-comparison]"/-Wunsed-value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62182 Eric Gallager changed: What|Removed |Added CC||egall at gwmail dot gwu.edu --- Comment #6 from Eric Gallager --- I think this is a duplicate of bug 53598
[Bug c/61593] Support '#pragma mark - foo' (by simply ignoring it without warning)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61593 --- Comment #1 from Eric Gallager --- The gcc documentation says pragma mark should be accepted: https://gcc.gnu.org/onlinedocs/gcc/Darwin-Pragmas.html#Darwin-Pragmas
[Bug c++/78715] New: [concepts] Access specifiers ignored after concept declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78715
Bug ID: 78715
Summary: [concepts] Access specifiers ignored after concept
declaration
Product: gcc
Version: 6.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tcbrindle at gmail dot com
Target Milestone: ---
Whilst playing with Casey Carter's STL2 implementation, I noticed an odd
phenomenon: after including a particular file, I was able to call private
functions of classes when I should not have been able to. After digging around,
I managed to boil it down to a short test case:
template
concept bool Dummy = true;
template
class example {
template U>
friend auto func();
};
class test {
test() = default;
};
int main()
{
test t;
}
This code compiles without warnings on GCC 6.2.0, whereas I would expect an
error due to calling the private default constructor of `test`. Modifying the
concept code (e.g. making `example` a non-template) produces the expected
error message.
I've got no idea what's going on, but if you need any more info then please let
me know.
[Bug sanitizer/78654] ubsan can lead to excessive stack usage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78654 --- Comment #3 from Jakub Jelinek --- It is mostly -fsanitize=alignment related on the serpent_generic.i, all the other undefined sanitizers together cause largest frame of size 600 or so. Also, if you use -fsanitize=undefined -fno-sanitize-recover=all then the problem does not exist (608 bytes max frame size). The problem with -fsanitize=alignment if recovery is required is that there is huge amount of those (conditional) calls, if (some_pointer_is_unaligned) __ubsan_handle_* (...); and that of course can't play well with register allocation, because it needs to keep everything live across those calls, and as those calls may clobber call used registers, that means having to push more variables into memory, at least across those calls.
[Bug tree-optimization/77862] [7 Regression] ice in add_equivalence
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77862 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #6 from Jakub Jelinek --- So is this fixed now?
[Bug target/72683] [7 Regression] MPX test failures with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72683 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Is this now fixed?
[Bug c/61593] Support '#pragma mark - foo' (by simply ignoring it without warning)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61593 --- Comment #2 from Sean --- Eric, thanks for your reply. Those docs read to me like the pragma is only supported *on* Darwin. I guess I was not clear when creating this ticket: I'm interested in the pragma being accepted on any platform. In our situation, we have portable code that runs on Darwin and Linux and would like to use those pragma marks in that code.
[Bug c++/71965] [7 regression] [concepts] Substitution error *after* failure to satisfy an earlier constraint
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71965 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||jason at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- Started with r238558.
[Bug middle-end/78716] New: [7 Regression] ICE in gimplify_va_arg_expr, at gimplify.c:12650 (i686-linux-gnu)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78716
Bug ID: 78716
Summary: [7 Regression] ICE in gimplify_va_arg_expr, at
gimplify.c:12650 (i686-linux-gnu)
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: doko at gcc dot gnu.org
Target Milestone: ---
Created attachment 40277
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40277&action=edit
preprocessed source
seen with -r on i686-linux-gnu with all optimization levels:
$ cat ttuple.ii
template
struct a;
template struct b;
template class e : b::c {
public:
typedef e f;
typedef typename b::c g;
e(__builtin_va_list *s) : g(__builtin_va_arg(*s, int)) {}
};
template <> struct b { typedef e<> c; };
template <> struct e<> { template e(h); };
template class a : public e {};
template
class a : e::f> {
public:
template
a(a) : a::f(0) {}
};
template a<> r(i, j, k, l);
void q() { a(r(4, 6, 9, 7)); }
$ g++ -c -O0 ttuple.ii
ttuple.ii: In constructor 'e< , d>::e(char**) [with
= e; d = void]':
ttuple.ii:9:56: internal compiler error: in gimplify_va_arg_expr, at
gimplify.c:12650
e(__builtin_va_list *s) : g(__builtin_va_arg(*s, int)) {}
^
0x852820c gimplify_va_arg_expr(tree_node**, gimple**, gimple**)
../../src/gcc/gimplify.c:12650
0x8524e36 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../src/gcc/gimplify.c:11256
0x852cf86 gimplify_expr
../../src/gcc/gimplify.c:12181
0x852e30c gimplify_call_expr
../../src/gcc/gimplify.c:3242
0x8525af3 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../src/gcc/gimplify.c:11155
0x8527be9 gimplify_stmt(tree_node**, gimple**)
../../src/gcc/gimplify.c:6459
0x8525a4b gimplify_cleanup_point_expr
../../src/gcc/gimplify.c:6210
0x8525a4b gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../src/gcc/gimplify.c:11559
0x8527be9 gimplify_stmt(tree_node**, gimple**)
../../src/gcc/gimplify.c:6459
0x8528622 gimplify_bind_expr
../../src/gcc/gimplify.c:1276
0x8525b45 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../src/gcc/gimplify.c:11383
0x8527be9 gimplify_stmt(tree_node**, gimple**)
../../src/gcc/gimplify.c:6459
0x8528eb2 gimplify_body(tree_node*, bool)
../../src/gcc/gimplify.c:12377
0x8529265 gimplify_function_tree(tree_node*)
../../src/gcc/gimplify.c:12534
0x83f1608 cgraph_node::analyze()
../../src/gcc/cgraphunit.c:626
0x83f3c00 analyze_functions
../../src/gcc/cgraphunit.c:1087
0x83f4660 symbol_table::finalize_compilation_unit()
../../src/gcc/cgraphunit.c:2562
Please submit a full bug report,
with preprocessed source if appropriate.
[Bug tree-optimization/71691] [6/7 Regression] wrong code at -O3 in both 32-bit and 64-bit modes on x86_64-linux-gnu (Floating point exception)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71691 --- Comment #18 from Aldy Hernandez --- On 12/07/2016 11:38 AM, law at redhat dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71691 > > --- Comment #17 from Jeffrey A. Law --- > It's just latent. We still need to fix it appropriately. > Ok. I see that compiling with -O3 -fno-tree-vrp shows a segfault at execution. I'll take a look. Hopefully it's still the same bug.
[Bug middle-end/78716] [7 Regression] ICE in gimplify_va_arg_expr, at gimplify.c:12650 (i686-linux-gnu)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78716 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-12-07 CC||mpolacek at gcc dot gnu.org Target Milestone|--- |7.0 Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- Confirmed, started with Make canonical_va_list_type more strict 2016-09-10 Tom de Vries PR C/71602 * builtins.c (std_canonical_va_list_type): Strictly return non-null for va_list type only. * config/i386/i386.c (ix86_canonical_va_list_type): Same. * gimplify.c (gimplify_va_arg_expr): Handle &va_list. * c-common.c (build_va_arg): Handle more strict targetm.canonical_va_list_type. Replace first argument type error with assert. * c-c++-common/va-arg-va-list-type.c: New test. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@240072 138bc75d-0d04-0410-961f-82ee72b054a4
[Bug middle-end/78716] [7 Regression] ICE in gimplify_va_arg_expr, at gimplify.c:12650 (i686-linux-gnu)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78716
--- Comment #2 from Marek Polacek ---
I think I see the error. If I add this hunk back (that r240072 removed), it
doesn't ICE anymore:
--- a/gcc/builtins.c
+++ b/gcc/builtins.c
@@ -4124,6 +4124,8 @@ std_canonical_va_list_type (tree type)
{
tree wtype, htype;
+ if (POINTER_TYPE_P (type) && POINTER_TYPE_P (TREE_TYPE (type)))
+type = TREE_TYPE (type);
wtype = va_list_type_node;
htype = type;
The testcase won't ICE if I change
__builtin_va_list *s
to
__builtin_va_list s
[Bug libstdc++/78717] New: no definition of string::find when lowered to gimple
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78717
Bug ID: 78717
Summary: no definition of string::find when lowered to gimple
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: hiraditya at msn dot com
Target Milestone: ---
$ cat test.cpp
#include
int foo(const std::string &s1, const std::string &s2, int i) {
return s1.find(s2) == i;
}
../gcc/install/usr/bin/g++ -S -o a.s ../a.cpp -fdump-tree-all-all
$ cat a.cpp.004t.gimple
int foo(const string&, const string&, int) (const struct string & s1, const
struct string & s2, int i)
{
intD.9 D.27718;
# USE = anything
# CLB = anything
_1 =
_ZNKSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE4findERKS4_mD.18492
(s1D.24055, s2D.24056, 0);
_2 = (long unsigned intD.14) iD.24057;
_3 = _1 == _2;
D.27718 = (intD.9) _3;
return D.27718;
}
The problem is that now inliner cannot see the definition of std::string::find
and hence cannot inline it. Maybe because std::basic_string is an extern
template, but I would hope that at least the definition should be visible to
the optimizer. That would help improve the performance of programs using
string::find.
Thanks,
[Bug libstdc++/66414] string::find ten times slower than strstr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66414 AK changed: What|Removed |Added CC||hiraditya at msn dot com --- Comment #6 from AK --- I have posted a patch up for review for string::find which might help as well. https://gcc.gnu.org/ml/libstdc++/2016-12/msg00051.html Please give feedback for improvement. -Aditya
[Bug rtl-optimization/78617] LRA clobbers live register during rematerialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78617 --- Comment #3 from Thomas Preud'homme --- Author: thopre01 Date: Wed Dec 7 17:56:53 2016 New Revision: 243374 URL: https://gcc.gnu.org/viewcvs?rev=243374&root=gcc&view=rev Log: 2016-12-07 Thomas Preud'homme gcc/ PR rtl-optimization/78617 * lra-remat.c (do_remat): Initialize live_hard_regs from live in registers, also setting hard registers mapped to pseudo registers. gcc/testsuite/ PR rtl-optimization/78617 * gcc.c-torture/execute/pr78617.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr78617.c Modified: trunk/gcc/ChangeLog trunk/gcc/lra-remat.c trunk/gcc/testsuite/ChangeLog
[Bug sanitizer/78708] [7 Regression][ASAN][LTO] ICE in expand_ASAN_MARK, at internal-fn.c:380 - when compiling but not linking with ASAN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78708 --- Comment #3 from Tobias Burnus --- (In reply to Jakub Jelinek from comment #2) > Works? You mean it doesn't ICE? [...] That's what I meant. Of course, when the bug is fixed, calling GCC as I did will will give tons of undefined symbols errors - but that's then a user and not a compiler error. > Of course, the result will not really link, but that is user fault. Exactly.
[Bug target/78631] [Intel MPX] libmpxwrappers shared library leads to a non-bounds-preserving memcpy()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78631 H.J. Lu changed: What|Removed |Added Status|REOPENED|NEW --- Comment #10 from H.J. Lu --- (In reply to Ilya Enkovich from comment #9) > (In reply to H.J. Lu from comment #8) > > > > MPX wrapper library doesn't call external functions with bounds > > and there is no need to use PLT to call internal functions within > > MPX wrapper library. > > It doesn't explain why it doesn't work. MPX wrapper library isn't built with -z bndplt since it doesn't call external functions with bounds. But some internal functions, which need bounds, are called via PLT which clear bounds. It should call call those internal functions directly instead of via PLT.
[Bug rtl-optimization/78671] [7 Regression] ICE: in extract_constrain_insn, at recog.c:2213 with -Og -march=skylake-avx512
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78671 --- Comment #3 from Vladimir Makarov --- (In reply to Jakub Jelinek from comment #2) > Started with r243038. It has just triggered a latent bug. It is a pretty interesting bug. The problem is that a TImode pseudo has class INT_SSE_REGS and r15(44) smoothly goes to xmm8 (45). So using available regs in LRA, r15 is ok for the pseudo. Actually on machine-depended side, a more detail implementation HARD_REGNO_MODE_OK could solve the problem. But it is too complicated and error prone and require a lot of efforts to define the macro accurately for all classes and modes. I think I'll use the same solution as IRA does which is based on usage of the register pressure classes which is based on hard reg cost movements (moving from sse to/from general regs is more expensive than just inside sse or general regs). I hope the patch will be ready by Friday.
[Bug rtl-optimization/78617] LRA clobbers live register during rematerialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78617 --- Comment #4 from Thomas Preud'homme --- Author: thopre01 Date: Wed Dec 7 18:15:52 2016 New Revision: 243375 URL: https://gcc.gnu.org/viewcvs?rev=243375&root=gcc&view=rev Log: 2016-12-07 Thomas Preud'homme Backport from mainline 2016-12-07 Thomas Preud'homme gcc/ PR rtl-optimization/78617 * lra-remat.c (do_remat): Initialize live_hard_regs from live in registers, also setting hard registers mapped to pseudo registers. gcc/testsuite/ PR rtl-optimization/78617 * gcc.c-torture/execute/pr78617.c: New test. Added: branches/ARM/embedded-6-branch/gcc/testsuite/gcc.c-torture/execute/pr78617.c Modified: branches/ARM/embedded-6-branch/gcc/ChangeLog.arm branches/ARM/embedded-6-branch/gcc/lra-remat.c branches/ARM/embedded-6-branch/gcc/testsuite/ChangeLog.arm
[Bug fortran/78674] [cleanup] merge gfc_convert_type_warn and gfc_convert_chartype
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78674 janus at gcc dot gnu.org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu.org --- Comment #2 from janus at gcc dot gnu.org --- Patch at https://gcc.gnu.org/ml/fortran/2016-12/msg00045.html
[Bug target/78631] [Intel MPX] libmpxwrappers shared library leads to a non-bounds-preserving memcpy()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78631 --- Comment #11 from Ilya Enkovich --- (In reply to H.J. Lu from comment #10) > > MPX wrapper library isn't built with -z bndplt since it doesn't call > external functions with bounds. But some internal functions, which > need bounds, are called via PLT which clear bounds. It should call > call those internal functions directly instead of via PLT. Thanks for explanation. I thought we added '-fcheck-pointer-bounds -mmpx' libmpxwrappers link flags but now I see we didn't. We also added tests to check memcpy copies bounds correctly but didn't check memcpy detects bounds violation. I suppose your patch is OK with such test added.
[Bug rtl-optimization/78626] [7 Regression] ICE in rtl_verify_bb_insns, at cfgrtl.c:2656 (error: flow control insn inside a basic block)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78626 Aldy Hernandez changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-12-07 CC||aldyh at gcc dot gnu.org Ever confirmed|0 |1
[Bug c++/72775] [6/7 Regression] internal compiler error: in finish_expr_stmt, at cp/semantics.c:677
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72775 Nathan Sidwell changed: What|Removed |Added CC||nathan at gcc dot gnu.org --- Comment #13 from Nathan Sidwell --- Marek, why the DECL_CONSTRUCTOR_P check? Isn't it enough that we've reached that location to know one's in a constructor? (and if it isn't, why are the other locations permitted to init the array?)
[Bug preprocessor/69543] [6/7 Regression] _Pragma does not apply within macro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69543 Aldy Hernandez changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2016-12-07 CC||aldyh at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #7 from Aldy Hernandez --- Is still an issue, or has it been properly fixed with dmalcolm's latest commits to the PR?
[Bug c++/71965] [7 regression] [concepts] Substitution error *after* failure to satisfy an earlier constraint
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71965 Aldy Hernandez changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-12-07 CC||aldyh at gcc dot gnu.org Ever confirmed|0 |1
[Bug c++/78550] [6/7 Regression] bit field and std::initializer_list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78550 Nathan Sidwell changed: What|Removed |Added Status|NEW |ASSIGNED CC||nathan at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |nathan at gcc dot gnu.org
[Bug c++/78551] [5/6/7 Regression] Internal compiler error with constexpr initialization of union
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78551 Nathan Sidwell changed: What|Removed |Added Status|NEW |ASSIGNED
[Bug fortran/70149] [F08] Character pointer initialization causes ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70149 Gerhard Steinmetz changed: What|Removed |Added CC||gerhard.steinmetz.fortran@t ||-online.de --- Comment #5 from Gerhard Steinmetz --- This variant gives the same backtrace as in pr68569 comment 2 : $ cat z2.f90 program p character(16), target :: char_data = 'forty two' character(:), pointer :: x => char_data print *, len(x), x end $ gfortran-7-20161204 z2.f90 z2.f90:1:0: program p internal compiler error: in gfc_get_symbol_decl, at fortran/trans-decl.c:1705 0x75b6f5 gfc_get_symbol_decl(gfc_symbol*) ../../gcc/fortran/trans-decl.c:1705 0x75e5b7 generate_local_decl ../../gcc/fortran/trans-decl.c:5327 0x71825b do_traverse_symtree ../../gcc/fortran/symbol.c:3994 0x75f412 generate_local_vars ../../gcc/fortran/trans-decl.c:5527 0x75f412 gfc_generate_function_code(gfc_namespace*) ../../gcc/fortran/trans-decl.c:6206 0x6e73d0 translate_all_program_units ../../gcc/fortran/parse.c:6038 0x6e73d0 gfc_parse_file() ../../gcc/fortran/parse.c:6238 0x72b182 gfc_be_parse_file ../../gcc/fortran/f95-lang.c:202
[Bug fortran/78718] New: ICE in gfc_get_symbol_decl, at fortran/trans-decl.c:1427
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78718 Bug ID: 78718 Summary: ICE in gfc_get_symbol_decl, at fortran/trans-decl.c:1427 Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gerhard.steinmetz.fort...@t-online.de Target Milestone: --- Affects versions down to at least 4.8 : $ cat z1.f90 program p integer :: n, z n = 1 contains function f() result(z) call s(n, z) end end $ gfortran-7-20161204 z1.f90 z1.f90:6:0: call s(n, z) internal compiler error: in gfc_get_symbol_decl, at fortran/trans-decl.c:1427 0x75a05e gfc_get_symbol_decl(gfc_symbol*) ../../gcc/fortran/trans-decl.c:1421 0x7731af gfc_conv_variable ../../gcc/fortran/trans-expr.c:2494 0x76ee42 gfc_conv_expr(gfc_se*, gfc_expr*) ../../gcc/fortran/trans-expr.c:7771 0x776f56 gfc_conv_expr_reference(gfc_se*, gfc_expr*) ../../gcc/fortran/trans-expr.c:7871 0x76a420 gfc_conv_procedure_call(gfc_se*, gfc_symbol*, gfc_actual_arglist*, gfc_expr*, vec*) ../../gcc/fortran/trans-expr.c:5169 0x7b4704 gfc_trans_call(gfc_code*, bool, tree_node*, tree_node*, bool) ../../gcc/fortran/trans-stmt.c:407 0x72e6ca trans_code ../../gcc/fortran/trans.c:1858 0x75f708 gfc_generate_function_code(gfc_namespace*) ../../gcc/fortran/trans-decl.c:6271 0x75f557 gfc_generate_contained_functions ../../gcc/fortran/trans-decl.c:5251 0x75f557 gfc_generate_function_code(gfc_namespace*) ../../gcc/fortran/trans-decl.c:6200 0x6e73d0 translate_all_program_units ../../gcc/fortran/parse.c:6038 0x6e73d0 gfc_parse_file() ../../gcc/fortran/parse.c:6238 0x72b182 gfc_be_parse_file ../../gcc/fortran/f95-lang.c:202
[Bug fortran/78719] New: ICE in gfc_get_symbol_decl, at fortran/trans-decl.c:1438
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78719 Bug ID: 78719 Summary: ICE in gfc_get_symbol_decl, at fortran/trans-decl.c:1438 Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gerhard.steinmetz.fort...@t-online.de Target Milestone: --- With invalid code (due to an extra declaration flagged with "!!"), down to at least 4.8 : $ cat z1.f90 program p type t integer :: n end type class(t) :: g !! abstract interface subroutine h end end interface procedure(h), pointer :: s s => f call s s => g call s contains subroutine f print *, 'inside f' end subroutine g print *, 'inside g' end end $ gfortran-7-20161204 z1.f90 z1.f90:13:0: s => g internal compiler error: Segmentation fault 0xc4940f crash_signal ../../gcc/toplev.c:333 0x75a0e9 gfc_get_symbol_decl(gfc_symbol*) ../../gcc/fortran/trans-decl.c:1438 0x7731af gfc_conv_variable ../../gcc/fortran/trans-expr.c:2494 0x76ee42 gfc_conv_expr(gfc_se*, gfc_expr*) ../../gcc/fortran/trans-expr.c:7771 0x77bc97 gfc_trans_pointer_assignment(gfc_expr*, gfc_expr*) ../../gcc/fortran/trans-expr.c:8169 0x72e667 trans_code ../../gcc/fortran/trans.c:1798 0x75f708 gfc_generate_function_code(gfc_namespace*) ../../gcc/fortran/trans-decl.c:6271 0x6e73d0 translate_all_program_units ../../gcc/fortran/parse.c:6038 0x6e73d0 gfc_parse_file() ../../gcc/fortran/parse.c:6238 0x72b182 gfc_be_parse_file ../../gcc/fortran/f95-lang.c:202
[Bug c++/72775] [6/7 Regression] internal compiler error: in finish_expr_stmt, at cp/semantics.c:677
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72775 --- Comment #14 from Marek Polacek --- I think you're right. I dropped the check and am regtesting this again. Thanks!
[Bug fortran/68569] ICE with automatic character object and DATA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68569 --- Comment #2 from Gerhard Steinmetz --- Update, backtrace : $ gfortran-7-20161204 -c z2a.f90 z2a.f90:4:12: data x /'a'/ 1 Warning: Initialization string at (1) was truncated to fit the variable (0/1) z2a.f90:1:0: subroutine s(n) internal compiler error: in gfc_get_symbol_decl, at fortran/trans-decl.c:1705 0x75b6f5 gfc_get_symbol_decl(gfc_symbol*) ../../gcc/fortran/trans-decl.c:1705 0x75e5b7 generate_local_decl ../../gcc/fortran/trans-decl.c:5327 0x71825b do_traverse_symtree ../../gcc/fortran/symbol.c:3994 0x75f412 generate_local_vars ../../gcc/fortran/trans-decl.c:5527 0x75f412 gfc_generate_function_code(gfc_namespace*) ../../gcc/fortran/trans-decl.c:6206 0x6e73d0 translate_all_program_units ../../gcc/fortran/parse.c:6038 0x6e73d0 gfc_parse_file() ../../gcc/fortran/parse.c:6238 0x72b182 gfc_be_parse_file ../../gcc/fortran/f95-lang.c:202
[Bug fortran/78719] ICE in gfc_get_symbol_decl, at fortran/trans-decl.c:1438
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78719 --- Comment #1 from Gerhard Steinmetz --- Detected with type "real" instead of "class(t)" : $ cat z3.f90 program p type t integer :: n end type real :: g !! abstract interface subroutine h end end interface procedure(h), pointer :: s s => f call s s => g call s contains subroutine f print *, 'inside f' end subroutine g print *, 'inside g' end end $ gfortran-7-20161204 z3.f90 z3.f90:19:15: z3.f90:5:12: real :: g !! 2 z3.f90:19:15: subroutine g 1 Error: Procedure 'g' at (1) has an explicit interface and must not have attributes declared at (2) --- Deleting that extra line gives a valid and correct program : $ cat z0.f90 program p type t integer :: n end type abstract interface subroutine h end end interface procedure(h), pointer :: s s => f call s s => g call s contains subroutine f print *, 'inside f' end subroutine g print *, 'inside g' end end $ gfortran-7-20161204 z0.f90 $ a.out inside f inside g
[Bug fortran/78719] ICE in gfc_get_symbol_decl, at fortran/trans-decl.c:1438
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78719 --- Comment #2 from Gerhard Steinmetz --- Interestingly, following invalid variant with "type(t)" is silently accepted and gives same results as z0.f90 in comment 1. $ cat z2.f90 program p type t integer :: n end type type(t) :: g !! abstract interface subroutine h end end interface procedure(h), pointer :: s s => f call s s => g call s contains subroutine f print *, 'inside f' end subroutine g print *, 'inside g' end end $ gfortran-7-20161204 z2.f90 $ a.out inside f inside g
