[Bug middle-end/66633] [5/6 regression] ICE on valid verify_gimple failed with OpenMP

2015-07-01 Thread ebotcazou at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66633

--- Comment #10 from Eric Botcazou ebotcazou at gcc dot gnu.org ---
Author: ebotcazou
Date: Wed Jul  1 08:21:40 2015
New Revision: 225227

URL: https://gcc.gnu.org/viewcvs?rev=225227root=gccview=rev
Log:
PR middle-end/66633
* tree-nested.c (convert_nonlocal_omp_clauses): Initialize need_chain
to true if the function is nested and if not optimizing.
(convert_local_omp_clauses): Initialize need_frame to true if the
function contains nested functions and if not optimizing.

Added:
trunk/gcc/testsuite/gfortran.dg/gomp/pr66633.f90
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-nested.c


[Bug rtl-optimization/66626] [4.9/5/6 Regression] gcc.dg/torture/stackalign/non-local-goto-5.c segfaults w/ -mregparm=3

2015-07-01 Thread ubizjak at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66626

--- Comment #8 from Uroš Bizjak ubizjak at gmail dot com ---
(In reply to H.J. Lu from comment #7)
 Created attachment 35882 [details]
 A patch

Uhuh... it's correct. We want to limit regparm value with local_regparm.

However, the unpatched compiler shows that LRA doesn't correctly handle argp
elimination. However, patched compiler will avoid this situation.

[Bug middle-end/66633] [5/6 regression] ICE on valid verify_gimple failed with OpenMP

2015-07-01 Thread ebotcazou at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66633

--- Comment #11 from Eric Botcazou ebotcazou at gcc dot gnu.org ---
Author: ebotcazou
Date: Wed Jul  1 08:24:29 2015
New Revision: 225228

URL: https://gcc.gnu.org/viewcvs?rev=225228root=gccview=rev
Log:
PR middle-end/66633
* tree-nested.c (convert_nonlocal_omp_clauses): Initialize need_chain
to true if the function is nested and if not optimizing.
(convert_local_omp_clauses): Initialize need_frame to true if the
function contains nested functions and if not optimizing.

Added:
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/gomp/pr66633.f90
  - copied unchanged from r225227,
trunk/gcc/testsuite/gfortran.dg/gomp/pr66633.f90
Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/testsuite/ChangeLog
branches/gcc-5-branch/gcc/tree-nested.c


[Bug middle-end/66685] [6 Regression] conftest.c:16:1: internal compiler error: in as_a, at is-a.h:192

2015-07-01 Thread rsandifo at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66685

--- Comment #8 from rsandifo at gcc dot gnu.org rsandifo at gcc dot gnu.org 
---
Author: rsandifo
Date: Wed Jul  1 08:41:33 2015
New Revision: 225230

URL: https://gcc.gnu.org/viewcvs?rev=225230root=gccview=rev
Log:
gcc/
PR bootstrap/66685
* rtl.c (classify_insn): Handle returns in PARALLELs.

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


[Bug c++/60365] multiple noreturn attribute specifiers in a single declaration doesn't result in a diagnostic

2015-07-01 Thread paolo.carlini at oracle dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60365

Paolo Carlini paolo.carlini at oracle dot com changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Assignee|paolo.carlini at oracle dot com|unassigned at gcc dot 
gnu.org

--- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com ---
Fixed.


[Bug c++/66717] New: In variable declaration, decltype incorrectly deduces return type of function returning const reference to int

2015-07-01 Thread charlie at charliedyson dot net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66717

Bug ID: 66717
   Summary: In variable declaration, decltype incorrectly deduces
return type of function returning const reference to
int
   Product: gcc
   Version: 5.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: charlie at charliedyson dot net
  Target Milestone: ---

Applying decltype to a function returning const int  appears to deduce int
rather than const int . This only seems to happen when declaring a variable.
Here's an example showing this using error messages:

#include iostream
#include string

const int const_ref_to_int ()
{
  static int i;
  return i;
}

const std::string const_ref_to_string ()
{
  static std::string s;
  return s;
}

int main ()
{
  // error: invalid conversion from 'const char*' to 'int' [-fpermissive]
  decltype (const_ref_to_int ()) x = foo;

  // error: invalid initialization of reference of type 'const string
  // {aka const std::__cxx11::basic_stringchar}' from expression
  // of type 'double'
  decltype (const_ref_to_string ()) y = 1.23;

  // But this is fine:
  static_assert (
std::is_samedecltype (const_ref_to_int ()), const int(), );
}

Above example on Godbolt: https://goo.gl/sWgdc9


[Bug middle-end/66633] [5/6 regression] ICE on valid verify_gimple failed with OpenMP

2015-07-01 Thread ebotcazou at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66633

Eric Botcazou ebotcazou at gcc dot gnu.org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 CC|ebotcazou at gcc dot gnu.org   |
 Resolution|--- |FIXED
   Target Milestone|--- |5.2

--- Comment #12 from Eric Botcazou ebotcazou at gcc dot gnu.org ---
Fixed everywhere.


[Bug c++/66701] __cxxabiv1::__cxa_pure_virtual - can it take an argument of the pointer to the function that was called, please?

2015-07-01 Thread jmcguiness at liquidcapital dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66701

Jason McG jmcguiness at liquidcapital dot com changed:

   What|Removed |Added

 Status|CLOSED  |UNCONFIRMED
 Resolution|WONTFIX |---

--- Comment #5 from Jason McG jmcguiness at liquidcapital dot com ---
Hang on: what has the ABI got to do with this? This discussion has got side
tracked onto a red herring. The code emitted by gcc apparently *eventually*
calls __cxa_pure_virtual, as we know. The signature of __cxa_pure_virtual could
be irrelevant: what is relevant is the *code path* that calls this function.
The code path could be enhanced to provide the extra information to the user.
The ABI function can then be left as is.

So I've re-opened the enhancement request.


[Bug c++/60365] multiple noreturn attribute specifiers in a single declaration doesn't result in a diagnostic

2015-07-01 Thread paolo at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60365

--- Comment #2 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org ---
Author: paolo
Date: Wed Jul  1 09:08:17 2015
New Revision: 225234

URL: https://gcc.gnu.org/viewcvs?rev=225234root=gccview=rev
Log:
/cp
2015-07-01  Paolo Carlini  paolo.carl...@oracle.com

PR c++/60365
* parser.c (cp_parser_check_std_attribute): New.
(cp_parser_std_attribute_list): Call it.

/testsuite
2015-07-01  Paolo Carlini  paolo.carl...@oracle.com

PR c++/60365
* g++.dg/cpp0x/gen-attrs-60.C: New.
* g++.dg/cpp1y/attr-deprecated-2.C: Likewise.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/gen-attrs-60.C
trunk/gcc/testsuite/g++.dg/cpp1y/attr-deprecated-2.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/parser.c
trunk/gcc/testsuite/ChangeLog


[Bug c++/65090] GCC produces instruction with bad alignment on SPARC when using -O

2015-07-01 Thread jason at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65090
Bug 65090 depends on bug 65945, which changed state.

Bug 65945 Summary: C++ alignment of nullptr_t is 1 and might cause unaligned 
stores to the frame
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65945

   What|Removed |Added

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


[Bug c++/65945] C++ alignment of nullptr_t is 1 and might cause unaligned stores to the frame

2015-07-01 Thread jason at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65945

Jason Merrill jason at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |jason at gcc dot gnu.org
   Target Milestone|--- |5.2

--- Comment #15 from Jason Merrill jason at gcc dot gnu.org ---
Fixed for GCC 5.2.


[Bug testsuite/66723] gcc.target/i386/vararg-loc.c FAILs

2015-07-01 Thread vries at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66723

--- Comment #1 from vries at gcc dot gnu.org ---
Author: vries
Date: Wed Jul  1 17:33:01 2015
New Revision: 225266

URL: https://gcc.gnu.org/viewcvs?rev=225266root=gccview=rev
Log:
Use scan-rtl-dump in i386/vararg-loc.c

2015-07-01  Tom de Vries  t...@codesourcery.com

PR testsuite/66723
* gcc.target/i386/vararg-loc.c: Use scan-rtl-dump instead of
scan-assembler.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/i386/vararg-loc.c


[Bug inline-asm/66727] New: Example artificial dependency incorrect

2015-07-01 Thread T.E.Baldwin99 at members dot leeds.ac.uk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66727

Bug ID: 66727
   Summary: Example artificial dependency incorrect
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: inline-asm
  Assignee: unassigned at gcc dot gnu.org
  Reporter: T.E.Baldwin99 at members dot leeds.ac.uk
  Target Milestone: ---

The in the section on extended asm the manual states:

The compiler may move the addition back before the volatile asm. To make it
work as expected, add an artificial dependency to the asm by referencing a
variable in the subsequent code, for example:

 asm volatile (mtfsf 255,%1 : =X (sum) : f (fpenv));
 sum = x + y;

However this addition does not depend on the asm and the code is permitted to
be reordered to:

 sum = x + y;
 asm volatile (mtfsf 255,%1 : =X (sum1) : f (fpenv));

The example should perhaps pass x or y though the asm:

 asm volatile (mtfsf 255,%1 : +g (x) : f (fpenv));
 sum = x + y;


[Bug debug/66728] CONST_WIDE_INT causes corrupted DWARF debug info

2015-07-01 Thread pinskia at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66728

--- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org ---
Related to bug 31690.


[Bug fortran/56520] Syntax error causes misleading message: Invalid character in name

2015-07-01 Thread kargl at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56520

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4
 CC||kargl at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |kargl at gcc dot gnu.org
   Severity|normal  |enhancement


[Bug c++/65945] C++ alignment of nullptr_t is 1 and might cause unaligned stores to the frame

2015-07-01 Thread jason at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65945

--- Comment #14 from Jason Merrill jason at gcc dot gnu.org ---
Author: jason
Date: Wed Jul  1 17:59:19 2015
New Revision: 225270

URL: https://gcc.gnu.org/viewcvs?rev=225270root=gccview=rev
Log:
PR c++/65945
* decl.c (cxx_init_decl_processing): Set TYPE_ALIGN of nullptr_t.
* class.c (layout_nonempty_base_or_field): Warn if that affects
the offset of a field.

Added:
trunk/gcc/testsuite/g++.dg/abi/nullptr-align.C
trunk/gcc/testsuite/g++.dg/abi/nullptr-align2.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/class.c
trunk/gcc/cp/decl.c


[Bug target/66509] the new clang-based assembler in Xcode 7 on 10.11 fails on the libjava/java/lang/reflect/natArray.cc file from FSF gcc 5.1 at -m32

2015-07-01 Thread mrs at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66509

mrs at gcc dot gnu.org mrs at gcc dot gnu.org changed:

   What|Removed |Added

  Known to work||6.0
   Target Milestone|--- |6.0
  Known to fail||5.1.0


[Bug tree-optimization/66729] New: Segfault starting with r224967

2015-07-01 Thread pthaugen at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66729

Bug ID: 66729
   Summary: Segfault starting with r224967
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pthaugen at gcc dot gnu.org
CC: bergner at gcc dot gnu.org, dje at gcc dot gnu.org,
rsandifo at gcc dot gnu.org
  Target Milestone: ---
  Host: powerpc64-unknown-linux-gnu
Target: powerpc64-unknown-linux-gnu
 Build: powerpc64-unknown-linux-gnu

Ran in to following error starting with subject revision while trying to
bootstrap.

Config:
/home/pthaugen/src/gcc/gcc_hunt/gcc/configure
--prefix=/home/pthaugen/install/gcc/gcc_hunt --enable-decimal-float
--enable-lto --with-as=/home/pthaugen/install/binutils/binutils-2.25/bin/as
--with-ld=/home/pthaugen/install/binutils/binutils-2.25/bin/ld
--with-gmp=/home/pthaugen/install/gcc-host-libs --without-ppl --without-cloog
--enable-languages=c,c++,fortran


/home/pthaugen/work/build/gcc/gcc_hunt/./gcc/xgcc
-B/home/pthaugen/work/build/gcc/gcc_hunt/./gcc/
-B/home/pthaugen/install/gcc/gcc_hunt/powerpc64-unknown-linux-gnu/bin/
-B/home/pthaugen/install/gcc/gcc_hunt/powerpc64-unknown-linux-gnu/lib/ -isystem
/home/pthaugen/install/gcc/gcc_hunt/powerpc64-unknown-linux-gnu/include
-isystem
/home/pthaugen/install/gcc/gcc_hunt/powerpc64-unknown-linux-gnu/sys-include   
-g -O2 -m32 -O2  -g -O2 -DIN_GCC-W -Wall -Wwrite-strings -Wcast-qual
-Wno-format -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition 
-isystem ./include   -fPIC -mlong-double-128 -mno-minimal-toc -g -DIN_LIBGCC2
-fbuilding-libgcc -fno-stack-protector   -fPIC -mlong-double-128
-mno-minimal-toc -I. -I. -I../../.././gcc
-I/home/pthaugen/src/gcc/gcc_hunt/gcc/libgcc
-I/home/pthaugen/src/gcc/gcc_hunt/gcc/libgcc/.
-I/home/pthaugen/src/gcc/gcc_hunt/gcc/libgcc/../gcc
-I/home/pthaugen/src/gcc/gcc_hunt/gcc/libgcc/../include
-I/home/pthaugen/src/gcc/gcc_hunt/gcc/libgcc/../libdecnumber/dpd
-I/home/pthaugen/src/gcc/gcc_hunt/gcc/libgcc/../libdecnumber -DHAVE_CC_TLS  -o
decContext.o -MT decContext.o -MD -MP -MF decContext.dep -c
/home/pthaugen/src/gcc/gcc_hunt/gcc/libgcc/../libdecnumber/decContext.c
In file included from
/home/pthaugen/src/gcc/gcc_hunt/gcc/libgcc/../libdecnumber/decContext.h:246:0,
 from
/home/pthaugen/src/gcc/gcc_hunt/gcc/libgcc/../libdecnumber/decContext.c:38:
/home/pthaugen/src/gcc/gcc_hunt/gcc/libgcc/../libdecnumber/decContext.c: In
function ‘__decContextStatusToString’:
/home/pthaugen/src/gcc/gcc_hunt/gcc/libgcc/../libdecnumber/decContextSymbols.h:16:34:
internal compiler error: Segmentation fault
 #define decContextStatusToString __decContextStatusToString
  ^
/home/pthaugen/src/gcc/gcc_hunt/gcc/libgcc/../libdecnumber/decContext.c:352:13:
note: in expansion of macro ‘decContextStatusToString’
 const char *decContextStatusToString(const decContext *context) {
 ^
0x10d2ed5f crash_signal
/home/pthaugen/src/gcc/gcc_hunt/gcc/gcc/toplev.c:366
0x117fee78 trim_filename(char const*)
/home/pthaugen/src/gcc/gcc_hunt/gcc/gcc/diagnostic.c:944
0x117fff87 fancy_abort(char const*, int, char const*)
/home/pthaugen/src/gcc/gcc_hunt/gcc/gcc/diagnostic.c:1340
0x111d635f inchash::add_expr(tree_node const*, inchash::hash)
/home/pthaugen/src/gcc/gcc_hunt/gcc/gcc/tree.c:7708
0x10d7b167 iterative_hash_expr
/home/pthaugen/src/gcc/gcc_hunt/gcc/gcc/tree.h:4519
0x10d7e7df tree_operand_hash::hash(tree_node const*)
/home/pthaugen/src/gcc/gcc_hunt/gcc/gcc/tree-hash-traits.h:33
0x10d802f7 simple_hashmap_traitstree_operand_hash::hash(tree_node* const)
/home/pthaugen/src/gcc/gcc_hunt/gcc/gcc/hash-map-traits.h:126
0x110c9f9f hash_maptree_node*, vectree_node*, va_heap, vl_ptr,
val_ssa_equiv_hash_traits::get(tree_node* const)
/home/pthaugen/src/gcc/gcc_hunt/gcc/gcc/hash-map.h:141
0x110c9367 uncprop_into_successor_phis
/home/pthaugen/src/gcc/gcc_hunt/gcc/gcc/tree-ssa-uncprop.c:408
0x110c9737 uncprop_dom_walker::before_dom_children(basic_block_def*)
/home/pthaugen/src/gcc/gcc_hunt/gcc/gcc/tree-ssa-uncprop.c:495
0x11628d93 dom_walker::walk(basic_block_def*)
/home/pthaugen/src/gcc/gcc_hunt/gcc/gcc/domwalk.c:183
0x110c9933 execute
/home/pthaugen/src/gcc/gcc_hunt/gcc/gcc/tree-ssa-uncprop.c:544
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See http://gcc.gnu.org/bugs.html for instructions.

[Bug c++/65090] GCC produces instruction with bad alignment on SPARC when using -O

2015-07-01 Thread jason at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65090

Jason Merrill jason at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||jason at gcc dot gnu.org
 Resolution|--- |DUPLICATE
   Target Milestone|--- |5.2

--- Comment #5 from Jason Merrill jason at gcc dot gnu.org ---
Fixed by the patch for 65945.

*** This bug has been marked as a duplicate of bug 65945 ***


[Bug c++/65945] C++ alignment of nullptr_t is 1 and might cause unaligned stores to the frame

2015-07-01 Thread jason at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65945

Jason Merrill jason at gcc dot gnu.org changed:

   What|Removed |Added

 CC||dirk.bo...@inform-ac.com

--- Comment #16 from Jason Merrill jason at gcc dot gnu.org ---
*** Bug 65090 has been marked as a duplicate of this bug. ***


[Bug preprocessor/53690] [C++11] \u0000 and \U00000000 are wrongly encoded as U+0001.

2015-07-01 Thread paolo.carlini at oracle dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53690

Paolo Carlini paolo.carlini at oracle dot com changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |paolo.carlini at oracle 
dot com

--- Comment #9 from Paolo Carlini paolo.carlini at oracle dot com ---
Mine.


[Bug tree-optimization/66729] Segfault starting with r224967

2015-07-01 Thread dje at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66729

--- Comment #1 from David Edelsohn dje at gcc dot gnu.org ---
Is this the bootstrap failure that Segher tracked to Richard Sandiford? 
Richard already posted a patch.


[Bug ipa/65844] [5/6 Regression] ICE (verify_cgraph_node failed) on i686-linux-gnu

2015-07-01 Thread marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65844

--- Comment #3 from Martin Liška marxin at gcc dot gnu.org ---
Even with fixed configure script, I am unable to reproduce the issue on
x86_64-linux-pc with -m32 option added.

Martin

[Bug tree-optimization/66720] gcc.dg/vect/pr48052.c FAILs

2015-07-01 Thread ro at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66720

Rainer Orth ro at gcc dot gnu.org changed:

   What|Removed |Added

   Target Milestone|--- |6.0


[Bug target/66509] the new clang-based assembler in Xcode 7 on 10.11 fails on the libjava/java/lang/reflect/natArray.cc file from FSF gcc 5.1 at -m32

2015-07-01 Thread howarth.at.gcc at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66509

Jack Howarth howarth.at.gcc at gmail dot com changed:

   What|Removed |Added

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

--- Comment #20 from Jack Howarth howarth.at.gcc at gmail dot com ---
Confirmed as fixed on x86_64-apple-darwin15.


[Bug tree-optimization/66719] gcc.dg/vect/bb-slp-32.c FAILs

2015-07-01 Thread ro at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66719

--- Comment #1 from Rainer Orth ro at gcc dot gnu.org ---
Created attachment 35884
  -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35884action=edit
bb-slp-32.c.142t.slp2 dump


[Bug fortran/66578] [F2008] Invalid free on allocate(...,source=a(:)) in block

2015-07-01 Thread vehre at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66578

vehre at gcc dot gnu.org changed:

   What|Removed |Added

  Attachment #35806|0   |1
is obsolete||

--- Comment #17 from vehre at gcc dot gnu.org ---
Created attachment 35887
  -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35887action=edit
Extended version of Mikael's patch

I have encountered some other issues with the patch for 44672 that are not
fixed by Mikael's patch. Using Mikael's patch as a base I could resolve these
issues:

- when the rank in an assignment was decreased (i.e., the rank of the object(!)
on the rhs was greater then the one needed for the assignment, e.q. selecting a
row from a matrix, testcases are allocate_with_source_7/8), 
- twice indirect element addressing (e.q. using a section of a vector of
indices to address elements in a second array, as in the new testcase
allocate_with_source_9.f08 provided by the patch), and
- fixing char_length_8.

In most cases the issues occurred because the offset was not set correctly when
rebasing to one for the lower bound. 

Please have look whether the things to accomplish can be done easier. This
patch bootstraps and regtests fine x86_64-linux-gnu/f21.


[Bug tree-optimization/66719] New: gcc.dg/vect/bb-slp-32.c FAILs

2015-07-01 Thread ro at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66719

Bug ID: 66719
   Summary: gcc.dg/vect/bb-slp-32.c FAILs
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
CC: rguenth at gcc dot gnu.org
  Target Milestone: ---
  Host: sparc*-sun-solaris2.*
Target: sparc*-sun-solaris2.*
 Build: sparc*-sun-solaris2.*

Since 20150624, gcc.dg/vect/bb-slp-32.c FAILs on Solaris/SPARC:

FAIL: gcc.dg/vect/bb-slp-32.c -flto -ffat-lto-objects  scan-tree-dump slp2
vectorization is not profitable
FAIL: gcc.dg/vect/bb-slp-32.c scan-tree-dump slp2 vectorization is not
profitable

I'm attaching the dump.

  Rainer


[Bug target/66523] the new clang-based assembler in Xcode 7 on 10.11 fails on libobjc/NXConstStr.m

2015-07-01 Thread howarth.at.gcc at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66523

--- Comment #5 from Jack Howarth howarth.at.gcc at gmail dot com ---
This is the last remaining issue with building gcc trunk using the clang-based
assembler in Xcode 7. Should we check in Iain's proposed fix for now as a
stop-gap fix


[Bug jit/66628] jit: Provide a way to add arbitrary options to the toplev command line

2015-07-01 Thread dmalcolm at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66628

--- Comment #2 from David Malcolm dmalcolm at gcc dot gnu.org ---
Author: dmalcolm
Date: Wed Jul  1 14:31:48 2015
New Revision: 225253

URL: https://gcc.gnu.org/viewcvs?rev=225253root=gccview=rev
Log:
PR jit/66628: add gcc_jit_context_add_command_line_option

Backport of r225205 (adb2df5592cdf8e70aa44c0f3c447da1d0134f4c)
from trunk

gcc/jit/ChangeLog:
Backport from mainline r225205
2015-06-30  David Malcolm  dmalc...@redhat.com

PR jit/66628
* docs/cp/topics/contexts.rst (Additional command-line options):
New section.
* docs/topics/compatibility.rst: New file.
* docs/topics/contexts.rst (Additional command-line options): New
section.
* docs/topics/index.rst: Add compatibility.rst.
* docs/_build/texinfo/libgccjit.texi: Regenerate.
* jit-playback.c (make_fake_args): Add call to
append_command_line_options.
* jit-recording.c: Within namespace gcc::jit...
(recording::context::~context): Free the optnames within
m_command_line_options.
(recording::context::set_bool_option): Likewise.
(recording::context::add_command_line_option): New method.
(recording::context::append_command_line_options): New method.
(recording::context::dump_reproducer_to_file): Add command-line
options.
* jit-recording.h: Within namespace gcc::jit...
(recording::context::add_command_line_option): New method.
(recording::context::append_command_line_options): New method.
(recording::context::m_command_line_options): New field.
* libgccjit++.h (gccjit::context::add_command_line_option): New
method.
* libgccjit.c (gcc_jit_context_add_command_line_option): New API
entrypoint.
* libgccjit.h (gcc_jit_context_add_command_line_option): New API
entrypoint.
(LIBGCCJIT_HAVE_gcc_jit_context_add_command_line_option): New
macro.
* libgccjit.map: Put existing symbols within LIBGCCJIT_ABI_0; add
LIBGCCJIT_ABI_1 and gcc_jit_context_add_command_line_option.

gcc/testsuite/ChangeLog:
Backport from mainline r225205
2015-06-30  David Malcolm  dmalc...@redhat.com

PR jit/66628
* jit.dg/all-non-failing-tests.h: Add note about
test-extra-options.c.
* jit.dg/test-extra-options.c: New testcase.

Added:
branches/gcc-5-branch/gcc/jit/docs/topics/compatibility.rst
branches/gcc-5-branch/gcc/testsuite/jit.dg/test-extra-options.c
Modified:
branches/gcc-5-branch/gcc/jit/ChangeLog
branches/gcc-5-branch/gcc/jit/docs/_build/texinfo/libgccjit.texi
branches/gcc-5-branch/gcc/jit/docs/cp/topics/contexts.rst
branches/gcc-5-branch/gcc/jit/docs/topics/contexts.rst
branches/gcc-5-branch/gcc/jit/docs/topics/index.rst
branches/gcc-5-branch/gcc/jit/jit-playback.c
branches/gcc-5-branch/gcc/jit/jit-recording.c
branches/gcc-5-branch/gcc/jit/jit-recording.h
branches/gcc-5-branch/gcc/jit/libgccjit++.h
branches/gcc-5-branch/gcc/jit/libgccjit.c
branches/gcc-5-branch/gcc/jit/libgccjit.h
branches/gcc-5-branch/gcc/jit/libgccjit.map
branches/gcc-5-branch/gcc/testsuite/ChangeLog
branches/gcc-5-branch/gcc/testsuite/jit.dg/all-non-failing-tests.h


[Bug tree-optimization/66721] [6 regression] gcc.target/i386/pr61403.c FAILs

2015-07-01 Thread ro at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66721

Rainer Orth ro at gcc dot gnu.org changed:

   What|Removed |Added

   Target Milestone|--- |6.0


[Bug tree-optimization/66721] New: [6 regression] gcc.target/i386/pr61403.c FAILs

2015-07-01 Thread ro at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66721

Bug ID: 66721
   Summary: [6 regression] gcc.target/i386/pr61403.c FAILs
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
CC: rguenth at gcc dot gnu.org
  Target Milestone: ---
  Host: i386-pc-solaris2.1[01], x86_64-unknown-linux-gnu
Target: i386-pc-solaris2.1[01], x86_64-unknown-linux-gnu
 Build: i386-pc-solaris2.1[01], x86_64-unknown-linux-gnu

For some time, gcc.target/i386/pr61403.c FAILs on Linux/x86 and Solaris/x86
(32-bit only):

FAIL: gcc.target/i386/pr61403.c scan-assembler blend

A reghunt identified the following patch as the culprit:

2015-06-08  Richard Biener  rguent...@suse.de

* tree-vect-stmts.c (vectorizable_load): Compute the pointer
adjustment for gaps at the end of a SLP load group properly.
* tree-vect-slp.c (vect_supported_load_permutation_p): Allow
all permutations we can generate.
(vect_transform_slp_perm_load): Use the correct group-size.

  Rainer


[Bug tree-optimization/66723] New: gcc.target/i386/vararg-loc.c FAILs

2015-07-01 Thread ro at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66723

Bug ID: 66723
   Summary: gcc.target/i386/vararg-loc.c FAILs
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
CC: vries at gcc dot gnu.org
  Target Milestone: ---
  Host: i386-pc-solaris2.1[01], x86_64-apple-darwin*
Target: i386-pc-solaris2.1[01], x86_64-apple-darwin*
 Build: i386-pc-solaris2.1[01], x86_64-apple-darwin*

The new gcc.target/i386/vararg-loc.c FAILs on Solaris/x86 when configured to
used
/usr/ccs/bin/as, and Mac OS X with the native assembler:

FAIL: gcc.target/i386/vararg-loc.c scan-assembler-times .loc 1 18 0 1
FAIL: gcc.target/i386/vararg-loc.c scan-assembler-times .loc 1 20 0 1

.loc support seems to be a gas-only feature, currently.

  Rainer


[Bug tree-optimization/66723] gcc.target/i386/vararg-loc.c FAILs

2015-07-01 Thread ro at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66723

Rainer Orth ro at gcc dot gnu.org changed:

   What|Removed |Added

   Target Milestone|--- |6.0


[Bug debug/66668] [6 regression] FAIL: gcc.dg/debug/dwarf2/stacked-qualified-types-3.c scan-assembler-times DIE \\([^\n]*\\) DW_TAG_(?:const|volatile|atomic|restrict)_type 8

2015-07-01 Thread ro at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=8

Rainer Orth ro at gcc dot gnu.org changed:

   What|Removed |Added

 Target|hppa64-hp-hpux11.11 |hppa64-hp-hpux11.11,
   ||*-*-solaris2.1[01],
   ||x86_64-unknown-linux-gnu
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-07-01
 CC||aldyh at gcc dot gnu.org,
   ||ro at gcc dot gnu.org
   Host|hppa64-hp-hpux11.11 |hppa64-hp-hpux11.11,
   ||*-*-solaris2.1[01],
   ||x86_64-unknown-linux-gnu
   Target Milestone|--- |6.0
Summary|FAIL:   |[6 regression] FAIL:
   |gcc.dg/debug/dwarf2/stacked |gcc.dg/debug/dwarf2/stacked
   |-qualified-types-3.c|-qualified-types-3.c
   |scan-assembler-times DIE|scan-assembler-times DIE
   |\\([^\n]*\\)|\\([^\n]*\\)
   |DW_TAG_(?:const|volatile|at |DW_TAG_(?:const|volatile|at
   |omic|restrict)_type 8   |omic|restrict)_type 8
 Ever confirmed|0   |1
  Build|hppa64-hp-hpux11.11 |hppa64-hp-hpux11.11,
   ||*-*-solaris2.1[01],
   ||x86_64-unknown-linux-gnu

--- Comment #1 from Rainer Orth ro at gcc dot gnu.org ---
This happens almost everywhere, it seems.  A reghunt confirmed that this
regression was caused by the debug-early merge.

  Rainer


[Bug tree-optimization/66720] New: gcc.dg/vect/pr48052.c FAILs

2015-07-01 Thread ro at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66720

Bug ID: 66720
   Summary: gcc.dg/vect/pr48052.c FAILs
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
CC: amker at gcc dot gnu.org
  Target Milestone: ---
  Host: *-*-solaris2.1[01]
Target: *-*-solaris2.1[01]
 Build: *-*-solaris2.1[01]

The new gcc.dg/vect/pr48052.c test FAILs on Solaris/SPARC:

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

both for 32 and 64-bit.

I'm attaching the dump.

  Rainer


[Bug tree-optimization/66720] gcc.dg/vect/pr48052.c FAILs

2015-07-01 Thread ro at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66720

--- Comment #1 from Rainer Orth ro at gcc dot gnu.org ---
Created attachment 35885
  -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35885action=edit
pr48052.c.132t.vect dump


[Bug jit/66700] Bogus gimplification of jit code using ptrs to functions

2015-07-01 Thread dmalcolm at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66700

--- Comment #5 from David Malcolm dmalcolm at gcc dot gnu.org ---
Author: dmalcolm
Date: Wed Jul  1 12:50:50 2015
New Revision: 225248

URL: https://gcc.gnu.org/viewcvs?rev=225248root=gccview=rev
Log:
PR jit/66700: set TREE_ADDRESSABLE when building an ADDR_EXPR

gcc/jit/ChangeLog:
PR jit/66700
* jit-playback.c (jit_mark_addressable): New function.
(gcc::jit::playback::lvalue::get_address): Call
jit_mark_addressable on the underlying tree.

gcc/testsuite/ChangeLog:
PR jit/66700
* jit.dg/all-non-failing-tests.h: Add
test-pr66700-observing-write-through-ptr.c.
* jit.dg/test-pr66700-observing-write-through-ptr.c: New testcase.


Added:
trunk/gcc/testsuite/jit.dg/test-pr66700-observing-write-through-ptr.c
Modified:
trunk/gcc/jit/ChangeLog
trunk/gcc/jit/jit-playback.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/jit.dg/all-non-failing-tests.h


[Bug rtl-optimization/66626] [4.9/5/6 Regression] gcc.dg/torture/stackalign/non-local-goto-5.c segfaults w/ -mregparm=3

2015-07-01 Thread hjl.tools at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66626

--- Comment #10 from H.J. Lu hjl.tools at gmail dot com ---
There is also

  else if (ix86_function_regparm (fntype, fndecl) == 3) 
{
  /* For regparm 3, we have no free call-clobbered registers in
 which to store the static chain.  In order to implement this,
 we have the trampoline push the static chain to the stack.
 However, we can't push a value below the return address when
 we call the nested function directly, so we have to use an
 alternate entry point.  For this we use ESI, and have the
 alternate entry point push ESI, so that things appear the
 same once we're executing the nested function.  */
  if (incoming_p)
{
  if (fndecl == current_function_decl)
ix86_static_chain_on_stack = true; 
  return gen_frame_mem (SImode,
plus_constant (Pmode,
   arg_pointer_rtx, -8)); 
}
  regno = SI_REG;
}


[Bug tree-optimization/66719] gcc.dg/vect/bb-slp-32.c FAILs

2015-07-01 Thread ro at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66719

Rainer Orth ro at gcc dot gnu.org changed:

   What|Removed |Added

   Target Milestone|--- |6.0


[Bug other/66722] New: libiberty/pex-unix.c warning: initialization from incompatible pointer type

2015-07-01 Thread richard at netbsd dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66722

Bug ID: 66722
   Summary: libiberty/pex-unix.c warning: initialization from
incompatible pointer type
   Product: gcc
   Version: 4.9.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: richard at netbsd dot org
  Target Milestone: ---

Created attachment 35886
  -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35886action=edit
pex_unix_wait returns pid_t  (as does wait())

noticed while building:
../../gcc-4.9.3/libiberty/pex-unix.c:325:3: warning: initialization from 
incompatible pointer type
../../gcc-4.9.3/libiberty/pex-unix.c:325:3: warning: (near initialization for 
'funcs.wait')
../../gcc-4.9.3/libiberty/pex-unix.c:325:3: warning: initialization from 
incompatible pointer type
../../gcc-4.9.3/libiberty/pex-unix.c:325:3: warning: (near initialization for 
'funcs.wait')

attached patch get over the int/pid_t confusion:

Also, from inspection I noticed waitpid() needs correction too.


[Bug fortran/66710] Unhelpful error message with unbalanced parenthesis

2015-07-01 Thread dominiq at lps dot ens.fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66710

Dominique d'Humieres dominiq at lps dot ens.fr changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr ---
Dup.

*** This bug has been marked as a duplicate of bug 56520 ***


[Bug tree-optimization/66718] Non-invariant ADDR_EXPR not vectorized

2015-07-01 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66718

Richard Biener rguenth at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-07-01
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener rguenth at gcc dot gnu.org ---
forwprop is the only one who does sth useful with the non-lowered form
(propagating the addresses into dereferences).  Eventually trying that
very specific transform during the lowering gives more freedom in pass
placement.

Indeed we'd like reassoc to run on the lowering result to expose CSE
opportunities.

I think lowering these makes sense in general and it's a much easier way
(implementation-wise) to get things vectorized as well.

Just do

  get_inner_reference (...)
  force_gimple_operand (...)


[Bug tree-optimization/66718] New: Non-invariant ADDR_EXPR not vectorized

2015-07-01 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66718

Bug ID: 66718
   Summary: Non-invariant ADDR_EXPR not vectorized
   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: jakub at gcc dot gnu.org
CC: mpolacek at gcc dot gnu.org, rguenth at gcc dot gnu.org
  Target Milestone: ---

E.g. on:
int *a[1024], b[1024];
struct S { int u, v, w, x; };
struct S c[1024];

void
f0 (void)
{
  for (int i = 0; i  1024; i++)
a[i] = b[0];
}

void
f1 (void)
{
  for (int i = 0; i  1024; i++)
{
  int *p = b[0];
  a[i] = p + i;
}
}

void
f2 (int *p)
{
  for (int i = 0; i  1024; i++)
a[i] = p[i];
}

void
f3 (void)
{
  for (int i = 0; i  1024; i++)
a[i] = b[i];
}

void
f4 (void)
{
  int *p = c[0].v;
  for (int i = 0; i  1024; i++)
a[i] = p[4 * i];
}

void
f5 (void)
{
  for (int i = 0; i  1024; i++)
a[i] = c[i].v;
}

with -O3 -mavx2 we vectorize only the loops where the address computation has
been lowered (f1, f2, f4) or is address of invariant (f0), but the vectorizer
is not able to vectorize ADDR_EXPR of non-invariant.

Richard thinks this would be best solved by lowering such ADDR_EXPR
assignments,
somewhere in between the last objsz pass and pre, maybe even before reassoc so
that it can optimize even that.


[Bug c++/66717] In variable declaration, decltype incorrectly deduces return type of function returning const reference to int

2015-07-01 Thread charlie at charliedyson dot net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66717

--- Comment #2 from Charlie charlie at charliedyson dot net ---
I think you may be right that it's only the diagnostic that's wrong. The
following compiles fine https://goo.gl/eyuv17

  static int foo = 1;
  decltype (const_ref_to_int ()) x = foo;
  static_assert (std::is_samedecltype (x), const int(), );


[Bug c++/66666] ARM wrong copy constructor address on multiple inheritance

2015-07-01 Thread jgreenhalgh at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=6

James Greenhalgh jgreenhalgh at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-07-01
 Ever confirmed|0   |1

--- Comment #15 from James Greenhalgh jgreenhalgh at gcc dot gnu.org ---
(In reply to Antonio Poggiali from comment #14)
  
  Your toolchain is arm-none-linux-gnueabi , but you build with
  -mfloat-abi=hard - do you have suitable hard-float libraries on the target?
  
 
 I have only hard-float libraries and related system header files.
 
  How was the toolchain configured
  (arm-poky-linux-gnueabi/arm-poky-linux-gnueabi-g++ -v)?
  
 
 Snip

Thanks, I've reproduced the failure using the configuration above.

Looks like we can drop most of the command line arguments and still tickle the
segmentation fault

 
  What userspace is running on the target?
 
 Sorry but I don't understand the question. Could you explain a little?

Debian/Ubuntu/Android etc. I've been able to reproduce it with a Ubuntu 12.04.4
userspace. But I haven't yet understood the issue.


[Bug rtl-optimization/66626] [4.9/5/6 Regression] gcc.dg/torture/stackalign/non-local-goto-5.c segfaults w/ -mregparm=3

2015-07-01 Thread hjl.tools at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66626

--- Comment #9 from H.J. Lu hjl.tools at gmail dot com ---
(In reply to Uroš Bizjak from comment #8)
 (In reply to H.J. Lu from comment #7)
  Created attachment 35882 [details]
  A patch
 
 Uhuh... it's correct. We want to limit regparm value with local_regparm.
 
 However, the unpatched compiler shows that LRA doesn't correctly handle argp
 elimination. However, patched compiler will avoid this situation.

LRA should check that it is impossible to pass 3 parameters plus
a hidden chain into nested functions for x86.

[Bug middle-end/66432] libgomp.c/appendix-a/a.29.1.c -O2 -g: type mismatch between an SSA_NAME and its symbol

2015-07-01 Thread vries at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66432

vries at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||ice-on-valid-code, patch

--- Comment #6 from vries at gcc dot gnu.org ---
https://gcc.gnu.org/ml/gcc-patches/2015-07/msg00034.html


[Bug c++/66666] ARM wrong copy constructor address on multiple inheritance

2015-07-01 Thread antonio.poggiali at datalogic dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=6

--- Comment #16 from Antonio Poggiali antonio.poggiali at datalogic dot com 
---
(In reply to James Greenhalgh from comment #15)
  
   What userspace is running on the target?
  
  Sorry but I don't understand the question. Could you explain a little?
 
 Debian/Ubuntu/Android etc. I've been able to reproduce it with a Ubuntu
 12.04.4 userspace. But I haven't yet understood the issue.

I'm using Yocto-generated Linux systems. I had the defect on systems build with
angstrom and also with poky. I had the defect on systems based on different HW
vendors systems (atmel  altera).

Currently i'm working on: Linux sama5d4ek
3.18.0-linux4sam_5.0-alpha1-00061-gfeb4121 #1 Tue Jun 30 11:14:11 CEST 2015
armv7l GNU/Linux

Do I answered you question?


[Bug fortran/56520] Syntax error causes misleading message: Invalid character in name

2015-07-01 Thread dominiq at lps dot ens.fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56520

Dominique d'Humieres dominiq at lps dot ens.fr changed:

   What|Removed |Added

 CC||casey.webster at gmail dot com

--- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr ---
*** Bug 66710 has been marked as a duplicate of this bug. ***


[Bug c++/66686] Instantiation of dependent template template parameter with non-dependent template rejected

2015-07-01 Thread ppalka at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66686

Patrick Palka ppalka at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |6.0

--- Comment #8 from Patrick Palka ppalka at gcc dot gnu.org ---
Fixed.


[Bug fortran/65073] dynamic character assignment gives wrong result

2015-07-01 Thread dominiq at lps dot ens.fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65073

--- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr ---
Question asked more than three months ago

 Any plan to back port the fix to 4.9?

Still present in gcc version 4.9.3. Without answer I'll resolve this PR as
FIXED.


[Bug c++/66717] In variable declaration, decltype incorrectly deduces return type of function returning const reference to int

2015-07-01 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66717

Jonathan Wakely redi at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-07-01
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org ---
The static_assert suggests the deduction is correct, so I'm not sure, but the
problem could just be a misleading diagnostic.

Trying to initialize the const int could be attempting to create a temporary
of type int (which the reference could bind to) and then giving an error
complaining that the creation of that temporary fails.

Presumably it tries the same thing in the string case, but when creating a
string temporary fails it gives a useful error, not an error about an unwanted
side-effect.


[Bug libstdc++/66624] libstdc++ iostream uninitialized data

2015-07-01 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66624

--- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org ---
I'm not sure, but I don't yet see how _M_state wouldn't get initialized.


[Bug jit/66546] No way to disable check for unreachable blocks

2015-07-01 Thread dmalcolm at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66546

--- Comment #4 from David Malcolm dmalcolm at gcc dot gnu.org ---
Author: dmalcolm
Date: Wed Jul  1 14:35:53 2015
New Revision: 225254

URL: https://gcc.gnu.org/viewcvs?rev=225254root=gccview=rev
Log:
PR jit/66546: Add gcc_jit_context_set_bool_allow_unreachable_blocks

Backport of r225206 (04feb56e6acd497d0add042232afd7940ef61adb)
from trunk

gcc/jit/ChangeLog:
Backport from mainline r225206
2015-06-30  David Malcolm  dmalc...@redhat.com

PR jit/66546
* docs/cp/topics/contexts.rst
(gccjit::context::set_bool_allow_unreachable_blocks): New.
* docs/topics/compatibility.rst (LIBGCCJIT_ABI_2): New.
* docs/topics/contexts.rst (Options): Add notes discussing the
transition from enums to entrypoints for new options.
(gcc_jit_context_set_bool_allow_unreachable_blocks): New.
* docs/_build/texinfo/libgccjit.texi: Regenerate.
* jit-common.h (gcc::jit::inner_bool_option): New enum.
* jit-recording.c: Within namespace gcc::jit...
(recording::context::context): Handle m_inner_bool_options.
(recording::context::set_inner_bool_option): New.
(inner_bool_option_reproducer_strings): New.
(recording::context::log_all_options): Log the inner bool
options.
(recording::context::log_inner_bool_option): New.
(recording::context::dump_reproducer_to_file): Write initializers
for inner bool options.
(recording::function::validate): Don't check for block
reachability if INNER_BOOL_OPTION_ALLOW_UNREACHABLE_BLOCKS is set.
* jit-recording.h: Within namespace gcc::jit...
(recording::context::set_inner_bool_option): New.
(recording::context::get_inner_bool_option): New.
(recording::context::log_inner_bool_option): New.
(recording::context::m_inner_bool_options): New.
* libgccjit++.h
(gccjit::context::set_bool_allow_unreachable_blocks): New.
* libgccjit.c
(gcc_jit_context_set_bool_allow_unreachable_blocks): New.
* libgccjit.h: Add note about options present in the
initial release of libgccjit.
(gcc_jit_context_set_bool_allow_unreachable_blocks): New API
entrypoint.
(LIBGCCJIT_HAVE_gcc_jit_context_set_bool_allow_unreachable_blocks):
New macro.
* libgccjit.map (LIBGCCJIT_ABI_2): New, containing...
(gcc_jit_context_set_bool_allow_unreachable_blocks): ...this new
entrypoint.

gcc/testsuite/ChangeLog:
Backport from mainline r225206
2015-06-30  David Malcolm  dmalc...@redhat.com

PR jit/66546
* jit.dg/all-non-failing-tests.h: Add note about
test-validly-unreachable-block.c.
* jit.dg/test-validly-unreachable-block.c: New file.

Added:
branches/gcc-5-branch/gcc/testsuite/jit.dg/test-validly-unreachable-block.c
Modified:
branches/gcc-5-branch/gcc/jit/ChangeLog
branches/gcc-5-branch/gcc/jit/docs/_build/texinfo/libgccjit.texi
branches/gcc-5-branch/gcc/jit/docs/cp/topics/contexts.rst
branches/gcc-5-branch/gcc/jit/docs/topics/compatibility.rst
branches/gcc-5-branch/gcc/jit/docs/topics/contexts.rst
branches/gcc-5-branch/gcc/jit/jit-common.h
branches/gcc-5-branch/gcc/jit/jit-recording.c
branches/gcc-5-branch/gcc/jit/jit-recording.h
branches/gcc-5-branch/gcc/jit/libgccjit++.h
branches/gcc-5-branch/gcc/jit/libgccjit.c
branches/gcc-5-branch/gcc/jit/libgccjit.h
branches/gcc-5-branch/gcc/jit/libgccjit.map
branches/gcc-5-branch/gcc/testsuite/ChangeLog
branches/gcc-5-branch/gcc/testsuite/jit.dg/all-non-failing-tests.h


[Bug tree-optimization/66718] Non-invariant ADDR_EXPR not vectorized

2015-07-01 Thread mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66718

Marek Polacek mpolacek at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org
   Target Milestone|--- |6.0

--- Comment #2 from Marek Polacek mpolacek at gcc dot gnu.org ---
I've started looking into this.


[Bug jit/66546] No way to disable check for unreachable blocks

2015-07-01 Thread dmalcolm at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66546

David Malcolm dmalcolm at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #5 from David Malcolm dmalcolm at gcc dot gnu.org ---
Fixed in trunk as r225206.
Fixed in gcc-5-branch (for gcc 5.2) as r225254.
Resolving as fixed.


[Bug jit/66700] Bogus gimplification of jit code using ptrs to functions

2015-07-01 Thread dmalcolm at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66700

David Malcolm dmalcolm at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #7 from David Malcolm dmalcolm at gcc dot gnu.org ---
Fixed in trunk as r225248.
Fixed in gcc-5-branch (for gcc 5.2) as r225258.
Resolving as fixed.


[Bug jit/66700] Bogus gimplification of jit code using ptrs to functions

2015-07-01 Thread dmalcolm at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66700

--- Comment #6 from David Malcolm dmalcolm at gcc dot gnu.org ---
Author: dmalcolm
Date: Wed Jul  1 14:48:55 2015
New Revision: 225258

URL: https://gcc.gnu.org/viewcvs?rev=225258root=gccview=rev
Log:
PR jit/66700: set TREE_ADDRESSABLE when building an ADDR_EXPR

Backport of r225248 (f410e1f5b44007c6cf6609df0afc16e7dcfeabd2)
from trunk

gcc/jit/ChangeLog:
Backport from mainline r225248
2015-07-01  David Malcolm  dmalc...@redhat.com

PR jit/66700
* jit-playback.c (jit_mark_addressable): New function.
(gcc::jit::playback::lvalue::get_address): Call
jit_mark_addressable on the underlying tree.

gcc/testsuite/ChangeLog:
Backport from mainline r225248
2015-07-01  David Malcolm  dmalc...@redhat.com

PR jit/66700
* jit.dg/all-non-failing-tests.h: Add
test-pr66700-observing-write-through-ptr.c.
* jit.dg/test-pr66700-observing-write-through-ptr.c: New testcase.

Added:
   
branches/gcc-5-branch/gcc/testsuite/jit.dg/test-pr66700-observing-write-through-ptr.c
Modified:
branches/gcc-5-branch/gcc/jit/ChangeLog
branches/gcc-5-branch/gcc/jit/jit-playback.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog
branches/gcc-5-branch/gcc/testsuite/jit.dg/all-non-failing-tests.h


[Bug target/65867] [5/6 Regression] bootstrap fails for mingw32 due to missing header in ssp.c

2015-07-01 Thread daniel.f.starke at freenet dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65867

--- Comment #4 from Daniel Starke daniel.f.starke at freenet dot de ---
I have already sent a patch to the ML.
https://gcc.gnu.org/ml/gcc-patches/2015-04/msg01539.html


[Bug jit/66628] jit: Provide a way to add arbitrary options to the toplev command line

2015-07-01 Thread dmalcolm at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66628

David Malcolm dmalcolm at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #3 from David Malcolm dmalcolm at gcc dot gnu.org ---
Fixed in trunk as r225205.
Fixed in gcc-5-branch (for gcc 5.2) as r225253.
Resolving as fixed.


[Bug jit/66627] Tracker bug for jit bugs affecting ravi

2015-07-01 Thread dmalcolm at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66627
Bug 66627 depends on bug 66546, which changed state.

Bug 66546 Summary: No way to disable check for unreachable blocks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66546

   What|Removed |Added

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


[Bug jit/66627] Tracker bug for jit bugs affecting ravi

2015-07-01 Thread dmalcolm at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66627
Bug 66627 depends on bug 66700, which changed state.

Bug 66700 Summary: Bogus gimplification of jit code using ptrs to functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66700

   What|Removed |Added

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


[Bug jit/66627] Tracker bug for jit bugs affecting ravi

2015-07-01 Thread dmalcolm at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66627
Bug 66627 depends on bug 66628, which changed state.

Bug 66628 Summary: jit: Provide a way to add arbitrary options to the toplev 
command line
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66628

   What|Removed |Added

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


[Bug debug/66716] gomp4: libgomp.oacc-c/../libgomp.oacc-c-c++-common/kernels-loop.c -g ICE

2015-07-01 Thread vries at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66716

--- Comment #2 from vries at gcc dot gnu.org ---
Author: vries
Date: Wed Jul  1 15:54:14 2015
New Revision: 225259

URL: https://gcc.gnu.org/viewcvs?rev=225259root=gccview=rev
Log:
Fix compilation libgomp.oacc-c-c++-common/kernels-loop.c -g

2015-07-01  Tom de Vries  t...@codesourcery.com

PR tree-optimization/66716
* tree-cfg.c (gimple_split_block_before_cond_jump): Split before
cond_jump, instead of split after last nondebug insn before cond_jump.

* c-c++-common/goacc/kernels-loop-g.c: New test.

* testsuite/libgomp.oacc-c-c++-common/kernels-loop-g.c: New test.

Added:
branches/gomp-4_0-branch/gcc/testsuite/c-c++-common/goacc/kernels-loop-g.c
   
branches/gomp-4_0-branch/libgomp/testsuite/libgomp.oacc-c-c++-common/kernels-loop-g.c
Modified:
branches/gomp-4_0-branch/gcc/ChangeLog.gomp
branches/gomp-4_0-branch/gcc/testsuite/ChangeLog.gomp
branches/gomp-4_0-branch/gcc/tree-cfg.c
branches/gomp-4_0-branch/libgomp/ChangeLog.gomp


[Bug target/66563] [4.9 Regression] ICE (segmentation fault) on sh4-linux-gnu

2015-07-01 Thread glaubitz at physik dot fu-berlin.de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563

--- Comment #43 from John Paul Adrian Glaubitz glaubitz at physik dot 
fu-berlin.de ---
(In reply to John Paul Adrian Glaubitz from comment #42) 
 Cross your fingers ;).

Btw, could building the fixed gcc-4.9 with a compiler affected by this
particular bug still propagate the problem? Or, asking the other way around:
Should the latest package version rather be built with an older, unaffected gcc
version?

I'm asking because I am worried the current compiler might generate another
broken gcc. On the other hand, it's also not that trivial to downgrade the
compiler in the build root, albeit it is possible. It just involves lots of
manual work.

Or is the bootstrap process with its 3 stages enough to mitigate such problems?

Adrian


[Bug tree-optimization/66729] Segfault starting with r224967

2015-07-01 Thread rsandifo at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66729

rsandifo at gcc dot gnu.org rsandifo at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2015-07-01
 Ever confirmed|0   |1

--- Comment #2 from rsandifo at gcc dot gnu.org rsandifo at gcc dot gnu.org 
---
(In reply to David Edelsohn from comment #1)
 Is this the bootstrap failure that Segher tracked to Richard Sandiford? 
 Richard already posted a patch.

Yeah, it sounds like it.  I committed the patch as r225263 -- please let
me know if that didn't fix it.


[Bug middle-end/66633] [5/6 regression] ICE on valid verify_gimple failed with OpenMP

2015-07-01 Thread abensonca at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66633

--- Comment #13 from Andrew Benson abensonca at gmail dot com ---
(In reply to Eric Botcazou from comment #12)
 Fixed everywhere.

Thanks for the fix! Unfortunately, while this fixes some instances, it still
results in an ICE with optimization at -O1 or higher. 

Specifically:

Original test case: compiles OK with -O0; same ICE as before with -O1 or higher

Test case from comment #1: compiles OK with any optimization level.


[Bug c++/66730] New: Optimizer seems to make incorrect assumptions about function alignment

2015-07-01 Thread kustermann.martin at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66730

Bug ID: 66730
   Summary: Optimizer seems to make incorrect assumptions about
function alignment
   Product: gcc
   Version: 4.8.4
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kustermann.martin at gmail dot com
  Target Milestone: ---

Here is a reproduction of the problem

$ cat repro.cc
#include stdio.h

void Foobar()  { }

int main(int argc, char** argv) {
  unsigned long lowest_bit = reinterpret_castunsigned long(Foobar)  1;
  printf(Lowest bit of %p is %ld\n, Foobar, lowest_bit);
  return 0;
}

I expect this to print the address of the function and the lowest bit of that
address. Despite this assumption, the lowest bit is wrong:

$ g++ -O1 -o repro repro.cc
$ ./repro
Lowest bit of 0x40052d is 0

$ python
 bin(0x40052d)
'0b100010100101101'

So the function is not 2-byte aligned, but the lowest bit gets reported as
being 0.
= Either the functions must be guaranteed to have a proper alignment or the
optimizer cannot make alignment assumptions.

$ objdump -d repro
...
0040055f main:
  40055f:   48 83 ec 08 sub$0x8,%rsp
  400563:   b9 00 00 00 00  mov$0x0,%ecx
  400568:   ba 5d 05 40 00  mov$0x40055d,%edx
  40056d:   be 14 06 40 00  mov$0x400614,%esi
  400572:   bf 01 00 00 00  mov$0x1,%edi
  400577:   b8 00 00 00 00  mov$0x0,%eax
  40057c:   e8 df fe ff ff  callq  400460 __printf_chk@plt
  400581:   b8 00 00 00 00  mov$0x0,%eax
  400586:   48 83 c4 08 add$0x8,%rsp
  40058a:   c3  retq   
  40058b:   0f 1f 44 00 00  nopl   0x0(%rax,%rax,1)
...


Beginning with optimization level '-O2' the problem seems to go away, since the
function is then properly aligned (not sure if this is guaranteed or not).

$ g++ --version
g++ (Ubuntu 4.8.4-2ubuntu1~14.04) 4.8.4
Copyright (C) 2013 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


For reference with clang, this produces
$ clang repro.cc -o repro
$ ./repro
Lowest bit of 0x400530 is 0
$ clang --version
clang version 3.7.0 (trunk 239765)
Target: x86_64-unknown-linux-gnu
Thread model: posix



The workaround for us at the moment is to use an attribute:

void __attribute__((aligned(4))) Foobar() {}


[Bug middle-end/66633] [5/6 regression] ICE on valid verify_gimple failed with OpenMP

2015-07-01 Thread ebotcazou at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66633

Eric Botcazou ebotcazou at gcc dot gnu.org changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 CC||ebotcazou at gcc dot gnu.org
 Resolution|FIXED   |---
   Assignee|ebotcazou at gcc dot gnu.org   |unassigned at gcc dot 
gnu.org

--- Comment #14 from Eric Botcazou ebotcazou at gcc dot gnu.org ---
 Thanks for the fix! Unfortunately, while this fixes some instances, it still
 results in an ICE with optimization at -O1 or higher. 

Then I probably papered over a more fundamental issue which was preexisting.


[Bug tree-optimization/66729] Segfault starting with r224967

2015-07-01 Thread pthaugen at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66729

--- Comment #3 from Pat Haugen pthaugen at gcc dot gnu.org ---
(In reply to rsand...@gcc.gnu.org from comment #2)
 (In reply to David Edelsohn from comment #1)
  Is this the bootstrap failure that Segher tracked to Richard Sandiford? 
  Richard already posted a patch.
 
 Yeah, it sounds like it.  I committed the patch as r225263 -- please let
 me know if that didn't fix it.

I still see the ICE with r225263.


[Bug target/64833] [SH]: Error: pcrel too far when compiling imagemagick and graphicsmagick on Debian sh4

2015-07-01 Thread kkojima at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64833

--- Comment #22 from Kazumoto Kojima kkojima at gcc dot gnu.org ---
Author: kkojima
Date: Wed Jul  1 22:01:09 2015
New Revision: 225282

URL: https://gcc.gnu.org/viewcvs?rev=225282root=gccview=rev
Log:
PR target/64833
* [SH] Set length of casesi_worker_1 insn to 8 when flag_pic is set.


Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/config/sh/sh.md


[Bug target/66731] New: vnmul, fnmul patterns incorrect for -frounding-math

2015-07-01 Thread jsm28 at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66731

Bug ID: 66731
   Summary: vnmul, fnmul patterns incorrect for -frounding-math
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jsm28 at gcc dot gnu.org
  Target Milestone: ---
Target: arm*-*-* aarch64*-*-*

config/arm/vfp.md has patterns:

(define_insn *mulsf3negsf_vfp
  [(set (match_operand:SF  0 s_register_operand =t)
(mult:SF (neg:SF (match_operand:SF 1 s_register_operand t))
 (match_operand:SF 2 s_register_operand t)))]
  TARGET_32BIT  TARGET_HARD_FLOAT  TARGET_VFP
  vnmul%?.f32\\t%0, %1, %2
  [(set_attr predicable yes)
   (set_attr predicable_short_it no)
   (set_attr type fmuls)]
)

(define_insn *muldf3negdf_vfp
  [(set (match_operand:DF  0 s_register_operand =w)
(mult:DF (neg:DF (match_operand:DF 1 s_register_operand w))
 (match_operand:DF 2 s_register_operand w)))]
  TARGET_32BIT  TARGET_HARD_FLOAT  TARGET_VFP_DOUBLE
  vnmul%?.f64\\t%P0, %P1, %P2
  [(set_attr predicable yes)
   (set_attr predicable_short_it no)
   (set_attr type fmuld)]
)

These describe the vnmul instruction as (-a) * b.  It's actually -(a * b).  The
two are different in round-upwards and round-downwards modes.  This is
resulting in miscompilation of tgamma from current glibc git (which uses (-a) *
b, expecting that actual multiplication), and consequent test failures.  On
inspection, AArch64 fnmul is similarly misdescribed, although I haven't done
any testing there.


[Bug target/64833] [SH]: Error: pcrel too far when compiling imagemagick and graphicsmagick on Debian sh4

2015-07-01 Thread kkojima at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64833

--- Comment #23 from Kazumoto Kojima kkojima at gcc dot gnu.org ---
Author: kkojima
Date: Wed Jul  1 22:05:09 2015
New Revision: 225283

URL: https://gcc.gnu.org/viewcvs?rev=225283root=gccview=rev
Log:
PR target/64833
* [SH] Set length of casesi_worker_1 insn to 8 when flag_pic is set.


Modified:
branches/gcc-4_9-branch/gcc/ChangeLog
branches/gcc-4_9-branch/gcc/config/sh/sh.md


[Bug debug/66716] gomp4: libgomp.oacc-c/../libgomp.oacc-c-c++-common/kernels-loop.c -g ICE

2015-07-01 Thread vries at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66716

vries at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||patch

--- Comment #4 from vries at gcc dot gnu.org ---
https://gcc.gnu.org/ml/gcc-patches/2015-07/msg00060.html


[Bug middle-end/66685] [6 Regression] conftest.c:16:1: internal compiler error: in as_a, at is-a.h:192

2015-07-01 Thread rsandifo at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66685

--- Comment #9 from rsandifo at gcc dot gnu.org rsandifo at gcc dot gnu.org 
---
Author: rsandifo
Date: Wed Jul  1 16:48:30 2015
New Revision: 225263

URL: https://gcc.gnu.org/viewcvs?rev=225263root=gccview=rev
Log:
gcc/
PR bootstrap/66685
* rtl.c (classify_insn): Only return JUMP_INSN for parallel returns if
there are no CALLs in the same pattern.

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


[Bug testsuite/66723] gcc.target/i386/vararg-loc.c FAILs

2015-07-01 Thread vries at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66723

vries at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||patch

--- Comment #2 from vries at gcc dot gnu.org ---
https://gcc.gnu.org/ml/gcc-patches/2015-07/msg00070.html


[Bug testsuite/66723] gcc.target/i386/vararg-loc.c FAILs

2015-07-01 Thread vries at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66723

vries at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #3 from vries at gcc dot gnu.org ---
Updated test-case, marking resolved-fixed.


[Bug debug/66716] gomp4: libgomp.oacc-c/../libgomp.oacc-c-c++-common/kernels-loop.c -g ICE

2015-07-01 Thread vries at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66716

vries at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||ice-on-valid-code, openacc
 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |vries at gcc dot gnu.org

--- Comment #3 from vries at gcc dot gnu.org ---
Committed patch with testcases, marking resolved-fixed.


[Bug rtl-optimization/61047] [4.9/5/6 Regression] wrong code at -O1 on x86_64-linux

2015-07-01 Thread edlinger at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61047

--- Comment #26 from Bernd Edlinger edlinger at gcc dot gnu.org ---
Author: edlinger
Date: Wed Jul  1 16:10:30 2015
New Revision: 225260

URL: https://gcc.gnu.org/viewcvs?rev=225260root=gccview=rev
Log:
gcc/ChangeLog:
2015-07-01  Bernd Edlinger  bernd.edlin...@hotmail.de

PR rtl-optimization/61047
* rtlanal.c (get_initial_register_offset): New function.
(rtx_addr_can_trap_p_1): Check offsets of stack references.

testsuite/ChangeLog:
2015-07-01  Bernd Edlinger  bernd.edlin...@hotmail.de

PR rtl-optimization/61047
* gcc.c-torture/execute/20150611-1.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.c-torture/execute/20150611-1.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/rtlanal.c
trunk/gcc/testsuite/ChangeLog


[Bug fortran/66725] Issue with silent conversion int to char, struggling in gfc_widechar_to_char

2015-07-01 Thread gerhard.steinmetz.fort...@t-online.de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66725

--- Comment #1 from Gerhard Steinmetz gerhard.steinmetz.fort...@t-online.de 
---
Whereas :


$ cat y_test_char_1.f90
program p
   print *, char(100)
end

$ gfortran y_test_char_1.f90
$ a.out
 d

---

$ cat y_test_char_2.f90
program p
   print *, char(257)
end

$ gfortran y_test_char_2.f90
y_test_char_2.f90:2:17:

print *, char(257)
 1
Error: Argument of CHAR function at (1) is too large for the collating sequence
of kind 1

---

$ cat y_test_char_3.f90
program p
   write (1, asynchronous=char(100))
end
$ gfortran y_test_char_3.f90
y_test_char_3.f90:2:36:

write (1, asynchronous=char(100))
1
Error: ASYNCHRONOUS specifier in WRITE statement at (1) has invalid value 'd'

---

$ cat y_test_char_4.f90
program p
   write (1, asynchronous=char(257))
end

$ gfortran y_test_char_4.f90
y_test_char_4.f90:2:26:

write (1, asynchronous=char(257))
  1
Error: ASYNCHRONOUS= specifier at (1) must be an initialization expression


[Bug c++/65945] C++ alignment of nullptr_t is 1 and might cause unaligned stores to the frame

2015-07-01 Thread jason at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65945

--- Comment #13 from Jason Merrill jason at gcc dot gnu.org ---
Author: jason
Date: Wed Jul  1 17:06:52 2015
New Revision: 225265

URL: https://gcc.gnu.org/viewcvs?rev=225265root=gccview=rev
Log:
PR c++/65945
gcc/c-family/
* c-opts.c (c_common_post_options): Highest ABI version is 9.
gcc/cp/
* decl.c (cxx_init_decl_processing): Set TYPE_ALIGN of nullptr_t.
* class.c (layout_nonempty_base_or_field): Warn if that affects
the offset of a field.

Added:
branches/gcc-5-branch/gcc/testsuite/g++.dg/abi/nullptr-align.C
branches/gcc-5-branch/gcc/testsuite/g++.dg/abi/nullptr-align2.C
Modified:
branches/gcc-5-branch/gcc/c-family/ChangeLog
branches/gcc-5-branch/gcc/c-family/c-opts.c
branches/gcc-5-branch/gcc/common.opt
branches/gcc-5-branch/gcc/cp/ChangeLog
branches/gcc-5-branch/gcc/cp/class.c
branches/gcc-5-branch/gcc/cp/decl.c
branches/gcc-5-branch/gcc/testsuite/g++.dg/abi/macro0.C


[Bug debug/66668] [6 regression] FAIL: gcc.dg/debug/dwarf2/stacked-qualified-types-3.c scan-assembler-times DIE \\([^\n]*\\) DW_TAG_(?:const|volatile|atomic|restrict)_type 8

2015-07-01 Thread aldyh at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=8

--- Comment #2 from Aldy Hernandez aldyh at gcc dot gnu.org ---
Yes, this is a known issue, likely across all architectures.  I mentioned this
upon merge of the debug-early work:

https://gcc.gnu.org/ml/gcc/2015-06/msg00093.html

As I discussed in the above post, this is a missed optimization while merging
the common denominator of a set of qualifiers for a type within a DIE. For
example, if two types share const volatile (say const volatile int and
const volatile char), dwarf2out outputs things in the most efficient manner
as to share the maximum common type DIEs. This is not working, as
TYPE_MAIN_VARIANTs are not complete by the time early dwarf is run.

Thanks for opening the PR.


[Bug debug/66728] CONST_WIDE_INT causes corrupted DWARF debug info

2015-07-01 Thread uweigand at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66728

--- Comment #1 from Ulrich Weigand uweigand at gcc dot gnu.org ---
A bit of debugging shows that what's going on here is this:

add_const_value_attribute is called with the following constant RTL:
(const_wide_int 0x8000)

The routine then does:
 add_AT_wide (die, DW_AT_const_value,
  std::make_pair (rtl, GET_MODE (rtl)));

Note that GET_MODE (rtl) is VOIDmode.  This apparently causes creation of a
wide_int value with precision 0:
{wide_int_storage = {val = {0, -9223372036854775808, 2}, len = 2, precision =
0}

This seems already wrong, but doesn't quite explain the inconsistent output.

However, dwarf2out.c:get_full_len returns 0 if the precision is 0. 
Subsequently, when the DIE is emitted in output_die, we have:

int len = get_full_len (*a-dw_attr_val.v.val_wide);
int l = HOST_BITS_PER_WIDE_INT / HOST_BITS_PER_CHAR;
if (len * HOST_BITS_PER_WIDE_INT  64)
  dw2_asm_output_data (1, get_full_len (*a-dw_attr_val.v.val_wide)
* l,
   NULL);

if (WORDS_BIG_ENDIAN)
  for (i = len - 1; i = 0; --i)
{
  dw2_asm_output_data (l, a-dw_attr_val.v.val_wide-elt (i),
   %s, name);
  name = NULL;
}

When get_full_len is 0, the if is false, and thus no length is emitted.  In
addition, the loop count is 0, so nothing is emitted at all.

On the other hand, when the abbrev is emitted, value_format does:

case dw_val_class_wide_int:
  switch (get_full_len (*a-dw_attr_val.v.val_wide) *
HOST_BITS_PER_WIDE_INT)
{
case 8:
  return DW_FORM_data1;
case 16:
  return DW_FORM_data2;
case 32:
  return DW_FORM_data4;
case 64:
  return DW_FORM_data8;
default:
  return DW_FORM_block1;
}

so for a length of 0 we fall into the default case and assume DW_FORM_block1.

Any suggestions how to fix those (two?) problems?


[Bug fortran/56520] Syntax error causes misleading message: Invalid character in name

2015-07-01 Thread kargl at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56520

--- Comment #3 from kargl at gcc dot gnu.org ---
Patch submitted for review

https://gcc.gnu.org/ml/gcc-patches/2015-07/msg00071.html


[Bug fortran/66724] New: ICE on input/output statements with wrong specifier data

2015-07-01 Thread gerhard.steinmetz.fort...@t-online.de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66724

Bug ID: 66724
   Summary: ICE on input/output statements with wrong specifier
data
   Product: gcc
   Version: 5.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gerhard.steinmetz.fort...@t-online.de
  Target Milestone: ---

For most input/output statements and for several specifiers
compilation aborts if assigned specifier key is not changeable
(is a constant) and/or is of wrong data type etc.
Several combinations are causing a segfault, some examples :


$ cat z_iostmt_iomsg_1.f90
program p
   backspace (1, iomsg=1)
   close (1, iomsg=1)
   endfile (1, iomsg=1)
   flush (1, iomsg=1)
   inquire (1, iomsg=1)
   open (1, iomsg=1)
   read (1, iomsg=1)
   rewind (1, iomsg=1)
   wait (1, iomsg=1)
   write (1, iomsg=1)
end


$ cat z_open_iomsg.f90
program p
   open (1, iomsg=1)
   open (1, iomsg=1e1)
   open (1, iomsg=1d1)
   open (1, iomsg='no')
   open (1, iomsg='')
   open (1, iomsg=.true.)
   open (1, iomsg=[1])
   open (1, iomsg=[''])
   ! ...
end

# analogous if open replaced with some other io-stmt


$ cat z_open_specifier.f90
program p
   open (1, access=.false.)
   open (1, action=.false.)
   open (1, asynchronous=.false.)
   open (1, blank=.false.)
   open (1, decimal=.false.)
   open (1, delim=.false.)
   open (1, encoding=.false.)
   open (1, form=.false.)
   open (1, pad=.false.)
   open (1, position=.false.)
   open (1, round=.false.)
   open (1, sign=.false.)
   open (1, status=.false.)
end

# analogous if open replaced with some other io-stmt


$ cat z_write_asynchronous.f90
program p
   write (1, asynchronous=1e1)
   write (1, asynchronous=1d1)
   write (1, asynchronous=.false.)
   write (1, asynchronous=null())
   write (1, asynchronous=[1])
   write (1, asynchronous=[''])
   write (1, asynchronous=['no'])
   ! ...
end

# analogous if write replaced with some other io-stmt

# and several more ...


Yields (with gfortran 5.1.1 on SUSE Linux 13.2, 64 bit)
f951: internal compiler error: Segmentation fault


[Bug fortran/66725] New: Issue with silent conversion int to char, struggling in gfc_widechar_to_char

2015-07-01 Thread gerhard.steinmetz.fort...@t-online.de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66725

Bug ID: 66725
   Summary: Issue with silent conversion int to char, struggling
in gfc_widechar_to_char
   Product: gcc
   Version: 5.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gerhard.steinmetz.fort...@t-online.de
  Target Milestone: ---

Sometimes a silent conversion from integer to character occurs
where it should not IMO, but should give an explicit error instead.
If this integer value n is too large (n  255 or n  -255),
an ICE occurs (gfc_widechar_to_char).

This happens for several io statements and several specifiers.
An integer value at this place is wrong anyway.
Required is e.g. a scalar-default-char-expr.
Maybe wrong caret position is an aftereffect.


$ cat z_iostmt_status_257.f90
program p
   open (1, status=257)
end


$ gfortran -g -Wall -fcheck=all -fno-frontend-optimize z_iostmt_status_257.f90
f951: internal compiler error: in gfc_widechar_to_char, at
fortran/scanner.c:197


---

$ cat z_iostmt_status_100.f90
program p
   open (1, status=100)   ! wrong data type !
end

$ gfortran -g -Wall -fcheck=all -fno-frontend-optimize z_iostmt_status_100.f90
z_iostmt_status_100.f90:2:48:

open (1, status=100)   ! wrong data type !
1
Error: STATUS specifier in OPEN statement at (1) has invalid value 'd'


---

$ cat z_iostmt_asynchronous_999.f90
program p
   write (1, asynchronous=999)
end


$ gfortran z_iostmt_asynchronous_999.f90
f951: internal compiler error: in gfc_widechar_to_char, at
fortran/scanner.c:197


---

$ cat z_iostmt_asynchronous_104.f90
program p
   write (1, asynchronous=104)   ! wrong data type !
end


$ gfortran z_iostmt_asynchronous_104.f90
z_iostmt_asynchronous_104.f90:2:55:

write (1, asynchronous=104)   ! wrong data type !
   1
Error: ASYNCHRONOUS specifier in WRITE statement at (1) has invalid value 'h'


[Bug tree-optimization/66726] New: missed optimization, factor conversion out of COND_EXPR

2015-07-01 Thread law at redhat dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66726

Bug ID: 66726
   Summary: missed optimization, factor conversion out of
COND_EXPR
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: law at redhat dot com
  Target Milestone: ---

Given something like this:

   n = (short unsigned int) mode_size[(unsigned int) mode] * 8 = 64 ? (int)
((short unsigned int) mode_size[(unsigned int) mode] * 8) : 64; 

Note the (int) cast on the true arm of the COND_EXPR.  As a result of that
cast, the transformations to turn a COND_EXPR into a MIN/MAX expression in
fold-const.c will not trigger.

This could be fixed by a patch to match.pd, but the pattern would only really
be applicable to GENERIC and thus isn't considered a good design match for
match.pd.

We could extend fold-const.c to catch this case, but that would really only
help GENERIC as well.

The best option it seems would be to catch this in phi-opt which would also
take us a step closer to handling pr45397.

Testcase:

/* { dg-do compile } */
/* { dg-options -O2 -fdump-tree-original } */


extern unsigned short mode_size[];
int
oof (int mode)
{
  return (64  mode_size[mode] ? 64 : mode_size[mode]);
}

/* { dg-final { scan-tree-dump-times MIN_EXPR 1 original } } */


[Bug debug/66728] New: CONST_WIDE_INT causes corrupted DWARF debug info

2015-07-01 Thread uweigand at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66728

Bug ID: 66728
   Summary: CONST_WIDE_INT causes corrupted DWARF debug info
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: uweigand at gcc dot gnu.org
  Target Milestone: ---

Compiling the following test case:

__uint128_t test(void)
{
  static const __uint128_t two127 = ((__uint128_t) 1)  127;

  return two127;
}

on x86_64-linux (or ppc64le-linux) with -O -S -g -dA results in:

.uleb128 0x2# (DIE (0x2d) DW_TAG_subprogram)
# DW_AT_external
.long   .LASF3  # DW_AT_name: test
[snip]
.uleb128 0x3# (DIE (0x4e) DW_TAG_variable)
.long   .LASF4  # DW_AT_name: two127
.byte   0x1 # DW_AT_decl_file (xxx.i)
.byte   0x4 # DW_AT_decl_line
.long   0x61# DW_AT_type
.byte   0   # end of children of DIE 0x2d

But abbreviation 3 (used for the 0x4e DIE) reads:
.uleb128 0x3# (abbrev code)
.uleb128 0x34   # (TAG: DW_TAG_variable)
.byte   0   # DW_children_no
.uleb128 0x3# (DW_AT_name)
.uleb128 0xe# (DW_FORM_strp)
.uleb128 0x3a   # (DW_AT_decl_file)
.uleb128 0xb# (DW_FORM_data1)
.uleb128 0x3b   # (DW_AT_decl_line)
.uleb128 0xb# (DW_FORM_data1)
.uleb128 0x49   # (DW_AT_type)
.uleb128 0x13   # (DW_FORM_ref4)
.uleb128 0x1c   # (DW_AT_const_value)
.uleb128 0xa# (DW_FORM_block1)
.byte   0
.byte   0

So the variable DIE should have an DW_AT_const_value attribute encoded as
DW_FORM_block1.  This makes sense, since the variable was optimized away due to
being constant, and the size of the constant is 16 bytes.

However, the code in .debug_info to construct the DIE does not emit any
DW_FORM_block1; in fact, it does not emit *anything* where the
DW_AT_const_value is expected.  This causes the resulting debug info to be
corrupted, and tools operating on this info will emit errors (or even crash).

On ppc64le-linux (but not x86_64-linux), the same problem occurs with GCC 5 as
well.  The difference seems to be that x86_64 in GCC 5 uses a CONST_DOUBLE
instead of a CONST_WIDE_INT to represent that 128-bit constant.


[Bug debug/66691] [5/6 Regression] ICE on valid code at -O3 with -g enabled in simplify_subreg, at simplify-rtx.c:5744

2015-07-01 Thread ubizjak at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66691

--- Comment #8 from Uroš Bizjak ubizjak at gmail dot com ---
(In reply to Vladimir Makarov from comment #7)
 I'll commit the same patch into gcc-5 branch on next week after some testing
 the patch on trunk.

Please note that I have fixed the wrong PR number in the testcase.

[Bug target/63408] [4.9/5/6 regression] GCC emits incorrect fixed-fp conversion instruction on Cortex-M4 target

2015-07-01 Thread ramana at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63408

Ramana Radhakrishnan ramana at gcc dot gnu.org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #17 from Ramana Radhakrishnan ramana at gcc dot gnu.org ---
Fixed now on all active release branches.


[Bug c++/66701] __cxxabiv1::__cxa_pure_virtual - can it take an argument of the pointer to the function that was called, please?

2015-07-01 Thread jmcguiness at liquidcapital dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66701

Jason McG jmcguiness at liquidcapital dot com changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED
 Resolution|INVALID |WONTFIX

--- Comment #4 from Jason McG jmcguiness at liquidcapital dot com ---
Once the existence of the restricted ABI was pointed out to me I did not
propose to change it. I proposed creating a new version of the ABI that would
have an improved signature. That signature would be dependent upon what the
compiler could emit. It is not unreasonable to assume that there is an
interplay between what the compiler can emit which should drive the
specification of the ABI.

I have edited the status to closed/wontfix as clearly there is no inclination
to implement this enhancement.


[Bug c++/66666] ARM wrong copy constructor address on multiple inheritance

2015-07-01 Thread antonio.poggiali at datalogic dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=6

--- Comment #14 from Antonio Poggiali antonio.poggiali at datalogic dot com 
---
 
 Your toolchain is arm-none-linux-gnueabi , but you build with
 -mfloat-abi=hard - do you have suitable hard-float libraries on the target?
 

I have only hard-float libraries and related system header files.

 How was the toolchain configured
 (arm-poky-linux-gnueabi/arm-poky-linux-gnueabi-g++ -v)?
 

arm-poky-linux-gnueabi-g++ -vUsing built-in specs.
COLLECT_GCC=/data/IA/atmel_gcc-4.9.1/poky/build-atmel/tmp/sysroots/x86_64-linux/usr/bin/arm-poky-linux-gnueabi/arm-poky-linux-gnueabi-g++
COLLECT_LTO_WRAPPER=/data/IA/atmel_gcc-4.9.1/poky/build-atmel/tmp/sysroots/x86_64-linux/usr/bin/arm-poky-linux-gnueabi/../../libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/4.9.1/lto-wrapper
Target: arm-poky-linux-gnueabi
Configured with:
/data/IA/atmel/poky/build-atmel/tmp/work-shared/gcc-4.9.1-r0/gcc-4.9.1/configure
--build=x86_64-linux --host=x86_64-linux --target=arm-poky-linux-gnueabi
--prefix=/data/IA/atmel/poky/build-atmel/tmp/sysroots/x86_64-linux/usr
--exec_prefix=/data/IA/atmel/poky/build-atmel/tmp/sysroots/x86_64-linux/usr
--bindir=/data/IA/atmel/poky/build-atmel/tmp/sysroots/x86_64-linux/usr/bin/arm-poky-linux-gnueabi
--sbindir=/data/IA/atmel/poky/build-atmel/tmp/sysroots/x86_64-linux/usr/bin/arm-poky-linux-gnueabi
--libexecdir=/data/IA/atmel/poky/build-atmel/tmp/sysroots/x86_64-linux/usr/libexec/arm-poky-linux-gnueabi
--datadir=/data/IA/atmel/poky/build-atmel/tmp/sysroots/x86_64-linux/usr/share
--sysconfdir=/data/IA/atmel/poky/build-atmel/tmp/sysroots/x86_64-linux/etc
--sharedstatedir=/data/IA/atmel/poky/build-atmel/tmp/sysroots/x86_64-linux/com
--localstatedir=/data/IA/atmel/poky/build-atmel/tmp/sysroots/x86_64-linux/var
--libdir=/data/IA/atmel/poky/build-atmel/tmp/sysroots/x86_64-linux/usr/lib/arm-poky-linux-gnueabi
--includedir=/data/IA/atmel/poky/build-atmel/tmp/sysroots/x86_64-linux/usr/include
--oldincludedir=/data/IA/atmel/poky/build-atmel/tmp/sysroots/x86_64-linux/usr/include
--infodir=/data/IA/atmel/poky/build-atmel/tmp/sysroots/x86_64-linux/usr/share/info
--mandir=/data/IA/atmel/poky/build-atmel/tmp/sysroots/x86_64-linux/usr/share/man
--disable-silent-rules --disable-dependency-tracking
--with-libtool-sysroot=/data/IA/atmel/poky/build-atmel/tmp/sysroots/x86_64-linux
--enable-clocale=generic --with-gnu-ld --enable-shared --enable-languages=c,c++
--enable-threads=posix --disable-multilib --enable-c99 --enable-long-long
--enable-symvers=gnu --enable-libstdcxx-pch
--program-prefix=arm-poky-linux-gnueabi- --without-local-prefix
--enable-target-optspace --enable-lto --enable-libssp --disable-bootstrap
--disable-libmudflap --with-system-zlib --with-linker-hash-style=gnu
--enable-linker-build-id --with-ppl=no --with-cloog=no
--enable-checking=release --enable-cheaders=c_global
--with-gxx-include-dir=/data/IA/atmel/poky/build-atmel/tmp/sysroots/sama5d4ek/usr/include/c++/4.9.1
--with-sysroot=/data/IA/atmel/poky/build-atmel/tmp/sysroots/sama5d4ek
--with-build-sysroot=/data/IA/atmel/poky/build-atmel/tmp/sysroots/sama5d4ek
--enable-poison-system-directories
--with-mpfr=/data/IA/atmel/poky/build-atmel/tmp/sysroots/x86_64-linux/usr
--with-system-zlib --disable-nls --with-arch=armv7-a
Thread model: posix
gcc version 4.9.1 (GCC) 

 What userspace is running on the target?

Sorry but I don't understand the question. Could you explain a little?


[Bug middle-end/66713] atomic compare_exchange_strong creates spurious store for x86-64 at -O3

2015-07-01 Thread tkoeppe at google dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66713

--- Comment #3 from Thomas Köppe tkoeppe at google dot com ---
Note: The code in question, and the hand-written assembly, are taken from the
ZMQ library:

https://github.com/zeromq/libzmq/blob/master/src/atomic_ptr.hpp

I added the C++11 atomic support recenlty.

[Bug target/63408] [4.9/5/6 regression] GCC emits incorrect fixed-fp conversion instruction on Cortex-M4 target

2015-07-01 Thread ramana at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63408

--- Comment #16 from Ramana Radhakrishnan ramana at gcc dot gnu.org ---
Author: ramana
Date: Wed Jul  1 08:01:57 2015
New Revision: 225226

URL: https://gcc.gnu.org/viewcvs?rev=225226root=gccview=rev
Log:
Fix PR target/63408 on the 4.9 branch.

2015-07-01  Ramana Radhakrishnan  ramana.radhakrish...@arm.com

Backport from mainline
2015-06-24  Ramana Radhakrishnan  ramana.radhakrish...@arm.com

PR target/63408
* config/arm/arm.c (vfp3_const_double_for_fract_bits): Disable
for negative numbers.

2015-07-01  Ramana Radhakrishnan  ramana.radhakrish...@arm.com

Backport from mainline
2015-06-24  Ramana Radhakrishnan  ramana.radhakrish...@arm.com

PR target/63408
* gcc.target/arm/pr63408.c: New test.



Added:
branches/gcc-4_9-branch/gcc/testsuite/gcc.target/arm/pr63408.c
  - copied unchanged from r224879,
trunk/gcc/testsuite/gcc.target/arm/pr63408.c
Modified:
branches/gcc-4_9-branch/gcc/ChangeLog
branches/gcc-4_9-branch/gcc/config/arm/arm.c
branches/gcc-4_9-branch/gcc/testsuite/ChangeLog


[Bug testsuite/66734] New: Many MPX tests are skipped

2015-07-01 Thread hjl.tools at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66734

Bug ID: 66734
   Summary: Many MPX tests are skipped
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: ienkovich at gcc dot gnu.org
  Target Milestone: ---

Executing on host: /export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc/build-x86_64-linux/gcc/ mpx21993.c   
-fno-diagnostics-show-caret -fdiagnostics-color=never  -fcheck-pointer-bounds
-mmpx -o mpx21993.exe(timeout = 300)
spawn -ignore SIGHUP /export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc/build-x86_64-linux/gcc/ mpx21993.c
-fno-diagnostics-show-caret -fdiagnostics-color=never -fcheck-pointer-bounds
-mmpx -o mpx21993.exe^M
xgcc: error: libmpx.spec: No such file or directory^M
compiler exited with status 1
output is:
xgcc: error: libmpx.spec: No such file or directory^M

UNSUPPORTED: gcc.dg/lto/chkp-ctor-merge_0.c
UNSUPPORTED: gcc.dg/lto/chkp-privatize-1_0.c
UNSUPPORTED: gcc.dg/lto/chkp-privatize-2_0.c
UNSUPPORTED: gcc.dg/lto/chkp-privatize_0.c
UNSUPPORTED: gcc.dg/lto/chkp-removed-alias_0


[Bug middle-end/66568] [CHKP] internal compiler error: in expand_expr_addr_expr_1

2015-07-01 Thread hjl.tools at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66568

--- Comment #2 from H.J. Lu hjl.tools at gmail dot com ---
All tests are failed with

FAIL: gcc.target/i386/mpx/pr66568.c   -O0  (test for excess errors)
FAIL: gcc.target/i386/mpx/pr66568.c   -O1  (test for excess errors)
FAIL: gcc.target/i386/mpx/pr66568.c   -O2  (test for excess errors)
FAIL: gcc.target/i386/mpx/pr66568.c   -O3 -fomit-frame-pointer  (test for
excess errors)
FAIL: gcc.target/i386/mpx/pr66568.c   -O3 -g  (test for excess errors)
FAIL: gcc.target/i386/mpx/pr66568.c   -Os  (test for excess errors)
FAIL: gcc.target/i386/mpx/pr66568.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  (test for excess errors)
FAIL: gcc.target/i386/mpx/pr66568.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  (test for excess errors)


[Bug target/66563] [4.9 Regression] ICE (segmentation fault) on sh4-linux-gnu

2015-07-01 Thread glaubitz at physik dot fu-berlin.de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563

--- Comment #42 from John Paul Adrian Glaubitz glaubitz at physik dot 
fu-berlin.de ---
(In reply to John Paul Adrian Glaubitz from comment #41)
 So, please bear with me until I can give some feedback.

Matthias has uploaded the 4.9.3 release now with additional patches from the
snapshot r225135 SVN revision. I just started building right now and the build
takes around 3 to 4 days. I'll report back once the build is finished and the
new gcc version is installed on all buildds.

Cross your fingers ;).


[Bug driver/66732] New: ISL 0.15 released, has breaking changes to gcc

2015-07-01 Thread jamespharvey20 at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66732

Bug ID: 66732
   Summary: ISL 0.15 released, has breaking changes to gcc
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: driver
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jamespharvey20 at gmail dot com
  Target Milestone: ---

I'm happily staying with ISL 0.14-1, just wanted to comment that ISL 0.15 is
released and has breaking changes.

See http://isl.gforge.inria.fr/user.html#Changes-since-isl-0.14

The first gcc compilation error I run into with it is:


g++ -std=gnu++98 -fno-PIE -c   -g -DIN_GCC-fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wno-format -Wmissing-format-attribute -Woverloaded-virtual
-pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings
-fno-common  -DHAVE_CONFIG_H -I. -I. -I../../src.git/gcc -I../../src.git/gcc/.
-I../../src.git/gcc/../include -I../../src.git/gcc/../libcpp/include 
-I../../src.git/gcc/../libdecnumber -I../../src.git/gcc/../libdecnumber/bid
-I../libdecnumber -I../../src.git/gcc/../libbacktrace
-I/home/username/gcc-new-isl/build/./isl/include
-I/home/username/gcc-new-isl/src.git/isl/include  -o graphite.o -MT graphite.o
-MMD -MP -MF ./.deps/graphite.TPo ../../src.git/gcc/graphite.c
In file included from
/home/username/gcc-new-isl/src.git/isl/include/isl/map_type.h:4:0,
 from
/home/username/gcc-new-isl/src.git/isl/include/isl/set.h:13,
 from ../../src.git/gcc/graphite.c:38:
/home/username/gcc-new-isl/src.git/isl/include/isl/ctx.h:83:17: warning: comma
at end of enumerator list [-Wpedantic]
  isl_stat_ok = 0,
 ^
In file included from ../../src.git/gcc/graphite.c:79:0:
../../src.git/gcc/graphite-poly.h:398:43: error: ‘isl_constraint’ has not been
declared
 extern void print_isl_constraint (FILE *, isl_constraint *);
   ^
../../src.git/gcc/graphite-poly.h:402:35: error: variable or field
‘debug_isl_constraint’ declared void
 extern void debug_isl_constraint (isl_constraint *);
   ^
../../src.git/gcc/graphite-poly.h:402:35: error: ‘isl_constraint’ was not
declared in this scope
../../src.git/gcc/graphite-poly.h:402:51: error: expected primary-expression
before ‘)’ token
 extern void debug_isl_constraint (isl_constraint *);
   ^
Makefile:1071: recipe for target 'graphite.o' failed
make[3]: *** [graphite.o] Error 1
make[3]: Leaving directory '/home/username/gcc-new-isl/build/gcc'
Makefile:4379: recipe for target 'all-stage1-gcc' failed

[Bug tree-optimization/66733] New: ICE at -Os and above on x86_64-linux-gnu

2015-07-01 Thread su at cs dot ucdavis.edu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66733

Bug ID: 66733
   Summary: ICE at -Os and above on x86_64-linux-gnu
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
  Target Milestone: ---

The following code causes an ICE when compiled with the current gcc trunk at
-Os and above on x86_64-linux-gnu in both 32-bit and 64-bit modes. 

It is a regression from 5.1.x. 


$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-unknown-linux-gnu/6.0.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-trunk/configure --prefix=/usr/local/gcc-trunk
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 6.0.0 20150701 (experimental) [trunk revision 225222] (GCC) 
$ 
$ gcc-trunk -O1 -c small.c
$ gcc-5.1 -Os -c small.c
$ 
$ gcc-trunk -Os -c small.c
small.c: In function ‘fn2’:
small.c:26:1: internal compiler error: Segmentation fault
 }
 ^
0xb339cf crash_signal
../../gcc-trunk/gcc/toplev.c:360
0x83d94d fold_comparison
../../gcc-trunk/gcc/fold-const.c:8807
0x81dec9 fold_binary_loc(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*)
../../gcc-trunk/gcc/fold-const.c:11922
0xb7b2c4 cleanup_control_expr_graph
../../gcc-trunk/gcc/tree-cfgcleanup.c:128
0xb7b2c4 cleanup_control_flow_bb
../../gcc-trunk/gcc/tree-cfgcleanup.c:223
0xb7b2c4 cleanup_tree_cfg_bb
../../gcc-trunk/gcc/tree-cfgcleanup.c:640
0xb7b8e8 cleanup_tree_cfg_1
../../gcc-trunk/gcc/tree-cfgcleanup.c:693
0xb7b8e8 cleanup_tree_cfg_noloop
../../gcc-trunk/gcc/tree-cfgcleanup.c:745
0xb7b8e8 cleanup_tree_cfg()
../../gcc-trunk/gcc/tree-cfgcleanup.c:800
0xa6ffe4 execute_function_todo
../../gcc-trunk/gcc/passes.c:1910
0xa70883 execute_todo
../../gcc-trunk/gcc/passes.c:2014
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See http://gcc.gnu.org/bugs.html for instructions.
$ 


--


int a;

int
fn1 ()
{
  return 1;
}

void
fn2 ()
{
  int b, j;
  for (;;)
{
  int c = 1;
  if (j)
{
  if (c)
break;
}
  else
b = a;
  fn1 ()  b;
  j = fn1 ();
}
}

  1   2   >