[Bug c/68075] Printf is changing the order of values

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68075

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #1 from Andrew Pinski  ---
The order of the get_db_insert_string function calls in
printf ("%s, %s, %s, %s, %s, %s\n",
get_db_insert_string (db_val, &val[0][0]),
get_db_insert_string (db_val, &val[1][0]),
get_db_insert_string (db_val, &val[2][0]),
get_db_insert_string (db_val, &val[3][0]),
get_db_insert_string (db_val, &val[4][0]),
get_db_insert_string (db_val, &val[5][0]));

is not specified in C.  So both answers are correct and your expectations for
the order of the function calls is incorrect.

[Bug c/68075] New: Printf is changing the order of values

[girish.elchuri at smuuthsolutions dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68075

Bug ID: 68075
   Summary: Printf is changing the order of values
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: critical
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: girish.elchuri at smuuthsolutions dot com
  Target Milestone: ---

Created attachment 36571
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36571&action=edit
Code that is producing the wrong output.

Look at the following code segment attached herewith. This is giving the
output:

>><<, NULL
>><<, NULL
>><<, NULL
>>ghi<<, 'ghi'
>>def<<, 'def'
>>abc<<, 'abc'
'abc', 'abc', 'abc', 'abc', 'abc', 'abc'


While th expected output is:
>>abc<<, 'abc'
>>def<<, 'def
>>ghi<<, 'ghi'
>><<, NULL
>><<, NULL
>><<, NULL
'abc', 'def', 'ghi', NULL, NULL, NULL

This is a real bug, please fix it.

[Bug ipa/68057] [6 Regression] 450.soplex in SPEC CPU 2006 failed to build

[trippels at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68057

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||trippels at gcc dot gnu.org

--- Comment #5 from Markus Trippelsdorf  ---
markus@x4 test % cat 1.ii
struct SPxPricer;
struct SoPlex {
  virtual void setPricer(SPxPricer *);
};
struct SPxPricer {
  virtual void load(SoPlex *);
};
struct SLUFactor {
  SLUFactor();
  virtual ~SLUFactor();
};
struct SPxSolver : SoPlex {
  SPxPricer pr;
  SLUFactor slu;
  SPxSolver();
};
struct A : SPxSolver {};
A a;

void SoPlex::setPricer(SPxPricer *p1) { p1->load(this); }


markus@x4 test % cat 2.ii
struct SPxPricer;
struct SoPlex {
  virtual void setPricer(SPxPricer *);
};
struct SPxPricer {
  virtual void load(SoPlex *);
};
struct SLUFactor {
  SLUFactor();
  virtual ~SLUFactor();
};
struct SPxSolver : SoPlex {
  SPxPricer pr;
  SLUFactor slu;
  SPxSolver();
};
SPxSolver::SPxSolver() { setPricer(&pr); }


markus@x4 test % g++ -r -nostdlib -O2 -flto 1.ii 2.ii
lto1: internal compiler error: in record_target_from_binfo, at
ipa-devirt.c:2599

[Bug ipa/68057] [6 Regression] 450.soplex in SPEC CPU 2006 failed to build

[miyuki at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68057

--- Comment #4 from Mikhail Maltsev  ---
Created attachment 36570
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36570&action=edit
reproducer

Compile like this:
/opt/gcc-6.0.0/bin/g++ -O3 -flto tu{1,2,3}.cc

lto1: internal compiler error: in record_target_from_binfo, at
ipa-devirt.c:2599
0x80492d record_target_from_binfo
/home/miyuki/gcc/src/gcc/ipa-devirt.c:2599
0x804405 record_target_from_binfo
/home/miyuki/gcc/src/gcc/ipa-devirt.c:2640
0x804e44 possible_polymorphic_call_targets_1
/home/miyuki/gcc/src/gcc/ipa-devirt.c:2687
0x80b8fc possible_polymorphic_call_targets(tree_node*, long,
ipa_polymorphic_call_context, bool*, void**, bool)
/home/miyuki/gcc/src/gcc/ipa-devirt.c:3216
0x80d1fc try_speculative_devirtualization(tree_node*, long,
ipa_polymorphic_call_context)
/home/miyuki/gcc/src/gcc/ipa-devirt.c:3576
0x109aec9 ipa_get_indirect_edge_target_1
/home/miyuki/gcc/src/gcc/ipa-cp.c:2142
0x81fb52 estimate_edge_devirt_benefit
/home/miyuki/gcc/src/gcc/ipa-inline-analysis.c:3048
0x81ff5b estimate_edge_size_and_time
<...>

I did not preserve validity, i.e. compiling without optimization gives link
error:
tu3.cc:(.text._ZN9SPxPricerC2Ev[_ZN9SPxPricerC5Ev]+0x9): undefined reference to
`vtable for SPxPricer'
(because of missing definition for SPxPricer::load).

[Bug c++/60417] [DR 1518] Bogus error on C++03 aggregate initialization

[jason at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60417

--- Comment #13 from Jason Merrill  ---
Following discussions of DR1518/1630 in Kona, the testcase is now ill-formed in
C++11 and up.

[Bug c++/54835] [C++11][DR 1518] Explicit default constructors not respected during copy-list-initialization

[jason at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54835

--- Comment #16 from Jason Merrill  ---
Since the last meeting it has been suggested that this effect of DR 1630 was
unintended, and the testcase should be ill-formed.  So I've changed it back.

[Bug c++/60417] [DR 1518] Bogus error on C++03 aggregate initialization

[jason at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60417

--- Comment #12 from Jason Merrill  ---
Author: jason
Date: Sat Oct 24 02:58:10 2015
New Revision: 229283

URL: https://gcc.gnu.org/viewcvs?rev=229283&root=gcc&view=rev
Log:
DR 1518
DR 1630
PR c++/54835
PR c++/60417
* call.c (convert_like_real): Value-initialization can't use
explicit constructors in C++11 and up.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/explicit10.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/call.c
trunk/gcc/testsuite/g++.dg/cpp0x/initlist40.C
trunk/gcc/testsuite/g++.dg/init/explicit1.C
trunk/gcc/testsuite/g++.dg/init/explicit2.C

[Bug c++/54835] [C++11][DR 1518] Explicit default constructors not respected during copy-list-initialization

[jason at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54835

--- Comment #15 from Jason Merrill  ---
Author: jason
Date: Sat Oct 24 02:58:10 2015
New Revision: 229283

URL: https://gcc.gnu.org/viewcvs?rev=229283&root=gcc&view=rev
Log:
DR 1518
DR 1630
PR c++/54835
PR c++/60417
* call.c (convert_like_real): Value-initialization can't use
explicit constructors in C++11 and up.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/explicit10.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/call.c
trunk/gcc/testsuite/g++.dg/cpp0x/initlist40.C
trunk/gcc/testsuite/g++.dg/init/explicit1.C
trunk/gcc/testsuite/g++.dg/init/explicit2.C

[Bug ipa/68057] [6 Regression] 450.soplex in SPEC CPU 2006 failed to build

[miyuki at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68057

Mikhail Maltsev  changed:

   What|Removed |Added

 CC||miyuki at gcc dot gnu.org

--- Comment #3 from Mikhail Maltsev  ---
This also started showing up in my x86_64 builds with the following options:

g++ -w  -Ofast -march=haswell -mtune=haswell -flto=12   -DSPEC_CPU_LP64
-std=c++98 -fprofile-generate <...> -o soplex

I'll try to reduce the testcase.

[Bug c++/68074] [C++14] Complex ConstExpr Evaluation

[arbmind at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68074

--- Comment #1 from Andreas Reischuck  ---
Fixed some issues in my example.
http://goo.gl/Rxq7TP

The ranged for loops now compile on clang. The problem is not the loop, but the
address calculation.

[Bug c++/68074] New: [C++14] Complex ConstExpr Evaluation

[arbmind at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68074

Bug ID: 68074
   Summary: [C++14] Complex ConstExpr Evaluation
   Product: gcc
   Version: 5.2.0
   URL: http://goo.gl/T7h3Qg
Status: UNCONFIRMED
  Keywords: rejects-valid, wrong-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: arbmind at gmail dot com
  Target Milestone: ---

Please take a look at my constexpr experiment.
http://goo.gl/T7h3Qg

GCC 5.2.0 and 5.1.0 has multiple issues with this code.
It compiles well in all variants on Clang 3.7 and 3.8 snapshots.

The goal of the experiment is to implement a multiplication table at compile
time. Peter Sommerlad showed it on CppCon 2015. Video
https://www.youtube.com/watch?v=DM-RXeiSCmc

This implementation makes much more use of constexpr features of C++14.

The issues are marked with comment in the code.

1. Currently the code compiles, but prints the strings backwards. Generating
the strings at runtime, does not schod this behavior. Clang gets this right as
well.

2. The auto generated copy & move operators of carray do behave different. In
compile time execution only the first element is handled. Using the class at
runtime works well. Clang does the same during compile time.

3. Adding an exception to the string generation triggers a strange compiler
error. "sorry, unimplemented: unexpected AST of kind loop_expr" Clang works
well.

4. GCC does not allow me to use range based for loops for carray. Clang has no
problem with that.

Thanks for all the good work. May my experiment help to improve g++.

[Bug fortran/68054] ICE on using protected attribute in program without program statement

[kargl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68054

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-10-24
 CC||kargl at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |kargl at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from kargl at gcc dot gnu.org ---
I have a patch

[Bug fortran/68055] ICE on using unsupported kinds in program without program statement

[sgk at troutmask dot apl.washington.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68055

--- Comment #3 from Steve Kargl  ---
Patch posted at 

https://gcc.gnu.org/ml/fortran/2015-10/msg00112.html

As I don't see an ICE, Gerhard can you test this?

[Bug fortran/68055] ICE on using unsupported kinds in program without program statement

[kargl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68055

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-10-23
 CC||kargl at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |kargl at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from kargl at gcc dot gnu.org ---
I could not generate an ICE with z1.f90.  Instead, I
the following error:

% gfc6 -c g1.f90
g1.f90:3:7:

c = 1
   1
Error: Can't convert INTEGER(4) to INTEGER(3) at (1)

with gcc 4.9.x, 5.2.x, and 6.  gfortran should reject
the *3.  I have a patch that does now does

% gfc6 -c g1.f90
g1.f90:2:12:

integer*3 c
1
Error: Old-style type declaration INTEGER*3 not supported at (1)

[Bug middle-end/65962] Missed vectorization of strided stores

[wschmidt at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65962

Bill Schmidt  changed:

   What|Removed |Added

 CC||bergner at gcc dot gnu.org,
   ||wschmidt at gcc dot gnu.org

--- Comment #6 from Bill Schmidt  ---
This commit (r229172) caused a vectorization failure for POWER:

FAIL: gcc.dg/vect/vect-62.c -flto -ffat-lto-objects  scan-tree-dump-times vect
"vectorized 1 loops" 1
FAIL: gcc.dg/vect/vect-62.c scan-tree-dump-times vect "vectorized 1 loops" 1

Seems like an odd result, but that's what the bisection shows...

[Bug c++/67813] [C++14] copy-initialization of object with pointer member fails in constexpr function

[jason at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67813

--- Comment #1 from Jason Merrill  ---
Author: jason
Date: Fri Oct 23 20:57:05 2015
New Revision: 229270

URL: https://gcc.gnu.org/viewcvs?rev=229270&root=gcc&view=rev
Log:
PR c++/67813
* constexpr.c (cxx_eval_store_expression): Always use *valp if
set.

Added:
trunk/gcc/testsuite/g++.dg/cpp1y/constexpr-copy1.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/constexpr.c

[Bug c++/68073] free(): invalid pointer errors with short strings using _GLIBCXX_USE_CXX11_ABI=1

[trippels at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68073

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||trippels at gcc dot gnu.org
 Resolution|--- |INVALID

--- Comment #1 from Markus Trippelsdorf  ---
This is due to the new small string optimization in libstdc++.
It doesn't use the heap anymore for this case.

Your code calls the string destructor directly:

202 template 
203 struct variant_helper  
204 {   
205 VARIANT_INLINE static void destroy(const std::size_t id, void * data)   
206 {   
207 if (id == sizeof...(Types)) 
208 {   
209 reinterpret_cast(data)->~T();   
210 } 

#1 0x401a5c in mapnik::util::variant_helper, std::allocator >, bool>::destroy(unsigned long,
void*) mapnik/include/mapnik/util/variant.hpp:209

So it will try to free an address that was never allocated.

[Bug tree-optimization/67830] [6 Regression] wrong code at -O1 and above on x86_64-linux-gnu

[law at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67830

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #7 from Jeffrey A. Law  ---
Fixed on the trunk.

[Bug tree-optimization/67830] [6 Regression] wrong code at -O1 and above on x86_64-linux-gnu

[law at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67830

--- Comment #6 from Jeffrey A. Law  ---
Author: law
Date: Fri Oct 23 19:16:53 2015
New Revision: 229267

URL: https://gcc.gnu.org/viewcvs?rev=229267&root=gcc&view=rev
Log:
[RFA] Fix pr67830, another type narrowing problem

PR tree-optimization/67830
* match.pd ((bit_and (plus/minus (convert @0) (convert @1)) mask)):
Explicitly verify the mask has no bits outside the type of
the innermost operands.

PR tree-optimization/67830
* gcc.dg/pr67830.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr67830.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/match.pd
trunk/gcc/testsuite/ChangeLog

[Bug rtl-optimization/67609] [5/6 Regression] Generates wrong code for SSE2 _mm_load_pd

[rth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67609

--- Comment #28 from Richard Henderson  ---
(In reply to Richard Biener from comment #26)
> Hmm, I don't see this documented anywhere.  In fact there is no such
> thing as a "vector register", there are only vector modes.  And we
> are using %xmm for plain SF/DFmode all over the place.
> 
> Note that in the particular case the mode we subreg is TImode,
> not a vector mode.

You're right, my language was sloppy.  The problem I describe is going
to be true for any register whose reg_raw_mode is larger than word_mode.

The assumption is that assignment to a word_mode subreg both (1) cannot
affect bits outside the word_mode and (2) can be simplified to a plain
hard register post-reload.

Part deux is impossible when reg_raw_mode is larger than word_mode,
because the subreg-y assignment result is indistinguishable from a
normal word_mode assignment.

> That may be a workaround for x86 but I don't see how this fixes the
> issue in general given that targets may have general registers larger
> than word_mode

It doesn't fix other targets, true.  But I don't see how to do that
without changes to each target.

> (is x32 TARGET_64BIT?).

Yes.

[Bug c++/68073] New: free(): invalid pointer errors with short strings using _GLIBCXX_USE_CXX11_ABI=1

[nikola.kovacs at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68073

Bug ID: 68073
   Summary: free(): invalid pointer errors with short strings
using _GLIBCXX_USE_CXX11_ABI=1
   Product: gcc
   Version: 5.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nikola.kovacs at gmail dot com
  Target Milestone: ---

Created attachment 36569
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36569&action=edit
testcases

Download mapnik from here: https://github.com/mapnik/mapnik
At least v3.0.3 and v3.0.7 are affected.
A few include files are needed, but you do not need to compile it.

I've attached a tar.gz with various testcases, the .ii files, and a shell
script to run them all.
All of them work with -D_GLIBCXX_USE_CXX11_ABI=0.

With -D_GLIBCXX_USE_CXX11_ABI=1:
test1 and test2 are the same except for the length of the string. test1 (short
string) crashes, test2 does not.
test3 and test4 are the same except for the length of the string. test3 (short
string) crashes, test4 does not.
test5, test6 and test7 are the same except for the length of the string. all
three crash, but the error message is random: sometimes munmap_chunk(): invalid
pointer, sometimes just Segmentation fault(core dumped)


I'm using Ubuntu 15.10 x86_64 and g++ version is g++ (Ubuntu 5.2.1-22ubuntu2)
5.2.1 20151010


I also tried the first test with the 5.2.1 20151013 snapshot, and it also had
this issue.


Here's the original mapnik bugreport:
https://github.com/mapnik/mapnik/issues/3090

[Bug go/67976] Cgo + Gccgo not working like Cgo + Golang?

[ian at airs dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67976

--- Comment #2 from Ian Lance Taylor  ---
This is probably https://golang.org/issue/8945 , which is fixed in the gc
repository but not in the gccgo repository.  That fix should come in when I
merge in the Go 1.5 sources.

[Bug go/67968] go1: internal compiler error: in write_specific_type_functions, at go/gofrontend/types.cc:1812

[ian at airs dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67968

--- Comment #9 from Ian Lance Taylor  ---
Does it crash on x86_64 or only on s390?

[Bug go/68072] New: malformed DWARF TagVariable entry

[vogt at linux dot vnet.ibm.com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68072

Bug ID: 68072
   Summary: malformed DWARF TagVariable entry
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: go
  Assignee: ian at airs dot com
  Reporter: vogt at linux dot vnet.ibm.com
CC: cmang at google dot com
  Target Milestone: ---
  Host: s390x
Target: s390x
 Build: s390x

Compiling the package crypto/secp256k1 from the go-ethereum package yields the
error message "malformed DWARF TagVariable entry" from cgo.  Maybe it does not
yet know about the latest changes to debug information in Gcc?

I know this report is very terse; if a code example is necessary to debug or
fix this issue, just give me a shout and I'll see what I can do next week.

(Gcc sources checked out at 25th of Septermber, 2015.)

[Bug go/67976] Cgo + Gccgo not working like Cgo + Golang?

[vogt at linux dot vnet.ibm.com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67976

--- Comment #1 from Dominik Vogt  ---
When cgo encounters the "C.foo_cgo", it determines that it must be a variable,
but finds no C definition, so it generates "extern char foo_cgo[]" (out.go) as
the type.  This conflicts with the declaration in the comment at the beginning
of the file.  Replacing

/* 
int foo_cgo(unsigned); 
*/ 

with

/* 
extern char foo_cgo[];
*/

Makes this code compile for me.  Is this kind of declaration supported by the
cgo version from the golang repository?  (If not, what would the symbol
C.foo_cgo be good for).

[Bug go/67968] go1: internal compiler error: in write_specific_type_functions, at go/gofrontend/types.cc:1812

[vogt at linux dot vnet.ibm.com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67968

--- Comment #8 from Dominik Vogt  ---
I had been testing with the latest gcc-5-branch and didn't see any ICEs but a
lot of other problems with the ethereum package that may be the fault of the
code or cgo, I don't know.  I can see the ICE on Gong's machine.  The compiler
version is

gccgo (Debian 5.2.1-22) 5.2.1 20151010

Other than that there's still that problem with cgo that I've reported
separately (latest gccgo-5).

So, I now have a crashing gccgo without debuginfo running in gdb with the stack
trace from comment 4.

[Bug go/67968] go1: internal compiler error: in write_specific_type_functions, at go/gofrontend/types.cc:1812

[ian at airs dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67968

--- Comment #7 from Ian Lance Taylor  ---
Dominik: Chris has committed a number of recent fixes for gccgo compiler
crashes.  Are you testing with current mainline or with the 5.2.1 release that
gong_su is using?  Or is the problem that you don't have the imported packages?

If that is the problem, then I wouldn't worry about shrinking the number or
size of the input files.  The only thing that matters is reducing the number of
imports.

Or, it's likely to be easier to just tar up the import files.  Once this kind
of problem can be reproduced, it's usually easy to fix.

[Bug libgomp/65099] nvptx offloading: hard-coded 64-bit assumptions

[amonakov at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65099

Alexander Monakov  changed:

   What|Removed |Added

 CC||amonakov at gcc dot gnu.org

--- Comment #3 from Alexander Monakov  ---
As of CUDA Toolkit release 7.0 (Early 2015), NVIDIA removed support for running
CUDA applications on 32-bit x86 kernels, and deprecated support for running
32-bit applications on 64-bit x86 kernels.  However, 32-bit support is in place
for the ARM platform.

Thought I'd add this note since the need for 32-bit support in GCC offloading
in the first place is non-obvious.

[Bug tree-optimization/68067] [4.9/5/6 Regression] Wrong constant folding

[jsm28 at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68067

Joseph S. Myers  changed:

   What|Removed |Added

   Target Milestone|--- |4.9.4
Summary|Wrong constant folding  |[4.9/5/6 Regression] Wrong
   ||constant folding

--- Comment #4 from Joseph S. Myers  ---
Regression relative to 4.2.

[Bug c/68067] Wrong constant folding

[jsm28 at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68067

Joseph S. Myers  changed:

   What|Removed |Added

 Status|RESOLVED|NEW
   Last reconfirmed||2015-10-23
 Resolution|INVALID |---
 Ever confirmed|0   |1

--- Comment #3 from Joseph S. Myers  ---
I don't think this is undefined.  b is INT_MIN, a valid value of type int.  b -
c is also INT_MIN, again no overflow.  And a - (b - c) is -1 - INT_MIN, a valid
subtraction whose value is within range.

a + (c - b) would indeed be undefined, but that's not what the source code has.

[Bug c/68065] Size calculations for VLAs can overflow

[joseph at codesourcery dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68065

--- Comment #2 from joseph at codesourcery dot com  ---
This seems like a matter for -fsanitize=undefined as I suggested in 
.

[Bug rtl-optimization/67736] Wrong optimization with -fexpensive-optimizations on mips64el

[sje at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67736

--- Comment #5 from Steve Ellcey  ---
Author: sje
Date: Fri Oct 23 15:58:33 2015
New Revision: 229260

URL: https://gcc.gnu.org/viewcvs?rev=229260&root=gcc&view=rev
Log:
2015-10-23  Steve Ellcey  
Andrew Pinski  

PR rtl-optimization/67736
* gcc.dg/torture/pr67736.c: New test.
* gcc.dg/combine-subregs.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/combine-subregs.c
trunk/gcc/testsuite/gcc.dg/torture/pr67736.c
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug rtl-optimization/67736] Wrong optimization with -fexpensive-optimizations on mips64el

[sje at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67736

--- Comment #4 from Steve Ellcey  ---
Author: sje
Date: Fri Oct 23 15:56:15 2015
New Revision: 229259

URL: https://gcc.gnu.org/viewcvs?rev=229259&root=gcc&view=rev
Log:
2015-10-23  Steve Ellcey  
Andrew Pinski  

PR rtl-optimization/67736
* combine.c (simplify_comparison): Use gen_lowpart_or_truncate instead
of gen_lowpart.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/combine.c

[Bug c++/68071] New: Generic lambda variadic argument pack cannot be empty

[vittorio.romeo at outlook dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68071

Bug ID: 68071
   Summary: Generic lambda variadic argument pack cannot be empty
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vittorio.romeo at outlook dot com
  Target Milestone: ---

struct C
{
template
auto operator()(T&& x, TRest&&...){ return x; }
};

int main()
{
// Compiles both with clang and gcc.
auto c = C{};
c(1);

// Compiles with clang 3.7.
// Does not compile with gcc 5.2.
auto l = [](auto&& x, auto&&...) { return x; };
l(1);
}

decltype(l)::operator() should be equivalent to C::operator(), but if variadic
pack is left empty in the generic lambda, gcc refuses to compile:

15 : error: no match for call to '(main()::) (int)' l(1);
15 : note: candidate: decltype (((main()::)0u).main()::(x, )) (*)(auto:1&&,
auto:2&&, ...)

15 : note: candidate expects 3 arguments, 2 provided
14 : note: candidate: template main()::
auto l = [](auto&& x, auto&&...) { return x; };

14 : note: template argument deduction/substitution failed:
15 : note: candidate expects 2 arguments, 1 provided
l(1);

Live example on godbolt.org:
https://goo.gl/2ikAUK

[Bug debug/67192] [6 Regression] Backward-goto in loop can get wrong line number

[arnez at linux dot vnet.ibm.com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67192

--- Comment #21 from Andreas Arnez  ---
(In reply to Andreas Arnez from comment #20)
> Posted a patch that is not as ambitious as completely getting rid of
> input_location, but also doesn't require a new function like
> c_parser_peek_token_keep_input_location():
> 
>   https://gcc.gnu.org/ml/gcc-patches/2015-10/msg01132.html

After investigating this further I recognized that this patch doesn't cover all
cases where the backward-goto is wrongly located.  Thus I've created a version
that basically follows the suggestion from comment #13, to pass an explicit
location to c_finish_loop:

  https://gcc.gnu.org/ml/gcc-patches/2015-10/msg02393.html

I haven't checked whether there are still other cases where add_stmt needs to
use input_location as the default location for the given statement.  It should
probably be one goal to get rid of this default handling.

[Bug c++/68070] New: Undefined reference to default constructor of member template class

[frrrwww at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68070

Bug ID: 68070
   Summary: Undefined reference to default constructor of member
template class
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: frrrwww at gmail dot com
  Target Milestone: ---

Hello,

When compiling the following simple program with `g++ prog.cc -Wall -Wextra
-std=c++14`

-
#include 

template
struct A
{
A() = default;
std::vector m_content;
};

void func(A a = {})
{
}

int main()
{
func();
}
-

We get the following error:

-
/tmp/ccr6nbUo.o: In function `main':
prog.cc:(.text+0x1b): undefined reference to `std::vector >::vector()'
collect2: error: ld returned 1 exit status
-

That error happens on gcc 4.9, 5.2 and 6.0, it does not happen on clang for
this specific code.

An alternative version of the code:

-
#include 

template
struct A
{
A() = default;
A(int) {}
std::vector m_content;
};

struct B { A a; };

void func(B b = {})
{
}

int main()
{
func();
}
-

gets this error:

-
/tmp/ccvOFE5O.o: In function `main':
prog.cc:(.text+0x33): undefined reference to `A::A()'
collect2: error: ld returned 1 exit status
-

[Bug c/68069] -fstack-protector-strong does not protect from buffer overflow attack

[chugaev.tolya at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68069

Anatoly Chugaev  changed:

   What|Removed |Added

 CC||chugaev.tolya at gmail dot com

--- Comment #2 from Anatoly Chugaev  ---
I have the same issue on 4.8.4.

[Bug c/68069] -fstack-protector-strong does not protect from buffer overflow attack

[milosvova at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68069

--- Comment #1 from Vladimir Miloserdov  ---
Created attachment 36568
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36568&action=edit
gcc -v output

[Bug c/68069] New: -fstack-protector-strong does not protect from buffer overflow attack

[milosvova at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68069

Bug ID: 68069
   Summary: -fstack-protector-strong does not protect from buffer
overflow attack
   Product: gcc
   Version: 4.9.3
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: milosvova at gmail dot com
  Target Milestone: ---

Created attachment 36567
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36567&action=edit
Vulnerable program

I've implemented very short and simple program that illegally calls a function
using buffer overflow attack. First, I compiled it with -fno-stack-protector
and it worked. Then I enabled stack protector and found out that my snippet is
still able to illegally call function.

Steps to reproduce:
1) Copy source.c from attachment
2) Compile the source: gcc -O0 -fstack-protector-strong source.c -o test
3) Run the program ./test
4) Input any number, press enter, input the number printed above, press enter,
input 10, press enter
5) If "In f2()" was printed, -fstack-protector-strong has failed to detect the
attack.

My GCC version: gcc (Gentoo 4.9.3 p1.2, pie-0.6.3) 4.9.3
The output of gcc -Q -v test.c -o test_stack and my program source will be
attached.

As my bug (if confirmed) is connected to serious security issues, I'm setting
severity to "major".

[Bug middle-end/68066] [6 Regression]: ICE in max_value, at wide-int.cc

[ienkovich at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68066

--- Comment #3 from Ilya Enkovich  ---
Author: ienkovich
Date: Fri Oct 23 13:38:16 2015
New Revision: 229256

URL: https://gcc.gnu.org/viewcvs?rev=229256&root=gcc&view=rev
Log:
gcc/

PR middle-end/68066
* tree.c (build_truth_vector_type): Support BLK mode
returned for boolean vector.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree.c

[Bug c/68062] [4.9/5/6 Regression] ICE when comparing vectors

[ienkovich at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68062

--- Comment #4 from Ilya Enkovich  ---
(In reply to Ilya Enkovich from comment #3)
> (In reply to Richard Biener from comment #1)
> > I suppose that is Iljas fault (only happens on trunk).
> 
> Yes, -funsigned-char seems to be my fault.  I'll have look.

It appears to be introduced by r229173.  We now try to lower vector comparison
using optab which doesn't actually exist.  This patch fixes it:

diff --git a/gcc/tree-vect-generic.c b/gcc/tree-vect-generic.c
index 2005383..9c59402 100644
--- a/gcc/tree-vect-generic.c
+++ b/gcc/tree-vect-generic.c
@@ -1533,7 +1533,8 @@ expand_vector_operations_1 (gimple_stmt_iterator *gsi)
   && TYPE_MODE (TREE_TYPE (type)) == TYPE_MODE (TREE_TYPE (srhs1)))
 {
   op = optab_for_tree_code (code, TREE_TYPE (type), optab_scalar);
-  if (optab_handler (op, TYPE_MODE (TREE_TYPE (type))) !=
CODE_FOR_nothing)
+  if (op != unknown_optab
+ && optab_handler (op, TYPE_MODE (TREE_TYPE (type))) !=
CODE_FOR_nothing)
{
  tree slhs = make_ssa_name (TREE_TYPE (srhs1));
  gimple *repl = gimple_build_assign (slhs, code, srhs1, srhs2);

[Bug rtl-optimization/67609] [5/6 Regression] Generates wrong code for SSE2 _mm_load_pd

[vmakarov at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67609

--- Comment #27 from Vladimir Makarov  ---
(In reply to Vladimir Makarov from comment #25)
> So it would be nice to benchmark it.  I'll try to do this on
> Friday.

Practically every SPEC2000 benchmark failed to compile with this patch.  GCC
crashes in split2 pass with messages like this

Error: unrecognizable insn:
(insn 381 345 67 3 (set (subreg:V2DF (reg:DF 22 xmm1 [287]) 0)
(xor:V2DF (subreg:V2DF (reg:DF 22 xmm1 [287]) 0)
(mem/u/c:V2DF (symbol_ref/u:DI ("*.LC6") [flags 0x2]) [2  S16
A128]))) apsi.f:3324 -1
 (nil))
apsi.f:3336:0: internal compiler error: in extract_insn, at recog.c:2297
0x9b9848 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/home/cygnus/vmakarov/build1/trunk3/gcc/gcc/rtl-error.c:109
0x9b9879 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/home/cygnus/vmakarov/build1/trunk3/gcc/gcc/rtl-error.c:117
0x988907 extract_insn(rtx_insn*)
/home/cygnus/vmakarov/build1/trunk3/gcc/gcc/recog.c:2297
0x988991 extract_insn_cached(rtx_insn*)
/home/cygnus/vmakarov/build1/trunk3/gcc/gcc/recog.c:2188
0x7e3f5d cleanup_subreg_operands(rtx_insn*)
/home/cygnus/vmakarov/build1/trunk3/gcc/gcc/final.c:3112
0x98638c split_insn
/home/cygnus/vmakarov/build1/trunk3/gcc/gcc/recog.c:2910
0x98ab77 split_all_insns()
/home/cygnus/vmakarov/build1/trunk3/gcc/gcc/recog.c:2964
0x98abd8 rest_of_handle_split_after_reload
/home/cygnus/vmakarov/build1/trunk3/gcc/gcc/recog.c:3902
0x98abd8 execute
/home/cygnus/vmakarov/build1/trunk3/gcc/gcc/recog.c:3931
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug middle-end/65855] missing optimization: triangular numbers

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65855

Richard Biener  changed:

   What|Removed |Added

 CC||spop at gcc dot gnu.org

--- Comment #5 from Richard Biener  ---
Looks like SCEV analysis is broken for this case.

  :
  # t_11 = PHI <0(5), t_5(7)>
  # i_13 = PHI <1(5), i_6(7)>
  t_5 = t_11 + i_13;
  i_6 = i_13 + 1;
  if (i_6 <= _10)
goto ;
  else
goto ;

  :
  goto ;

  :
  # t_2 = PHI 

t_11 = { 0, +, i_13 }_1  (ok)
i_13 = {1, +, 1}_1 (ok)

(instantiate_scev
  (instantiate_below = 5)
  (evolution_loop = 1)
  (chrec = {0, +, i_13}_1)
(analyze_scalar_evolution
  (loop_nb = 1)
  (scalar = i_13)
(get_scalar_evolution
  (scalar = i_13)
  (scalar_evolution = {1, +, 1}_1))
(set_scalar_evolution
  instantiated_below = 5
  (scalar = i_13)
  (scalar_evolution = {1, +, 1}_1))
)
  (res = {0, +, {1, +, 1}_1}_1))

(instantiate_scev
  (instantiate_below = 5)
  (evolution_loop = 1)
  (chrec = {1, +, 1}_1)
  (res = {1, +, 1}_1))
(set_scalar_evolution
  instantiated_below = 5
  (scalar = t_5)
  (scalar_evolution = {1, +, {2, +, 1}_1}_1))

not sure where the latter result comes from.  It comes from

#10 0x00eac871 in scev_const_prop ()
at /space/rguenther/src/svn/trunk/gcc/tree-scalar-evolution.c:3456
3456   NULL);
(gdb) l
3451  if (!POINTER_TYPE_P (type)
3452  && !INTEGRAL_TYPE_P (type))
3453continue;
3454
3455  ev = resolve_mixers (loop, analyze_scalar_evolution (loop,
name),
3456   NULL);

analyzing the evolution of t_2.

So we end up looking at t_5 = t_11 + i_13 which is {0, +, {1,+, 1}_1}_1 +
{1,+,1}_1 but that isn't {1, +, {2, +, 1}_1 }_1 as chrec_fold_plus_poly_poly
maintains?

But maybe this kind of CHREC is just ill-formed in the first place?

Sebastian, any ideas here?

[Bug middle-end/65947] Vectorizer misses conditional assignment of constant

[alahay01 at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65947

--- Comment #5 from alahay01 at gcc dot gnu.org ---
Author: alahay01
Date: Fri Oct 23 12:40:33 2015
New Revision: 229245

URL: https://gcc.gnu.org/viewcvs?rev=229245&root=gcc&view=rev
Log:
Support for vectorizing conditional expressions

2015-10-23  Alan Hayward 

gcc/
PR tree-optimization/65947
* tree-vect-loop.c
(vect_is_simple_reduction_1): Find condition reductions.
(vect_model_reduction_cost): Add condition reduction costs.
(get_initial_def_for_reduction): Add condition reduction initial var.
(vect_create_epilog_for_reduction): Add condition reduction epilog.
(vectorizable_reduction): Condition reduction support.
* tree-vect-stmts.c (vectorizable_condition): Add vect reduction arg
* doc/sourcebuild.texi (Vector-specific attributes): Document
vect_max_reduc

gcc/testsuite
PR tree-optimization/65947
* lib/target-supports.exp
(check_effective_target_vect_max_reduc): Add.
* gcc.dg/vect/pr65947-1.c: New test.
* gcc.dg/vect/pr65947-2.c: New test.
* gcc.dg/vect/pr65947-3.c: New test.
* gcc.dg/vect/pr65947-4.c: New test.
* gcc.dg/vect/pr65947-5.c: New test.
* gcc.dg/vect/pr65947-6.c: New test.
* gcc.dg/vect/pr65947-7.c: New test.
* gcc.dg/vect/pr65947-8.c: New test.
* gcc.dg/vect/pr65947-9.c: New test.
* gcc.dg/vect/pr65947-10.c: New test.
* gcc.dg/vect/pr65947-11.c: New test.


Added:
trunk/gcc/testsuite/gcc.dg/vect/pr65947-1.c
trunk/gcc/testsuite/gcc.dg/vect/pr65947-10.c
trunk/gcc/testsuite/gcc.dg/vect/pr65947-11.c
trunk/gcc/testsuite/gcc.dg/vect/pr65947-2.c
trunk/gcc/testsuite/gcc.dg/vect/pr65947-3.c
trunk/gcc/testsuite/gcc.dg/vect/pr65947-4.c
trunk/gcc/testsuite/gcc.dg/vect/pr65947-5.c
trunk/gcc/testsuite/gcc.dg/vect/pr65947-6.c
trunk/gcc/testsuite/gcc.dg/vect/pr65947-7.c
trunk/gcc/testsuite/gcc.dg/vect/pr65947-8.c
trunk/gcc/testsuite/gcc.dg/vect/pr65947-9.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/doc/sourcebuild.texi
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/lib/target-supports.exp
trunk/gcc/tree-vect-loop.c
trunk/gcc/tree-vect-stmts.c
trunk/gcc/tree-vectorizer.h

[Bug go/67968] go1: internal compiler error: in write_specific_type_functions, at go/gofrontend/types.cc:1812

[vogt at linux dot vnet.ibm.com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67968

--- Comment #6 from Dominik Vogt  ---
@Ian: Any hints to help Gong isolating the problem?

[Bug go/67968] go1: internal compiler error: in write_specific_type_functions, at go/gofrontend/types.cc:1812

[vogt at linux dot vnet.ibm.com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67968

--- Comment #5 from Dominik Vogt  ---
Unfortunately I cannot reproduce this yet.  Please try to identify the "faulty"
source file and strip it down to the minimum.

1. Find out in which file the ICE occurs.

1.a Recompile GCC with debug information, e.g. with

$ make CXXFLAGS="-g3 -O2" CFLAGS="$CXXFLAGS" GOCFLAGS="$CXXFLAGS" -j 7 all

1.b Use the commands from comment 4 to run the gccgo-5 command line manually. 
This whould still generate an ICE.

1.c Run the go1 command in gdb.  Just add the option

  -wrapper gdb,--args

at the end of the gccgo-5 command line.  Then type "run" in the debugger.  Gdb
should automatically stop when the ICE occurs.  From there, check the available
information in the current stack frame and the higher ones and see if you can
find the name of the current source file or the function name and possibly the
line number in some structure.  I know nothing about the Go frontent, so
unfortunately you have to figure that out on your own.

2. Strip down the sources as much as possible.

Now that you know which file generates the ICE, try to strip down the api
module as much as possible.  The first step is to get rid of all the other
files in the package.  Next, remove the imports in the faulty file and finally
strip down the file as much as possible to make a standalone test case.

[Bug middle-end/65855] missing optimization: triangular numbers

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65855

--- Comment #4 from Richard Biener  ---
match.pd now has the desired simplification.  So we run into

(chrec_apply
  (varying_loop = 1
)
  (chrec = {1, +, {2, +, 1}_1}_1)
  (x = (long unsigned int) n_3(D) + 18446744073709551615)
  (res = scev_not_known))

the question is if we can handle this kind of CHREC in chrec_apply generally
or not.

{ x, +, { y, +, C}_N }_N

specifically. I suppose it's simply x + y*X + C*X*(X+1)/2.

Now the question is whether it's generally profitable to handle this.  We'll
see.

I have a patch that produces

(chrec_apply
  (varying_loop = 1
)
  (chrec = {1, +, {2, +, 1}_1}_1)
  (x = (long unsigned int) n_3(D) + 18446744073709551615)
  (res = (((long unsigned int) n_3(D) * ((long unsigned int) n_3(D) +
18446744073709551615)) /[ex] 2 + (uint64_t) n_3(D) * 2) +
18446744073709551615))

but that's somehow off.

Index: gcc/tree-chrec.c
===
--- gcc/tree-chrec.c(revision 229233)
+++ gcc/tree-chrec.c(working copy)
@@ -602,19 +602,37 @@ chrec_apply (unsigned var,
   switch (TREE_CODE (chrec))
 {
 case POLYNOMIAL_CHREC:
-  if (evolution_function_is_affine_p (chrec))
+  if (CHREC_VARIABLE (chrec) != var)
+   return build_polynomial_chrec
+   (CHREC_VARIABLE (chrec),
+chrec_apply (var, CHREC_LEFT (chrec), x),
+chrec_apply (var, CHREC_RIGHT (chrec), x));
+  else if (evolution_function_is_affine_p (chrec))
{
- if (CHREC_VARIABLE (chrec) != var)
-   return build_polynomial_chrec
- (CHREC_VARIABLE (chrec),
-  chrec_apply (var, CHREC_LEFT (chrec), x),
-  chrec_apply (var, CHREC_RIGHT (chrec), x));
-
  /* "{a, +, b} (x)"  ->  "a + b*x".  */
  x = chrec_convert_rhs (type, x, NULL);
  res = chrec_fold_multiply (TREE_TYPE (x), CHREC_RIGHT (chrec), x);
  res = chrec_fold_plus (type, CHREC_LEFT (chrec), res);
}
+  else if (evolution_function_is_affine_p (CHREC_RIGHT (chrec))
+  && CHREC_VARIABLE (CHREC_RIGHT (chrec)) == var)
+   {
+ /* "{a, +, {b, +, c} } (x)" -> "a + b*x + c*x*(x+1)/2".  */
+ tree chrecr = CHREC_RIGHT (chrec);
+ x = chrec_convert_rhs (type, x, NULL);
+ /* c*x*(x+1)/2  */
+ res = chrec_fold_plus (type, x, build_int_cst (type, 1));
+ res = chrec_fold_multiply (type, res, x);
+ res = fold_build2 (EXACT_DIV_EXPR, type, res,
+build_int_cst (type, 2));
+ res = chrec_fold_multiply (type, CHREC_RIGHT (chrecr), res);
+ /* + b*x  */
+ res = chrec_fold_plus (type, res,
+chrec_fold_multiply (type, x,
+ CHREC_LEFT (chrecr)));
+ /* + a  */
+ res = chrec_fold_plus (type, res, CHREC_LEFT (chrec));
+   }
   else if (TREE_CODE (x) == INTEGER_CST
   && tree_int_cst_sgn (x) == 1)
/* testsuite/.../ssa-chrec-38.c.  */


produces 76 for n == 11 and 298 for n == 23.  Testcase that works with SCCP
disabled:

extern void abort (void);

typedef __UINT64_TYPE__ uint64_t;
typedef __UINT32_TYPE__ uint32_t;
uint64_t __attribute__((noinline,noclone))
triangle(uint32_t n)
{
  uint64_t t = 0;
  for (uint64_t i=1;i<=n;i++) t += i;
  return t;
}

int main()
{
  uint64_t t11 = triangle (11);
  uint64_t t23 = triangle (23);
  if (t11 != 66 || t23 != 276)
abort ();
  return 0;
}

[Bug libgcc/66883] config/epiphany/udivsi3-float.c:52: bad if test ?

[amylaar at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66883

--- Comment #2 from Jorn Wolfgang Rennecke  ---
Author: amylaar
Date: Fri Oct 23 11:57:26 2015
New Revision: 229236

URL: https://gcc.gnu.org/viewcvs?rev=229236&root=gcc&view=rev
Log:
PR libgcc/66883
* config/epiphany/udivsi3-float.c: Fix CONCISE test, and comment typo.

N.B., this is not active code, just documenting a previous approach for this
function in C.

Modified:
trunk/libgcc/ChangeLog
trunk/libgcc/config/epiphany/udivsi3-float.c

[Bug middle-end/68068] [6 Regression] ICE: in get_untransformed_body, at cgraph.c:3268

[trippels at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68068

--- Comment #1 from Markus Trippelsdorf  ---
markus@x4 Release % cat WebDOMActivityLogger.ii
template  struct A {
  static void deletePtr(T *p1) { delete p1; }
};
template  class PassOwnPtr;
template  PassOwnPtr adoptPtr(T *);
template  class PassOwnPtr {
public:
  template  PassOwnPtr(U);
  ~PassOwnPtr() { A::deletePtr(m_ptr); }
  T *m_ptr;
};

class WebDOMActivityLogger {
public:
  virtual ~WebDOMActivityLogger() {}
};
class V8DOMActivityLogger {
public:
  void operator delete(void *);
  virtual ~V8DOMActivityLogger() {}
  static void setActivityLogger(int, PassOwnPtr);
};

WebDOMActivityLogger *a;
int b;
void setDOMActivityLogger() {
  V8DOMActivityLogger::setActivityLogger(b, adoptPtr(a));
}

[Bug c/68062] [4.9/5/6 Regression] ICE when comparing vectors

[ienkovich at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68062

--- Comment #3 from Ilya Enkovich  ---
(In reply to Richard Biener from comment #1)
> I suppose that is Iljas fault (only happens on trunk).

Yes, -funsigned-char seems to be my fault.  I'll have look.

[Bug testsuite/68063] FAIL: libgomp.c++/member-2.C execution test

[vries at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68063

vries at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from vries at gcc dot gnu.org ---
Committed patch for testsuite, marking resolved-fixed.

[Bug testsuite/68063] FAIL: libgomp.c++/member-2.C execution test

[vries at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68063

--- Comment #3 from vries at gcc dot gnu.org ---
Author: vries
Date: Fri Oct 23 10:45:13 2015
New Revision: 229229

URL: https://gcc.gnu.org/viewcvs?rev=229229&root=gcc&view=rev
Log:
Add missing private clause in libgomp.c++/member-2.C

2015-10-23  Tom de Vries  

PR testsuite/68063
* testsuite/libgomp.c++/member-2.C (A::m1): Add missing private clause.

Modified:
trunk/libgomp/ChangeLog
trunk/libgomp/testsuite/libgomp.c++/member-2.C

[Bug ipa/68057] [6 Regression] 450.soplex in SPEC CPU 2006 failed to build

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68057

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-10-23
 Ever confirmed|0   |1

--- Comment #2 from H.J. Lu  ---
It was caused by r229148.

[Bug rtl-optimization/67443] [5/6 regression] DSE removes required store instruction

[vogt at linux dot vnet.ibm.com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67443

--- Comment #21 from Dominik Vogt  ---
Trying to write a test case for Power, I was unable to force the bug to show in
the first place.  Although I can force the addresses used into different
registers, dead store elimination on power does not kill the first store.  ==>
No test case for Power.

[Bug middle-end/68068] [6 Regression] ICE: in get_untransformed_body, at cgraph.c:3268

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68068

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |6.0

[Bug middle-end/68068] New: [6 Regression] ICE: in get_untransformed_body, at cgraph.c:3268

[trippels at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68068

Bug ID: 68068
   Summary: [6 Regression] ICE: in get_untransformed_body, at
cgraph.c:3268
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: trippels at gcc dot gnu.org
CC: hubicka at gcc dot gnu.org
  Target Milestone: ---

Trying to build the Chromium browser with trunk shows:

markus@x4 Release % g++ -c -fno-strict-aliasing -O2 WebDOMActivityLogger.ii
../../third_party/WebKit/Source/web/WebDOMActivityLogger.cpp:102:1: internal
compiler error: in get_untransformed_body, at cgraph.c:3268
 } // namespace blink
 ^
0x909133 cgraph_node::get_untransformed_body()
../../gcc/gcc/cgraph.c:3268
0x914c2f cgraph_node::expand()
../../gcc/gcc/cgraphunit.c:1955
0x9164e0 expand_all_functions
../../gcc/gcc/cgraphunit.c:2119
0x9164e0 symbol_table::compile()
../../gcc/gcc/cgraphunit.c:2472
0x918a57 symbol_table::compile()
../../gcc/gcc/cgraphunit.c:2536
0x918a57 symbol_table::finalize_compilation_unit()
../../gcc/gcc/cgraphunit.c:2562
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

Reducing...

[Bug c++/57443] Captured variable hide the parameter if they have the same name in Lambdas

[ville.voutilainen at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57443

Ville Voutilainen  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||ville.voutilainen at gmail dot 
com
   Assignee|unassigned at gcc dot gnu.org  |ville.voutilainen at 
gmail dot com

--- Comment #1 from Ville Voutilainen  ---
Mine.

[Bug target/62109] __gthr_i486_lock_cmp_xchg missing clobber

[ktietz at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62109

--- Comment #11 from Kai Tietz  ---
(In reply to David from comment #10)
> (In reply to Kai Tietz from comment #5)
> > This patch is clear stage 1 material. 
> 
> We're in stage 1.  Is it time?

Sure, patch for it is welcome.

> The patch adds the memory clobber, but I think the conclusion here was to
> remove __gthr_i486_lock_cmp_xchg since it only applies to (the no longer
> supported) win95.

Right, I prefer this.

[Bug libgomp/68063] FAIL: libgomp.c++/member-2.C execution test

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68063

--- Comment #2 from Jakub Jelinek  ---
Is that the
  #pragma omp parallel private (f)
{
  f = false;
#pragma omp single
#pragma omp taskloop lastprivate (a, T::t, b, n)
part?  That indeed sounds like a data race, there should be private (r) or
private (R::r) clause most likely on the taskloop.

[Bug target/68059] [arm] libgcc uses __write to report error

[nsz at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68059

nsz at gcc dot gnu.org changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
   Last reconfirmed||2015-10-23
 Resolution|INVALID |---
 Ever confirmed|0   |1

--- Comment #2 from nsz at gcc dot gnu.org ---
bionic does not have __write either, it seems the android ndk
changed it to write (which is not in the c namespace so might
be wrong, but i guess the code is about to crash anyway).

i'm reopening since i think the compiler should not assume
such symbols to be available on a linux system (fwiw it is
not part of the linux standard base abi core spec:
http://refspecs.linuxfoundation.org/LSB_4.1.0/LSB-Core-generic/LSB-Core-generic/libc.html#AEN2405
or any other abi spec i'm aware of).

[Bug middle-end/68066] [6 Regression]: ICE in max_value, at wide-int.cc

[ienkovich at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68066

--- Comment #2 from Ilya Enkovich  ---
(In reply to Richard Biener from comment #1)
> Hmm, the boolean type shouldn't have precision 0.  Ilya?

Yep.  I sent a patch to fix it.

https://gcc.gnu.org/ml/gcc-patches/2015-10/msg02298.html

[Bug middle-end/68066] [6 Regression]: ICE in max_value, at wide-int.cc

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68066

Richard Biener  changed:

   What|Removed |Added

 CC||ienkovich at gcc dot gnu.org
   Target Milestone|--- |6.0

--- Comment #1 from Richard Biener  ---
Hmm, the boolean type shouldn't have precision 0.  Ilya?

[Bug c/68067] Wrong constant folding

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68067

--- Comment #2 from Richard Biener  ---
Yep.  Btw, what happens is that we see

 if (tem - 1 != 2147483647)

and that is obviously always true unless tem - 1 wraps from -2147483648 to
2147483647 which would invoke undefined behavior.

[Bug c++/68052] No printf format warnings in C++ code for macro in system headers

[manu at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68052

--- Comment #5 from Manuel López-Ibáñez  ---
(In reply to Olivier Blin from comment #3)
> Quoting Martin Sebor's answer from the gcc-help mailing list:
> https://gcc.gnu.org/ml/gcc-help/2015-10/msg00128.html

What Martin describes there is a different bug that occurs when there is a
whole stack of macro expansions (which is not the case in the original
testcase). My guess is that it is https://gcc.gnu.org/PR52998

Most of the bugs in the macro unwinder are known and triaged, but no one has
stepped up to fix them. See I) at https://gcc.gnu.org/wiki/Better_Diagnostics

[Bug c/68065] Size calculations for VLAs can overflow

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68065

--- Comment #1 from Andrew Pinski  ---
VLA also does not detect stack overflows either.

[Bug c/68067] Wrong constant folding

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68067

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #1 from Andrew Pinski  ---
Try with -fsantize=undefined?  This is a signed integer overflow as -1
--2147483648 is undefined due to - -2147483648 overflows.

[Bug c++/68052] No printf format warnings in C++ code for macro in system headers

[manu at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68052

--- Comment #4 from Manuel López-Ibáñez  ---
(In reply to Olivier Blin from comment #2)
> No, the difference that I observe is that, in this specific case involving a
> macro in system header, there is a warning in C, and none in C++.
> This has been discussed with Martin Sebor on the gcc-help mailing list.

What you observe is only a manifestation of something else. The reason for that
is that the warning for C is given at ", which is a token that does not come
from the system header, while the warning for C++ is given at ), which is a
token that comes from the system header, hence, the warning is suppressed. If
you move the "%lld" within the macro definition, you'll see the same behavior
for both (minus the column numbers).

But you can keep the bug reports separated if that pleases you, if makes not
difference on whether they will get fixed either way, it just makes less likely
that you will get notified if the bug gets eventually fixed through the other
report.

[Bug libgomp/68063] FAIL: libgomp.c++/member-2.C execution test

[vries at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68063

--- Comment #1 from vries at gcc dot gnu.org ---
Created attachment 36566
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36566&action=edit
minimized version

[Bug c/68067] New: Wrong constant folding

[ishiura-compiler at ml dot kwansei.ac.jp]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68067

Bug ID: 68067
   Summary: Wrong constant folding
   Product: gcc
   Version: trans-mem
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ishiura-compiler at ml dot kwansei.ac.jp
  Target Milestone: ---

GCC-6.0.0 miscompiles the following code.
GCC-4.3.6 or later versions miscompile too.


$cat error.c

int main(void) {
  int a = -1;
  static int b = -2147483647 - 1;
  static int c = 0;
  int t = a - (b - c);
  if (t != 2147483647) { __builtin_abort(); }
  return 0;
}


$gcc-6.0 error.c -O3 && ./a.out
[1]25603 abort (core dumped)  ./a.out


$gcc-6.0 -v
Using built-in specs.
COLLECT_GCC=gcc-6.0
COLLECT_LTO_WRAPPER=$HOME/opt/gcc-6.0.0/libexec/gcc/x86_64-pc-linux-gnu/6.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --prefix=$HOME/opt/gcc-6.0.0
--enable-languages=c --disable-multilib --program-suffix=-6.0
Thread model: posix
gcc version 6.0.0 20151022 (experimental) (GCC)

[Bug middle-end/68066] New: [6 Regression]: ICE in max_value, at wide-int.cc

[ubizjak at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68066

Bug ID: 68066
   Summary: [6 Regression]: ICE in max_value, at wide-int.cc
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ubizjak at gmail dot com
  Target Milestone: ---
Target: alpha-linux-gnu

Recent regression, FAILs in the testsuite on alpha-linux-gnu:

FAIL: gcc.dg/fold-compare-7.c (internal compiler error)
FAIL: gcc.dg/fold-compare-7.c (test for excess errors)

This failure can be triggered with a crosscompiler to alpha-linux-gnu:

~/gcc-build-alpha/gcc/cc1 -O2 -fpreprocessed -quiet fold-compare-7.c 
fold-compare-7.c: In function ‘f’:
fold-compare-7.c:8:1: internal compiler error: in max_value, at wide-int.cc:308
 }
 ^
0xe0c6c8 wi::max_value(unsigned int, signop)
../../gcc-svn/trunk/gcc/wide-int.cc:308
0xdb537c integer_all_onesp(tree_node const*)
../../gcc-svn/trunk/gcc/tree.c:2372
0xdb5452 integer_all_onesp(tree_node const*)
../../gcc-svn/trunk/gcc/tree.c:2364
0xeccbd7 generic_simplify_VEC_COND_EXPR
/home/uros/gcc-build-alpha/gcc/generic-match.c:23341
0x7b4bdb fold_ternary_loc(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*, tree_node*)
../../gcc-svn/trunk/gcc/fold-const.c:11351
0xe292cf gimple_resimplify3(gimple**, code_helper*, tree_node*, tree_node**,
tree_node* (*)(tree_node*))
../../gcc-svn/trunk/gcc/gimple-match-head.c:222
0xe93abd gimple_simplify(gimple*, code_helper*, tree_node**, gimple**,
tree_node* (*)(tree_node*), tree_node* (*)(tree_node*))
../../gcc-svn/trunk/gcc/gimple-match-head.c:718
0x826370 fold_stmt_1
../../gcc-svn/trunk/gcc/gimple-fold.c:3605
0x82740d fold_stmt(gimple_stmt_iterator*, tree_node* (*)(tree_node*))
../../gcc-svn/trunk/gcc/gimple-fold.c:3816
0xbff600 execute
../../gcc-svn/trunk/gcc/tree-ssa-forwprop.c:2326
Please submit a full bug report,


(gdb) bt
#0  internal_error (gmsgid=0x123aab5 "in %s, at %s:%d") at
../../gcc-svn/trunk/gcc/diagnostic.c:1134
#1  0x0105dffc in fancy_abort (file=, line=308, 
function=0x11af765 
"max_value") at ../../gcc-svn/trunk/gcc/diagnostic.c:1209
#2  0x00e0c6c9 in wi::max_value (precision=308, sgn=) at
../../gcc-svn/trunk/gcc/wide-int.cc:308
#3  0x00db537d in integer_all_onesp (expr=0x2e876b40) at
../../gcc-svn/trunk/gcc/tree.c:2372
#4  0x00db5453 in integer_all_onesp (expr=0x2e886c30) at
../../gcc-svn/trunk/gcc/tree.c:2364
#5  0x00eccbd8 in generic_simplify_VEC_COND_EXPR (loc=0, code=18544485,
type=0x2e889738, op0=0x134, op1=0x2e8869b0, 
op2=0x2e886960) at generic-match.c:23341

(gdb) f 2
#2  0x00e0c6c9 in wi::max_value (precision=308, sgn=) at
../../gcc-svn/trunk/gcc/wide-int.cc:308
308   gcc_checking_assert (precision != 0);
(gdb) up
#3  0x00db537d in integer_all_onesp (expr=0x2e876b40) at
../../gcc-svn/trunk/gcc/tree.c:2372
2372  return wi::max_value (TYPE_PRECISION (TREE_TYPE (expr)), UNSIGNED) ==
expr;

(gdb) p debug_generic_expr (expr)
0
$2 = void
(gdb) p debug_tree (expr)
  constant 0>
$3 = void

[Bug middle-end/68046] -ftrapv doesn't catch leaq-based overflows on x86-64

[ebotcazou at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68046

Eric Botcazou  changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot gnu.org

--- Comment #6 from Eric Botcazou  ---
> If we have a variant that doesn't require libubsan (which is not available
> on all targets) then yes, that would indeed be nice.  Of course it's
> restricted to the C family languages while -ftrapv was "working" for all
> languages before (though IIRC Ada has its own implementation).

Correct, the Ada compiler doesn't use -ftrapv at all, it's too broad.

[Bug ipa/68064] [6 Regression] ICE: in meet_with, at ipa-cp.c:874

[trippels at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68064

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-10-23
 CC||hubicka at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Markus Trippelsdorf  ---
markus@x4 Release % cat typer.ii
template  class A {
public:
  class B;
  typedef typename Config::template D::type TypeHandle;
  static A *Tagged() { return B::New(B::kTagged); }
  static TypeHandle Union(TypeHandle);
  static TypeHandle Representation(TypeHandle, typename Config::Region *);
  bool Is();
};

template  class A::B {
  friend A;
  enum { kTaggedPointer = 1 << 31, kTagged = kTaggedPointer };
  static A *New(int p1) { return Config::from_bitset(p1); }
};

struct C {
  typedef int Region;
  template  struct D { typedef A *type; };
  static A *from_bitset(unsigned);
};
A *C::from_bitset(unsigned p1) { return reinterpret_cast *>(p1); }

namespace {
int *a;
void fn1(A *p1) { A::Union(A::Representation(p1, a)); }
}

void fn2() {
  A b;
  A *c = b.Is() ? 0 : A::Tagged();
  fn1(c);
}

markus@x4 Release % g++ -c -O2 typer.ii
typer.ii:33:1: internal compiler error: in meet_with, at ipa-cp.c:874

[Bug c/68065] New: Size calculations for VLAs can overflow

[ch3root at openwall dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68065

Bug ID: 68065
   Summary: Size calculations for VLAs can overflow
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ch3root at openwall dot com
  Target Milestone: ---

The following program crashes while writing to a buffer:

#include 
#include 

int main(void)
{
  size_t size = SIZE_MAX / sizeof(int) + 2;
  int buf[size];

  printf("%zu\n", sizeof(buf));
  for (size_t i = 0; i < size; i++)
buf[i] = 1;

  return 0;
}

(Compile without optimization or make sure the loop is not optimized away.)

It would be better to detect an overflow in the size calculation and crash
right away, before any harm is done.

While at it, size of VLAs could probably be limited to PRTDIFF_MAX to be in
line with ordinary arrays.

[Bug rtl-optimization/67609] [5/6 Regression] Generates wrong code for SSE2 _mm_load_pd

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67609

--- Comment #26 from Richard Biener  ---
(In reply to Richard Henderson from comment #22)
> (In reply to Jeffrey A. Law from comment #21)
> > So going back to the original problem, for a subreg of a multi-word reg, 
> > why can't we simplify that down to a suitably sized reg?
> 
> Because we're dealing with registers of different sizes.
> 
> Assigning to a subreg as the low-part of a multi-word pseudo only
> makes sense when talking about general registers, which is the only
> place that "word_mode" applies.

Hmm, I don't see this documented anywhere.  In fact there is no such
thing as a "vector register", there are only vector modes.  And we
are using %xmm for plain SF/DFmode all over the place.

Note that in the particular case the mode we subreg is TImode,
not a vector mode.

> When talking about vector registers, which are universally larger
> than word-mode, we cannot simply assign to a subreg.
> 
> There is a vec_set named pattern that can perform an insertion into
> a vector element, like what's being demonstrated in the test source
> here.  Ideally that's how we'd have expanded this originally.

Indeed, if expand can see we are setting the low part of a vector
then it should try using vec_set.  Auditing of other targets might
be necessary here though.  And of course the i386 backend might
end up choosing movdf for this operation anyway...

> We already have ix86_cannot_change_mode_class to avoid the cases
> that we knew we couldn't support, e.g. QI and HImode loads/stores.
> But perhaps we should prevent all size-changing mode changes for
> the vector registers.

That may be a workaround for x86 but I don't see how this fixes the
issue in general given that targets may have general registers larger
than word_mode (is x32 TARGET_64BIT?).

[Bug ipa/68057] [6 Regression] 450.soplex in SPEC CPU 2006 failed to build

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68057

Richard Biener  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org
Version|5.3.0   |6.0
 Blocks||67056
   Target Milestone|--- |6.0

--- Comment #1 from Richard Biener  ---
Honza, probably caused by your devirt fix?


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67056
[Bug 67056] [5 regression] Wrong code generated

[Bug tree-optimization/68060] [6 Regression] ICE on valid code at -O3 on x86_64-linux-gnu in vect_get_vec_def_for_operand, at tree-vect-stmts.c:1413

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68060

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-10-23
  Known to work||5.2.0
   Target Milestone|--- |6.0
Summary|ICE on valid code at -O3 on |[6 Regression] ICE on valid
   |x86_64-linux-gnu in |code at -O3 on
   |vect_get_vec_def_for_operan |x86_64-linux-gnu in
   |d, at   |vect_get_vec_def_for_operan
   |tree-vect-stmts.c:1413  |d, at
   ||tree-vect-stmts.c:1413
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed.

[Bug c/68062] [4.9/5/6 Regression] ICE when comparing vectors

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68062

--- Comment #2 from Richard Biener  ---
The FEs are missing a VIEW_CONVERT_EXPR around one of the operands.  But I
suppose 4.8 is correct in rejecting this compare with mismatched sign
(though the rejection isn't dependent on the sign of char).

[Bug c/68062] [4.9/5/6 Regression] ICE when comparing vectors

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68062

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |4.9.4
Summary|ICE when comparing vectors  |[4.9/5/6 Regression] ICE
   ||when comparing vectors

[Bug c/68062] ICE when comparing vectors

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68062

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-10-23
 CC||ienkovich at gcc dot gnu.org
Version|unknown |5.2.0
 Ever confirmed|0   |1
  Known to fail||4.9.2, 5.2.0, 6.0

--- Comment #1 from Richard Biener  ---
Looks like a C FE issue.  The C++ FE also spits out bogus(?)

t.c: In function 'void ret(char)':
t.c:8:19: warning: narrowing conversion of 'a' from 'char' to 'unsigned char'
inside { } [-Wnarrowing]
   uv4qi d={a,a,a,a};
   ^
t.c:8:19: warning: narrowing conversion of 'a' from 'char' to 'unsigned char'
inside { } [-Wnarrowing]
t.c:8:19: warning: narrowing conversion of 'a' from 'char' to 'unsigned char'
inside { } [-Wnarrowing]
t.c:8:19: warning: narrowing conversion of 'a' from 'char' to 'unsigned char'
inside { } [-Wnarrowing]
t.c:5:6: error: mismatching comparison operand types
 void ret(char a)
  ^
v4qi
uv4qi
D.2265 = c != d;
t.c:5:6: internal compiler error: verify_gimple failed


Note that GCC 4.8 rejects the comparison with

t.c: In function ‘ret’:
t.c:9:9: error: comparing vectors with different element types
   v = (c!=d);
 ^


With -funsigned-char the ICE is different:

> /abuild/rguenther/trunk-g/gcc/cc1plus -quiet t.c -funsigned-char
t.c: In function 'void ret(char)':
t.c:5:6: internal compiler error: in optab_handler, at optabs-query.h:32
 void ret(char a)
  ^
0xae59c7 optab_handler(optab_tag, machine_mode)
/space/rguenther/src/svn/trunk/gcc/optabs-query.h:32
0x12a4f3e expand_vector_operations_1


I suppose that is Iljas fault (only happens on trunk).

[Bug ipa/68064] [6 Regression] ICE: in meet_with, at ipa-cp.c:874

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68064

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |6.0

[Bug ipa/68064] New: [6 Regression] ICE: in meet_with, at ipa-cp.c:874

[trippels at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68064

Bug ID: 68064
   Summary: [6 Regression] ICE: in meet_with, at ipa-cp.c:874
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: trippels at gcc dot gnu.org
CC: jamborm at gcc dot gnu.org
  Target Milestone: ---

r228491 causes during build of Chromium browser:

In file included from ../../v8/src/heap/heap.h:18:0,
 from ../../v8/src/contexts.h:8,
 from ../../v8/src/isolate.h:17,
 from ../../v8/src/factory.h:8,
 from ../../v8/src/bootstrapper.h:8,
 from ../../v8/src/compiler/typer.cc:9:
../../v8/src/heap/spaces.h:3016:7: internal compiler error: in meet_with, at
ipa-cp.c:874
 class LargeObjectIterator : public ObjectIterator {
   ^
0x133609f ipcp_alignment_lattice::meet_with(unsigned int, unsigned int)
../../gcc/gcc/ipa-cp.c:874
0x1337eef propagate_alignment_accross_jump_function
../../gcc/gcc/ipa-cp.c:1615
0x1337eef propagate_constants_accross_call
../../gcc/gcc/ipa-cp.c:1958
0x133b548 propagate_constants_topo
../../gcc/gcc/ipa-cp.c:2825
0x133b548 ipcp_propagate_stage
../../gcc/gcc/ipa-cp.c:2922
0x133de5c ipcp_driver
../../gcc/gcc/ipa-cp.c:4581
0x133de5c execute
../../gcc/gcc/ipa-cp.c:4673
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

Reducing...

[Bug libgomp/68063] New: FAIL: libgomp.c++/member-2.C execution test

[vries at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68063

Bug ID: 68063
   Summary: FAIL: libgomp.c++/member-2.C execution test
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgomp
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
  Target Milestone: ---

While testing an x86_64 bootstrap build from r229170 I noticed the following
failure for -m32:
...
FAIL: libgomp.c++/member-2.C execution test
...

When trying to reproduce from the command line, the test failed in 31 out of
10.000 runs, so it only fails in 0.3% of the runs.

First mentioned on gcc-testresults at
https://gcc.gnu.org/ml/gcc-testresults/2015-10/msg01506.html for r228794.

Also seems to fail on powerpc64-unknown-linux-gnu (
https://gcc.gnu.org/ml/gcc-testresults/2015-10/msg02051.html ) with -m32.

[Bug sanitizer/68042] [6 Regression] c-c++-common/asan/(memcmp-1.c|sanity-check-pure-c-1.c) failures on x86_64-apple-darwin14 after r229111

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68042

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #7 from Dominique d'Humieres  ---
> Should be fix on trunk.

Confirmed, Thanks for the quick fix. Closing.

[Bug c++/68061] Can't use [[deprecated]] with requires clause

[chrisb2244 at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68061

--- Comment #1 from Christian Butcher  ---
Created attachment 36565
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36565&action=edit
Short compilable (or not) case showing problem

Commenting out the function definition for 'foo' allows compilation using 
g++ -std=c++1z reqClauseDep.cpp -o Test

[Bug sanitizer/68042] [6 Regression] c-c++-common/asan/(memcmp-1.c|sanity-check-pure-c-1.c) failures on x86_64-apple-darwin14 after r229111

[chefmax at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68042

--- Comment #6 from Maxim Ostapenko  ---
Should be fix on trunk.

[Bug sanitizer/68042] [6 Regression] c-c++-common/asan/(memcmp-1.c|sanity-check-pure-c-1.c) failures on x86_64-apple-darwin14 after r229111

[chefmax at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68042

--- Comment #5 from Maxim Ostapenko  ---
Author: chefmax
Date: Fri Oct 23 07:22:37 2015
New Revision: 229212

URL: https://gcc.gnu.org/viewcvs?rev=229212&root=gcc&view=rev
Log:
Fix ASan output pattern tests on Darwin.

gcc/testsuite/

PR sanitizer/68042
* c-c++-common/asan/memcmp-1.c: Adjust test to pass on Darwin.
* c-c++-common/asan/sanity-check-pure-c-1.c: Likewise.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/c-c++-common/asan/memcmp-1.c
trunk/gcc/testsuite/c-c++-common/asan/sanity-check-pure-c-1.c