[Bug target/70797] gcc.exe: Internal compiler error: (program as)

[abhijithr1 at gmail dot com]

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

--- Comment #2 from Abhijith Raghavendra  ---
(In reply to Marek Polacek from comment #1)
> Something in your installation is wrong, then, but it's hard to say anything
> without more details.  Anyway, hardly a C FE issue.

Thanks a lot for your reply. What details i should provide so that you can tell
in detail regarding this issue.

[Bug fortran/70817] New: Internal compiler error coarrays -finit-real=snan

[physiker at toast2 dot net]

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

Bug ID: 70817
   Summary: Internal compiler error coarrays -finit-real=snan
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: physiker at toast2 dot net
  Target Milestone: ---

Compiling the file t.f90 causes gfortran version 5.3 (OpenCoarrays-1.4.0) and
gcc-6.0.1-RC-20160423 (OpenCoarrays current git version) to crash with an
internal compiler error. Without the option -finit-real=snan the code compiles
without errors.

t.f90
   PROGRAM f
  IMPLICIT NONE
  REAL(4), PARAMETER :: zero = 0.0e0_4
  INTEGER :: n[*]
  REAL (4) :: p[*]
  REAL (4) :: h

  n = 1
  h = REAL(n, KIND=4)
  p = zero

END PROGRAM f

Driving: gfortran-6 -Wl,-flat_namespace --verbose t.f90 -finit-real=snan -L
/Users/Peter/Downloads/opencoarrays/opencoarrays-build/lib -fcoarray=lib
-lcaf_mpi
-I/Users/Peter/Downloads/opencoarrays/prerequisites/mpich-3.1.4-installation/include
-I/Users/Peter/Downloads/opencoarrays/prerequisites/mpich-3.1.4-installation/include
-L/Users/Peter/Downloads/opencoarrays/prerequisites/mpich-3.1.4-installation/lib
-lmpifort -lmpi -lpmpi -mmacosx-version-min=10.9.4 -l gfortran -shared-libgcc
Using built-in specs.
COLLECT_GCC=gfortran-6
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-apple-darwin13.4.0/6.0.1/lto-wrapper
Target: x86_64-apple-darwin13.4.0
Configured with: ../gcc-6.0.1-RC-20160423/configure
--enable-languages=c,c++,fortran,lto --with-gmp=/sw --with-libiconv-prefix=/sw
--with-isl=/sw --with-mpc=/sw --with-system-zlib --program-suffix=-6
Thread model: posix
gcc version 6.0.1 20160423 (prerelease) (GCC) 
COLLECT_GCC_OPTIONS='-v' '-finit-real=snan'
'-L/Users/Peter/Downloads/opencoarrays/opencoarrays-build/lib' '-fcoarray=lib'
'-I'
'/Users/Peter/Downloads/opencoarrays/prerequisites/mpich-3.1.4-installation/include'
'-I'
'/Users/Peter/Downloads/opencoarrays/prerequisites/mpich-3.1.4-installation/include'
'-L/Users/Peter/Downloads/opencoarrays/prerequisites/mpich-3.1.4-installation/lib'
'-mmacosx-version-min=10.9.4' '-shared-libgcc' '-mtune=core2'
 /usr/local/libexec/gcc/x86_64-apple-darwin13.4.0/6.0.1/f951 t.f90 -I
/Users/Peter/Downloads/opencoarrays/prerequisites/mpich-3.1.4-installation/include
-I
/Users/Peter/Downloads/opencoarrays/prerequisites/mpich-3.1.4-installation/include
-fPIC -quiet -dumpbase t.f90 -mmacosx-version-min=10.9.4 -mtune=core2 -auxbase
t -version -finit-real=snan -fcoarray=lib -fintrinsic-modules-path
/usr/local/lib/gcc/x86_64-apple-darwin13.4.0/6.0.1/finclude -o
/var/folders/97/4qnhjhtn25s86s9hkz0h37_mgn/T//cc821ws8.s
GNU Fortran (GCC) version 6.0.1 20160423 (prerelease)
(x86_64-apple-darwin13.4.0)
compiled by GNU C version 6.0.1 20160423 (prerelease), GMP version
6.1.0, MPFR version 3.1.4, MPC version 1.0.3, isl version 0.14 or 0.13
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU Fortran2008 (GCC) version 6.0.1 20160423 (prerelease)
(x86_64-apple-darwin13.4.0)
compiled by GNU C version 6.0.1 20160423 (prerelease), GMP version
6.1.0, MPFR version 3.1.4, MPC version 1.0.3, isl version 0.14 or 0.13
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
t.f90:5:0:

   REAL (4) :: p[*]

internal compiler error: in fold_convert_loc, at fold-const.c:2256

t.f90:5:0: internal compiler error: Abort trap: 6
gfortran-6: internal compiler error: Abort trap: 6 (program f951)
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Bug c++/67824] constexpr char* compare operations not constexpr, but char[] operations ARE

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Last reconfirmed|2015-11-25 00:00:00 |2016-4-26
 CC||msebor at gcc dot gnu.org
  Known to fail||4.9.3, 5.3.0, 6.0

--- Comment #4 from Martin Sebor  ---
Confirmed with all supported versions of GCC, including today's top of trunk:

$ cat z.cpp && /home/msebor/build/gcc-trunk-git/gcc/xgcc
-B/home/msebor/build/gcc-trunk-git/gcc -S -Wall -Wextra -Wpedantic
-fdump-tree-optimized=/dev/stdout  -xc++ z.cpp
constexpr const char s[] = "1234";
constexpr const char* p = "1234";

static_assert (s < s + 1, "This works");
static_assert (p < p + 1, "This fails");
z.cpp:5:1: error: non-constant condition for static assertion
 static_assert (p < p + 1, "This fails");
 ^
z.cpp:5:18: error: ‘(((const char*)"1234") < (((const char*)"1234") + 1u))’ is
not a constant expression
 static_assert (p < p + 1, "This fails");
~~^~~

[Bug c++/67026] GCC incorrectly rejects well-formed constexpr function definition

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Last reconfirmed|2015-08-29 00:00:00 |2016-4-26
 CC||msebor at gcc dot gnu.org
  Known to fail||5.3.0, 6.0

--- Comment #5 from Martin Sebor  ---
All test cases still fail with the current trunk.  I've updated the Known to
fail field to reflect that.

$ cat z.cpp && /home/msebor/build/gcc-trunk-git/gcc/xgcc
-B/home/msebor/build/gcc-trunk-git/gcc -S -Wall -Wextra -Wpedantic z.cpp
void g () { }
constexpr int f0 () { return 0; g (); }
constexpr int f1 () { return 0; throw 0; }

z.cpp: In function ‘constexpr int f0()’:
z.cpp:2:35: error: call to non-constexpr function ‘void g()’
 constexpr int f0 () { return 0; g (); }
 ~~^~
z.cpp: In function ‘constexpr int f1()’:
z.cpp:3:42: error: expression ‘’ is not a constant-expression
 constexpr int f1 () { return 0; throw 0; }
  ^

[Bug c++/70816] New: bogus error __builtin_strcmp is not a constant expression in a constexpr function

[msebor at gcc dot gnu.org]

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

Bug ID: 70816
   Summary: bogus error __builtin_strcmp is not a constant
expression in a constexpr function
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

G++ accepts most calls to __builtin_strcmp with constant arguments in constexpr
contexts, except when the intrinsic is invoked on local arrays defined in a
constexpr function.  The test case below shows a number of accepted calls along
with the one that's incorrectly rejected.

$ cat u.c && /home/msebor/build/gcc-trunk-git/gcc/xgcc
-B/home/msebor/build/gcc-trunk-git/gcc -Wall -Wextra -Wpedantic -xc++ u.c
constexpr int f0 ()
{
  return __builtin_strcmp ("a", "b");
}

constexpr int f1 ()
{
  const char a [] = "a";
  const char b [] = "b";
  return __builtin_strcmp (a, b);
}

constexpr int f2 (const char *a, const char *b)
{
  int d = 0;
  do {
d = *b - *a;
  } while (*a++ && *b++);
  return d;
}

constexpr int f3 ()
{
  const char s [] = "a";
  const char t [] = "b";

  const char *a = s;
  const char *b = t;

  int d = 0;
  do {
d = *b - *a;
  } while (*a++ && *b++);
  return d;
}

constexpr char a [] = "a";
constexpr char b [] = "b";

constexpr int i0 = __builtin_strcmp ("a", "b");
constexpr int i1 = __builtin_strcmp (a, b);
constexpr int i2 = f1 ();
constexpr int i3 = f2 (a, b);
constexpr int i4 = f3 ();

u.c:42:23:   in constexpr expansion of ‘f1()’
u.c:10:27: error: ‘__builtin_strcmp(((const char*)(& a)), ((const char*)(&
b)))’ is not a constant expression
   return __builtin_strcmp (a, b);
  ~^~

[Bug c++/66561] __builtin_LINE at al. should yield constant expressions

[msebor at gcc dot gnu.org]

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

--- Comment #2 from Martin Sebor  ---
Patch posted for review:
https://gcc.gnu.org/ml/gcc-patches/2016-04/msg01565.html

[Bug c++/66639] declare __func__ , __FUNCTION__ & __PRETTY_FUNCTION__ as constexpr

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #6 from Martin Sebor  ---
Looks like this has been implemented/fixed.

[Bug c++/66639] declare __func__ , __FUNCTION__ & __PRETTY_FUNCTION__ as constexpr

[msebor at gcc dot gnu.org]

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

--- Comment #5 from Martin Sebor  ---
Author: msebor
Date: Tue Apr 26 22:57:34 2016
New Revision: 235458

URL: https://gcc.gnu.org/viewcvs?rev=235458&root=gcc&view=rev
Log:
PR c++/66639 - declare __func__ , __FUNCTION__ & __PRETTY_FUNCTION__ constexpr
* g++.dg/cpp1y/func_constexpr.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp1y/func_constexpr.C
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug c++/70241] Enumerators introduced out-of-line by extending an opaque enum definition always get private accessibility

[ppalka at gcc dot gnu.org]

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

--- Comment #2 from Patrick Palka  ---
Author: ppalka
Date: Tue Apr 26 22:24:43 2016
New Revision: 235456

URL: https://gcc.gnu.org/viewcvs?rev=235456&root=gcc&view=rev
Log:
Fix PR c++/70241 (inconsistent access with in-class enumeration)

gcc/cp/ChangeLog:

PR c++/70241
* decl.c (build_enumerator): Set current_access_specifier when
declaring an enumerator belonging to an in-class enumeration.
* parser.c (cp_parser_check_access_in_redecleration): Also
consider in-class enumerations.

gcc/testsite/ChangeLog:

PR c++/70241
* g++.dg/cpp0x/enum32.C: New test.
* g++.dg/cpp0x/enum33.C: New test.


Added:
trunk/gcc/testsuite/g++.dg/cpp0x/enum32.C
trunk/gcc/testsuite/g++.dg/cpp0x/enum33.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl.c
trunk/gcc/cp/parser.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/70815] New: ICE when using read statement applied to deferred-length string pointer as derived type component

[pvdp.bugzilla at gmail dot com]

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

Bug ID: 70815
   Summary: ICE when using read statement applied to
deferred-length string pointer as derived type
component
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pvdp.bugzilla at gmail dot com
  Target Milestone: ---

Read statements applied to deferred-length string pointers inside derived types
cause an ICE if upper bound is omitted.

EXAMPLE:

program mwe

implicit none

type tStruc
character(len=:),pointer :: str
end type tStruc


type(tStruc) :: t
character(len=300),target :: buffer
character(len=:),pointer :: strptr
integer :: i, j, k

buffer = "10 11 12"
t%str => buffer
strptr => buffer


read(t%str(3:),*) j ! <-- causes ICE
read(t%str(3:len(t%str)),*) j   ! <-- work-around

read(buffer(3:),*) i ! works
read(strptr(3:),*) k ! works

print *, i,j,k

end program

ICE REPORT MINGW:

f951.exe: out of memory allocating 1718048288 bytes

ICE REPORT LINUX:

f951: internal compiler error: Segmentation fault
0xa3e2ef crash_signal
../../src/gcc/toplev.c:383
0x5f375e gfc_copy_shape(__mpz_struct (*) [1], int)
../../src/gcc/fortran/expr.c:708
0x5f3805 gfc_copy_expr(gfc_expr*)
../../src/gcc/fortran/expr.c:393
0x64dbb7 gfc_resolve_substring_charlen(gfc_expr*)
../../src/gcc/fortran/resolve.c:4575
0x64b555 gfc_resolve_expr(gfc_expr*)
../../src/gcc/fortran/resolve.c:6262
0x612926 gfc_resolve_dt(gfc_dt*, locus*)
../../src/gcc/fortran/io.c:2915
0x652967 gfc_resolve_code(gfc_code*, gfc_namespace*)
../../src/gcc/fortran/resolve.c:10375
0x654932 resolve_codes
../../src/gcc/fortran/resolve.c:15057
0x654a21 gfc_resolve(gfc_namespace*)
../../src/gcc/fortran/resolve.c:15091
0x6402ba resolve_all_program_units
../../src/gcc/fortran/parse.c:5282
0x6402ba gfc_parse_file()
../../src/gcc/fortran/parse.c:5525
0x67f9d5 gfc_be_parse_file
../../src/gcc/fortran/f95-lang.c:229
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.

[Bug target/70814] New: atomic store of __int128 is not lock free on aarch64

[yyc1992 at gmail dot com]

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

Bug ID: 70814
   Summary: atomic store of __int128 is not lock free on aarch64
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: yyc1992 at gmail dot com
  Target Milestone: ---

`std::atomic<__int128>::store` on aarch64 is not lock free and generates a
function call `__atomic_store_16`. However, required atomic instructions
(`stlxp`) exists in armv8 and is used by clang. Should gcc use the same
instruction as well?

Ref https://llvm.org/bugs/show_bug.cgi?id=27081, which fixes the clang codegen
for this case.

[Bug libstdc++/70794] vector.push_back() crashes with std::bad_alloc after 2^32 calls

[numien at deathwyrm dot com]

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

--- Comment #5 from numien at deathwyrm dot com ---
Created attachment 38344
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38344&action=edit
Preprocessed source

[Bug libstdc++/70794] vector.push_back() crashes with std::bad_alloc after 2^32 calls

[numien at deathwyrm dot com]

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

--- Comment #4 from numien at deathwyrm dot com ---
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/5.3.1/lto-wrapper
Target: x86_64-redhat-linux
Configured with: ../configure --enable-bootstrap
--enable-languages=c,c++,objc,obj-c++,fortran,ada,go,lto --prefix=/usr
--mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared
--enable-threads=posix --enable-checking=release --enable-multilib
--with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions
--enable-gnu-unique-object --enable-linker-build-id
--with-linker-hash-style=gnu --enable-plugin --enable-initfini-array
--disable-libgcj --with-isl --enable-libmpx --enable-gnu-indirect-function
--with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux
Thread model: posix
gcc version 5.3.1 20151207 (Red Hat 5.3.1-2) (GCC) 

$ ulimit -m
unlimited

$ ulimit -v
unlimited

$ g++ -m64 -O2 -save-temps -o test test.cpp
(no output)

$ ./test 
Reported max: 18446744073709551615
4294932terminate called after throwing an instance of 'std::bad_alloc'
  what():  std::bad_alloc
4294967297
Aborted (core dumped)



Preprocessed source attached... just in case my headers are different from the
standard somehow. It's certainly possible that the problem is local to my
system, though I'm not sure why it would be, it's a pretty average setup.

[Bug debug/51358] incorrect/missing location for function arg, -O0, without VTA

[mark at gcc dot gnu.org]

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

--- Comment #12 from Mark Wielaard  ---
Having to parse line information to skip the prologue us somewhat inconvenient.
Especially since GCC doesn't actually emit DW_LNS_set_prologue_end, you have to
use some heuristic to determine whether you have reach the end of the prologue.

As an alternative it might be nice if GCC could emit a
DW_AT_GNU_entry_breakpoint that indicates where the "valid scope" of the
function starts (it could either be an address or a constant to be added to
low_pc).

[Bug c/70812] Delay folding further in C front-end

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||diagnostic
Summary|Delay folding in C  |Delay folding further in C
   |front-end   |front-end

--- Comment #1 from Andrew Pinski  ---
The folding is delayed, just not enough it seems.

[Bug c/70813] New: Wrong warning "'0' flag ignored with precision and ‘%d’ gnu_printf format"

[ch3root at openwall dot com]

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

Bug ID: 70813
   Summary: Wrong warning "'0' flag ignored with precision and
‘%d’ gnu_printf format"
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ch3root at openwall dot com
  Target Milestone: ---

When compiling this program:

#include 

int main()
{
  printf("abc"
 "%05.*d\n", -1, 1);
}

I get the following error message:

example.c: In function ‘main’:
example.c:5:10: warning: '0' flag ignored with precision and ‘%d’ gnu_printf
format [-Wformat=]
   printf("abc"
  ^

The output from the program:

abc1

There are two issues here.

1. Wrong position for the warning.

2. The warning itself is wrong in this corner case. Yes, '0' flag is ordinarily
ignored with precision and %d per C11, 7.21.6.1p6: "For d, i, o, u, x, and X
conversions, if a precision is specified, the 0 flag is ignored." But the
precision is negative here and C11, 7.21.6.1p5, reads: "A negative precision
argument is taken as if the precision were omitted."

The output from the program demonstrates that indeed '0' flag is not ignored.

Maybe it's better to limit this warning to cases where precision is known at
compile time (e.g., for simplicity, when it's not '*')?

This gcc bug was pointed out to me in
https://twitter.com/spun_off/status/723558401599524865 .

[Bug c/70812] New: Delay folding in C front-end

[glisse at gcc dot gnu.org]

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

Bug ID: 70812
   Summary: Delay folding in C front-end
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: glisse at gcc dot gnu.org
  Target Milestone: ---

Hello,

gcc.dg/gomp/loop-1.c recently gained a few xfails
https://gcc.gnu.org/ml/gcc-patches/2016-04/msg01417.html

Those happen because the C front-end folds i+=i to i*=2 before the OMP code has
a chance to check if the increment has a supported form. I think the problem
only happens for forms which are invalid anyway.

If you believe the behavior is fine, then we could update the testcase so the
xfails become passes.

[Bug c/70811] error on #pragma GCC diagnostic in an enum

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic, rejects-valid
  Known to fail||4.9.3, 5.3.0, 6.0

--- Comment #2 from Martin Sebor  ---
G++ gives several errors.  The first one is more meaningful than the one issued
by GCC.  The rest suggest it's too confused to gracefully recover.

FWIW, I wonder if it would be worth adding a c-c++ Component to Bugzilla for
reports that affect both front ends but that might need a separate fix in each.
 (Not sure if this is one such case but I know there are some.)

$ cat -n v.c && /home/msebor/build/gcc-trunk-git/gcc/xgcc
-B/home/msebor/build/gcc-trunk-git/gcc -S -Wall -Wextra -Wpedantic -xc++ v.c
 1  enum E
 2{
 3  #pragma GCC diagnostic push
 4  e
 5};
v.c:3:9: error: ‘#pragma’ is not allowed here
 #pragma GCC diagnostic push
 ^~~
v.c:4:5: error: expected ‘}’ before ‘e’
 e
 ^
v.c:5:3: error: expected initializer before ‘}’ token
   };
   ^
v.c:5:3: error: expected declaration before ‘}’ token

[Bug c/70811] error on #pragma GCC diagnostic in an enum

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|preprocessor|c

--- Comment #1 from Andrew Pinski  ---
The preprocessor is not involved in this case, it just passes down #pragma to
the C/C++ front-end.  Does C++ front-end fail too?

[Bug preprocessor/70811] New: error on #pragma GCC diagnostic in an enum

[msebor at gcc dot gnu.org]

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

Bug ID: 70811
   Summary: error on #pragma GCC diagnostic in an enum
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: preprocessor
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

GCC gives a syntax error when #pragma GCC diagnostic appears in the
enumeraror-list of a definition of an enumerator (for example, when attempting
to suppress a warning about the constant-expression used to assign to one of
the enumerators, as in the example below).  GCC does not give an error when
#pragma push_macro is used in the same place.

I couldn't find anything about this limitation in the manual.  If it is a known
limitation or one that cannot be fixed the manual should be updated to mention
it.  AFAICS, the C standard allows implementations to fail to translate
programs with implementation-defined pragmas but it does require them to
document this (implementation-defined) behavior.

$ cat -n v.c && /home/msebor/build/gcc-trunk-git/gcc/xgcc
-B/home/msebor/build/gcc-trunk-git/gcc -S -Wall -Wextra -Wpedantic -xc v.c
 1  enum E
 2  {
 3  e = "a" - "a"
 4  };
 5  
 6  enum F
 7  {
 8  #pragma GCC diagnostic ignored "-Waddress"
 9  f = "b" - "b"
10  };
11  
v.c:3:9: warning: enumerator value for ‘e’ is not an integer constant
expression [-Wpedantic]
 e = "a" - "a"
 ^~~
v.c:8:9: error: expected identifier before ‘#pragma’
 #pragma GCC diagnostic ignored "-Waddress"
 ^~~

[Bug c/70772] Wrong warning about unspecified behavior for comparison with string literal

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org
  Known to fail||4.9.3, 5.3.0, 6.0

--- Comment #3 from Martin Sebor  ---
This bug affects both the C and the C++ front ends.  I mention it because when
developing a patch, it would be worth fixing both, and handle other equality
and relational operators, as well as the substraction expression.  Since the C
rules are different than C++, the handling needs to be different for each
language.

The test case below shows the problems in C and documents the expected output
in C++.  Note that even in cases where a diagnostic is expected and issued, the
text of the diagnostic should change to reflect what the relevant standard says
(undefined behavior in C rather than unspecified).  Unlike in C, in C++, the
behavior of relational expressions is well defined even for pointers pointing
to different objects provided one compares either less that or equal to the
other (it is unspecified otherwise), so the text of the diagnostic should be
adjusted to reflect that.

$ cat v.c && gcc -S -Wall -Wextra -Wpedantic -xc v.c
void f (void)
{
  const __PTRDIFF_TYPE__ a[] = {
"a" == "b",   // no warning expected (behavior well defined)
"a" != "b",   // no warning expected (behavior well defined)
"a" <  "b",   // warning expected in C only (undefined behavior)
"a" <= "b",   // warning expected in C only (undefined behavior)
"a" >  "b",   // warning expected in C only (undefined behavior)
"a" >= "b",   // warning expected in C only (undefined behavior)
"a" -  "b"// warning expected (undefined behavior)
  };
  (void)a;
}
v.c: In function ‘f’:
v.c:4:9: warning: comparison with string literal results in unspecified
behavior [-Waddress]
 "a" == "b",   // no warning expected (behavior well defined)
 ^~
v.c:5:9: warning: comparison with string literal results in unspecified
behavior [-Waddress]
 "a" != "b",   // no warning expected (behavior well defined)
 ^~
v.c:6:9: warning: comparison with string literal results in unspecified
behavior [-Waddress]
 "a" <  "b",   // warning expected in C only (undefined behavior)
 ^
v.c:7:9: warning: comparison with string literal results in unspecified
behavior [-Waddress]
 "a" <= "b",   // warning expected in C only (undefined behavior)
 ^~
v.c:8:9: warning: comparison with string literal results in unspecified
behavior [-Waddress]
 "a" >  "b",   // warning expected in C only (undefined behavior)
 ^
v.c:9:9: warning: comparison with string literal results in unspecified
behavior [-Waddress]
 "a" >= "b",   // warning expected in C only (undefined behavior)
 ^~

[Bug target/70809] [AArch64] aarch64_vmls pattern should be rejected if -ffp-contract=off

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-04-26
 CC||ktkachov at gcc dot gnu.org
   Target Milestone|--- |4.9.5
 Ever confirmed|0   |1
  Known to fail||4.8.5, 4.9.4, 5.3.1, 6.0,
   ||7.0

--- Comment #1 from ktkachov at gcc dot gnu.org ---
Confirmed on all branches (hence not a regression).
For 4.9 and earlier (where there's no -mtune=xgene1) I see the fmls with
-mtune=generic

[Bug c++/70810] New: std::function template variadic template arguments do not unpack in function template

[sd.foolegg at gmail dot com]

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

Bug ID: 70810
   Summary: std::function template variadic template arguments do
not unpack in function template
   Product: gcc
   Version: 5.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sd.foolegg at gmail dot com
  Target Milestone: ---

std::function template variadic template arguments do not unpack in function
template, like this:

template
void invoke(std::function f, Ts ... args) {}

void foo(std::string s, int i) {}

invoke(foo, "a", 1); // fail

// mismatched types 'std::function' and 'void
(*)(std::__cxx11::string, int) {aka void (*)(std::__cxx11::basic_string,
int)}'

full code :

#include 
#include 

template
struct Invoker {
void invoke(std::function f, Ts ... args) {
f(args ...);
}
};

template
void invoke(std::function f, Ts ... args) {
f(args ...);
}

void foo(std::string s, int i) {
std::cout << "foo " << s << " " << i << std::endl;
}

int main() {
Invoker invoker;
invoker.invoke(foo, "a", 1); // ok

invoke(foo, "a", 1); // fail

return 0;
}

main.cc:24:41: note:   mismatched types 'std::function' and 'void
(*)(std::__cxx11::string, int) {aka void (*)(std::__cxx11::basic_string,
int)}'

gcc version 5.3.1 20160301 [gcc-5-branch revision 233849] (SUSE Linux)

[Bug target/70809] New: [AArch64] aarch64_vmls pattern should be rejected if -ffp-contract=off

[jgreenhalgh at gcc dot gnu.org]

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

Bug ID: 70809
   Summary: [AArch64] aarch64_vmls pattern should be rejected if
-ffp-contract=off
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jgreenhalgh at gcc dot gnu.org
  Target Milestone: ---
Target: aarch64*-*-*

Take this simple testcase:

  void
  foo (float * __restrict__ __attribute__ ((aligned (16))) a,
   float * __restrict__ __attribute__ ((aligned (16))) x,
   float * __restrict__ __attribute__ ((aligned (16))) y,
   float * __restrict__ __attribute__ ((aligned (16))) z)
  {
unsigned i = 0;
for (i = 0; i < 256; i++)
  a[i] = x[i] - (y[i] * z[i]);
  }

GCC for AArch64 (all versions) will generate a vectorized fmls instruction even
when given the --fp-contract=off command (for trunk and 6 you'll need to play
with -mcpu options to find one which permits the combine through the cost
model):

(for trunk) $ gcc -O3 -ffp-contract=off -mcpu=xgene1 foo.c

   
   .L4:
ldr q2, [x9, x4]
add w5, w5, 1
ldr q1, [x8, x4]
cmp w5, w7
ldr q0, [x10, x4]
fmlsv0.4s, v2.4s, v1.4s
str q0, [x6, x4]
add x4, x4, 16
bcc .L4
  

The problem seems pretty clear, the aarch64_vmls pattern needs to be
tightened up not to fuse multiplies and subtracts when we're not in
-ffp-contract=fast.

  (define_insn "aarch64_vmls"
[(set (match_operand:VDQF 0 "register_operand" "=w")
 (minus:VDQF (match_operand:VDQF 1 "register_operand" "0")
 (mult:VDQF (match_operand:VDQF 2 "register_operand" "w")
(match_operand:VDQF 3 "register_operand"
"w"]
"TARGET_SIMD"
   "fmls\\t%0., %2., %3."
[(set_attr "type" "neon_fp_mla__scalar")]
  )

[Bug libstdc++/69945] Provide an equivalent of __libc_freeres to release emergency EH pool memory

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-04-26
  Known to work||6.0
 Ever confirmed|0   |1

[Bug c/70791] -Wnested-externs prints inconsistent column number

[egall at gwmail dot gwu.edu]

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

--- Comment #4 from Eric Gallager  ---
(In reply to Marek Polacek from comment #3)
> Fixed.

Thanks for the speedy response and fix!

[Bug tree-optimization/69489] missed vectorization for boolean loop, missed if-conversion

[amker at gcc dot gnu.org]

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

--- Comment #15 from amker at gcc dot gnu.org ---
Also the case is reported not vectorized on Solaris/SPARC in PR70803.  I will
investigate and follow up it in that ticket.

Thanks.

[Bug c++/70808] New: Spurious -Wzero-as-null-pointer-constant for nullptr_t

[lucdanton at free dot fr]

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

Bug ID: 70808
   Summary: Spurious -Wzero-as-null-pointer-constant for nullptr_t
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lucdanton at free dot fr
  Target Milestone: ---

The following program emits a warning when compiled with
-Wzero-as-null-pointer-constant:

int main()
{
int* no_warn = {};
// main.cpp:5:33: warning: zero as null pointer constant
[-Wzero-as-null-pointer-constant]
decltype( nullptr ) warn = {};
}

Unless I'm mistaken, this is not intended as demonstrated by the innocuous
no_warn variable.

Happens on a variety of versions, e.g. 5.3.1 and 6, as well as multiple -std
settings, e.g. c++11 and c++1z.

[Bug c/70791] -Wnested-externs prints inconsistent column number

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #3 from Marek Polacek  ---
Fixed.

[Bug c/70791] -Wnested-externs prints inconsistent column number

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek  ---
Author: mpolacek
Date: Tue Apr 26 15:01:09 2016
New Revision: 235447

URL: https://gcc.gnu.org/viewcvs?rev=235447&root=gcc&view=rev
Log:
PR c/70791
* c-decl.c (pushdecl): Pass LOCUS down to warning.

* gcc.dg/Wnested-externs-2.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/Wnested-externs-2.c
Modified:
trunk/gcc/c/ChangeLog
trunk/gcc/c/c-decl.c
trunk/gcc/testsuite/ChangeLog

[Bug c/67784] Incorrect parsing when using declarations in for loops and typedefs

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

--- Comment #12 from Marek Polacek  ---
Fixed again.

[Bug middle-end/70807] New: fwprop pass doesn't with incoming CDI_DOMINATORS

[hjl.tools at gmail dot com]

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

Bug ID: 70807
   Summary: fwprop pass doesn't with incoming CDI_DOMINATORS
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
  Target Milestone: ---

When

calculate_dominance_info (CDI_DOMINATORS);

is called before fwprop pass, fwprop pass will ICE if

free_dominance_info (CDI_DOMINATORS);

isn't called before fwprop pass:

https://gcc.gnu.org/ml/gcc/2016-03/msg00143.html

I will provide a patch to trigger ICE in libgcc build on x86-64
after PR target/70155 is fixed.

[Bug c/67784] Incorrect parsing when using declarations in for loops and typedefs

[mpolacek at gcc dot gnu.org]

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

--- Comment #11 from Marek Polacek  ---
Author: mpolacek
Date: Tue Apr 26 14:59:40 2016
New Revision: 235446

URL: https://gcc.gnu.org/viewcvs?rev=235446&root=gcc&view=rev
Log:
PR c/67784
* c-parser.c (c_parser_maybe_reclassify_token): New function factored
out of ...
(c_parser_for_statement): ... here.
(c_parser_if_statement): Use it.
(c_parser_switch_statement): Use it.
(c_parser_while_statement): Use it.

* gcc.dg/pr67784-3.c: New test.
* gcc.dg/pr67784-4.c: New test.
* gcc.dg/pr67784-5.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr67784-3.c
trunk/gcc/testsuite/gcc.dg/pr67784-4.c
trunk/gcc/testsuite/gcc.dg/pr67784-5.c
Modified:
trunk/gcc/c/ChangeLog
trunk/gcc/c/c-parser.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/70796] [DR 1030] Initialization order with braced-init-lists still broken

[lefticus at gmail dot com]

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

Jason Turner  changed:

   What|Removed |Added

 CC||lefticus at gmail dot com

--- Comment #1 from Jason Turner  ---
Also related: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70792

[Bug ada/70786] Missing "not" breaks Ada.Text_IO.Get_Immediate(File, Item, Available)

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-04-26
 CC||ebotcazou at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Eric Botcazou  ---
Ouch.  Thanks for reporting the issue and providing the fix.

[Bug libstdc++/70806] New: Missing deallocation of exception handler emergency pool breaks -static-libstdc++ with dlopen

[emil.styrke at gmail dot com]

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

Bug ID: 70806
   Summary: Missing deallocation of exception handler emergency
pool breaks -static-libstdc++ with dlopen
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: emil.styrke at gmail dot com
  Target Milestone: ---

There are multiple reports of benign "memory leaks" (still reachable bytes) in
eh_alloc.c, for example https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65434.

And even a request for a hook to manually deallocate this memory in valgrind
and similar tools:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69945

However, my use case is slightly different: Firstly, I build dynamic libraries
with -static-libstdc++ to be able to run on systems with libstdc++ older than
on the build machine.  Secondly, I load such libraries as plugins with
dlopen/dlclose. This works fine in GCC 4.9, but leaks memory in GCC 5.

Each time the library is dlopened a new pool object is created, and after
dlclose it will not have any references left. Valgrind shows this (after
looping the dlopen/dlsym/dlclose part a few times):

==3679== 3,707,904 bytes in 51 blocks are definitely lost in loss record 106 of
106
==3679==at 0x4C2BBCF: malloc (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==3679==by 0x77335EF: _GLOBAL__sub_I_eh_alloc.cc (in
[...]/libmock_di_plugin.so)
==3679==by 0x40105B9: call_init.part.0 (dl-init.c:72)
==3679==by 0x40106CA: call_init (dl-init.c:30)
==3679==by 0x40106CA: _dl_init (dl-init.c:120)
==3679==by 0x4015586: dl_open_worker (dl-open.c:579)
==3679==by 0x4010463: _dl_catch_error (dl-error.c:187)
==3679==by 0x40149A2: _dl_open (dl-open.c:663)
==3679==by 0x6B94FC8: dlopen_doit (dlopen.c:66)
==3679==by 0x4010463: _dl_catch_error (dl-error.c:187)
==3679==by 0x6B9562C: _dlerror_run (dlerror.c:163)
==3679==by 0x6B95060: dlopen@@GLIBC_2.2.5 (dlopen.c:87)
==3679==by 0x4F303E6: load_library (dipluginhandlerimpl.cpp:60)

Is there any solution to this, other than me manually calling
__gnu_cxx::__freeres (mentioned in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69945) before calling dlclose?

[Bug c++/70495] false warning: comparison between signed and unsigned integer expressions

[andras.szilard at gmail dot com]

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

András  changed:

   What|Removed |Added

Version|5.3.0   |6.1.0

--- Comment #7 from András  ---
Presents in latest GCC/C++.

https://gcc.godbolt.org/#compilers:!((compiler:g6,options:'-Wall',sourcez:MQSwdgxgNgrgJgUwAQB4IGcAudyYHwBQBuSAtgIbgAUuANEhABbkBOAVANoC6AlAQN4EkwpDFwBmAEwB9TEnJIAvEgAMAbiEixYTAA5ZSAEZLVGzcJAAzJFQUojPJP2EB6F0jAB7JAHdWYcABzcxFhFgRMGBYwJABGDVCAXyJQqxs7IyQAagcnV3cvX38gkNDwyOikSQSRZNCQtNtUTJzjVsdnJDckQKycwJAANwR0IuiggC4GT1IAB1YQdE8YwwifBAQY9BBAsAQ4eTADmDBt3f2kXARAhBYkBAAPWfD0beX0UpFyqJjxGuFkiFuj5PCwANasTwnA7AWINaxNexYciYEAQaQQchYFDaPSyPBUNotBwdfIebx%2BcZgYKhMoRH5IP4hQGhYGgiEsKFHJDASTw9LNZGo9GY7G4/T4QnZXLtPJdAoU4rUz5hemVJlJFIibpYFjkanIEHgyHQnlw1IIjJE63SlQwUny8ljALK2lfNUxAAs/yQLO17l1%2BpuvnZJu5vP5iOJNpysRgSAAtHF7XLuoVKS6aW6kN9Kt7mVrVRUYuoCMkgAA%3D%3D)),filterAsm:(colouriseAsm:!t,commentOnly:!t,directives:!t,labels:!t),version:3

[Bug other/51153] OpenACC implementation

[tschwinge at gcc dot gnu.org]

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

Thomas Schwinge  changed:

   What|Removed |Added

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

--- Comment #6 from Thomas Schwinge  ---
(In reply to Tobias Burnus from comment #4)
> The basic implementation is now (= GCC 5) in:

> See also https://gcc.gnu.org/wiki/OpenACC

Compared to GCC 5, the GCC 6 release series includes a much improved
implementation of the OpenACC 2.0a specification.  See
 or the OpenACC wiki page for a
high-level overview.

> I think this PR can now be closed
> and instead one could concentrate on the remaining issues elsewhere (PRs
> with 'openacc' keyword, pending patches).

ACK.

[Bug c/70791] -Wnested-externs prints inconsistent column number

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-04-26
 CC||mpolacek at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org
   Target Milestone|--- |7.0
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Patch should be trivial.

[Bug c/70753] missing diagnostic in C11 mode: sizeof, _Alignof of function type

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #4 from Marek Polacek  ---
.

[Bug libgomp/70805] libgomp.c/for-5.c and libgomp.c++/for-13.C FAIL

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |7.0

[Bug target/70797] gcc.exe: Internal compiler error: (program as)

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org
  Component|c   |target
   Severity|critical|normal

--- Comment #1 from Marek Polacek  ---
Something in your installation is wrong, then, but it's hard to say anything
without more details.  Anyway, hardly a C FE issue.

[Bug libgomp/70805] New: libgomp.c/for-5.c and libgomp.c++/for-13.C FAIL

[ro at gcc dot gnu.org]

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

Bug ID: 70805
   Summary: libgomp.c/for-5.c and libgomp.c++/for-13.C FAIL
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgomp
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
  Target Milestone: ---
  Host: sparc*-sun-solaris2.*
Target: sparc*-sun-solaris2.*
 Build: sparc*-sun-solaris2.*

The libgomp.c/for-5.c and libgomp.c++/for-13.C tests FAIL on 1.2 GHz UltraSPARC
T2
systems running Solaris 1[0-2]:

WARNING: program timed out.
FAIL: libgomp.c/for-5.c (test for excess errors)
WARNING: libgomp.c/for-5.c compilation failed to produce executable
WARNING: program timed out.
FAIL: libgomp.c++/for-13.C (test for excess errors)
WARNING: libgomp.c++/for-13.C compilation failed to produce executable

It turns out that even on an otherwise idle system, compilation times are
dangerously close to the default testcase timeout of 300s:

real3:28.01
user3:25.67
sys0.71

real3:30.60
user3:27.88
sys0.71

On a 2.27 GHz Xeon X5520, I get instead:

real  30.12
user  28.59
sys0.38

real  30.65
user  28.93
sys0.39

I long didn't noticed this because I had doubled the default timeout to 600 s,
but those two tests are almost the only ones where this makes a difference.
I wonder if one should either use dg-timeout-factor 2 or something else.

  Rainer

[Bug c++/21057] iso C99 complex double: problems with g++

[graham.frye at hotmail dot com]

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

Graham Frye  changed:

   What|Removed |Added

 CC||graham.frye at hotmail dot com

--- Comment #5 from Graham Frye  ---
Created attachment 38343
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38343&action=edit
stack misalignment using complex

#include 
#include 
//changes
typedef std::complex Cx;
Cx foo(int kojack)
{
double x=3, y=kojack;
return (x, y);
}
int main(int argc, char *argv[])
{
Cx z1(3.0, 4.0);
Cx z2(foo(4));
std::cout << "z1=" << z1 << std::endl;
std::cout << "z2=" << z2 << std::endl;
// compiled with gcc 4.8.4 on lxle
// g++ -o bug bug.cpp
//output:
//z1=(3,4)
//z2=(4,0)
}
end

[Bug tree-optimization/70804] Missed tail-call

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 Target||aarch64

--- Comment #1 from Ramana Radhakrishnan  ---
Update target

[Bug tree-optimization/70804] New: Missed tail-call

[ramana at gcc dot gnu.org]

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

Bug ID: 70804
   Summary: Missed tail-call
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ramana at gcc dot gnu.org
  Target Milestone: ---

Given. 


struct E {
  virtual ~E() { destroy(); }
  virtual E *clone() = 0;
  void destroy();

};

struct B: public E {
  virtual ~B() {}
  virtual B *clone() { return 0; }
  virtual void bar() {}
};


void f(void) { B b; }

Notice the missing tail call to E:destroy from f. 

.file   "m.cpp"
.section   
.text._ZN1B5cloneEv,"axG",%progbits,_ZN1B5cloneEv,comdat
.align  2
.p2align 3,,7
.weak   _ZN1B5cloneEv
.type   _ZN1B5cloneEv, %function
_ZN1B5cloneEv:
.LFB8:
.cfi_startproc
mov x0, 0
ret
.cfi_endproc
.LFE8:
.size   _ZN1B5cloneEv, .-_ZN1B5cloneEv
.section.text._ZN1B3barEv,"axG",%progbits,_ZN1B3barEv,comdat
.align  2
.p2align 3,,7
.weak   _ZN1B3barEv
.type   _ZN1B3barEv, %function
_ZN1B3barEv:
.LFB9:
.cfi_startproc
ret
.cfi_endproc
.LFE9:
.size   _ZN1B3barEv, .-_ZN1B3barEv
.section.text._ZN1BD2Ev,"axG",%progbits,_ZN1BD5Ev,comdat
.align  2
.p2align 3,,7
.weak   _ZN1BD2Ev
.type   _ZN1BD2Ev, %function
_ZN1BD2Ev:
.LFB5:
.cfi_startproc
ldr x1, .LC0
str x1, [x0]
b   _ZN1E7destroyEv
.cfi_endproc
.LFE5:
.size   _ZN1BD2Ev, .-_ZN1BD2Ev
.align  3
.LC0:
.xword  _ZTV1E+16
.weak   _ZN1BD1Ev
_ZN1BD1Ev = _ZN1BD2Ev
.section.text._ZN1BD0Ev,"axG",%progbits,_ZN1BD5Ev,comdat
.align  2
.p2align 3,,7
.weak   _ZN1BD0Ev
.type   _ZN1BD0Ev, %function
_ZN1BD0Ev:
.LFB7:
.cfi_startproc
stp x19, x30, [sp, -16]!
.cfi_def_cfa_offset 16
.cfi_offset 19, -16
.cfi_offset 30, -8
ldr x1, .LC1
mov x19, x0
str x1, [x0]
bl  _ZN1E7destroyEv
mov x0, x19
ldp x19, x30, [sp], 16
.cfi_restore 30
.cfi_restore 19
.cfi_def_cfa_offset 0
b   _ZdlPv
.cfi_endproc
.LFE7:
.size   _ZN1BD0Ev, .-_ZN1BD0Ev
.align  3
.LC1:
.xword  _ZTV1E+16
.text
.align  2
.p2align 3,,7
.global _Z1fv
.type   _Z1fv, %function
_Z1fv:
.LFB10:
.cfi_startproc
str x30, [sp, -32]!
.cfi_def_cfa_offset 32
.cfi_offset 30, -32
ldr x1, .LC2
add x0, sp, 32
str x1, [x0, -8]!
bl  _ZN1E7destroyEv
ldr x30, [sp], 32
.cfi_restore 30
.cfi_def_cfa_offset 0
ret
.cfi_endproc
.LFE10:
.size   _Z1fv, .-_Z1fv
.align  3
.LC2:
.xword  _ZTV1E+16
.weak   _ZTS1E
.section.rodata._ZTS1E,"aG",%progbits,_ZTS1E,comdat
.align  3
.type   _ZTS1E, %object
.size   _ZTS1E, 3
_ZTS1E:
.string "1E"
.weak   _ZTI1E
.section.rodata._ZTI1E,"aG",%progbits,_ZTI1E,comdat
.align  3
.type   _ZTI1E, %object
.size   _ZTI1E, 16
_ZTI1E:
.xword  _ZTVN10__cxxabiv117__class_type_infoE+16
.xword  _ZTS1E
.weak   _ZTV1E
.section.rodata._ZTV1E,"aG",%progbits,_ZTV1E,comdat
.align  3
.type   _ZTV1E, %object
.size   _ZTV1E, 40
_ZTV1E:
.xword  0
.xword  _ZTI1E
.xword  0
.xword  0
.xword  __cxa_pure_virtual

[Bug ipa/70760] [6/7 regression] wrong generated code for std::make_unique with -fipa-pta

[david.abdurachmanov at gmail dot com]

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

--- Comment #12 from David Abdurachmanov  
---
I have re-tested #3 patch by recompiling 316 RPMs (from GCC to our software --
top package). Have not seen those strange segfaults.

[Bug c++/65734] Yet another case of lost alignment by stor_layout

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|6.0 |5.3

[Bug tree-optimization/70803] gcc.dg/vect/pr56625.c FAILs

[amker at gcc dot gnu.org]

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

--- Comment #1 from amker at gcc dot gnu.org ---
Thanks for reporting this, I will check it.  Maybe a simple "vect_int_mult" to
skip on some targets.

[Bug rtl-optimization/57193] [4.9/5/6/7 Regression] suboptimal register allocation for SSE registers

[bernds at gcc dot gnu.org]

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

--- Comment #11 from Bernd Schmidt  ---
Author: bernds
Date: Tue Apr 26 12:43:42 2016
New Revision: 235442

URL: https://gcc.gnu.org/viewcvs?rev=235442&root=gcc&view=rev
Log:
Enable -frename-registers at -O2.

PR rtl-optimization/57193
* opts.c (default_options_table): Add OPT_frename_registers at -O2
and above.
* doc/invoke.texi (-frename-registers, -O2): Update documentation.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/doc/invoke.texi
trunk/gcc/opts.c

[Bug tree-optimization/70803] gcc.dg/vect/pr56625.c FAILs

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |7.0

[Bug tree-optimization/70803] New: gcc.dg/vect/pr56625.c FAILs

[ro at gcc dot gnu.org]

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

Bug ID: 70803
   Summary: gcc.dg/vect/pr56625.c FAILs
   Product: gcc
   Version: 7.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: sparc*-sun-solaris2.*
Target: sparc*-sun-solaris2.*
 Build: sparc*-sun-solaris2.*

Created attachment 38342
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38342&action=edit
pr56625.c.148t.vect

The new gcc.dg/vect/pr56625.c testcase FAILs on 32 and 64-bit Solaris/SPARC:

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

I'm attaching the dump.

  Rainer

[Bug middle-end/70802] New: IRA memory cost calculation incorrect for immediates

[wdijkstr at arm dot com]

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

Bug ID: 70802
   Summary: IRA memory cost calculation incorrect for immediates
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wdijkstr at arm dot com
  Target Milestone: ---

The following code in ira-costs.c tries to improve the memory cost for
rematerializeable loads. There are several issues with this though:

1. The memory cost can become negative, forcing a spill, which is known to
cause incorrect code (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64242)
2. The code only handles a subset of immediate loads, not all rematerializeable
values
3. The cost adjustment is not sufficient to make better decisions between
allocating an immediate to a callee-save register and spill a variable, or
allocate the variable and rematerialize the immediate

As an example of (3), if there is only one callee-save register free, IRA will
use it to allocate the immediate rather than the variable:

float bad_alloc(float x)
{
  x += 3.0f;
  g();
  x *= 3.0f;
  return x;
}

With -O2 -fomit-frame-pointer -ffixed-d8 -ffixed-d9 -ffixed-d10 -ffixed-d11
-ffixed-d12 -ffixed-d13 -ffixed-d14:

str x30, [sp, -32]!
str d15, [sp, 8]
fmovs15, 3.0e+0
fadds0, s0, s15
str s0, [sp, 28]
bl  g
ldr s0, [sp, 28]
fmuls0, s0, s15
ldr d15, [sp, 8]
ldr x30, [sp], 32
ret

  a0(r76,l0) costs: CALLER_SAVE_REGS:15000,15000 GENERAL_REGS:15000,15000
FP_REGS:0,0 ALL_REGS:15000,15000 MEM:12000,12000
  a1(r73,l0) costs: CALLER_SAVE_REGS:1,1 GENERAL_REGS:1,1
FP_REGS:0,0 ALL_REGS:1,1 MEM:8000,8000

The immediate value r76 is counted as 1 def and 2 uses, so memory cost of
12000, while r73 has 1 def and 1 use, so memory cost of 8000. However the
worst-case rematerialization cost of r76 would be 2 moves, one which already
exists of course, so the memory cost should have been 4000...

ira-costs.c, ~line 1458:

  if (set != 0 && REG_P (SET_DEST (set)) && MEM_P (SET_SRC (set))
  && (note = find_reg_note (insn, REG_EQUIV, NULL_RTX)) != NULL_RTX
  && ((MEM_P (XEXP (note, 0))
   && !side_effects_p (SET_SRC (set)))
  || (CONSTANT_P (XEXP (note, 0))
  && targetm.legitimate_constant_p (GET_MODE (SET_DEST (set)),
XEXP (note, 0))
  && REG_N_SETS (REGNO (SET_DEST (set))) == 1))
  && general_operand (SET_SRC (set), GET_MODE (SET_SRC (set
{
  enum reg_class cl = GENERAL_REGS;
  rtx reg = SET_DEST (set);
  int num = COST_INDEX (REGNO (reg));

  COSTS (costs, num)->mem_cost
-= ira_memory_move_cost[GET_MODE (reg)][cl][1] * frequency;
  record_address_regs (GET_MODE (SET_SRC (set)),
   MEM_ADDR_SPACE (SET_SRC (set)),
   XEXP (SET_SRC (set), 0), 0, MEM, SCRATCH,
   frequency * 2);
  counted_mem = true;
}

[Bug go/70787] No time and child info with -pg and gccgo

[vogt at linux dot vnet.ibm.com]

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

--- Comment #2 from Dominik Vogt  ---
The Go runtime seems to register a handler for SIGPROF even if it does not want
to profile.  So it always uninstalls the handler installed by Glibc on behalf
of the -pg option.  To me it looks like -pg actually enables the profiling from
libgo instead.  Some ways to circumvent this:

1) Don't install a SIGPROF handler in the Go runtime if another is already
installed (possibly emit a warning or a fatal error if the program attempts to
enable the Go profiling).
=> Simple to implement.

2) Install the SIGPROF handler on the fly when it's needed instead of
unconditionally at Go runtime startup.  Possibly emit a warning if an existing
signal handler is uninstalled in the process.
=> Cleanest solution.

3) Store the previous signal handler and call it at the start of the Go runtime
signal handler.  However, this introduces a number several problems (the Go
runtime won't notice if the original profiling code wants to uninstall the
handler or install a new one or it might overwrite the Go runtime handler;
also, the two profiling systems will probably not agree on a common timing
interval).
=> May allow to run Glibc and libgo profiling in parallel but probably has some
unfixable issues.

[Bug c++/70744] preincrements possibly double-evaluated in GNU ternaries

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #8 from Marek Polacek  ---
Fixed for GCC 7.

[Bug c++/70744] preincrements possibly double-evaluated in GNU ternaries

[mpolacek at gcc dot gnu.org]

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

--- Comment #7 from Marek Polacek  ---
Author: mpolacek
Date: Tue Apr 26 11:32:26 2016
New Revision: 235438

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

Bootstrapped/regtested on x86_64-linux, ok for trunk?

2016-04-25  Marek Polacek  

PR c++/70744
* call.c (build_conditional_expr_1): Call cp_stabilize_reference
instead of stabilize_reference.
(build_over_call): Likewise.
* cp-tree.h (cp_stabilize_reference): Declare.
* tree.c (cp_stabilize_reference): New function.
* typeck.c (cp_build_unary_op): Call cp_stabilize_reference instead of
stabilize_reference.
(unary_complex_lvalue): Likewise.
(cp_build_modify_expr): Likewise.

* g++.dg/ext/cond2.C: New test.

diff --git gcc/cp/call.c gcc/cp/call.c
index 11f2d42..476e806 100644
--- gcc/cp/call.c
+++ gcc/cp/call.c
@@ -4634,7 +4634,7 @@ build_conditional_expr_1 (location_t loc, tree arg1, tree
arg2, tree arg3,

   /* Make sure that lvalues remain lvalues.  See g++.oliva/ext1.C.  */
   if (real_lvalue_p (arg1))
-   arg2 = arg1 = stabilize_reference (arg1);
+   arg2 = arg1 = cp_stabilize_reference (arg1);
   else
arg2 = arg1 = save_expr (arg1);
 }
@@ -7644,8 +7644,9 @@ build_over_call (struct z_candidate *cand, int flags,
tsubst_flags_t complain)
   || (TREE_CODE (arg) == TARGET_EXPR
   && !unsafe_copy_elision_p (fa, arg)))
{
- tree to = stabilize_reference (cp_build_indirect_ref (fa, RO_NULL,
-   complain));
+ tree to = cp_stabilize_reference (cp_build_indirect_ref (fa,
+  RO_NULL,
+  complain));

  val = build2 (INIT_EXPR, DECL_CONTEXT (fn), to, arg);
  return val;
@@ -7655,7 +7656,7 @@ build_over_call (struct z_candidate *cand, int flags,
tsubst_flags_t complain)
   && trivial_fn_p (fn)
   && !DECL_DELETED_FN (fn))
 {
-  tree to = stabilize_reference
+  tree to = cp_stabilize_reference
(cp_build_indirect_ref (argarray[0], RO_NULL, complain));
   tree type = TREE_TYPE (to);
   tree as_base = CLASSTYPE_AS_BASE (type);
diff --git gcc/cp/cp-tree.h gcc/cp/cp-tree.h
index ec92718..0e46ae1 100644
--- gcc/cp/cp-tree.h
+++ gcc/cp/cp-tree.h
@@ -6494,6 +6494,7 @@ extern cp_lvalue_kind real_lvalue_p  
(const_tree);
 extern cp_lvalue_kind lvalue_kind  (const_tree);
 extern bool lvalue_or_rvalue_with_address_p(const_tree);
 extern bool xvalue_p   (const_tree);
+extern tree cp_stabilize_reference (tree);
 extern bool builtin_valid_in_constant_expr_p(const_tree);
 extern tree build_min  (enum tree_code, tree, ...);
 extern tree build_min_nt_loc   (location_t, enum tree_code,
diff --git gcc/cp/tree.c gcc/cp/tree.c
index 112c8c7..137186f 100644
--- gcc/cp/tree.c
+++ gcc/cp/tree.c
@@ -296,6 +296,46 @@ xvalue_p (const_tree ref)
   return (lvalue_kind (ref) == clk_rvalueref);
 }

+/* C++-specific version of stabilize_reference.  */
+
+tree
+cp_stabilize_reference (tree ref)
+{
+  switch (TREE_CODE (ref))
+{
+/* We need to treat specially anything stabilize_reference doesn't
+   handle specifically.  */
+case VAR_DECL:
+case PARM_DECL:
+case RESULT_DECL:
+CASE_CONVERT:
+case FLOAT_EXPR:
+case FIX_TRUNC_EXPR:
+case INDIRECT_REF:
+case COMPONENT_REF:
+case BIT_FIELD_REF:
+case ARRAY_REF:
+case ARRAY_RANGE_REF:
+case COMPOUND_EXPR:
+case ERROR_MARK:
+  break;
+default:
+  cp_lvalue_kind kind = lvalue_kind (ref);
+  if ((kind & ~clk_class) != clk_none)
+   {
+ tree type = unlowered_expr_type (ref);
+ bool rval = !!(kind & clk_rvalueref);
+ type = cp_build_reference_type (type, rval);
+ /* This inhibits warnings in, eg, cxx_mark_addressable
+(c++/60955).  */
+ warning_sentinel s (extra_warnings);
+ ref = build_static_cast (type, ref, tf_error);
+   }
+}
+
+  return stabilize_reference (ref);
+}
+
 /* Test whether DECL is a builtin that may appear in a
constant-expression. */

diff --git gcc/cp/typeck.c gcc/cp/typeck.c
index cef5604..7e12009 100644
--- gcc/cp/typeck.c
+++ gcc/cp/typeck.c
@@ -5912,7 +5912,7 @@ cp_build_unary_op (enum tree_code code, tree xarg, int
noconvert,
{
  tree real, imag;

- arg = stabilize_reference (arg);
+ arg = cp_stabilize_reference (arg);
  real = cp_build_unary_op (REALPART_EXPR, arg, 1, complain);
  imag = cp_build_unary_op (IMAGPART_EXPR, arg, 1, complain);
  real = cp_build_unary_op (code, real, 1, complain);
@@ -6112,7 +6112,7 @@ unary_complex_lvalue (en

[Bug middle-end/70801] New: IRA caller-saves does not support rematerialization

[wdijkstr at arm dot com]

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

Bug ID: 70801
   Summary: IRA caller-saves does not support rematerialization
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wdijkstr at arm dot com
  Target Milestone: ---

GCC emits the same code for caller-saves in all cases, even if the caller-save
is an immediate which can be trivially rematerialized. The caller-save code
should support rematerialization directly by omitting saves and emitting the
init value for restores. This allows the cost of rematerializeable caller-saves
to be lowered and avoids a stack slot. 

Alternatively given the spill code already supports rematerialization, it may
be possible to stop immediates from being caller-saved by increasing their
caller-save cost significantly.

void g(void);
float bad_remat(float x)
{
  x += 3.0f;
  g();
  x *= 3.0f;
  x *= (3.0f + x);
  g();
  x *= 3.0f;
  x *= (3.0f + x);
  return x;
}

AArch64 gives with -O2 -fomit-frame-pointer -ffixed-d8 -ffixed-d9 -ffixed-d10
-ffixed-d11 -ffixed-d12 -ffixed-d13 -ffixed-d14 -ffixed-d15:

fmovs1, 3.0e+0
str x30, [sp, -32]!
fadds0, s0, s1
stp s0, s1, [sp, 24]
bl  g
ldp s0, s1, [sp, 24]
fmuls0, s0, s1
fadds2, s0, s1
fmuls0, s0, s2
str s0, [sp, 24]
bl  g
ldp s0, s1, [sp, 24]
ldr x30, [sp], 32
fmuls0, s0, s1
fadds1, s0, s1
fmuls0, s0, s1
ret


x86_64 with plain -O2:
subq$24, %rsp
movss   .LC0(%rip), %xmm1
addss   %xmm1, %xmm0
movss   %xmm1, 12(%rsp)
movss   %xmm0, 8(%rsp)
callg
movss   8(%rsp), %xmm0
movaps  %xmm0, %xmm2
movss   12(%rsp), %xmm1
mulss   %xmm1, %xmm2
movaps  %xmm2, %xmm0
addss   %xmm1, %xmm0
mulss   %xmm2, %xmm0
movss   %xmm0, 8(%rsp)
callg
movss   12(%rsp), %xmm1
movss   8(%rsp), %xmm0
addq$24, %rsp
mulss   %xmm1, %xmm0
addss   %xmm0, %xmm1
mulss   %xmm1, %xmm0
ret

[Bug tree-optimization/70775] [7 Regression] ICE on valid code at -O3 on x86_64-linux-gnu: Segmentation fault

[amker at gcc dot gnu.org]

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

--- Comment #3 from amker at gcc dot gnu.org ---
Author: amker
Date: Tue Apr 26 11:10:47 2016
New Revision: 235436

URL: https://gcc.gnu.org/viewcvs?rev=235436&root=gcc&view=rev
Log:
PR tree-optimization/70771
PR tree-optimization/70775
* tree-if-conv.c (if_convertible_phi_p): Remove check on special
virtual PHI nodes.  Delete parameter.
(if_convertible_loop_p_1): Delete argument to above function.
(predicate_all_scalar_phis): Delete code handling single-argument
PHIs.
(tree_if_conversion): Mark and update virtual SSA.

gcc/testsuite/ChangeLog
PR tree-optimization/70771
PR tree-optimization/70775
* gcc.dg/pr70771.c: New test.
* gcc.dg/pr70771.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr70771.c
trunk/gcc/testsuite/gcc.dg/pr70775.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-if-conv.c

[Bug tree-optimization/70771] [7 Regression] ICE on valid code at -O3 on x86_64-linux-gnu in operator[], at vec.h:714

[amker at gcc dot gnu.org]

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

--- Comment #4 from amker at gcc dot gnu.org ---
Author: amker
Date: Tue Apr 26 11:10:47 2016
New Revision: 235436

URL: https://gcc.gnu.org/viewcvs?rev=235436&root=gcc&view=rev
Log:
PR tree-optimization/70771
PR tree-optimization/70775
* tree-if-conv.c (if_convertible_phi_p): Remove check on special
virtual PHI nodes.  Delete parameter.
(if_convertible_loop_p_1): Delete argument to above function.
(predicate_all_scalar_phis): Delete code handling single-argument
PHIs.
(tree_if_conversion): Mark and update virtual SSA.

gcc/testsuite/ChangeLog
PR tree-optimization/70771
PR tree-optimization/70775
* gcc.dg/pr70771.c: New test.
* gcc.dg/pr70771.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr70771.c
trunk/gcc/testsuite/gcc.dg/pr70775.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-if-conv.c

[Bug libstdc++/70794] vector.push_back() crashes with std::bad_alloc after 2^32 calls

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
And 'ulimit -v'

[Bug libstdc++/70794] vector.push_back() crashes with std::bad_alloc after 2^32 calls

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
Also, check your 'ulimit -m' value.

[Bug libstdc++/70794] vector.push_back() crashes with std::bad_alloc after 2^32 calls

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2016-04-26
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
I can't reproduce this on x86_64 GNU/Linux. I see a very slight pause around
the 4GB mark, and again at 8GB (probably as the allocated pages actually get
touched) but it keeps going well past that. This is a 64GB machine, so it
suggests that the problem is local to your system.

Please provide the missing information requested when you created this bug, see
https://gcc.gnu.org/bugs/

[Bug libgcc/70800] New: libgcc/config/libbid/bid_binarydecimal.c: suspicious comparison ?

[dcb314 at hotmail dot com]

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

Bug ID: 70800
   Summary: libgcc/config/libbid/bid_binarydecimal.c: suspicious
comparison ?
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgcc
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

trunk/libgcc/config/libbid/bid_binarydecimal.c:143934]: (style) Expression '(X
& 0x) > 0xf423f' is always false.

Source code is

nan(s,x) & 0xul) > 99ul) ? 0 :  \
   (((unsigned long long) x) << 44)),0ull); 

Masking something with 0xul would appear to limit it to [0..64K),
so it should always be < 99ul.

[Bug target/61821] gcc.target/i386/pr61599-1.c FAILs with Sun as

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|5.4 |7.0

--- Comment #6 from Rainer Orth  ---
Fixed for 7.1.

[Bug target/61821] gcc.target/i386/pr61599-1.c FAILs with Sun as

[ro at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61821
Bug 61821 depends on bug 59407, which changed state.

Bug 59407 Summary: gcc.target/i386/pr58218.c FAILs with Sun as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59407

   What|Removed |Added

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

[Bug target/59407] gcc.target/i386/pr58218.c FAILs with Sun as

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |7.0

--- Comment #6 from Rainer Orth  ---
Fixed for 7.1.

[Bug target/61821] gcc.target/i386/pr61599-1.c FAILs with Sun as

[ro at gcc dot gnu.org]

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

--- Comment #5 from Rainer Orth  ---
Author: ro
Date: Tue Apr 26 10:10:33 2016
New Revision: 235435

URL: https://gcc.gnu.org/viewcvs?rev=235435&root=gcc&view=rev
Log:
Support .largecomm with Solaris as (PR target/61821)

PR target/61821
* config/i386/i386.c (LARGECOMM_SECTION_ASM_OP): Define default.
(x86_elf_aligned_common): Rename to ...
(x86_elf_aligned_decl_common): ... this.
Add decl arg.  Switch to .lbss for largecomm object.  Use
LARGECOMM_SECTION_ASM_OP.
* config/i386/i386-protos.h (x86_elf_aligned_common): Reflect
renaming.
* config/i386/x86-64.h (ASM_OUTPUT_ALIGNED_COMMON): Rename to ...
(ASM_OUTPUT_ALIGNED_DECL_COMMON): ... this.
Pass new decl arg.
* config/i386/sol2.h (ASM_OUTPUT_ALIGNED_COMMON): Likewise.
[!USE_GAS] (LARGECOMM_SECTION_ASM_OP): Define.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386-protos.h
trunk/gcc/config/i386/i386.c
trunk/gcc/config/i386/sol2.h
trunk/gcc/config/i386/x86-64.h

[Bug target/59407] gcc.target/i386/pr58218.c FAILs with Sun as

[ro at gcc dot gnu.org]

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

--- Comment #5 from Rainer Orth  ---
Author: ro
Date: Tue Apr 26 10:06:16 2016
New Revision: 235434

URL: https://gcc.gnu.org/viewcvs?rev=235434&root=gcc&view=rev
Log:
Support .lbss etc. sections with Solaris as (PR target/59407)

PR target/59407
* config/i386/i386.c (SECTION_LARGE): Define.
(x86_64_elf_select_section): Set it for large data/bss sections.
Only clear SECTION_WRITE for .lrodata.
(x86_64_elf_section_type_flags): Set SECTION_LARGE for large
data/bss sections.
* config/i386/sol2.h (MACH_DEP_SECTION_ASM_FLAG): Define.
* varasm.c (default_elf_asm_named_section): Grow flagchars.
[MACH_DEP_SECTION_ASM_FLAG] Emit MACH_DEP_SECTION_ASM_FLAG for
SECTION_MACH_DEP.
* doc/tm.texi.in (Sections, MACH_DEP_SECTION_ASM_FLAG): Describe.
* doc/tm.texi: Regenerate.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/config/i386/sol2.h
trunk/gcc/doc/tm.texi
trunk/gcc/doc/tm.texi.in
trunk/gcc/varasm.c

[Bug target/70799] STV pass does not convert DImode shifts and rotates

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
I've been also surprised that the STV pass punts on moves of constants into
DImode registers, if it is not 0, sure, it has higher cost, because it needs to
be loaded from memory, but in the end together with enough other DImode
operations it can be still beneficial.

[Bug middle-end/56888] memcpy implementation optimized as a call to memcpy

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||knakahara at netbsd dot org

--- Comment #36 from Richard Biener  ---
*** Bug 70798 has been marked as a duplicate of this bug. ***

[Bug middle-end/70795] [7 Regression] gcc/libjava/interpret.cc:1948:1: ICE: in binds_to_current_def_p, at symtab.c:2232

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |7.0

[Bug c/70798] optimize-strlen generate infinite recursion code when the program has own "calloc" function

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

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

[Bug ipa/70760] [6/7 regression] wrong generated code for std::make_unique with -fipa-pta

[rguenther at suse dot de]

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

--- Comment #11 from rguenther at suse dot de  ---
On Tue, 26 Apr 2016, david.abdurachmanov at gmail dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70760
> 
> --- Comment #10 from David Abdurachmanov  com> ---
> I did a quick test (still took several hours) with #1 and #3 patches and both
> seem to solve the issue. Patches were tested on top of r235408.
> 
> Just in case I will run patch #3 (for now) again, but will force the whole
> world to be recompiled starting GCC. That is a more extensive, but also
> expensive test.

Thanks for the effort!

[Bug c/12245] [4.9/5/6/7 regression] Uses lots of memory when compiling large initialized arrays

[rguenth at gcc dot gnu.org]

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

--- Comment #60 from Richard Biener  ---
GCC 5 should have improved things a bit by wide-ints as small INTEGER_CSTs now
use 8 bytes less memory.  A quick check with GCC 6 shows around ~200MB memory
use for the attached testcase.

Note that your last example uses C++ initializer lists which have its own
issue (quite expensive wrapping) and separate bugreports.

[Bug target/70799] New: STV pass does not convert DImode shifts and rotates

[ubizjak at gmail dot com]

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

Bug ID: 70799
   Summary: STV pass does not convert DImode shifts and rotates
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ubizjak at gmail dot com
CC: hjl.tools at gmail dot com, ienkovich at gcc dot gnu.org
  Target Milestone: ---

These should all be converted to DImode vector shifts for SSE2/AVX2 32bit
target (and similar for rotates):

long long a, b;

void test_ll (void)
{
  a = b << 1;
}

void test_llv (int c)
{
  a = b << c;
}

unsigned long long d, e;

void test_lr (void)
{
  d = e >> 1;
}

void test_lrv (int c)
{
  d = e >> c;
}

void test_ar (void)
{
  a = b >> 1;
}

void test_arv (int c)
{
  a = b >> c;
}

[Bug ipa/70760] [6/7 regression] wrong generated code for std::make_unique with -fipa-pta

[david.abdurachmanov at gmail dot com]

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

--- Comment #10 from David Abdurachmanov  
---
I did a quick test (still took several hours) with #1 and #3 patches and both
seem to solve the issue. Patches were tested on top of r235408.

Just in case I will run patch #3 (for now) again, but will force the whole
world to be recompiled starting GCC. That is a more extensive, but also
expensive test.

[Bug target/60290] 32-bit g++.dg/cilk-plus/CK/catch_exc.cc FAILs on Solaris/x86

[ro at gcc dot gnu.org]

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

--- Comment #9 from Rainer Orth  ---
Fixed for 7.1.

[Bug target/60290] 32-bit g++.dg/cilk-plus/CK/catch_exc.cc FAILs on Solaris/x86

[ro at gcc dot gnu.org]

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

--- Comment #8 from Rainer Orth  ---
Author: ro
Date: Tue Apr 26 08:55:02 2016
New Revision: 235432

URL: https://gcc.gnu.org/viewcvs?rev=235432&root=gcc&view=rev
Log:
Compile libcilkrts with -funwind-tables (PR target/60290)

PR target/60290
* Makefile.am (GENERAL_FLAGS): Add -funwind-tables.
* Makefile.in: Regenerate.

Modified:
trunk/libcilkrts/ChangeLog
trunk/libcilkrts/Makefile.am
trunk/libcilkrts/Makefile.in

[Bug c/70798] New: optimize-strlen generate infinite recursion code when the program has own "calloc" function

[knakahara at netbsd dot org]

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

Bug ID: 70798
   Summary: optimize-strlen generate infinite recursion code when
the program has own "calloc" function
   Product: gcc
   Version: 5.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: knakahara at netbsd dot org
  Target Milestone: ---

Created attachment 38341
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38341&action=edit
reproduction code

COMPILER VERSION:

% gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/5/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 5.3.1-14ubuntu2'
--with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs
--enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-5 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --with-system-zlib
--disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-amd64/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686
--with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib
--with-tune=generic --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 5.3.1 20160413 (Ubuntu 5.3.1-14ubuntu2)


SYSTEM TYPE:

Ubuntu 16.04, here is the detail.

% uname -srvmpio
Linux 4.4.0-21-generic #37-Ubuntu SMP Mon Apr 18 18:33:37 UTC 2016 x86_64
x86_64 x86_64 GNU/Linux


WHAT HAPPENS 1:

When I compile the attached source code with "-O2" option, the output
executable file segmentation faulted. Here is the command line log.

% gcc -Wall -O2 calloc.c -o calloc
% ./calloc
zsh: segmentation fault (core dumped)  ./calloc

% gdb calloc core
(gdb) bt
#0  0x00400625 in calloc ()
#1  0x0040062a in calloc ()
#2  0x0040062a in calloc ()
#3  0x0040062a in calloc ()
#4  0x0040062a in calloc ()
#5  0x0040062a in calloc ()
#6  0x0040062a in calloc ()
#7  0x0040062a in calloc ()
#8  0x0040062a in calloc ()
#9  0x0040062a in calloc ()
:
:
continue until stack overflow


WHAT HAPPENS 2:

In contrast, I compile with the attached source code with "-O2" and
"-fno-optimize-strlen", the oputput executable file did not segmentation fault.
Here is the command line log.

% gcc -Wall -O2 -fno-optimize-strlen calloc.c -o calloc
% ./calloc
=0x229e010


EXPECTED BEHAVIOR:

Even when I compile with "-O2" only, the oputput executable file did not
segmentation fault.


SUPPLEMENT:

I also get this problem in gcc 5.3.0 on NetBSD-current(7.99.28).


Regards,

[Bug c/70797] New: gcc.exe: Internal compiler error: (program as)

[abhijithr1 at gmail dot com]

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

Bug ID: 70797
   Summary: gcc.exe: Internal compiler error: (program as)
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: critical
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: abhijithr1 at gmail dot com
  Target Milestone: ---

I have installed DJGPP in MS DOS operating system (X86 machine), when i try to
compile the source i am getting the following .

gcc 2.c

gcc.exe: internal compiler error: (program as)
Please submit a full bug report,
with prepocessed source if appropriate.
see  for instructions.

[Bug c++/58211] gcc: internal compiler error: Segmentation fault (program as)

[abhijithr1 at gmail dot com]

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

Abhijith Raghavendra  changed:

   What|Removed |Added

 CC||abhijithr1 at gmail dot com

--- Comment #7 from Abhijith Raghavendra  ---
I have installed DJGPP in MS DOS operating system (X86 machine), when i try to
compile the source i am getting the following .

gcc 2.c

gcc.exe: internal compiler error: (program as)
Please submit a full bug report,
with prepocessed source if appropriate.
see  for instructions.