[Bug c++/69864] Narrowing conversion warning instead of an error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69864
--- Comment #5 from mgsergio ---
And what about the inconsistency with compilation error on
int main() {
int b{2.3};
}
In that case an error is generated.
And if I use
template
inline T narrowing_check(U const u)
{
return {u};
}
I get a warning.
#include
using namespace std;
int main() {
int b{2.3};
(void)b;
return 0;
}
g++-5 -std=c++11 1.cc
1.cc: In function 'int main()':
1.cc:5:12: error: narrowing conversion of '2.2998e+0' from 'double'
to 'int' inside { } [-Wnarrowing]
int b{2.3};
^
[Bug target/69671] [6 Regression] FAIL: gcc.target/i386/avx512vl-vpmovqb-1.c scan-assembler-times vpmovqb[ \\t]+[^{\n]*%ymm[0-9]+[^\n]*%xmm[0-9]+{%k[1-7]}{z}(?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69671 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #27 from Jakub Jelinek --- Fixed.
[Bug target/66337] __alignof__(s.d) incorrect for a double member with -malign-power
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66337 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #6 from Jakub Jelinek --- I actually don't see any bug here, what makes you think the ABI can't enforce bigger alignment on structs as whole over their first element? If the struct will then contain some more aligned member, that is obviously true, but the ABI might enforce extra alignment on structs say for performance reasons etc. In any case, changing the ABI just because you don't like __alignof__ output is broken.
[Bug c++/69864] Narrowing conversion warning instead of an error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69864
--- Comment #6 from Jonathan Wakely ---
Because int b{2.3} absolutely definitely loses precision, and since it's a
constant you can just fix the code.
For {u} the compiler doesn't know whether it really narrows or not, since it
depends on un time values, so it gives you the benefit of the doubt.
The standard only requires a "diagnostic" for ill-formed code, and both
warnings and errors are diagnostics.
You can use https://gcc.gnu.org/onlinedocs/gcc/Diagnostic-Pragmas.html to
enable -Werror=narrowing just for your narrowing_check function if that's what
you want.
[Bug c++/69865] -trigraphs option broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69865 --- Comment #7 from Jonathan Wakely --- (In reply to Bernd Edlinger from comment #1) > weird: > If I add -std=c++14 (or any other c++ version, including -ansi) > to the command line, it works. As documented in the manual: -trigraphs Support ISO C trigraphs. The -ansi option (and -std options for strict ISO C conformance) implies -trigraphs. Since the default is -std=gnu++14, -trigraphs is not enabled by default.
[Bug lto/69866] lto1: internal compiler error: in add_symbol_to_partition_1, at lto/lto-partition.c:158
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69866 Richard Biener changed: What|Removed |Added Keywords||lto Target||arm-none-eabi Status|UNCONFIRMED |WAITING Last reconfirmed||2016-02-19 Component|c |lto Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Can you try a recent snapshot and provide a testcase please?
[Bug c++/69865] -trigraphs option broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69865 --- Comment #8 from Bernd Edlinger --- (In reply to Jonathan Wakely from comment #7) > (In reply to Bernd Edlinger from comment #1) > > weird: > > If I add -std=c++14 (or any other c++ version, including -ansi) > > to the command line, it works. > > As documented in the manual: > >-trigraphs >Support ISO C trigraphs. The -ansi option (and -std options for >strict ISO C conformance) implies -trigraphs. > > Since the default is -std=gnu++14, -trigraphs is not enabled by default. Yes, but -trigraphs does not work, unless you explicictly add -std=gnu++14 -trigraphs to the command line. Same for -fno-extended-identifiers, it is overwritten in line 805. and the handling of flag_gnu89_inline uses the flag_isoc99 which is not defined correctly here.
[Bug rtl-optimization/60818] ICE in validate_condition_mode on powerpc*-linux-gnu*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60818 Segher Boessenkool changed: What|Removed |Added CC||segher at gcc dot gnu.org Component|target |rtl-optimization --- Comment #6 from Segher Boessenkool --- It's a combine bug. I am testing a patch.
[Bug c++/69851] [6 Regression] ICE: in assign_temp, at function.c:961
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69851 --- Comment #5 from Jakub Jelinek --- Created attachment 37738 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37738&action=edit gcc6-pr69851.patch Untested fix.
[Bug libgomp/69625] S/390 deadlock in libgomp.c/doacross-1.c test (vararg function trashes r6)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69625 --- Comment #4 from Andreas Krebbel --- Author: krebbel Date: Fri Feb 19 10:15:43 2016 New Revision: 233546 URL: https://gcc.gnu.org/viewcvs?rev=233546&root=gcc&view=rev Log: S/390: PR 69625: Add test case gcc/testsuite/ChangeLog PR target/69625 * gcc.target/s390/pr69625.c: Add test case. Added: trunk/gcc/testsuite/gcc.target/s390/pr69625.c Modified: trunk/gcc/testsuite/ChangeLog
[Bug fortran/69870] ICE while detecting undeclared parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69870 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Dominique d'Humieres --- Duplicate of pr69064 comment 47. *** This bug has been marked as a duplicate of bug 69064 ***
[Bug fortran/69064] [5/6 Regression] ICE: in gfc_typenode_for_spec, at fortran/trans-types.c:1062 when LEN is set to a variable with no explicit type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69064 Dominique d'Humieres changed: What|Removed |Added CC||jwmwalrus at gmail dot com --- Comment #52 from Dominique d'Humieres --- *** Bug 69870 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/69871] New: Type punned structs returned by value optimized poorly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69871
Bug ID: 69871
Summary: Type punned structs returned by value optimized poorly
Product: gcc
Version: 5.3.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: rf at rufflewind dot com
Target Milestone: ---
The following code, which unpacks a 32-bit integer into a struct of four bytes,
does not optimize as well as it should. While "unpack" seems to optimize just
fine, trivial wrappers of the function do not seem to get optimized nearly as
well:
- Two of the wrappers ("wrapper", "wrapper2") are completely identical yet they
do not result in the same assembly code. One is optimized well, the other is
not.
- Adding another layer of indirection ("wrapperwrapper") also prevents the
optimization from occurring.
The problem occurs not only for union-based type-punning, but also for similar
tricks that involve:
- memcpy, where all three wrappers would optimize poorly, or
- bitshift operators, where even "unpack" would optimize poorly.
See also: https://gcc.gnu.org/ml/gcc/2016-02/msg00244.html
The code was compiled with "gcc -fverbose-asm -Wall -S -O3 foo.c" on Linux
4.4.1 x86-64. The GCC binaries are part of the Arch Linux's gcc-multilib
5.3.0-4 binary package.
---
struct alpha {
char a, b, c, d;
};
struct alpha unpack(unsigned x)
{
union {
struct alpha r;
unsigned i;
} u;
u.i = x;
return u.r;
}
struct alpha wrapper(unsigned y)
{
return unpack(y);
}
struct alpha wrapper2(unsigned y)
{
return unpack(y);
}
struct alpha wrapperwrapper(unsigned y)
{
return wrapper(y);
}
---
.file "foo.c"
# GNU C11 (GCC) version 5.3.0 (x86_64-unknown-linux-gnu)
# compiled by GNU C version 5.3.0, GMP version 6.1.0, MPFR version
3.1.3-p5, MPC version 1.0.3
# GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
# options passed: foo.c -mtune=generic -march=x86-64 -O3 -Wall
# -fverbose-asm
# options enabled: -faggressive-loop-optimizations -falign-labels
# -fasynchronous-unwind-tables -fauto-inc-dec -fbranch-count-reg
# -fcaller-saves -fchkp-check-incomplete-type -fchkp-check-read
# -fchkp-check-write -fchkp-instrument-calls -fchkp-narrow-bounds
# -fchkp-optimize -fchkp-store-bounds -fchkp-use-static-bounds
# -fchkp-use-static-const-bounds -fchkp-use-wrappers
# -fcombine-stack-adjustments -fcommon -fcompare-elim -fcprop-registers
# -fcrossjumping -fcse-follow-jumps -fdefer-pop
# -fdelete-null-pointer-checks -fdevirtualize -fdevirtualize-speculatively
# -fdwarf2-cfi-asm -fearly-inlining -feliminate-unused-debug-types
# -fexpensive-optimizations -fforward-propagate -ffunction-cse -fgcse
# -fgcse-after-reload -fgcse-lm -fgnu-runtime -fgnu-unique
# -fguess-branch-probability -fhoist-adjacent-loads -fident -fif-conversion
# -fif-conversion2 -findirect-inlining -finline -finline-atomics
# -finline-functions -finline-functions-called-once
# -finline-small-functions -fipa-cp -fipa-cp-alignment -fipa-cp-clone
# -fipa-icf -fipa-icf-functions -fipa-icf-variables -fipa-profile
# -fipa-pure-const -fipa-ra -fipa-reference -fipa-sra -fira-hoist-pressure
# -fira-share-save-slots -fira-share-spill-slots
# -fisolate-erroneous-paths-dereference -fivopts -fkeep-static-consts
# -fleading-underscore -flifetime-dse -flra-remat -flto-odr-type-merging
# -fmath-errno -fmerge-constants -fmerge-debug-strings
# -fmove-loop-invariants -fomit-frame-pointer -foptimize-sibling-calls
# -foptimize-strlen -fpartial-inlining -fpeephole -fpeephole2
# -fpredictive-commoning -fprefetch-loop-arrays -free -freg-struct-return
# -freorder-blocks -freorder-blocks-and-partition -freorder-functions
# -frerun-cse-after-loop -fsched-critical-path-heuristic
# -fsched-dep-count-heuristic -fsched-group-heuristic -fsched-interblock
# -fsched-last-insn-heuristic -fsched-rank-heuristic -fsched-spec
# -fsched-spec-insn-heuristic -fsched-stalled-insns-dep -fschedule-fusion
# -fschedule-insns2 -fsemantic-interposition -fshow-column -fshrink-wrap
# -fsigned-zeros -fsplit-ivs-in-unroller -fsplit-wide-types -fssa-phiopt
# -fstdarg-opt -fstrict-aliasing -fstrict-overflow
# -fstrict-volatile-bitfields -fsync-libcalls -fthread-jumps
# -ftoplevel-reorder -ftrapping-math -ftree-bit-ccp -ftree-builtin-call-dce
# -ftree-ccp -ftree-ch -ftree-coalesce-vars -ftree-copy-prop
# -ftree-copyrename -ftree-cselim -ftree-dce -ftree-dominator-opts
# -ftree-dse -ftree-forwprop -ftree-fre -ftree-loop-distribute-patterns
# -ftree-loop-if-convert -ftree-loop-im -ftree-loop-ivcanon
# -ftree-loop-optimize -ftree-loop-vectorize -ftree-parallelize-loops=
# -ftree-partial-pre -ftree-phiprop -ftree-pre -ftree-pta -ftree-reassoc
# -ftree-scev-cprop -ftree-sink -ftree-slp-vectorize -ftree-slsr -ftree-sra
# -ftree-switch-conversion -ftree-tail-merge -ftree-ter -ftree-vrp
# -funit-at-a-ti
[Bug lto/69866] lto1: internal compiler error: in add_symbol_to_partition_1, at lto/lto-partition.c:158
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69866 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org --- Comment #2 from Martin Liška --- Issue with ChibiOS was already discussed a bit in: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65380#c17 Where a reproducer script uses a base metal compiler. Martin
[Bug regression/69838] [4.9/5/6 Regression] Lra deletes EH_REGION
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69838
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2016-02-19
CC||jakub at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #4 from Jakub Jelinek ---
I think the regression is since r199754 when LRA got enabled on s390x.
Anyway, this is reproduceable even in C++ (if one looks at the RTL dumps, not
as an executable testcase) with -O2 -fexceptions -fnon-call-exceptions:
int
foo ()
{
try
{
*(int *)0 = 1;
}
catch (...)
{
return 1;
}
return 0;
}
The difference between reload and LRA is that reload reloads:
(insn 7 2 30 2 (set (mem:SI (const_int 0 [0]) [2 MEM[(int *)0B]+0 S4 A64])
(const_int 1 [0x1])) a.c:6 67 {*movsi_zarch}
(expr_list:REG_EH_REGION (const_int 1 [0x1])
(nil)))
as:
(insn 62 2 7 2 (set (reg:SI 1 %r1)
(const_int 1 [0x1])) a.c:6 67 {*movsi_zarch}
(nil))
(insn 7 62 30 2 (set (mem:SI (const_int 0 [0]) [2 MEM[(int *)0B]+0 S4 A64])
(reg:SI 1 %r1)) a.c:6 67 {*movsi_zarch}
(expr_list:REG_EH_REGION (const_int 1 [0x1])
(nil)))
i.e. the memory store is the original instruction and preserves the
REG_EH_REGION note on it, while lra reloads it as:
(insn 7 2 61 2 (set (reg:SI 1 %r1 [50])
(const_int 1 [0x1])) a.c:6 67 {*movsi_zarch}
(nil))
(insn 61 7 3 2 (set (mem:SI (const_int 0 [0]) [2 MEM[(int *)0B]+0 S4 A64])
(reg:SI 1 %r1 [50])) a.c:6 67 {*movsi_zarch}
(expr_list:REG_DEAD (reg:SI 1 %r1 [50])
(nil)))
where the original insn doesn't contain the MEM anymore, and the new one does.
Perhaps LRA should check if the insn it is reloading contains REG_EH_REGION
note, and if yes, for all the reloading instructions it has added for the insn
check if they might trap and if yes, copy (or move) the REG_EH_REGION note(s)
to them.
[Bug target/69706] internal compiler error: in extract_constrain_insn, at recog.c:2246
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69706 --- Comment #8 from Eric Botcazou --- > I'm leaning towards fixing both the ICE and the ABI bug. OK, let's do that for GCC 6 then and document it, thanks.
[Bug middle-end/69838] [4.9/5/6 Regression] Lra deletes EH_REGION
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69838 Jakub Jelinek changed: What|Removed |Added Component|regression |middle-end --- Comment #5 from Jakub Jelinek --- Seems except.c has already copy_reg_eh_region_note_forward and copy_reg_eh_region_note_backward functions for this purpose and reload1.c uses them.
[Bug middle-end/69838] [4.9/5/6 Regression] Lra deletes EH_REGION
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69838
--- Comment #6 from Jakub Jelinek ---
Created attachment 37739
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37739&action=edit
gcc6-pr69838.patch
Untested fix. Don't have ada set up on s390{,x}, so can just test this on
x86_64.
[Bug c++/69864] Narrowing conversion warning instead of an error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69864 --- Comment #7 from Jonathan Wakely --- (In reply to Manuel López-Ibáñez from comment #4) > (In reply to Jakub Jelinek from comment #3) > > Or use -pedantic-errors. > > I find it a bit ironic that Clang does inform the user when something is > accepted as a GNU extension, but *GNU* GCC does not clarify this. Perhaps > the pedwarn below would be clearer with something like? The example in this testcase doesn't trigger a pedwarn, and accepting it is not a GNU extension. GCC's behaviour here is standard conforming. There are some other narrowing conversions that do get a pedwarn, but I'm not sure exactly which conditions trigger that. In any case, adding a "this is an extension" note to diagnostics should be its own PR.
[Bug c++/69872] New: Wnarrowing note without warning/errror
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69872
Bug ID: 69872
Summary: Wnarrowing note without warning/errror
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: manu at gcc dot gnu.org
Target Milestone: ---
struct s { int x, y; };
short offsets[1] = {
((char*) &(((struct s*)16)->y) - (char *)16), // { dg-message "narrowing" ""
{ target c++11 } }
};
$ g++ prog.cc -Wall -Wextra -std=gnu++1z -pedantic "-Wno-narrowing"
prog.cc:3:34: note: the expression has a constant value but is not a C++
constant-expression
((char*) &(((struct s*)16)->y) - (char *)16), // { dg-message "narrowing" ""
{ target c++11 } }
~~~^
[Bug c++/69864] Fix various Wnarrowing minor issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69864
Manuel López-Ibáñez changed:
What|Removed |Added
Keywords||diagnostic, documentation,
||easyhack
Status|RESOLVED|UNCONFIRMED
Resolution|DUPLICATE |---
Summary|Narrowing conversion|Fix various Wnarrowing
|warning instead of an error |minor issues
--- Comment #8 from Manuel López-Ibáñez ---
(In reply to Jonathan Wakely from comment #6)
> Because int b{2.3} absolutely definitely loses precision, and since it's a
> constant you can just fix the code.
>
> For {u} the compiler doesn't know whether it really narrows or not, since it
> depends on un time values, so it gives you the benefit of the doubt.
I updated the FAQ, but I actually agree with mgsergio that this behavior is
inconsistent and not at all how other -Wflags behave. The fact that we have to
do ugly kludges in the code to support this makes it only more obvious.
I'm actually going to reopen this to propose some improvements that perhaps
someone would decide to tackle as easy hacks:
* Document that -Wnarrowing also emits errors in doc/invoke.texi
* Make the message for the error and the warning different, for example:
narrowing conversion of constant expression from 'double' to 'int' inside { }
* Do not pretty-print expressions! '2.2998e+0' is very ugly and I'm
sure one can easily trick GCC to print absolute non-sense. That is, remove %qE
and use proper locations/ranges.
* Create a new function in diagnostic.c, e.g.,
extern diagnostic_t pederror (location_t, int, const char *, ...)
ATTRIBUTE_GCC_DIAG(3,4);
and replace the kludge in cp/typeck2.c with it (possibly fixing PR69872 along
the way). Document when some warnings might be errors (like we have precise
definitions for permerror/pedwarn).
[Bug c++/69864] Fix various Wnarrowing minor issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69864
--- Comment #9 from Markus Trippelsdorf ---
(In reply to Manuel López-Ibáñez from comment #8)
> (In reply to Jonathan Wakely from comment #6)
> > Because int b{2.3} absolutely definitely loses precision, and since it's a
> > constant you can just fix the code.
> >
> > For {u} the compiler doesn't know whether it really narrows or not, since it
> > depends on un time values, so it gives you the benefit of the doubt.
>
> I updated the FAQ, but I actually agree with mgsergio that this behavior is
> inconsistent and not at all how other -Wflags behave. The fact that we have
> to do ugly kludges in the code to support this makes it only more obvious.
>
> I'm actually going to reopen this to propose some improvements that perhaps
> someone would decide to tackle as easy hacks:
>
> * Document that -Wnarrowing also emits errors in doc/invoke.texi
>
> * Make the message for the error and the warning different, for example:
>
> narrowing conversion of constant expression from 'double' to 'int' inside { }
>
> * Do not pretty-print expressions! '2.2998e+0' is very ugly and
> I'm sure one can easily trick GCC to print absolute non-sense. That is,
> remove %qE and use proper locations/ranges.
>
> * Create a new function in diagnostic.c, e.g.,
>
> extern diagnostic_t pederror (location_t, int, const char *, ...)
> ATTRIBUTE_GCC_DIAG(3,4);
>
> and replace the kludge in cp/typeck2.c with it (possibly fixing PR69872
> along the way). Document when some warnings might be errors (like we have
> precise definitions for permerror/pedwarn).
The kludges are there because gcc used to emit an error even with
-Wno-narrowing.
That broke tons of existing C++ code. There is such a thing as QOI and that
means you have to use a compromise sometimes.
[Bug tree-optimization/69871] Type punned structs returned by value optimized poorly due to SRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69871 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-02-19 Summary|Type punned structs |Type punned structs |returned by value optimized |returned by value optimized |poorly |poorly due to SRA Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Confirmed also on x86_64. It's SRA messing things up - it possibly should take into account whether args / return values will end up in registers or not [maybe we should re-write those in to SSA in some way].
[Bug c++/69864] Fix various Wnarrowing minor issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69864
--- Comment #10 from Manuel López-Ibáñez ---
(In reply to Markus Trippelsdorf from comment #9)
> > * Create a new function in diagnostic.c, e.g.,
> >
> > extern diagnostic_t pederror (location_t, int, const char *, ...)
> > ATTRIBUTE_GCC_DIAG(3,4);
> >
> > and replace the kludge in cp/typeck2.c with it (possibly fixing PR69872
> > along the way). Document when some warnings might be errors (like we have
> > precise definitions for permerror/pedwarn).
>
> The kludges are there because gcc used to emit an error even with
> -Wno-narrowing.
> That broke tons of existing C++ code. There is such a thing as QOI and that
> means you have to use a compromise sometimes.
This is the kludge I'm talking about:
{
int savederrorcount = errorcount;
global_dc->pedantic_errors = 1;
pedwarn (loc, OPT_Wnarrowing,
"narrowing conversion of %qE from %qT to %qT "
"inside { }", init, ftype, type);
if (errorcount == savederrorcount)
ok = true;
global_dc->pedantic_errors = flag_pedantic_errors;
}
I'm just suggesting to created a pederror function to hide this uglyness and
make such "diagnostics mandated by the standard for which we give an error but
allow the user to downgrade to a warning" a properly defined and consistently
behaved function before it extends by copy-pasting.
[Bug tree-optimization/69873] New: Vectorizer fails to emit runtime profitability check if no peeling/versioning is done
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69873
Bug ID: 69873
Summary: Vectorizer fails to emit runtime profitability check
if no peeling/versioning is done
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: rguenth at gcc dot gnu.org
Target Milestone: ---
double a[1024];
void foo (unsigned n)
{
for (unsigned i = 0; i < n * 2; ++i)
a[i] = 1.;
}
currently says the threshold is > 3 iterations but no such guard is added
(whether that's a reasonable threshold is another question of course).
[Bug tree-optimization/69873] Vectorizer fails to emit runtime profitability check if no peeling/versioning is done
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69873
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2016-02-19
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
Ever confirmed|0 |1
--- Comment #1 from Richard Biener ---
Created attachment 37740
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37740&action=edit
patch
Patch fixing this. Also fixing some incosistencies in cost estimation which
unfortunately "improves" the threshold to > 6 iterations.
Issues with the cost model include the odd separation between taken vs.
not-taken
branch cost (as opposed to fallthru, not fallthru or well predicted vs. not
predicted). This artificially raises the cost of the vectorized path (on
x86_64
generic model, vectorized path has a "taken" branch of cost 3 while
unvectorized
has an "not taken" branch of cost 1).
Another issue is the prologue cost for emitting the vector double constant
{ 1., 1. }. The scalar version also has a constant pool entry but we assume
none exist for the scalar path - reasonable only if insns with immediate forms
are available which IMHO is not reasonable to assume for FP modes. This skews
the cost by one.
If you disable cunroll then generated code is
cmpl$6, %edi
jbe .L3
subl$2, %edi
movapd .LC0(%rip), %xmm0
shrl%edi
xorl%eax, %eax
leal1(%rdi), %ecx
.L4:
movq%rax, %rdx
addq$1, %rax
salq$4, %rdx
cmpl%eax, %ecx
movaps %xmm0, a(%rdx)
ja .L4
rep ret
.L3:
movsd .LC1(%rip), %xmm0
xorl%eax, %eax
.L6:
movsd %xmm0, a(,%rax,8)
addq$1, %rax
cmpl%eax, %edi
ja .L6
.L1:
rep ret
so the stupid IV choice makes the runtime check reasonable.
[Bug tree-optimization/69873] Vectorizer fails to emit runtime profitability check if no peeling/versioning is done
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69873 --- Comment #2 from Richard Biener --- ICC decides to have a cut-off at 8 iterations, having an unrolled vectorized iteration ..B1.4: # Preds ..B1.4 ..B1.3 addl $8, %eax #4.3 movaps%xmm0, a(,%rdx,8) #5.5 cmpl %ecx, %eax#4.3 movaps%xmm0, 16+a(,%rdx,8) #5.5 movaps%xmm0, 32+a(,%rdx,8) #5.5 movaps%xmm0, 48+a(,%rdx,8) #5.5 movl %eax, %edx#4.3 jb..B1.4 with a shared scalar epilogue (shared with the non-vectorized path) ..B1.8: # Preds ..B1.8 ..B1.7 incl %edx #4.3 movq %rax, a(,%rcx,8) #5.5 incl %ecx #4.3 cmpl %edi, %edx#4.3 jb..B1.8 where at least that scalar loop with two IVs looks sub-optimal. This also shows that unrolling from within the vectorizer might be more profitable than doing it afterwards (generating an additional vectorized epilogue for the remaining vectorized iterations). Code-size wise, of course.
[Bug target/66337] __alignof__(s.d) incorrect for a double member with -malign-power
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66337 David Edelsohn changed: What|Removed |Added Target|powerpc*-*-*-* |powerpc*-*-* --- Comment #7 from David Edelsohn --- I agree that changing the alignment to make the __alignof__ output happy is wrong. The "bug" is __alignof__ output on XLC and GCC are different, despite the actual alignment of the structure and member. The ADJUST_FIELD_ALIGN computation is correct and I don't believe that GCC structure layout provides control to describe the alignment of the first member different than other members of a structure.
[Bug tree-optimization/69820] [6 Regression] Test miscompiled with -O3 option
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69820 --- Comment #12 from Jakub Jelinek --- Author: jakub Date: Fri Feb 19 13:42:38 2016 New Revision: 233558 URL: https://gcc.gnu.org/viewcvs?rev=233558&root=gcc&view=rev Log: PR target/69820 * config/i386/sse.md (VI_512): Only include V64QImode and V32HImode if TARGET_AVX512BW. * gcc.target/i386/pr69820.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr69820.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/sse.md trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/69820] [6 Regression] Test miscompiled with -O3 option
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69820 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #13 from Jakub Jelinek --- Fixed.
[Bug c++/69864] Fix various Wnarrowing minor issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69864 --- Comment #11 from Jonathan Wakely --- (In reply to Manuel López-Ibáñez from comment #8) > I'm actually going to reopen this to propose some improvements that perhaps > someone would decide to tackle as easy hacks: > > * Document that -Wnarrowing also emits errors in doc/invoke.texi Patch: https://gcc.gnu.org/ml/gcc-patches/2016-02/msg01326.html
[Bug middle-end/69838] [4.9/5/6 Regression] Lra deletes EH_REGION
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69838 --- Comment #7 from Dominik Vogt --- With the patch I get an Ice with -m31: spawn -ignore SIGHUP .../build/gcc/xgcc -B.../build/gcc/ .../gcc/testsuite/gcc.dg/graphite/id-pr45230-1.c -fno-diagnostics-show-caret -fdiagnostics-color=never -O2 -fgraphite-identity -ffast-math -S -m31 -o id-pr45230-1.s^M .../gcc/testsuite/gcc.dg/graphite/id-pr45230-1.c: In function 'main':^M /home/vogt/src/git/gcc/gcc/testsuite/gcc.dg/graphite/id-pr45230-1.c:45:1: internal compiler error: Segmentation fault^M 0x806199b9 crash_signal^M ../../gcc/toplev.c:335^M 0x80a55d06 translate_isl_ast_to_gimple::collect_all_ssa_names(tree_node*, vec*)^M ../../gcc/graphite-isl-ast-to-gimple.c:1408^M 0x80a55d51 translate_isl_ast_to_gimple::collect_all_ssa_names(tree_node*, vec*)^M ../../gcc/graphite-isl-ast-to-gimple.c:1418^M 0x80a55d51 translate_isl_ast_to_gimple::collect_all_ssa_names(tree_node*, vec*)^M ../../gcc/graphite-isl-ast-to-gimple.c:1418^M 0x80a55d51 translate_isl_ast_to_gimple::collect_all_ssa_names(tree_node*, vec*)^M ../../gcc/graphite-isl-ast-to-gimple.c:1418^M 0x80a5748b translate_isl_ast_to_gimple::rename_all_uses(tree_node*, basic_block\ _def*, basic_block_def*)^M ../../gcc/graphite-isl-ast-to-gimple.c:1569^M 0x80a57631 translate_isl_ast_to_gimple::get_rename_from_scev(tree_node*, gimple\ **, loop*, basic_block_def*, basic_block_def*, vec\ )^M ../../gcc/graphite-isl-ast-to-gimple.c:1623^M 0x80a597a1 translate_isl_ast_to_gimple::rename_uses(gimple*, gimple_stmt_iterat\ or*, basic_block_def*, loop*, vec)^M ../../gcc/graphite-isl-ast-to-gimple.c:1730^M 0x80a5b06d translate_isl_ast_to_gimple::graphite_copy_stmts_from_block(basic_b\ lock_def*, basic_block_def*, vec)^M ../../gcc/graphite-isl-ast-to-gimple.c:2596^M 0x80a5b5eb translate_isl_ast_to_gimple::copy_bb_and_scalar_dependences(basic_bl\ ock_def*, edge_def*, vec)^M ../../gcc/graphite-isl-ast-to-gimple.c:2809^M 0x80a5bbf5 translate_isl_ast_to_gimple::translate_isl_ast_node_user(isl_ast_nod\ e*, edge_def*, std::map, std::allocator\ > >&)^M ../../gcc/graphite-isl-ast-to-gimple.c:935^M 0x80a5bf95 translate_isl_ast_to_gimple::translate_isl_ast_for_loop(loop*, isl_a\ st_node*, edge_def*, tree_node*, tree_node*, tree_node*, std::map, std::allocator\ > >&)^M ../../gcc/graphite-isl-ast-to-gimple.c:685^M 0x80a5c217 translate_isl_ast_to_gimple::translate_isl_ast_node_for(loop*, isl_a\ st_node*, edge_def*, std::map, std::all\ ocator > >&)^M ../../gcc/graphite-isl-ast-to-gimple.c:854^M 0x80a5beb1 translate_isl_ast_to_gimple::translate_isl_ast(loop*, isl_ast_node*,\ edge_def*, std::map, std::allocator > >&)^M ../../gcc/graphite-isl-ast-to-gimple.c:1032^M 0x80a5c359 translate_isl_ast_to_gimple::translate_isl_ast_node_block(loop*, isl\ _ast_node*, edge_def*, std::map, std::a\ llocator > >&)^M ../../gcc/graphite-isl-ast-to-gimple.c:964^M 0x80a5be69 translate_isl_ast_to_gimple::translate_isl_ast(loop*, isl_ast_node*,\ edge_def*, std::map, std::allocator > >&)^M ../../gcc/graphite-isl-ast-to-gimple.c:1043^M 0x80a5c359 translate_isl_ast_to_gimple::translate_isl_ast_node_block(loop*, isl\ _ast_node*, edge_def*, std::map, std::a\ llocator > >&)^M ../../gcc/graphite-isl-ast-to-gimple.c:964^M 0x80a5be69 translate_isl_ast_to_gimple::translate_isl_ast(loop*, isl_ast_node*,\ edge_def*, std::map, std::allocator > >&)^M ../../gcc/graphite-isl-ast-to-gimple.c:1043^M 0x80a5c359 translate_isl_ast_to_gimple::translate_isl_ast_node_block(loop*, isl\ _ast_node*, edge_def*, std::map, std::a\ llocator > >&)^M ../../gcc/graphite-isl-ast-to-gimple.c:964^M 0x80a5be69 translate_isl_ast_to_gimple::translate_isl_ast(loop*, isl_ast_node*,\ edge_def*, std::map, std::allocator > >&)^M ../../gcc/graphite-isl-ast-to-gimple.c:1043^M
[Bug middle-end/69838] [4.9/5/6 Regression] Lra deletes EH_REGION
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69838 --- Comment #8 from Jakub Jelinek --- (In reply to Dominik Vogt from comment #7) > With the patch I get an Ice with -m31: > > spawn -ignore SIGHUP .../build/gcc/xgcc -B.../build/gcc/ > .../gcc/testsuite/gcc.dg/graphite/id-pr45230-1.c -fno-diagnostics-show-caret > -fdiagnostics-color=never -O2 -fgraphite-identity -ffast-math -S -m31 -o > id-pr45230-1.s^M > .../gcc/testsuite/gcc.dg/graphite/id-pr45230-1.c: In function 'main':^M > /home/vogt/src/git/gcc/gcc/testsuite/gcc.dg/graphite/id-pr45230-1.c:45:1: > internal compiler error: Segmentation fault^M > 0x806199b9 crash_signal^M > ../../gcc/toplev.c:335^M > 0x80a55d06 translate_isl_ast_to_gimple::collect_all_ssa_names(tree_node*, > vec
[Bug middle-end/56888] memcpy implementation optimized as a call to memcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56888 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #35 from Richard Biener --- Let's try "fixing" this finally for GCC 6. Still waiting for Honza for comment #27 (lets put that in a symtab->equal_to (enum built_in_function) function). Similar issue is present for malloc + memset -> calloc.
[Bug middle-end/69838] [4.9/5/6 Regression] Lra deletes EH_REGION
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69838 --- Comment #9 from Dominik Vogt --- I think I've already tested this commit without the patch and did not get that Ice, but maybe my memory fails me. I'm just running the test suite again with the commit reverted to make sure ...
[Bug middle-end/69838] [4.9/5/6 Regression] Lra deletes EH_REGION
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69838 --- Comment #10 from Uroš Bizjak --- (In reply to Dominik Vogt from comment #7) > With the patch I get an Ice with -m31: > > spawn -ignore SIGHUP .../build/gcc/xgcc -B.../build/gcc/ > .../gcc/testsuite/gcc.dg/graphite/id-pr45230-1.c -fno-diagnostics-show-caret > -fdiagnostics-color=never -O2 -fgraphite-identity -ffast-math -S -m31 -o > id-pr45230-1.s^M > .../gcc/testsuite/gcc.dg/graphite/id-pr45230-1.c: In function 'main':^M > /home/vogt/src/git/gcc/gcc/testsuite/gcc.dg/graphite/id-pr45230-1.c:45:1: > internal compiler error: Segmentation fault^M > 0x806199b9 crash_signal^M > ../../gcc/toplev.c:335^M This is known issue, PR 68659. Also fails on i686 [1]. [1] https://gcc.gnu.org/ml/gcc-testresults/2016-02/msg02008.html
[Bug c++/69874] New: Program crashes when an exception is thrown to second base class reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69874
Bug ID: 69874
Summary: Program crashes when an exception is thrown to second
base class reference
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: blocker
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: maysam.kind at gmail dot com
Target Milestone: ---
I tried the following code using several GCCs and got problems when I run the
code which is compiled using O1 with gcc4.7.1 and onward.
#include
#include
struct Interface_1
{
virtual void setA() = 0;
};
struct Interface_2
{
virtual void setB() = 0;
};
struct Master: Interface_1, Interface_2
{
void setA()
{
throw std::runtime_error("I was thrown");
}
void setB()
{
throw std::runtime_error("I was thrown");
}
};
int main()
{
Master m;
Interface_2& i2 = m;
try
{
i2.setB();
}
catch (const std::runtime_error& e)
{
std::cout << "Caught exception e=" << e.what() << std::endl;
}
catch (...)
{
std::cout << "Did not catch exception" << std::endl;
}
std::cout << "Done running" << std::endl;
}
In the code above I am a reference from interface Interface_2 to refer to an
object from Master class, and this will result into a crash
terminate called after throwing an instance of 'std::runtime_error'
what(): I was thrown
Abort (core dumped)
But it works if I use a reference from Interface_1:
int main()
{
Master m;
Interface_1& i1 = m;
try
{
i1.setA();
}
catch (const Exception& e)
{
std::cout << "Caught exception e=" << e.what() << std::endl;
}
catch (...)
{
std::cout << "Did not catchexception" << std::endl;
}
std::cout << "Done running" << std::endl;
}
I just get what is expected:
Caught exception e=I was thrown
Done running
It seems that the first interface that I inherit from can just be used to refer
to a object from Master class. I also made the inheritance from the first
interface as follows:
class Master: public virtual Interface_1, public Interface_2
Then references from Interface_2 just turned out to be fine. Instead, I got
problem with references from Interface_1.
[Bug middle-end/69838] [4.9/5/6 Regression] Lra deletes EH_REGION
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69838 --- Comment #11 from Dominik Vogt --- If that is unrelated, the patch does not cause any regressions on a biarch build. Sould I also test it in a 31-bit changeroot?
[Bug middle-end/69838] [4.9/5/6 Regression] Lra deletes EH_REGION
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69838 --- Comment #12 from Dominik Vogt --- (The test just finished; the Ice is present without the patch too.)
[Bug target/69875] [4.9/5/6 Regression] Wrong barrier placement for 64-bit atomic loads on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69875 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2016-02-19 Assignee|unassigned at gcc dot gnu.org |ktkachov at gcc dot gnu.org Target Milestone|--- |4.9.5 Ever confirmed|0 |1 Known to fail||4.9.4, 5.3.1, 6.0 --- Comment #1 from ktkachov at gcc dot gnu.org --- Mine.
[Bug target/69875] New: [4.9/5/6 Regression] Wrong barrier placement for 64-bit atomic loads on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69875
Bug ID: 69875
Summary: [4.9/5/6 Regression] Wrong barrier placement for
64-bit atomic loads on arm
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: ktkachov at gcc dot gnu.org
Target Milestone: ---
Target: arm*
Consider the code:
#include
atomic_ullong foo;
int glob;
int
main (void)
{
atomic_load_explicit (&foo, memory_order_acquire);
return glob;
}
Compiled for arm with flags -O2 -S -march=armv7ve --std=c11 this generates:
movwr3, #:lower16:glob
movtr3, #:upper16:glob
dmb ish
movwr2, #:lower16:foo
movtr2, #:upper16:foo
ldrexd r0, r1, [r2]
ldr r0, [r3]
bx lr
This is wrong for the acquire memory order. The barrier DMB should go after the
LDREXD. Furthermore, for armv7ve we should be able to relax the LDREXD into an
LDRD.
The same code is generated for -march=armv7-a, armv7ve and armv8-a.
But for armv8-a we should be able to make use of the load-double-word-acquire
instruction LDAEXD and avoid the barrier.
So there is wrong-code and missed-optimization and occurs on all currently
maintained branches.
[Bug tree-optimization/69042] [6 regression] Missed optimization in ivopts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69042 --- Comment #8 from amker at gcc dot gnu.org --- Though adding candidate with offset stripped from base helps this case, it causes other regressions which I need to understand.
[Bug sanitizer/69840] two ASAN help nits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69840 --- Comment #1 from Martin Liška --- Created attachment 37741 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37741&action=edit Patch draft I've tried to sketch-up a simple patch that can do that. As the original source of the modified code is in LLVM project (which is merged to GCC), please create a PR in LLVM and I'll try to apply to patch to current LLVM trunk. The patch can be send eventually. Martin
[Bug c++/67767] -Wsuggest-attribute=noreturn suggests noreturn for function which already has noreturn and cold.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67767 --- Comment #4 from Jakub Jelinek --- Author: jakub Date: Fri Feb 19 16:01:50 2016 New Revision: 233560 URL: https://gcc.gnu.org/viewcvs?rev=233560&root=gcc&view=rev Log: PR c++/67767 * parser.c (cp_parser_std_attribute_spec_seq): Don't assume attr_spec is always single element chain, chain all the attributes properly together in the right order. * g++.dg/cpp0x/pr67767.C: New test. Added: trunk/gcc/testsuite/g++.dg/cpp0x/pr67767.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/testsuite/ChangeLog
[Bug c++/69850] [6 Regression] unnecessary -Wnonnull-compare warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69850 --- Comment #17 from Jakub Jelinek --- Author: jakub Date: Fri Feb 19 16:02:51 2016 New Revision: 233561 URL: https://gcc.gnu.org/viewcvs?rev=233561&root=gcc&view=rev Log: PR c++/69850 * init.c (build_vec_delete_1): Set TREE_NO_WARNING on the NE_EXPR condition. * cp-gimplify.c (cp_fold): Propagate TREE_NO_WARNING from binary operators if folding preserved the binop, just with different arguments. * g++.dg/warn/Wnonnull-compare-2.C: New test. * g++.dg/warn/Wnonnull-compare-3.C: New test. Added: trunk/gcc/testsuite/g++.dg/warn/Wnonnull-compare-2.C trunk/gcc/testsuite/g++.dg/warn/Wnonnull-compare-3.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-gimplify.c trunk/gcc/cp/init.c trunk/gcc/testsuite/ChangeLog
[Bug middle-end/69876] New: Offloaded code: missing -Wuninitialized diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69876
Bug ID: 69876
Summary: Offloaded code: missing -Wuninitialized diagnostic
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Keywords: openacc, openmp
Severity: minor
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: tschwinge at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
Target Milestone: ---
Found in the course of PR69858. Consider:
int f(void)
{
int x;
#pragma omp target map(from:x)
x++;
return x;
}
Compiling with -fno-openmp, we get the expected -Wuninitialized diagnostic:
w.c:5:4: warning: 'x' is used uninitialized in this function
[-Wuninitialized]
x++;
~^~
Compiling with -fopenmp, we don't get the -Wuninitialized diagnostic.
[Bug middle-end/69876] Offloaded code: missing -Wuninitialized diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69876
--- Comment #1 from Jakub Jelinek ---
Sure. But there is the other case, say
int x;
#pragma omp target defaultmap(tofrom: scalar) // explicit or implicit
map(tofrom:x)
{
x = 6;
}
This is similar to shared clause on parallel or task etc.; where we often need
to pass a value, even when we don't know if it will be used uninitialized or
not. Better not to warn in that case IMHO.
So I'd say if we want to warn, we would need to perform some post-SSA IPA
analysis of the outlined regions together with the original functions.
[Bug libgomp/69858] OpenACC no free memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69858 Thomas Schwinge changed: What|Removed |Added Keywords||openacc Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID Assignee|unassigned at gcc dot gnu.org |tschwinge at gcc dot gnu.org --- Comment #1 from Thomas Schwinge --- As I understand it, the issue is that when using a copyout(pi) clause, the value of the pi variable in the device memory is undefined (is not initialized), whereas when using a copy(pi) clause, the value from the host (0.0f) will be copied to the device. The way your code is laid out, however, it expects pi to be initialized to zero. And then, as you write, 'the GPU memory "remembers" the result', because of using the same memory location for pi in each run, which happened to have an initial value of zero, but 3.14[...] after the first run, and so on. There should be a warning about the uninitialized use of pi on the device; I filed PR69876 for that. I'm closing this, but please re-open if you don't agree with my reasoning.
[Bug middle-end/69838] [4.9/5/6 Regression] Lra deletes EH_REGION
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69838 --- Comment #13 from Jakub Jelinek --- Author: jakub Date: Fri Feb 19 16:25:58 2016 New Revision: 233562 URL: https://gcc.gnu.org/viewcvs?rev=233562&root=gcc&view=rev Log: PR middle-end/69838 * lra.c (lra_process_new_insns): If non-call exceptions are enabled, call copy_reg_eh_region_note_forward on before and/or after sequences and remove note from insn if it no longer can throw. Modified: trunk/gcc/ChangeLog trunk/gcc/lra.c
[Bug c++/69874] Program crashes when an exception is thrown to second base class reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69874 Jonathan Wakely changed: What|Removed |Added Severity|blocker |normal
[Bug middle-end/69838] [4.9/5 Regression] Lra deletes EH_REGION
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69838 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Summary|[4.9/5/6 Regression] Lra|[4.9/5 Regression] Lra |deletes EH_REGION |deletes EH_REGION --- Comment #14 from Jakub Jelinek --- Should be fixed on the trunk now.
[Bug c++/69874] Program crashes when an exception is thrown to second base class reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69874 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2016-02-19 Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- Please provide the information requested by https://gcc.gnu.org/bugs.html
[Bug tree-optimization/69666] [5/6 Regression] gcc ICE at -O2 and -O3 on valid code on x86_64-linux-gnu in "verify_gimple failed"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69666 --- Comment #6 from Martin Jambor --- I have proposed a fix on the mailing list: https://gcc.gnu.org/ml/gcc-patches/2016-02/msg01349.html
[Bug rtl-optimization/69806] [6 Regression][SH] Combine doesn't see constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69806 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P4 CC||jakub at gcc dot gnu.org --- Comment #5 from Jakub Jelinek --- I think you should bisect it to the exact commit. The only combine.c change in that range is r233159, but there is e.g. r233133 cse.c change too etc.
[Bug c++/69874] Program crashes when an exception is thrown to second base class reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69874 --- Comment #2 from Andrew Pinski --- (In reply to Jonathan Wakely from comment #1) > Please provide the information requested by https://gcc.gnu.org/bugs.html Mainly which target is this on? Since there is a self contained example already in comment #0.
[Bug c++/69874] Program crashes when an exception is thrown to second base class reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69874 Markus Trippelsdorf changed: What|Removed |Added Status|WAITING |NEW CC||trippels at gcc dot gnu.org Known to work||5.3.1, 6.0 Known to fail||4.9.3 --- Comment #3 from Markus Trippelsdorf --- Confirmed. markus@x4 /tmp % /usr/x86_64-pc-linux-gnu/gcc-bin/4.9.3/g++ -O2 ex.cpp markus@x4 /tmp % ./a.out terminate called after throwing an instance of 'std::runtime_error' what(): I was thrown [1]19864 abort ./a.out markus@x4 /tmp % /usr/x86_64-pc-linux-gnu/gcc-bin/5.3.1/g++ -O2 ex.cpp markus@x4 /tmp % ./a.out Caught exception e=I was thrown Done running markus@x4 /tmp % /usr/x86_64-pc-linux-gnu/gcc-bin/6.0.0/g++ -O2 ex.cpp markus@x4 /tmp % ./a.out Caught exception e=I was thrown Done running
[Bug c++/68948] G++ voluntarily removes a function call with terrible side effects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68948 --- Comment #14 from Patrick Palka --- Author: ppalka Date: Fri Feb 19 17:04:29 2016 New Revision: 233563 URL: https://gcc.gnu.org/viewcvs?rev=233563&root=gcc&view=rev Log: Adjust fix PR c++/68948 gcc/cp/ChangeLog: PR c++/68948 * pt.c (tsubst_baselink): Don't diagnose an invalid constructor call here. * semantics.c (finish_call_expr): Don't assume a constructor call is dependent if only the "this" pointer is dependent. When building a constructor call, always use a dummy object. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c trunk/gcc/cp/semantics.c
[Bug c++/68948] G++ voluntarily removes a function call with terrible side effects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68948 Patrick Palka changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #15 from Patrick Palka --- Fixed for GCC 6.
[Bug c++/69874] Program crashes when an exception is thrown to second base class reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69874
--- Comment #4 from Markus Trippelsdorf ---
Program received signal SIGABRT, Aborted.
0x777d50d8 in __GI_raise (sig=sig@entry=6) at
../sysdeps/unix/sysv/linux/raise.c:54
54return INLINE_SYSCALL (tgkill, 3, pid, selftid, sig);
(gdb) bt
#0 0x777d50d8 in __GI_raise (sig=sig@entry=6) at
../sysdeps/unix/sysv/linux/raise.c:54
#1 0x777d6d7d in __GI_abort () at abort.c:89
#2 0x77ec1425 in __gnu_cxx::__verbose_terminate_handler() () from
/usr/lib/gcc/x86_64-pc-linux-gnu/6.0.0/libstdc++.so.6
#3 0x77ebefc6 in __cxxabiv1::__terminate(void (*)()) () from
/usr/lib/gcc/x86_64-pc-linux-gnu/6.0.0/libstdc++.so.6
#4 0x77ebf031 in std::terminate() () from
/usr/lib/gcc/x86_64-pc-linux-gnu/6.0.0/libstdc++.so.6
#5 0x77ebf2a7 in __cxa_throw () from
/usr/lib/gcc/x86_64-pc-linux-gnu/6.0.0/libstdc++.so.6
#6 0x00400e58 in Master::setB (this=) at ex.cpp:14
#7 0x00400c5f in main () at ex.cpp:21
Unfortunately the stack gets corrupted with 4.9.3/libstdc++.so.6.0.20:
markus@x4 /tmp %
LD_PRELOAD=/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/libstdc++.so.6.0.20 gdb
./a.out
Reading symbols from ./a.out...done.
(gdb) run
Starting program: /var/tmp/tmp/a.out
Program received signal SIGSEGV, Segmentation fault.
_dl_lookup_symbol_x (undef_name=0x77aba4d3 "__tls_get_addr",
undef_map=0x77ff65e0, ref=ref@entry=0x7fffe260,
symbol_scope=0x77ff6938,
version=0x77fd0f60, type_class=type_class@entry=1, flags=1,
skip_map=0x0) at dl-lookup.c:809
809 struct sym_val current_value = { NULL, NULL };
(gdb) bt
#0 _dl_lookup_symbol_x (undef_name=0x77aba4d3 "__tls_get_addr",
undef_map=0x77ff65e0, ref=ref@entry=0x7fffe260,
symbol_scope=0x77ff6938,
version=0x77fd0f60, type_class=type_class@entry=1, flags=1,
skip_map=0x0) at dl-lookup.c:809
#1 0x77de6534 in _dl_fixup (l=, reloc_arg=) at ../elf/dl-runtime.c:111
#2 0x77deef5f in _dl_runtime_resolve_sse () at
../sysdeps/x86_64/dl-trampoline.h:112
#3 0x77afa78c in __cxa_get_globals () from
/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/libstdc++.so.6.0.20
#4 0x77afbdb6 in __cxa_throw () from
/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/libstdc++.so.6.0.20
#5 0x00400e58 in Master::setB (this=) at ex.cpp:14
#6 0x00400c5f in main () at ex.cpp:21
[Bug c++/69874] Program crashes when an exception is thrown to second base class reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69874 Markus Trippelsdorf changed: What|Removed |Added CC||hjl.tools at gmail dot com --- Comment #5 from Markus Trippelsdorf --- Ah the misalignment will be fixed for 4.9.4, PR58066. H.J.: sysdeps/x86_64/dl-trampoline.S says: 23 #ifndef DL_STACK_ALIGNMENT 24 /* Due to GCC bug: 25 26https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58066 27 28__tls_get_addr may be called with 8-byte stack alignment. Although 29this bug has been fixed in GCC 4.9.4, 5.3 and 6, we can't assume 30that stack will be always aligned at 16 bytes. We use unaligned 3116-byte move to load and store SSE registers, which has no penalty 32on modern processors if stack is 16-byte aligned. */ 33 # define DL_STACK_ALIGNMENT 8 34 #endif 35 36 #ifndef DL_RUNIME_UNALIGNED_VEC_SIZE 37 /* The maximum size of unaligned vector load and store. */ 38 # define DL_RUNIME_UNALIGNED_VEC_SIZE 16 39 #endif 40 41 /* True if _dl_runtime_resolve should align stack to VEC_SIZE bytes. */ 42 #define DL_RUNIME_RESOLVE_REALIGN_STACK \ 43 (VEC_SIZE > DL_STACK_ALIGNMENT \ 44&& VEC_SIZE > DL_RUNIME_UNALIGNED_VEC_SIZE) this apparently doesn't work for _dl_runtime_resolve_sse.
[Bug target/69810] PowerPC64: unrecognizable insn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69810 David Edelsohn changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-02-19 CC||dje at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from David Edelsohn --- confirmed
[Bug middle-end/69838] [4.9/5 Regression] Lra deletes EH_REGION
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69838 Dominik Vogt changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #15 from Dominik Vogt --- Successfully tested and bootstrapped trunk on s390x (biarch).
[Bug middle-end/69838] [4.9/5 Regression] Lra deletes EH_REGION
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69838 Jakub Jelinek changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #16 from Jakub Jelinek --- I wanted to keep this open for possible backports to 5.x and 4.9.x.
[Bug c++/69874] Program crashes when an exception is thrown to second base class reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69874 H.J. Lu changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #6 from H.J. Lu --- Please open a glibc bug instead.
[Bug c++/69874] Program crashes when an exception is thrown to second base class reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69874 Markus Trippelsdorf changed: What|Removed |Added Status|RESOLVED|NEW Resolution|INVALID |--- --- Comment #7 from Markus Trippelsdorf --- Will do. But lets reopen this bug for the original issue.
[Bug preprocessor/69126] [6 regression] _Pragma does not apply if part of a macro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69126
David Malcolm changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #25 from David Malcolm ---
Stephan provided me with a tarball of his reproducer (thanks!), and I'm able to
reproduce this locally.
The root cause is a bug in linemap_compare_locations.
(gdb) call inform (pre, "pre")
test.cc:8:16: note: pre
#define IGNORE _Pragma("GCC diagnostic ignored \"-Wdeprecated-declarations\"")
^
test.cc:8:16: note: in definition of macro ‘IGNORE’
#define IGNORE _Pragma("GCC diagnostic ignored \"-Wdeprecated-declarations\"")
^~~
(gdb) call inform (post, "post")
test.cc:12:5: note: post
f();
^
After macro expansion, we have (at the end of linemap_compare_locations):
(gdb) p /x l0
$13 = 0x800101ec
(gdb) p /x l1
$14 = 0x50684c05
and hence:
(gdb) p /x l1 - l0
$23 = 0xd0674a19
it's effectively negative, and so before_p is false.
But this is wrong: l0 is an ad-hoc loc, whereas l1 is a non-ad-hoc loc.
It's clearly insane to treat all ad-hoc locations as being later than all
non-ad-hoc locations. The fix is simple: resolve ads-hoc locations at the end
of linemap_compare_locations.
For this bug to occur, we need a location for the macro name that's an ad-hoc
location, and a location for the diagnostic that's *not* an ad-hoc location.
The reason it triggered for Stephan is that the sheer quantity of code in his
reproducer meant that both locations in question were above
LINE_MAP_MAX_LOCATION_WITH_PACKED_RANGES (but below
LINE_MAP_MAX_LOCATION_WITH_COLS), so range-packing was disabled, in particular
for the "IGNORE" macro.
I can reproduce it trivially by using a macro name that's >=32 characters (thus
forcing the use of an ad-hoc location):
/* { dg-options "-Wdeprecated-declarations" } */
#define IGNORE_WHERE_MACRO_IS_LONGER_THAN_31_CHARS _Pragma("GCC diagnostic
ignored \"-Wdeprecated-declarations\"")
__attribute__((deprecated)) void f();
int main() {
IGNORE_WHERE_MACRO_IS_LONGER_THAN_31_CHARS
f();
}
I have a patch that seems to work for this test case; am testing it more
thoroughly now.
[Bug testsuite/69573] FAIL: gcc.dg/pr61053.c (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69573 --- Comment #16 from Martin Sebor --- Author: msebor Date: Fri Feb 19 18:37:40 2016 New Revision: 233564 URL: https://gcc.gnu.org/viewcvs?rev=233564&root=gcc&view=rev Log: PR testsuite/69573 - FAIL: gcc.dg/pr61053.c (test for excess errors) Tested on x86_64 by running make check-c with RUNTESTFLAGS='--target_board=unix/-m32/-m128bit-long-double dg.exp=pr61053.c' gcc/testsuite/ChangeLog: 2016-01-30 Martin Sebor PR testsuite/69573 * gcc.dg/pr61053.c: Tweaked test to avoid bogus failures. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/pr61053.c
[Bug testsuite/69573] FAIL: gcc.dg/pr61053.c (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69573 Martin Sebor changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #17 from Martin Sebor --- Patch committed in r233564.
[Bug c++/69851] [6 Regression] ICE: in assign_temp, at function.c:961
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69851 --- Comment #6 from Jakub Jelinek --- Author: jakub Date: Fri Feb 19 19:11:58 2016 New Revision: 233566 URL: https://gcc.gnu.org/viewcvs?rev=233566&root=gcc&view=rev Log: PR c++/69851 * expr.c (store_field): Don't use bit-field path if exp is COMPONENT_REF with TREE_ADDRESSABLE type, where TYPE_SIZE is different from bitsize, but DECL_SIZE of FIELD_DECL is bitsize and the assignment can be performed by bitwise copy. Formatting fix. * g++.dg/torture/pr69851.C: New test. Added: trunk/gcc/testsuite/g++.dg/torture/pr69851.C Modified: trunk/gcc/ChangeLog trunk/gcc/expr.c trunk/gcc/testsuite/ChangeLog
[Bug c++/69850] [6 Regression] unnecessary -Wnonnull-compare warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69850 --- Comment #18 from Jakub Jelinek --- Author: jakub Date: Fri Feb 19 19:16:31 2016 New Revision: 233568 URL: https://gcc.gnu.org/viewcvs?rev=233568&root=gcc&view=rev Log: PR c++/69850 * rtti.c (ifnonnull): Set TREE_NO_WARNING on the condition, use NE_EXPR instead of EQ_EXPR and swap last two arguments on COND_EXPR. * g++.dg/warn/Wnonnull-compare-4.C: New test. Added: trunk/gcc/testsuite/g++.dg/warn/Wnonnull-compare-4.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/rtti.c trunk/gcc/testsuite/ChangeLog
[Bug c++/69851] [6 Regression] ICE: in assign_temp, at function.c:961
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69851 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from Jakub Jelinek --- Fixed.
[Bug c++/69850] [6 Regression] unnecessary -Wnonnull-compare warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69850 Jakub Jelinek changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #19 from Jakub Jelinek --- Fixed. If you encounter some other -Wnonnull-compare false positive, please file a new PR.
[Bug c++/68679] [5/6 Regression] gcc-5.2.1 ICE in C++11 anon union of structs with template fns, OK in gcc <= 4.9.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68679 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Jason Merrill --- Fixed.
[Bug c++/68585] [5/6 Regression] c++14 code accepted by 4.9 not accepted by 5 and 6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68585 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Jason Merrill --- Fixed.
[Bug libstdc++/69877] New: Problem with std::basic_ios::setstate()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69877
Bug ID: 69877
Summary: Problem with std::basic_ios::setstate()
Product: gcc
Version: 5.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: lcarreon at bigpond dot net.au
Target Milestone: ---
I created the following simple test program:
#include
#include
int main()
{
std::ostringstream vStream;
vStream.exceptions(std::ios_base::badbit);
vStream.setstate(std::ios_base::badbit);
return 0;
}
I then compiled and linked it on 64-bit Fedora 23 using the following commands:
g++ -ansi -c -g -m64 -o sample.o -Wall -Werror -std=c++14 sample.cpp
g++ -g -m64 -o sample sample.o
When I execute the resulting executable, it generates the following output:
terminate called after throwing an instance of 'std::ios_base::failure'
what(): basic_ios::clear
./sample.sh: line 3: 3397 Aborted (core dumped) ./sample
Please notice that the executable core dumped. Even if I try to catch the
exception, it still core dumps. If I remember correctly, this did not happen
on Fedora 22 which included g++ 5.1.1.
Do you have an idea why this is happening? The above problem is causing my
user defined type's stream insertion/extraction operators to fail.
[Bug c++/69864] Fix various Wnarrowing minor issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69864 --- Comment #12 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #11) > Patch: https://gcc.gnu.org/ml/gcc-patches/2016-02/msg01326.html Committed to trunk.
[Bug libstdc++/69877] Problem with std::basic_ios::setstate()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69877 --- Comment #1 from Leo Carreon --- In addition, if I comment out the line: vStream.exceptions(std::ios_base::badbit); The executable does not core dump.
[Bug libstdc++/66145] [5/6 Regression] std::ios_base::failure objects thrown from libstdc++.so use old ABI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66145 Jonathan Wakely changed: What|Removed |Added CC||lcarreon at bigpond dot net.au --- Comment #9 from Jonathan Wakely --- *** Bug 69877 has been marked as a duplicate of this bug. ***
[Bug libstdc++/69877] Problem with std::basic_ios::setstate()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69877 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Jonathan Wakely --- (In reply to Leo Carreon from comment #0) > Please notice that the executable core dumped. Even if I try to catch the > exception, it still core dumps. If I remember correctly, this did not > happen on Fedora 22 which included g++ 5.1.1. No, an unhandled exception results in abort() which always dumped core. That hasn't changed. The reason you can't catch it is that the library throws std::ios::failure but you try to catch std::__cxx11::ios::failure, due to the default ABI changing in F23. If you compile with -D_GLIBCXX_USE_CXX11_ABI=0 then you'll be able to refer to the old exception type, but that changes the ABI. The fact the old ABI exception is thrown is PR66145. *** This bug has been marked as a duplicate of bug 66145 ***
[Bug libstdc++/69877] Problem with std::basic_ios::setstate()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69877 --- Comment #3 from Jonathan Wakely --- (In reply to Leo Carreon from comment #1) > In addition, if I comment out the line: > > vStream.exceptions(std::ios_base::badbit); > > The executable does not core dump. Yes, obviously. If you don't ask the stream to throw an exception when the badbit is set in the stream's state, then it won't throw an exception when you set the badbit.
[Bug rtl-optimization/69806] [6 Regression][SH] Combine doesn't see constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69806 Segher Boessenkool changed: What|Removed |Added CC||segher at gcc dot gnu.org --- Comment #6 from Segher Boessenkool --- r233159 was reverted in r233356. Does this problem still happen?
[Bug c/69878] New: GCC produces pessimal assembly for C11 atomic increments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69878
Bug ID: 69878
Summary: GCC produces pessimal assembly for C11 atomic
increments
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: matt at bitbashing dot io
Target Milestone: ---
Consider the following test case:
#include
atomic_int foo;
void plusPlus(void)
{
foo++;
}
void fetchAdd(void)
{
atomic_fetch_add(&foo, 1);
}
The assembly for plusPlus and fetchAdd should be the same,
since the two perform the same operation.
However, GCC 5.3 with -O2 -c yields:
:
0: 8b 05 00 00 00 00 mov0x0(%rip),%eax# 6
6: 66 2e 0f 1f 84 00 00nopw %cs:0x0(%rax,%rax,1)
d: 00 00 00
10: 89 44 24 fc mov%eax,-0x4(%rsp)
14: 8d 50 01lea0x1(%rax),%edx
17: 8b 44 24 fc mov-0x4(%rsp),%eax
1b: f0 0f b1 15 00 00 00lock cmpxchg %edx,0x0(%rip)# 23
22: 00
23: 75 eb jne10
25: f3 c3 repz retq
27: 66 0f 1f 84 00 00 00nopw 0x0(%rax,%rax,1)
2e: 00 00
0030 :
30: f0 83 05 00 00 00 00lock addl $0x1,0x0(%rip)# 38
37: 01
38: c3 retq
It seems like instead of a "simple" atomic increment, foo++ does the following:
1. Atomically load the value (with full sequential consistency).
2. Increment
3. Compare and swap the original value (with full sequential consistency).
4. If the CAS didn't take, go to step 1.
While this produces the desired effect (atomically adding one),
there's obviously much more going on than there should be,
and the extra memory barriers around each step are probably quite unfriendly
to performance (especially if there are several threads accessing the value).
The problem exists on ARM as well (where I originally discovered this issue),
so it doesn't seem to be target dependent:
:
0: b510push{r4, lr}
2: 4a0fldr r2, [pc, #60] ; (40 )
4: f3bf 8f5f dmb sy
8: b082sub sp, #8
a: ac02add r4, sp, #8
c: 6813ldr r3, [r2, #0]
e: f3bf 8f5f dmb sy
12: f844 3d04 str.w r3, [r4, #-4]!
16: 1c58addsr0, r3, #1
18: 6821ldr r1, [r4, #0]
1a: f3bf 8f5f dmb sy
1e: e852 3f00 ldrex r3, [r2]
22: 428bcmp r3, r1
24: d104bne.n 30
26: e842 0e00 strex lr, r0, [r2]
2a: f1be 0f00 cmp.w lr, #0
2e: d1f6bne.n 1e
30: f3bf 8f5f dmb sy
34: d101bne.n 3a
36: b002add sp, #8
38: bd10pop {r4, pc}
3a: 6023str r3, [r4, #0]
3c: e7ebb.n 16
3e: bf00nop
40: .word 0x
0044 :
44: 4b06ldr r3, [pc, #24] ; (60 )
46: f3bf 8f5f dmb sy
4a: e853 2f00 ldrex r2, [r3]
4e: 3201addsr2, #1
50: e843 2100 strex r1, r2, [r3]
54: 2900cmp r1, #0
56: d1f8bne.n 4a
58: f3bf 8f5f dmb sy
5c: 4770bx lr
5e: bf00nop
60: .word 0x
(compiled using arm-none-eabi-gcc version 5.3 with -O2 -mthumb -mcpu=cortex-m4)
What's curious is that the C++ frontend doesn't seem to have this problem.
With g++ -std=c++11 -O2 -c and the equivalent C++:
#include
std::atomic_int foo;
void plusPlus()
{
foo++;
}
void fetchAdd()
{
foo.fetch_add(1);
}
the compiler recognizes it's the same and implements one as a jump to the
other:
:
0: f0 83 05 00 00 00 00lock addl $0x1,0x0(%rip)# 8
7: 01
8: c3 retq
9: 0f 1f 80 00 00 00 00nopl 0x0(%rax)
0010 :
10: e9 00 00 00 00 jmpq 15
Clang also generates the same code for both (using clang and clang++):
:
0: f0 ff 05 00 00 00 00lock incl 0x0(%rip)# 7
7: c3 retq
8: 0f 1f 84 00 00 00 00nopl 0x0(%rax,%rax,1)
f: 00
0010 :
10: f0 ff 05 00 00 00 00lock incl 0x0(%rip)# 17
17: c3 retq
Obligatory information:
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-unknown-linux-gnu/5.3.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /build/gcc-multilib/src/gcc-5-20160209/configure --prefix=/usr
--libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared
--enable-threads=posix --enable-libmpx --with-system-zlib
[Bug libstdc++/69879] New: Create a pointer to the default operator new and delete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69879
Bug ID: 69879
Summary: Create a pointer to the default operator new and
delete
Product: gcc
Version: 5.2.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: daniel.gutson at tallertechnologies dot com
Target Milestone: ---
This issue comes from the following discussion:
https://gcc.gnu.org/ml/libstdc++/2015-11/msg9.html
In short: Pedro Alves suggested as a solution the addition of a pointer to the
original (default) operator new and another for the operator delete, e.g.
__default_operator_new and __default_operator_delete.
This will allow users to override the global operators new and delete, and yet
call the original implementations, for example to alter the behavior when there
is no memory and the nothrow new should not iterate calling the new_handler.
// Example 1:
void* operator new ( std::size_t count, const std::nothrow_t& tag)
noexcept(true)
{
const auto old_handler = std::set_new_handler(nullptr);
const auto ret = __default_operator_new(count, tag);
std::set_new_handler(old_handler);
return ret;
}
// Slightly different example:
void* operator new ( std::size_t count, const std::nothrow_t& tag)
noexcept(true)
{
const auto old_handler = std::set_new_handler(nullptr);
const auto ret = __default_operator_new(count, tag);
std::set_new_handler(old_handler);
if (ret == nullptr && old_handler != nullptr)
old_handler();
return ret;
}
Please assign this to aurelio.remo...@tallertechnologies.com
[Bug c++/69826] problem with cilkplus pragma and preprocessor variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69826 --- Comment #8 from Jakub Jelinek --- Author: jakub Date: Fri Feb 19 22:12:54 2016 New Revision: 233571 URL: https://gcc.gnu.org/viewcvs?rev=233571&root=gcc&view=rev Log: PR c++/69826 * c-pragma.c (c_pp_lookup_pragma): Handle PRAGMA_CILK_GRAINSIZE. (init_pragma): Register PRAGMA_CILK_GRAINSIZE even for flag_preprocess_only. * c-c++-common/cilk-plus/CK/pr69826-1.c: New test. * c-c++-common/cilk-plus/CK/pr69826-2.c: New test. Added: trunk/gcc/testsuite/c-c++-common/cilk-plus/CK/pr69826-1.c trunk/gcc/testsuite/c-c++-common/cilk-plus/CK/pr69826-2.c Modified: trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c-pragma.c trunk/gcc/testsuite/ChangeLog
[Bug c++/69826] problem with cilkplus pragma and preprocessor variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69826 --- Comment #9 from Jakub Jelinek --- Fixed on the trunk so far.
[Bug driver/69805] [6 Regression] ICE in greater_than_spec_func, at gcc.c:9722
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69805 --- Comment #7 from Jakub Jelinek --- Author: jakub Date: Fri Feb 19 22:18:38 2016 New Revision: 233573 URL: https://gcc.gnu.org/viewcvs?rev=233573&root=gcc&view=rev Log: PR driver/69805 * gcc.c (LINK_COMMAND_SPEC, GOMP_SELF_SPECS): Use :%* in %:gt() argument. (greater_than_spec_func): Adjust for expecting only numbers, if there are more than two numbers, compare the last two. * testsuite/libgomp.c/pr69805.c: New test. Added: trunk/libgomp/testsuite/libgomp.c/pr69805.c Modified: trunk/gcc/ChangeLog trunk/gcc/gcc.c trunk/libgomp/ChangeLog
[Bug c/68908] inefficient code for _Atomic operations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68908 Jakub Jelinek changed: What|Removed |Added CC||matt at bitbashing dot io --- Comment #18 from Jakub Jelinek --- *** Bug 69878 has been marked as a duplicate of this bug. ***
[Bug c/69878] GCC produces pessimal assembly for C11 atomic increments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69878 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jakub at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #1 from Jakub Jelinek --- Dup of PR68908. *** This bug has been marked as a duplicate of bug 68908 ***
[Bug c++/69865] -trigraphs option broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69865 --- Comment #9 from Bernd Edlinger --- Author: edlinger Date: Fri Feb 19 22:22:04 2016 New Revision: 233574 URL: https://gcc.gnu.org/viewcvs?rev=233574&root=gcc&view=rev Log: gcc/c-family/ChangeLog: 2016-02-19 Bernd Edlinger PR c++/69865 * c-opts.c (c_common_post_options): Move call to set_std_cxx14 from here... (c_common_init_options): ...to here. (set_std_cxx98): Initialize flag_isoc94 and flag_isoc99. gcc/testsuite/ChangeLog: 2016-02-19 Bernd Edlinger PR c++/69865 * c-c++-common/Wshift-negative-value-6.c: Add -std=c++11 before -std=c++03. Modified: trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c-opts.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/c-c++-common/Wshift-negative-value-6.c
[Bug driver/69805] [6 Regression] ICE in greater_than_spec_func, at gcc.c:9722
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69805 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Jakub Jelinek --- Fixed.
[Bug target/69868] vec_perm built-in is not handled by swap optimization on powerpc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69868 Bill Schmidt changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-02-19 Ever confirmed|0 |1 --- Comment #1 from Bill Schmidt --- Confirmed.
[Bug c++/69865] -trigraphs option broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69865 Bernd Edlinger changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #10 from Bernd Edlinger --- fixed on trunk. gcc-5 does not have this issue.
[Bug c++/69743] [5/6 Regression] function overload with variadic arguments - template instantiation depth exceeds maximum (gcc4, clang - no problem)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69743 Jason Merrill changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2016-02-19 Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Ever confirmed|0 |1
[Bug libstdc++/57272] node-based containers don't use allocator's pointer type internally
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57272 --- Comment #6 from Phil Bouchard --- Also please make sure the pointer arguments are passed by reference and not by value. This would ensure we could use our own smart pointers.
[Bug c/69880] New: Linking Windows resources + implicit 'default-manifest.o' creates bad .exe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69880 Bug ID: 69880 Summary: Linking Windows resources + implicit 'default-manifest.o' creates bad .exe Product: gcc Version: 5.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: vsz.bugzilla at emailuser dot net Target Milestone: --- Hi, Sorry for the ambiguous title, I'm not completely sure where/what is the culprit yet. Please bear with me. While migrating to MSYS2 and its own mingw-w64 (5.3.0) toolchain (from a non-MSYS2 build of the same toolchain), I stumbled into a problem. When linking an application that has its own Windows resource, including a Windows Manifest, I noticed that the final .exe is not compressible with UPX (3.91) anymore, with the error: upx: my.exe: CantPackException: superfluous data between sections Further investigation revealed that MSYS2 comes with a _default Windows manifest_, as part of the toolchain. They are packaged as `*windows-default-manifest`. The GCC patch below made this feature possible, by automatically linking a default resource object, whenever it's found on disk: https://gcc.gnu.org/ml/gcc-patches/2014-04/msg01378.html The problem happens when the application is also supplying its own resource object (like in my case), and above default resource object is found as well. In this case _both_ objects get linked to the executable. It means that the .exe now has _two_ manifests. This by itself is already an ambiguity and some unnecessary bloat. But, the way these two objects are linked also causes the second instance to be apparently "orphaned" between two valid sections (.rsrc and .reloc in my particular case) of the executable. This orphaned data seems to be confusing UPX, hence its fatal error. The orphaned data can be discarded by using `strip -g test.exe` (or `strip --strip-unneeded test.exe`). In my case it deleted the extra data, and UPX worked again. I'm not sure this works in all possible cases though, and unfortunately it strips other information too, f.e. digital signatures. Plus this extra step requires a revamp of existing build scripts and tooling. To my best knowledge mingw never handled linking multiple Windows resources well, but so far this could be easily mitigated by either merging .rc files in advance and/or avoiding to pass multiple resource objects explicitly. With the newly added implicit object feature, such care can no longer be taken. IMO it'd be nice to have option to disable picking up the implicit `default-manifest.o` object (deleting it cannot always be done and/or cannot be done cleanly), or even better automatically drop it if there is any user supplied resource object. Cleverly merging them and dropping any duplicate entries, while giving the user-supplied object a priority would also be helpful, if feasible. Anyhow, the goal is to allow to have a _single_ manifest in the final executable, controlled by the user. Here's my original bug report with some more aspects/information, plus steps to recreate a minimal example: https://github.com/Alexpux/MSYS2-packages/issues/454 -Viktor
[Bug lto/69866] lto1: internal compiler error: in add_symbol_to_partition_1, at lto/lto-partition.c:158
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69866
--- Comment #3 from acrsofter at gmail dot com ---
reproduce steps:
[foo.c]
int _umh(int i)
{
return i+1;
}
int weaks(int i) __attribute__((weak, alias("_umh")));
int main()
{
return weaks(10);
}
[bar.c]
int weaks(int i)
{
return i+1;
}
now compile:
gcc -c bar.c
gcc -flto -c foo.c
gcc -flto -o elf bar.o foo.o
note:
bar compiled without flt
but rest with flt
now at linking stage booms
at line
gcc_assert (c != SYMBOL_EXTERNAL
&& (c == SYMBOL_DUPLICATE || !symbol_partitioned_p (node)));
in lto/lto-partition.c
===
same code compiled without lto ok
gcc 4.9.3 not affected
but 5.3.0 affected and latest (gcc-6-20160214) affected
[Bug rtl-optimization/69806] [6 Regression][SH] Combine doesn't see constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69806 --- Comment #7 from Oleg Endo --- (In reply to Segher Boessenkool from comment #6) > r233159 was reverted in r233356. Does this problem still happen? Yes, problem is still there, because ... (In reply to Jakub Jelinek from comment #5) > I think you should bisect it to the exact commit. > The only combine.c change in that range is r233159, but there is e.g. > r233133 cse.c change too etc. I can confirm that r233133 is the actual cause.
[Bug c++/69743] [5/6 Regression] function overload with variadic arguments - template instantiation depth exceeds maximum (gcc4, clang - no problem)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69743 --- Comment #3 from Jason Merrill --- Author: jason Date: Sat Feb 20 04:31:16 2016 New Revision: 233579 URL: https://gcc.gnu.org/viewcvs?rev=233579&root=gcc&view=rev Log: PR c++/69743 * call.c (remaining_arguments): No longer static. * cp-tree.h: Declare it. * pt.c (more_specialized_fn): Use it. Added: trunk/gcc/testsuite/g++.dg/cpp0x/variadic167.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c trunk/gcc/cp/cp-tree.h trunk/gcc/cp/pt.c --- Comment #4 from Jason Merrill --- Author: jason Date: Sat Feb 20 04:31:29 2016 New Revision: 233580 URL: https://gcc.gnu.org/viewcvs?rev=233580&root=gcc&view=rev Log: PR c++/69743 * call.c (remaining_arguments): No longer static. * cp-tree.h: Declare it. * pt.c (more_specialized_fn): Use it. Added: branches/gcc-5-branch/gcc/testsuite/g++.dg/cpp0x/variadic167.C Modified: branches/gcc-5-branch/gcc/cp/ChangeLog branches/gcc-5-branch/gcc/cp/call.c branches/gcc-5-branch/gcc/cp/cp-tree.h branches/gcc-5-branch/gcc/cp/pt.c
[Bug c++/69743] [5/6 Regression] function overload with variadic arguments - template instantiation depth exceeds maximum (gcc4, clang - no problem)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69743 --- Comment #3 from Jason Merrill --- Author: jason Date: Sat Feb 20 04:31:16 2016 New Revision: 233579 URL: https://gcc.gnu.org/viewcvs?rev=233579&root=gcc&view=rev Log: PR c++/69743 * call.c (remaining_arguments): No longer static. * cp-tree.h: Declare it. * pt.c (more_specialized_fn): Use it. Added: trunk/gcc/testsuite/g++.dg/cpp0x/variadic167.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c trunk/gcc/cp/cp-tree.h trunk/gcc/cp/pt.c --- Comment #4 from Jason Merrill --- Author: jason Date: Sat Feb 20 04:31:29 2016 New Revision: 233580 URL: https://gcc.gnu.org/viewcvs?rev=233580&root=gcc&view=rev Log: PR c++/69743 * call.c (remaining_arguments): No longer static. * cp-tree.h: Declare it. * pt.c (more_specialized_fn): Use it. Added: branches/gcc-5-branch/gcc/testsuite/g++.dg/cpp0x/variadic167.C Modified: branches/gcc-5-branch/gcc/cp/ChangeLog branches/gcc-5-branch/gcc/cp/call.c branches/gcc-5-branch/gcc/cp/cp-tree.h branches/gcc-5-branch/gcc/cp/pt.c
[Bug c++/69743] [5/6 Regression] function overload with variadic arguments - template instantiation depth exceeds maximum (gcc4, clang - no problem)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69743 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Jason Merrill --- Fixed.
