[Bug rtl-optimization/70408] New: reusing the same call-preserved register would give smaller code in some cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70408
Bug ID: 70408
Summary: reusing the same call-preserved register would give
smaller code in some cases
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: peter at cordes dot ca
Target Milestone: ---
int foo(int); // not inlineable
int bar(int a) {
return foo(a+2) + 5 * foo (a);
}
gcc (and clang and icc) all make bigger code than necessary for x86. gcc uses
two call-preserved registers to save `a` and `foo(a+2)`. Besides the extra
push/pop, stack alignment requires a sub/add esp,8 pair.
Combining data-movement with arithmetic wherever possible is also a win (using
lea), but gcc also misses out on that.
# gcc6 snapshot 20160221 on godbolt (with -O3): http://goo.gl/dN5OXD
pushq %rbp
pushq %rbx
movl%edi, %ebx
leal2(%rdi), %edi # why lea instead of add rdi,2?
subq$8, %rsp
callfoo# foo(a+2)
movl%ebx, %edi
movl%eax, %ebp
callfoo# foo(a)
addq$8, %rsp
leal(%rax,%rax,4), %eax
popq%rbx
addl%ebp, %eax
popq%rbp
ret
clang 3.8 makes essentially the same code (but wastes an extra mov because it
doesn't produce the result in %eax).
By hand, the best I can come up with is:
push%rbx
lea 2(%rdi), %ebx # stash ebx=a+2
callfoo# foo(a)
mov %ebx, %edi
lea (%rax,%rax,4), %ebx# reuse ebx to stash 5*foo(a)
callfoo# foo(a+2)
add %ebx, %eax
pop %rbx
ret
Note that I do the calls to foo() in the other order, which allows more folding
of MOV into LEA. The savings from that are somewhat orthogonal to the savings
from reusing the same call-preserved register.
Should I open a separate bug report for the failure to optimize by reordering
the calls?
I haven't tried to look closely at ARM or PPC code to see if they succeed at
combining data movement with math (prob. worth testing with `foo(a) * 4` since
x86's shift+add LEA is not widely available). I didn't mark this as an
i386/x86-64 but, because the reuse of call-preserved registers affects all
architectures.
IDK if teaching gcc about either of these tricks would help with real code in
many cases, or how hard it would be.
[Bug c++/69564] [5/6 Regression] lto and/or C++ make scimark2 LU slower
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69564 --- Comment #19 from vincenzo Innocente --- patch applied to gcc version 6.0.0 20160324 (experimental) [trunk revision 234461] (GCC) I confirm the improvement in timing for c++ and lto timing difference between gcc and c++ seems to be inside "errors" I am satisfied. Thanks Patrick! (btw I suppose no hope for a back port to 5.4?)
[Bug fortran/70409] New: Silent truncation of character parameters with len=huge()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70409 Bug ID: 70409 Summary: Silent truncation of character parameters with len=huge() Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: anlauf at gmx dot de Target Milestone: --- Related to/derived from pr68441. The following code demonstrates a strange behavior of character parameter declarations if the len argument involves huge(). integer, parameter :: huge_1 = huge(0_1) character(huge_1 ), parameter :: x = 'abc' character(huge(0_1) ), parameter :: y = 'abc' character(huge(0_1)+0 ), parameter :: z = 'abcdef' character(huge(0_1) ):: a = 'abc' integer, parameter :: huge_2 = huge(0_2) character(huge_2 ), parameter :: u = 'abc' character(huge(0_2) ), parameter :: v = 'abc' character(int(huge(0_2),4)), parameter :: w = 'abcdef' character(huge(0_2) ):: b = 'abc' print*, huge_1, len(x), len(y), len(z), len (a) print*, huge_2, len(u), len(v), len(w), len (b) end Output for 4.6 .. 6.0 trunk: 127 127 3 6 127 32767 32767 3 6 32767 Expected: all numbers should be 127 in the first line, 32767 in the second.
[Bug fortran/68441] ICE on using transfer with character parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68441 --- Comment #3 from Harald Anlauf --- (In reply to Harald Anlauf from comment #2) > There's a subtle wrong-code problem: This wrong-code issue is discussed in pr70409.
[Bug c/70408] reusing the same call-preserved register would give smaller code in some cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70408 Andrew Pinski changed: What|Removed |Added Component|rtl-optimization|c --- Comment #1 from Andrew Pinski --- Note teaching this trick requires a huge amount of work as you need to teach GCC more about order of operands does not matter; this requires work in the front-end and then in the gimple level and then maybe the middle-end. Is it worth it for the gain, most likely not, you are more likely just to get better code by not depending on unspecified behavior in C. ># why lea instead of add rdi,2? Because lea does not clobber the flags, so this might be faster, it depends on the machine. Also try -Os you might see a difference code.
[Bug c++/69564] [5/6 Regression] lto and/or C++ make scimark2 LU slower
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69564 --- Comment #20 from rguenther at suse dot de --- On March 25, 2016 8:42:50 AM GMT+01:00, "vincenzo.innocente at cern dot ch" wrote: >https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69564 > >--- Comment #19 from vincenzo Innocente ch> --- >patch applied to >gcc version 6.0.0 20160324 (experimental) [trunk revision 234461] (GCC) > >I confirm the improvement in timing for c++ and lto >timing difference between gcc and c++ seems to be inside "errors" >I am satisfied. > >Thanks Patrick! > >(btw I suppose no hope for a back port to 5.4?) It needs some more understanding and a fix in the appropriate place. Thanks Patrick for narrowing down a workaround.
[Bug fortran/69603] [5/6 Regression] ICE: segfault with -fimplicit-none and proc_ptr_comp_24.f90
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69603
--- Comment #3 from Harald Anlauf ---
(In reply to Harald Anlauf from comment #2)
> Possible fix (for the crash), untested:
>
> Index: gcc/fortran/interface.c
> ===
> --- gcc/fortran/interface.c (revision 234170)
> +++ gcc/fortran/interface.c (working copy)
> @@ -2006,7 +2006,7 @@
> }
>
>ppc = gfc_get_proc_ptr_comp (actual);
> - if (ppc)
> + if (ppc && ppc->ts.interface)
> {
>if (!gfc_compare_interfaces (formal, ppc->ts.interface, ppc->name, 0,
> 1,
>err, sizeof(err), NULL, NULL))
The patch regtests ok on i686-pc-linux-gnu.
[Bug fortran/69603] [5/6 Regression] ICE: segfault with -fimplicit-none and proc_ptr_comp_24.f90
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69603 --- Comment #4 from Harald Anlauf --- Proposed patch posted at: https://gcc.gnu.org/ml/fortran/2016-03/msg00059.html
[Bug target/70052] ICE compiling _Decimal128 test case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70052 --- Comment #6 from Alan Modra --- Author: amodra Date: Fri Mar 25 09:10:03 2016 New Revision: 234479 URL: https://gcc.gnu.org/viewcvs?rev=234479&root=gcc&view=rev Log: [RS6000] PR70052, ICE compiling _Decimal128 test case gcc/ PR target/70052 * config/rs6000/constraints.md (j): Simplify. * config/rs6000/predicates.md (easy_fp_constant): Exclude decimal float 0.D. * config/rs6000/rs6000.md (zero_fp): New mode_attr. (mov_hardfloat, mov_hardfloat32, mov_hardfloat64, mov_64bit_dm, mov_32bit): Use zero_fp in place of j in all constraint alternatives. (movtd_64bit_nodm): Delete "j" constraint alternative. gcc/testsuite/ * gcc.dg/dfp/pr70052.c: New test. Added: trunk/gcc/testsuite/gcc.dg/dfp/pr70052.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/constraints.md trunk/gcc/config/rs6000/predicates.md trunk/gcc/config/rs6000/rs6000.md trunk/gcc/testsuite/ChangeLog
[Bug target/70406] ICE: in extract_insn, at recog.c:2287 (unrecognizable insn) with -mtune=pentium2 -mavx512f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70406 Kirill Yukhin changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2016-03-25 Ever confirmed|0 |1 --- Comment #2 from Kirill Yukhin --- Reproduced.
[Bug c++/70410] New: no uninitialized variable warning if 'offsetof' is used in expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70410
Bug ID: 70410
Summary: no uninitialized variable warning if 'offsetof' is
used in expression
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: sergiusthebest at hotmail dot com
Target Milestone: ---
You can easily reproduce the issue with the following code:
#include
struct C
{
int x;
int y;
};
int main()
{
int a;
int b = a + offsetof(C, y); // <= missing warning that 'a' is uninitialized
return b;
}
[Bug c/70408] reusing the same call-preserved register would give smaller code in some cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70408 --- Comment #2 from Peter Cordes --- Should I open a separate bug for the reusing call-preserved regs thing, and retitle this one to the call-reordering issue we ended up talking about here? I always have a hard time limiting an optimization bug report to a single issue, sorry. (In reply to Andrew Pinski from comment #1) > Note teaching this trick requires a huge amount of work as you need to teach > GCC more about order of operands does not matter; this requires work in the > front-end and then in the gimple level and then maybe the middle-end. Ok :( > Is it worth it for the gain, most likely not, you are more likely just to > get better code by not depending on unspecified behavior in C. Writing the code this way intentionally leaves it up to the compiler to choose the optimal order to evaluate foo(a+2) and foo(a). I don't see why forcing the compiler into one choice or the other should be considered "better" for performance, just because gcc doesn't take advantage of its options. (Better for maintainability in case someone adds side-effects to foo(), sure). I should have used __attribute__((pure)) int foo(int); to make it clear that the order of the function calls didn't matter. That would make reordering legal even the calls were separated by a sequence point, wouldn't it? (Of course, it sounds like gcc still wouldn't consider doing the reordering). > ># why lea instead of add rdi,2? > > Because lea does not clobber the flags, so this might be faster, it depends > on the machine. Every OOO x86 CPU renames EFLAGS, because almost every instruction writes flags. There aren't any CPUs where instructions that don't write flags are faster for that reason. (Not writing flags is useful when it lets you reuse some already-set flags for another check with a different condition, or stuff like that, but that's not the case here). On Intel Haswell for example, the LEA can run on port 1 or 5, but the add can run on port 0,1,5,6. Otherwise they're the same (latency, total uops, and code-size). Using `-mtune=haswell` doesn't get it to choose add edi,2 :( (From http://agner.org/optimize/ instruction tables, and Agner's microarch pdf) LEA is special on Atom. I don't remember exactly what its effect is on latency in Atom's in-order pipeline, but LEA happens at a different pipeline stage from normal ALU instructions (actually running on the AGUs). IIRC, that's an earlier stage, so inputs need to be ready sooner. > Also try -Os you might see a difference code. No change with -Os
[Bug libstdc++/70411] New: Stack overflow with std::regex_match
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70411
Bug ID: 70411
Summary: Stack overflow with std::regex_match
Product: gcc
Version: 5.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: bisqwit at iki dot fi
Target Milestone: ---
When running this code, libstdc++ crashes with a stack overflow (segmentation
fault) in std::regex_match. This regular expression is not the type that should
require exponential backtracking.
Crash occurs in code compiled by GCC 5.3.1 on x86_64-linux-gnu. Clang++ does
the same crash, when using libstdc++ from GCC.
Code compiled by GCC 4.9 does _not_ produce a crash, as it evidently uses a
different version of libstdc++.
#include
#include
std::string make_test_string()
{
std::string result = " 16777216 1 ";
for(unsigned n=0; n<1; ++n) result += "EA NOP%";
return result;
}
std::regex testregex("^([0-9A-F]+) +([0-9]+) +([0-9]+) (.*)$");
int main()
{
std::string teststr = make_test_string();
std::smatch res;
std::regex_match(teststr, res, testregex);
}
[Bug libstdc++/70411] Stack overflow with std::regex_match
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70411 --- Comment #1 from Joel Yliluoma --- Minimal regex that causes the same crash: "^0+ .*"
[Bug rtl-optimization/70405] [6 Regression] -fcompare-debug failure with -mavx512f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70405
--- Comment #1 from Uroš Bizjak ---
There is difference in _.optimized dump:
--- pr70405.c.211t.optimized2016-03-25 13:54:01.942116037 +0100
+++ pr70405.c.gk.211t.optimized 2016-03-25 13:54:01.968115746 +0100
@@ -107,8 +107,10 @@
_70 = (unsigned int) _68;
_71 = _68 >> _70;
v.1_2 = {_11, _15, _19, _23, _27, _31, _35, _39, _43, _47, _51, _55, _59,
_63, _67, _71};
- _3 = VEC_PERM_EXPR ;
+ # DEBUG v => v.1_2
+ _3 = {_11, _11, _11, _11, _11, _11, _11, _11, _11, _11, _11, _11, _11, _11,
_11, _11};
v.2_4 = v.1_2 - _3;
+ # DEBUG v => v.2_4
_5 = BIT_FIELD_REF ;
_6 = (int) _5;
return _6;
[Bug tree-optimization/70405] [6 Regression] -fcompare-debug failure with -mavx512f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70405 Uroš Bizjak changed: What|Removed |Added Keywords|ice-on-valid-code | Status|UNCONFIRMED |NEW Last reconfirmed||2016-03-25 Component|rtl-optimization|tree-optimization Target Milestone|--- |6.0 Ever confirmed|0 |1 --- Comment #2 from Uroš Bizjak --- Confirmed as a tree-optimization problem.
[Bug c/70412] New: -Wswitch and functions that can only return a small set of values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70412
Bug ID: 70412
Summary: -Wswitch and functions that can only return a small
set of values
Product: gcc
Version: 5.3.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: izaberina at gmail dot com
Target Milestone: ---
$ cat wswitch.c
#include
typedef enum { a, b, c, d, e } letter;
letter func (int arg) {
if (arg > 0) return a;
return b;
}
int main() {
switch(func(7)) {
case a: puts("a"); break;
case b: puts("b"); break;
}
return 0;
}
$ gcc -Wall wswitch.c
wswitch.c: In function 'main':
wswitch.c:11:3: warning: enumeration value 'c' not handled in switch [-Wswitch]
switch(func(7)) {
^
wswitch.c:11:3: warning: enumeration value 'd' not handled in switch [-Wswitch]
wswitch.c:11:3: warning: enumeration value 'e' not handled in switch [-Wswitch]
This is more of a question than a bug report: does that code need a default
case? I think it shouldn't, it handles all the possible return values...
Is that warning useful?
For the records, clang 3.7 reports a very similar warning.
[Bug c++/69564] [5/6 Regression] lto and/or C++ make scimark2 LU slower
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69564
--- Comment #21 from Patrick Palka ---
To be clear, given the loop
for (int i = 0; i < M; i++) { ... }
The fold_build3 in question was transforming
if (i < M)
fallthrough;
else
goto exit;
to
if (i >= M)
goto exit;
else
fallthrough;
The C FE emits
if (i < M)
goto body;
else
goto L;
L:
I would guess r217669 introduced the regression. Before this commit the two
arms of the COND_EXPR would be GOTO_EXPRs and so during folding
tree_swap_operands_p would return false. After this commit, the true arm is an
empty statement which is TREE_CONSTANT and so during folding
tree_swap_operands_p returns true.
The tree dumps do not seem to diverge significantly with and without the above
patch. The only difference throughout is the inversion of the branches.
[Bug c++/69564] [5/6 Regression] lto and/or C++ make scimark2 LU slower
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69564 --- Comment #22 from Patrick Palka --- (In reply to Patrick Palka from comment #21) > The tree dumps do not seem to diverge significantly with and without the > above patch. The only difference throughout is the inversion of the > branches. Was only looking at LU.c though.
[Bug fortran/70235] [4.9/5/6 Regression] Incorrect output with PF format
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70235 --- Comment #17 from Dominique d'Humieres --- Created attachment 38092 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38092&action=edit Updated patch "hiding" the problem reported in 16 With the attached patch I get -8pf18.2 y= 0.00 -7pf18.2 y= 0.00 -6pf18.2 y= 0.00 -5pf18.2 y= 0.00 -4pf18.2 y= 0.06 -3pf18.2 y= 0.64 -2pf18.2 y= 6.43 ... Note that -5pf18.2 y= 0.00 should be -5pf18.2 y= 0.01 if correctly rounded. Note that the patch includes some cleaning by removing a useless block and moving nzero = d; where it belongs. I agree that digits[1] = '0'; is just a working hack.
[Bug fortran/70409] Silent truncation of character parameters with len=huge()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70409 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-03-25 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Confirmed.
[Bug fortran/70397] [5/6 Regression] ice while allocating ultimate polymorphic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70397 Dominique d'Humieres changed: What|Removed |Added Priority|P3 |P4 Status|UNCONFIRMED |NEW Last reconfirmed||2016-03-25 CC||pault at gcc dot gnu.org, ||vehre at gcc dot gnu.org Known to work||4.9.3 Summary|ice while allocating|[5/6 Regression] ice while |ultimate polymorphic|allocating ultimate ||polymorphic Ever confirmed|0 |1 Known to fail||5.3.0, 6.0 --- Comment #1 from Dominique d'Humieres --- The test compiles with 4.9.3 (it does not mean that the generated code is correct;-). The change occurred around revision r221495+patches (may be r221621).
[Bug c++/68475] [4.9/5/6 Regression] ICE: in merge_exception_specifiers, at cp/typeck2.c:2115 with -fno-exceptions on invalid code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68475 Patrick Palka changed: What|Removed |Added CC||ppalka at gcc dot gnu.org --- Comment #2 from Patrick Palka --- We don't emit an error for an exception specification mismatch when !flag_exceptions. Not doing so causes us to ICE in merge_exception_specifiers because we assert that either the specifiers are equivalent or errorcount != 0. Looks like this can be fixed either by checking !flag_exceptions in the assert or by removing the flag_exceptions restriction for emitting mismatch errors.
[Bug c++/70403] A null pointer check removed with -O2 even with -fno-delete-null-pointer-checks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70403 --- Comment #6 from Hadula, Tomasz --- Created attachment 38093 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38093&action=edit Output from gcc -v -save-temps Generated by g++ -v -save-temps
[Bug c++/70403] A null pointer check removed with -O2 even with -fno-delete-null-pointer-checks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70403 --- Comment #7 from Hadula, Tomasz --- Created attachment 38094 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38094&action=edit Preprocessed source generated by gcc -v -save-temps Unfortunately I had to compress it with gzip as the file size exceeded 1000 KB and I couldn't attach it as is.
[Bug target/70406] ICE: in extract_insn, at recog.c:2287 (unrecognizable insn) with -mtune=pentium2 -mavx512f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70406 --- Comment #3 from Kirill Yukhin --- Created attachment 38095 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38095&action=edit Bootstrapped/regtested patch Will submit to gcc-patches shortly
[Bug bootstrap/67728] Build fails when cross-compiling with in-tree GMP and ISL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67728 --- Comment #23 from Bernd Edlinger --- Hi, I tried this combination in-tree: gmp -> gmp-6.1.0 mpfr -> mpfr-3.1.3 mpc -> mpc-1.0.3 isl -> isl-1.15 While I can now reproduce the original problem, I noticed another anomaly: make check-mpc fails because it does not resolve -lmpfr make check-mpc [...] libtool: link: ( cd ".libs" && rm -f "libmpc-tests.la" && ln -s "../libmpc-tests.la" "libmpc-tests.la" ) gcc -DHAVE_CONFIG_H -I. -I../../../gcc-trunk/mpc/tests -I.. -I../../../gcc-trunk/mpc/src -I/home/ed/gnu/gcc-build/./gmp -I/home/ed/gnu/gcc-trunk/mpfr/src -g -O2 -MT tabs.o -MD -MP -MF .deps/tabs.Tpo -c -o tabs.o ../../../gcc-trunk/mpc/tests/tabs.c mv -f .deps/tabs.Tpo .deps/tabs.Po /bin/bash ../libtool --tag=CC --mode=link gcc -g -O2 -no-install -static-libstdc++ -static-libgcc -o tabs tabs.o libmpc-tests.la ../src/libmpc.la -lmpfr -lgmp -lm libtool: link: gcc -g -O2 -static-libstdc++ -static-libgcc -o tabs tabs.o ./.libs/libmpc-tests.a ../src/.libs/libmpc.a -lmpfr /home/ed/gnu/gcc-build/./gmp/.libs/libgmp.a -lm /usr/bin/ld: cannot find -lmpfr collect2: error: ld returned 1 exit status make[3]: *** [tabs] Error 1 make[3]: Leaving directory `/home/ed/gnu/gcc-build/mpc/tests' make[2]: *** [check-am] Error 2 make[2]: Leaving directory `/home/ed/gnu/gcc-build/mpc/tests' make[1]: *** [check-recursive] Error 1 make[1]: Leaving directory `/home/ed/gnu/gcc-build/mpc' make: *** [check-mpc] Error 2
[Bug preprocessor/69650] [6 Regression] ICE in linemap_line_start, at libcpp/line-map.c:803
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69650 --- Comment #37 from Jeffrey A. Law --- Author: law Date: Fri Mar 25 16:15:39 2016 New Revision: 234481 URL: https://gcc.gnu.org/viewcvs?rev=234481&root=gcc&view=rev Log: PR lto/69650 * directives.c (do_linemarker): Test for file left but not entered here. * line-map.c (linemap_add): Not here. PR lto/69650 * gcc.dg/pr69650.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr69650.c Modified: trunk/gcc/testsuite/ChangeLog trunk/libcpp/ChangeLog trunk/libcpp/directives.c trunk/libcpp/line-map.c
[Bug preprocessor/69650] [6 Regression] ICE in linemap_line_start, at libcpp/line-map.c:803
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69650 Jeffrey A. Law changed: What|Removed |Added Status|ASSIGNED|RESOLVED CC||law at redhat dot com Resolution|--- |FIXED --- Comment #38 from Jeffrey A. Law --- Fixed by Bernd's patch on the trunk.
[Bug c++/70387] -fnon-call-exceptions has no effect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70387
--- Comment #3 from jwjagersma at gmail dot com ---
Possibly interesting observation; the exception can be caught when using a
pointer as divisor:
int i = 0;
int* volatile p = &i;
try
{
std::cout << 1 / *p << std::endl;
}
catch (std::exception& e)
{
std::cout << "oops: " << e.what() << std::endl;
}
[Bug c/69415] -Wmisleading-indentation warns on "if (__b < __a) return __b; return __a;"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69415 Patrick Palka changed: What|Removed |Added CC||ppalka at gcc dot gnu.org --- Comment #13 from Patrick Palka --- (In reply to Jonathan Wakely from comment #3) > In the resipMin example the braces are on separate lines. My guess is that's > fairly uncommon, but the warning doesn't seem helpful in that case anyway: > nobody is going to think the second return is guarded by the if, because it > immediately follows another return. > > I think the returns in this example make it very different from: > > if (b) do_something(); do_something_else(); > > Also, when the entire function body is on a single line (except possibly the > braces) it's debatable whether there is any "indentation" at all, let alone > misleading indentation :-) Would it be a reasonable tradeoff then to suppress the warning if the body of the one-liner is a jump statement (return, goto, break, continue)? Note that e.g. bdwgc uses this coding style heavily and we emit a lot of false-positives about it.
[Bug c/62184] [C/C++] Extend -Wempty-body to 'while' loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62184
Patrick Palka changed:
What|Removed |Added
Status|NEW |RESOLVED
CC||ppalka at gcc dot gnu.org
Resolution|--- |FIXED
Target Milestone|--- |6.0
--- Comment #8 from Patrick Palka ---
Good news, with GCC 6's new -Wmisleading-indentation flag we emit the
appropriate warning for the test case in comment #1:
62184.C: In function ‘int foo()’:
62184.C:5:3: warning: this ‘while’ clause does not guard...
[-Wmisleading-indentation]
while (bar());
^
62184.C:6:5: note: ...this statement, but the latter is misleadingly indented
as if it is guarded by the ‘while’
sleep();
^
As for the test case in comment #6:
int main()
{
for (; 1<2; );
if (1==1);
while (1==1);
return 0;
}
We don't and arguably shouldn't warn, because none of the statements are
indented as if they're intended to be guarded by a previous one. However, we
do warn (twice) for
int main()
{
for (; 1<2; );
if (1==1);
while (1==1);
return 0;
}
So I think this PR can finally be closed.
[Bug c++/70387] -fnon-call-exceptions has no effect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70387 --- Comment #4 from jwjagersma at gmail dot com --- Created attachment 38096 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38096&action=edit Test case 2 Generic test case, which doesn't require djgpp or a DOS machine. (Assuming throwing from inline asm is similar enough) compile with: "g++ -std=gnu++14 -fnon-call-exceptions throw_from_asm.cpp"
[Bug fortran/70235] [4.9/5/6 Regression] Incorrect output with PF format
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70235 --- Comment #18 from Dominique d'Humieres --- Created attachment 38097 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38097&action=edit Patch with correct rounding With the attached patch I get the expected rounding ... -6pf18.2 y= 0.00 -5pf18.2 y= 0.01 -4pf18.2 y= 0.06 ... While I think the handling of nafter < 0 is correct, it is probably a too big hammer since the expected output should be all zeroes. TODO: (1) More testing, including the different rounding modes. (2) Add (a) test case(s).
[Bug c++/62212] [4.9/5 Regression] ICE compiling template function with array reference parameter whose size depends on a template parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62212 --- Comment #7 from Dominique d'Humieres --- Is there any reason why the test g++.dg/template/mangle2.C is "dg-do assemble" and not "dg-do compile"? This causes UNRESOLVED: g++.dg/template/mangle2.C -std=c++11 scan-assembler _Z1fIvEvRAsr1XIT_E5value_Ki because the assembly file is not saved.
[Bug c++/64266] Can GCC produce local mergeable symbols for *.__FUNCTION__ and *.__PRETTY_FUNCTION__ functions?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64266 --- Comment #3 from Jason Merrill --- Created attachment 38098 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38098&action=edit patch A simple fix is to tell varasm that it's OK to share artificial variables. I'm not sure what other effects that might have.
[Bug c++/62212] [4.9/5 Regression] ICE compiling template function with array reference parameter whose size depends on a template parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62212 --- Comment #8 from Patrick Palka --- (In reply to Dominique d'Humieres from comment #7) > Is there any reason why the test g++.dg/template/mangle2.C is "dg-do > assemble" and not "dg-do compile"? > > This causes > > UNRESOLVED: g++.dg/template/mangle2.C -std=c++11 scan-assembler > _Z1fIvEvRAsr1XIT_E5value_Ki > > because the assembly file is not saved. Sorry, will adjust it shortly.
[Bug c++/62212] [4.9/5 Regression] ICE compiling template function with array reference parameter whose size depends on a template parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62212 --- Comment #9 from Patrick Palka --- Author: ppalka Date: Fri Mar 25 18:21:44 2016 New Revision: 234482 URL: https://gcc.gnu.org/viewcvs?rev=234482&root=gcc&view=rev Log: Adjust dg-do directive in mangle2.C gcc/testsuite/ChangeLog: PR c++/62212 * g++.dg/template/mangle2.C: The dg-do directive should be "compile" not "assemble". Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/template/mangle2.C
[Bug c++/70413] New: Class template names in anonymous namespaces are not globally unique
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70413
Bug ID: 70413
Summary: Class template names in anonymous namespaces are not
globally unique
Product: gcc
Version: 5.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ers.trion at gmail dot com
Target Milestone: ---
Created attachment 38099
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38099&action=edit
Example Source Code
If a class template is defined twice with the same name inside of anonymous
namespaces in different translation units and then used as a template template
parameter, the two templates are not treated as having globally unique names.
Example:
invoke.hh:
#include
void invoke_foo(), invoke_bar();
template class T>
void invoke_print() {
T<0>{}.print();
}
foo.cc:
#include "invoke.hh"
namespace {
template struct s {
void print() { std::cout << "foo\n"; }
};
}
void invoke_foo() { invoke_print(); }
bar.cc:
#include "invoke.hh"
namespace {
template struct s {
void print() { std::cout << "bar\n"; }
};
}
void invoke_bar() { invoke_print(); }
main.cc:
#include "invoke.hh"
int main() {
invoke_foo();
invoke_bar();
}
Compile with
g++ -obug main.cc foo.cc bar.cc -std=c++11
Expected output:
foo
bar
Actual output:
foo
foo
Tested with GCC 5.3.0 on x86_64. Clang 3.7.1 gets this right.
The source files are attached.
[Bug c++/70414] New: Function declaration in other scope: type safety violation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70414
Bug ID: 70414
Summary: Function declaration in other scope: type safety
violation
Product: gcc
Version: 4.8.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: stackoverflow...@gmx-topmail.de
Target Milestone: ---
The following code compiles:
-
#include
void t(){
std::cout << "func t()" << std::endl;
}
int main(int argc, char **argv) {
int t();
std::cout << t() << std::endl;
}
-
Output:
func t()\n6295712
This should not compile in my opinion because the two function declarations are
of different type.
I'm also referring to (I asked this question):
https://stackoverflow.com/questions/36224099/violation-of-type-safety-in-c-with-function-declaration-of-other-type
[Bug c++/70414] Function declaration in other scope: type safety violation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70414 Andrew Pinski changed: What|Removed |Added Keywords||accepts-invalid --- Comment #1 from Andrew Pinski --- The front-end should have rejected this code as it is invalid.
[Bug c++/70275] -w disables all -Werror flags
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70275
Kevin Tucker changed:
What|Removed |Added
CC||kevin-tucker at cox dot net
--- Comment #1 from Kevin Tucker ---
Tried example on 5.3.0 on Cygwin and got reported results.
Found similar results for unused variable warnings with following source:
int main()
{
int i;
return 0;
}
Compiled with:
gcc -w -Werror=unused-variable -Wunused-variable unused.cpp
Gives no error
Also tried w/v6.0 (updated and built from r234482 of
svn://gcc.gnu.org/svn/gcc/trunk) and got same results.
However, I would think that if "-w" is given, then there are no warnings to
promote to errors, since warnings are disabled.
[Bug c++/64266] Can GCC produce local mergeable symbols for *.__FUNCTION__ and *.__PRETTY_FUNCTION__ functions?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64266 --- Comment #4 from Jason Merrill --- Author: jason Date: Fri Mar 25 21:29:26 2016 New Revision: 234484 URL: https://gcc.gnu.org/viewcvs?rev=234484&root=gcc&view=rev Log: PR c++/64266 PR c++/70353 Core issue 1962 * decl.c (cp_fname_init): Decay the initializer to pointer. (cp_make_fname_decl): Set DECL_DECLARED_CONSTEXPR_P, DECL_VALUE_EXPR, DECL_INITIALIZED_BY_CONSTANT_EXPRESSION_P. Don't call cp_finish_decl. * pt.c (tsubst_expr) [DECL_EXPR]: Set DECL_VALUE_EXPR, DECL_INITIALIZED_BY_CONSTANT_EXPRESSION_P. Don't call cp_finish_decl. * constexpr.c (cxx_eval_constant_expression) [VAR_DECL]: Handle DECL_VALUE_EXPR. Added: trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-__func__2.C trunk/gcc/testsuite/g++.dg/ext/fnname5.C Removed: trunk/gcc/testsuite/g++.old-deja/g++.ext/pretty4.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/constexpr.c trunk/gcc/cp/decl.c trunk/gcc/cp/pt.c
[Bug c++/70353] [5/6 regression] ICE on __PRETTY_FUNCTION__ in a constexpr function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70353 --- Comment #12 from Jason Merrill --- Author: jason Date: Fri Mar 25 21:29:26 2016 New Revision: 234484 URL: https://gcc.gnu.org/viewcvs?rev=234484&root=gcc&view=rev Log: PR c++/64266 PR c++/70353 Core issue 1962 * decl.c (cp_fname_init): Decay the initializer to pointer. (cp_make_fname_decl): Set DECL_DECLARED_CONSTEXPR_P, DECL_VALUE_EXPR, DECL_INITIALIZED_BY_CONSTANT_EXPRESSION_P. Don't call cp_finish_decl. * pt.c (tsubst_expr) [DECL_EXPR]: Set DECL_VALUE_EXPR, DECL_INITIALIZED_BY_CONSTANT_EXPRESSION_P. Don't call cp_finish_decl. * constexpr.c (cxx_eval_constant_expression) [VAR_DECL]: Handle DECL_VALUE_EXPR. Added: trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-__func__2.C trunk/gcc/testsuite/g++.dg/ext/fnname5.C Removed: trunk/gcc/testsuite/g++.old-deja/g++.ext/pretty4.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/constexpr.c trunk/gcc/cp/decl.c trunk/gcc/cp/pt.c
[Bug c++/70353] [5/6 regression] ICE on __PRETTY_FUNCTION__ in a constexpr function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70353 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work||6.0 Resolution|--- |FIXED Known to fail|6.0 | --- Comment #13 from Jason Merrill --- Fixed for 6, but the patch isn't really suitable for backporting since it's a change in behavior. Since 4.9 didn't accept the code, I'm going to close this.
[Bug c++/64266] Can GCC produce local mergeable symbols for *.__FUNCTION__ and *.__PRETTY_FUNCTION__ functions?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64266 Jason Merrill changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |6.0 --- Comment #5 from Jason Merrill --- Fixed for GCC 6.
[Bug c++/55004] [meta-bug] constexpr issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55004 Bug 55004 depends on bug 70353, which changed state. Bug 70353 Summary: [5/6 regression] ICE on __PRETTY_FUNCTION__ in a constexpr function https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70353 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug fortran/70235] [4.9/5/6 Regression] Incorrect output with PF format
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70235 --- Comment #19 from Dominique d'Humieres --- Created attachment 38100 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38100&action=edit Another patch with correct rounding > While I think the handling of nafter < 0 is correct, it is probably > a too big hammer since the expected output should be all zeroes. The attached patch does exactly that.
[Bug lto/70415] New: -Wa options should be passed to LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70415
Bug ID: 70415
Summary: -Wa options should be passed to LTO
Product: gcc
Version: 5.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: vincent.riviere at freesbee dot fr
Target Milestone: ---
Target: m68k-elf
Basically, options specified with -Wa should be used in final LTO step.
Currently, they are not passed to LTO, this can break inline assembly.
Concretely, LTO fails if inline assembly requires gas
--register-prefix-optional option.
Testcase:
$ cat bug.c
void _start(void)
{
asm("clr.l d0"); /* Note the absence of % in front of d0 */
}
$ m68k-elf-gcc -nostartfiles -nodefaultlibs -Wa,--register-prefix-optional
bug.c -o bug
# This works
$ m68k-elf-gcc -nostartfiles -nodefaultlibs -Wa,--register-prefix-optional
bug.c -o bug -flto
/tmp/ccQVzOtj.ltrans0.ltrans.o: In function `_start':
:(.text+0x6): undefined reference to `d0'
collect2: error: ld returned 1 exit status
If we add -v on the command line, we can see that --register-prefix-optional is
not passed to "as" when for the LTO pass. While it should.
[Bug rtl-optimization/68695] [6 Regression] Performance regression related to ssa patch / ifcvt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68695 Jeffrey A. Law changed: What|Removed |Added Priority|P1 |P2 CC||law at redhat dot com --- Comment #24 from Jeffrey A. Law --- I think one could easily argue here that the only reason we got good code before Alex's change is because the copyrename pass was buggy. Given something like this: # i_1 = PHI Where x & a are parameters and i is a local, all of type int. The copyrename pass would ignore the fact that x & a were promoted to DImode while i was SImode Alex's work exposed this as problematical in general and the suggested fix was to not coalesce with the promoted modes were different. I don't think this deserves to be a release blocker, but I do think we can continue to look at either improving things on the RTL side, or finding a safe set of cases where we can coalesce even when the promotions are different.
[Bug target/70120] [6 Regression][aarch64] -g causes Assembler messages: Error: unaligned opcodes detected in executable segment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70120 --- Comment #10 from Jeffrey A. Law --- Author: law Date: Fri Mar 25 23:37:13 2016 New Revision: 234486 URL: https://gcc.gnu.org/viewcvs?rev=234486&root=gcc&view=rev Log: 2016-03-25 Richard Henderson PR target/70120 * config/aarch64/aarch64.c (aarch64_asm_output_pool_epilogue): New. * config/aarch64/aarch64-protos.h: Declare it. * config/aarch64/aarch64.h (ASM_OUTPUT_POOL_EPILOGUE): New. PR target/70120 * gcc.target/aarch64/pr70120-1.c: New. * gcc.target/aarch64/pr70120-2.c: New. * gcc.target/aarch64/pr70120-3.c: New. Added: trunk/gcc/testsuite/gcc.target/aarch64/pr70120-1.c trunk/gcc/testsuite/gcc.target/aarch64/pr70120-2.c trunk/gcc/testsuite/gcc.target/aarch64/pr70120-3.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/aarch64/aarch64-protos.h trunk/gcc/config/aarch64/aarch64.c trunk/gcc/config/aarch64/aarch64.h trunk/gcc/testsuite/ChangeLog
[Bug target/70120] [6 Regression][aarch64] -g causes Assembler messages: Error: unaligned opcodes detected in executable segment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70120 Jeffrey A. Law changed: What|Removed |Added Status|ASSIGNED|RESOLVED CC||law at redhat dot com Resolution|--- |FIXED --- Comment #11 from Jeffrey A. Law --- Fixed by rth's patch which I committed to the trunk.
[Bug fortran/70235] [4.9/5/6 Regression] Incorrect output with PF format
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70235 --- Comment #20 from Jerry DeLisle --- (In reply to Dominique d'Humieres from comment #19) > Created attachment 38100 [details] > Another patch with correct rounding > > > While I think the handling of nafter < 0 is correct, it is probably > > a too big hammer since the expected output should be all zeroes. > > The attached patch does exactly that. Nice work!
[Bug c++/64372] [DR1560] Gratuitous lvalue-to-rvalue conversion in conditional-expression with throw-expression operand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64372
hs changed:
What|Removed |Added
CC||hs at xmission dot com
--- Comment #8 from hs ---
I wanted to bump this bug and supply a simpler test-case:
void blah(int&) {}
int main() {
int i{};
blah(true ? i : throw);
}
result with gcc 6.0:
prog.cc: In function 'int main()':
prog.cc:6:15: error: invalid initialization of non-const reference of type
'int&' from an rvalue of type 'int'
blah(true ? i : throw 0);
~^
prog.cc:2:6: note: initializing argument 1 of 'void blah(int&)'
void blah(int&) {}
^~~~
[Bug libstdc++/61582] C++11 regex memory corruption
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61582 Tim Shen changed: What|Removed |Added CC||bisqwit at iki dot fi --- Comment #18 from Tim Shen --- *** Bug 70411 has been marked as a duplicate of this bug. ***
[Bug libstdc++/70411] Stack overflow with std::regex_match
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70411 Tim Shen changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||timshen at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #2 from Tim Shen --- This is a known issue. I have a plan to fix it, but it's not going to be in GCC 6. Thanks for reporting! *** This bug has been marked as a duplicate of bug 61582 ***
[Bug target/70319] [6 Regression] FAIL: gcc.dg/sso/q2.c -O1 -fno-inline execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70319 Jeffrey A. Law changed: What|Removed |Added Status|NEW |RESOLVED CC||law at redhat dot com Resolution|--- |FIXED --- Comment #14 from Jeffrey A. Law --- Fixed by John's commit on the trunk.
[Bug target/69331] [6 regression] FAIL: 20_util/shared_ptr/thread/default_weaktoshared.cc execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69331 Jeffrey A. Law changed: What|Removed |Added Priority|P4 |P3 CC||law at redhat dot com --- Comment #7 from Jeffrey A. Law --- Bumping up to P3 given it's showing up on multiple targets.
[Bug fortran/70031] Error in recursive module subroutine declaration if declared as "module recursive"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70031 Jeffrey A. Law changed: What|Removed |Added Status|NEW |RESOLVED CC||law at redhat dot com Resolution|--- |FIXED --- Comment #3 from Jeffrey A. Law --- Fixed on the trunk a couple weeks ago.
[Bug fortran/69524] [6 Regression] [F08] Compiler segfaults on "module subroutine"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69524 Jeffrey A. Law changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #10 from Jeffrey A. Law --- Fixed on the trunk a couple weeks ago.
[Bug c/70389] uint_16t left shift with -Wconversion produces incorrect warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70389 --- Comment #2 from Bob Meyers --- Does the most recent C spec actually say that short unsigned ints should be promoted to signed ints prior to a left shift? (But somehow "x++" just increments the short unsigned int x with no such implicit conversion, and so does not trigger the same -Wconversion error.) That seems inconsistent, but if it's true, then this is correct behavior. Thanks for the comment.
[Bug fortran/69043] Trying to include a directory causes an infinite loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69043 Jerry DeLisle changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Jerry DeLisle --- Closing
