[Bug libstdc++/77537] pair constructors do not properly SFINAE

[ville.voutilainen at gmail dot com]

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

--- Comment #1 from Ville Voutilainen  ---
See https://gcc.gnu.org/ml/gcc-patches/2016-08/msg01230.html

[Bug c/77520] wrong value for extended ASCII characters in -Wformat message

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-09-09
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
 Ever confirmed|0   |1
  Known to fail||4.9.3, 5.3.0, 6.2.0, 7.0

--- Comment #1 from Martin Sebor  ---
Patch posted for review:
https://gcc.gnu.org/ml/gcc-patches/2016-09/msg00487.html

[Bug c/77521] %qc format directive should quote non-printable characters

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-09-09
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
 Ever confirmed|0   |1
  Known to fail||4.9.3, 5.3.0, 6.1.0, 7.0

--- Comment #1 from Martin Sebor  ---
Patch posted for review:
https://gcc.gnu.org/ml/gcc-patches/2016-09/msg00487.html

[Bug libstdc++/77537] New: pair constructors do not properly SFINAE

[Casey at Carter dot net]

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

Bug ID: 77537
   Summary: pair constructors do not properly SFINAE
   Product: gcc
   Version: 6.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Casey at Carter dot net
  Target Milestone: ---

Created attachment 39586
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39586=edit
Patch

Both static_asserts in this program fail:

#include 
#include 

struct moveonly {
moveonly() = default;
moveonly(moveonly&&) = default;
};

template
using P = std::pair;
static_assert(!std::is_constructible::value,
"FAIL");
static_assert(!std::is_constructible>::value,
"FAIL");

Because the resolution of PR 70437 makes many of the pair constructors
inappropriately participate in overload resolution.

Attached patch is a poorly-tested fix. (It works for this repro, and the repro
in 70437, but caveat emptor.)

[Bug fortran/77505] Negative character length not treated as LEN=0

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4
   Severity|minor   |normal

[Bug fortran/69514] ICE with nested array constructor

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #8 from kargl at gcc dot gnu.org ---
Fixed on trunk.

[Bug fortran/69514] ICE with nested array constructor

[kargl at gcc dot gnu.org]

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

--- Comment #7 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Thu Sep  8 22:33:10 2016
New Revision: 240039

URL: https://gcc.gnu.org/viewcvs?rev=240039=gcc=rev
Log:
2016-09-08  Steven G. Kargl  

PR fortran/69514
* array.c (gfc_match_array_constructor):  If type-spec is present,
walk the array constructor performing possible conversions for 
numeric types.

2016-09-08  Steven G. Kargl  
Louis Krupp  

PR fortran/69514
* gfortran.dg/pr69514_1.f90: New test.
* gfortran.dg/pr69514_2.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/pr69514_1.f90
trunk/gcc/testsuite/gfortran.dg/pr69514_2.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/array.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/77536] New: Vectorizer not maintaining relationship of relative block frequencies in absence of real profile data

[pthaugen at gcc dot gnu.org]

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

Bug ID: 77536
   Summary: Vectorizer not maintaining relationship of relative
block frequencies in absence of real profile data
   Product: gcc
   Version: 7.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: dje at gcc dot gnu.org, rguenth at gcc dot gnu.org,
wschmidt at gcc dot gnu.org
  Target Milestone: ---
  Host: powerpc64*-unknown-linux-gnu
Target: powerpc64*-unknown-linux-gnu
 Build: powerpc64*-unknown-linux-gnu

// gcc -O3 -ffast-math -mcpu=power8 -mrecip=all -S test.c

void sub(float *restrict x, float *restrict y, float *restrict z, int n)
{
  int i;

  for (i = 0; i < n; i++)
x[i] = z[i]/y[i];
}


In the dump before vectorizer (148t.ifcvt) the loop block has freq=8500 which
is almost 6X the freq of the entry block(1500). After vectoriztion the now
vectorized loop block has freq=662. While I agree the freq of the loop block
should drop some after vectorization, it should still maintain the relationship
of being the hottest block in the function.

[Bug bootstrap/77512] gcc compilation stops with Arithmetic Exception

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2016-09-08
 CC||ebotcazou at gcc dot gnu.org
 Ever confirmed|0   |1
  Build||sparc-sun-solaris2.10

--- Comment #1 from Eric Botcazou  ---
> First stage was compiled using gcc 4.0.3

Any options passed to this compiler during the first stage?  Could you post the
output of 'uname -a' on the machine?

> Prerequisits are dowload using contrib/download_prerequisites
> GNU binutils-2.27 are used
> configuration was done with:
> ../gcc-6.2.0/configure --prefix=$HOME/gcc-6.2.0-bin
> --target=sparc-sun-solaris2.10 --with-gnu-as --with-gnu-ld --disable-libgcj
> --enable-languages=c,c++

I'll try to reproduce locally.

[Bug ada/77535] GNAT.Perfect_Hash_Generators access invalid memory with non-1-based strings

[fw at gcc dot gnu.org]

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

Florian Weimer  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-09-08
   Assignee|unassigned at gcc dot gnu.org  |fw at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug ada/77535] New: GNAT.Perfect_Hash_Generators access invalid memory with non-1-based strings

[fw at gcc dot gnu.org]

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

Bug ID: 77535
   Summary: GNAT.Perfect_Hash_Generators access invalid memory
with non-1-based strings
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fw at gcc dot gnu.org
  Target Milestone: ---

Created attachment 39585
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39585=edit
phg2.adb

Natasha Kerensikova reported this to comp.lang.ada.  The attached file was
downloaded from:

  http://users.instinctive.eu/nat/phg/

When running it under valgrind, I get:

==4196== Invalid read of size 1
==4196==at 0x5032D23: ??? (in /usr/lib/x86_64-linux-gnu/libgnat-4.9.so.1)
==4196==by 0x5035254: gnat__perfect_hash_generators__compute (in
/usr/lib/x86_64-linux-gnu/libgnat-4.9.so.1)
==4196==by 0x402F3B: _ada_phg2 (in /tmp/g/phg2)
==4196==by 0x402DA5: main (in /tmp/g/phg2)
==4196==  Address 0x5e61837 is 23 bytes after a block of size 16 alloc'd
==4196==at 0x4C28C20: malloc (vg_replace_malloc.c:296)
==4196==by 0x507F403: __gnat_malloc (in
/usr/lib/x86_64-linux-gnu/libgnat-4.9.so.1)
==4196==by 0x5033413: ??? (in /usr/lib/x86_64-linux-gnu/libgnat-4.9.so.1)
==4196==by 0x5035098: gnat__perfect_hash_generators__compute (in
/usr/lib/x86_64-linux-gnu/libgnat-4.9.so.1)
==4196==by 0x402F3B: _ada_phg2 (in /tmp/g/phg2)
==4196==by 0x402DA5: main (in /tmp/g/phg2)

Others have reported a segfault.

This is apparently due to GNAT.Perfect_Hash_Generators not dealing properly
with non-1-based strings.

[Bug fortran/77532] ICE in check_dtio_interface1, at fortran/interface.c:4622

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |pault at gcc dot gnu.org

--- Comment #2 from Paul Thomas  ---
It's mine!

Paul

[Bug fortran/77534] ICE in check_dtio_arg_TKR_intent, at fortran/interface.c:4572

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

 CC||pault at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |pault at gcc dot gnu.org

--- Comment #3 from Paul Thomas  ---
Thanks Gerhard and Steve! I'll take it.

Paul

[Bug fortran/77533] ICE in check_dtio_interface1, at fortran/interface.c:4614

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |pault at gcc dot gnu.org

--- Comment #3 from Paul Thomas  ---
It's obviously mine :-(

Paul

[Bug fortran/77533] ICE in check_dtio_interface1, at fortran/interface.c:4614

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-09-08
 CC||pault at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Dominique d'Humieres  ---
Confirmed on trunk (7.0).

[Bug fortran/77534] ICE in check_dtio_arg_TKR_intent, at fortran/interface.c:4572

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-09-08
 Ever confirmed|0   |1

--- Comment #2 from Dominique d'Humieres  ---
Confirmed.

[Bug fortran/77534] ICE in check_dtio_arg_TKR_intent, at fortran/interface.c:4572

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #1 from kargl at gcc dot gnu.org ---
One should return from check_dtio_arg_TKR_intent() after
any error is issued instead of falling through to the 
end of the function.  The following prevents the ICE.


Index: interface.c
===
--- interface.c (revision 240038)
+++ interface.c (working copy)
@@ -4559,8 +4570,11 @@ check_dtio_arg_TKR_intent (gfc_symbol *f
   int kind, int rank, sym_intent intent)
 {
   if (fsym->ts.type != type)
-gfc_error ("DTIO dummy argument at %L must be of type %s",
-  >declared_at, gfc_basic_typename (type));
+{
+  gfc_error ("DTIO dummy argument at %L must be of type %s",
+>declared_at, gfc_basic_typename (type));
+  return;
+}

   if (fsym->ts.type != BT_CLASS && fsym->ts.type != BT_DERIVED
   && fsym->ts.kind != kind)

[Bug fortran/77532] ICE in check_dtio_interface1, at fortran/interface.c:4622

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-09-08
 CC||pault at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Confirmed on trunk (7.0), not implemented before.

[Bug fortran/77525] wrong requirement of an upper bound for an array argument

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-09-08
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Confirmed from 4.5 up to trunk (7.0). Fortran 2003: Procedure components at (1)
are not yet implemented in gfortran-4.4.

> This is a regression because gfortran 4.9.2 is OK

Are you sure of that? I don't have 4.9.2, but I see the error with various
4.9.0 and 4.9.4.

[Bug fortran/77534] New: ICE in check_dtio_arg_TKR_intent, at fortran/interface.c:4572

[gerhard.steinmetz.fort...@t-online.de]

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

Bug ID: 77534
   Summary: ICE in check_dtio_arg_TKR_intent, at
fortran/interface.c:4572
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gerhard.steinmetz.fort...@t-online.de
  Target Milestone: ---

With a nonpolymorphic dtv :


$ cat z1.f90
module m
   type t
   end type
   interface read(unformatted)
  module procedure s
   end interface
contains
   subroutine s(dtv)
  type(t), intent(inout) :: dtv
   end
end


$ gfortran-7-20160904 z1.f90
z1.f90:8:19:

subroutine s(dtv)
   1
Error: DTIO dummy argument at (1) must be of type CLASS
f951: internal compiler error: Segmentation fault
0xc2100f crash_signal
../../gcc/toplev.c:336
0x6926db check_dtio_arg_TKR_intent
../../gcc/fortran/interface.c:4572
0x6927f9 check_dtio_interface1
../../gcc/fortran/interface.c:4662
0x69a2d8 gfc_check_dtio_interfaces(gfc_symbol*)
../../gcc/fortran/interface.c:4741
0x70c87b do_traverse_symtree
../../gcc/fortran/symbol.c:3939
0x6f65c0 resolve_types
../../gcc/fortran/resolve.c:15658
0x6f1d9c gfc_resolve(gfc_namespace*)
../../gcc/fortran/resolve.c:15730
0x6dd3a4 gfc_parse_file()
../../gcc/fortran/parse.c:6056
0x71f602 gfc_be_parse_file
../../gcc/fortran/f95-lang.c:198

[Bug fortran/77533] ICE in check_dtio_interface1, at fortran/interface.c:4614

[gerhard.steinmetz.fort...@t-online.de]

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

--- Comment #1 from Gerhard Steinmetz  
---

Sidenote : one message mentions a "KIND = 0".


$ cat z3.f90
module m
   type t
   contains
  procedure :: s
  generic :: write(formatted) => s
   end type
contains
   subroutine s(x)
  class(t), intent(in) : x
   end
end


$ gfortran-7-20160904 z3.f90
z3.f90:9:15:

   class(t), intent(in) : x
   1
Error: Invalid character in name at (1)
z3.f90:4:15:

   procedure :: s
   1
Error: Non-polymorphic passed-object dummy argument of 's' at (1)
z3.f90:8:17:

subroutine s(x)
 1
Error: DTIO dummy argument at (1) must be of type CLASS
z3.f90:8:17:

subroutine s(x)
 1
Error: DTIO dummy argument at (1) must be of KIND = 0
z3.f90:8:17:

subroutine s(x)
 1
Error: DTIO dummy argument at (1) must have intent IN

[Bug fortran/77533] New: ICE in check_dtio_interface1, at fortran/interface.c:4614

[gerhard.steinmetz.fort...@t-online.de]

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

Bug ID: 77533
   Summary: ICE in check_dtio_interface1, at
fortran/interface.c:4614
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gerhard.steinmetz.fort...@t-online.de
  Target Milestone: ---

Referencing an unknown type :


$ cat z1.f90
module m
   type t
  type(unknown), pointer :: next
   contains
  procedure :: s
  generic :: write(formatted) => s
   end type
contains
   subroutine s(x)
   end
end


$ gfortran-7-20160904 z1.f90
z1.f90:3:36:

   type(unknown), pointer :: next
1
Error: The pointer component 'next' of 't' at (1) is a type that has not been
declared
f951: internal compiler error: Segmentation fault
0xc2100f crash_signal
../../gcc/toplev.c:336
0x692790 check_dtio_interface1
../../gcc/fortran/interface.c:4614
0x69a293 gfc_check_dtio_interfaces(gfc_symbol*)
../../gcc/fortran/interface.c:4729
0x70c87b do_traverse_symtree
../../gcc/fortran/symbol.c:3939
0x6f65c0 resolve_types
../../gcc/fortran/resolve.c:15658
0x6f1d9c gfc_resolve(gfc_namespace*)
../../gcc/fortran/resolve.c:15730
0x6dd3a4 gfc_parse_file()
../../gcc/fortran/parse.c:6056
0x71f602 gfc_be_parse_file
../../gcc/fortran/f95-lang.c:198

[Bug fortran/77532] New: ICE in check_dtio_interface1, at fortran/interface.c:4622

[gerhard.steinmetz.fort...@t-online.de]

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

Bug ID: 77532
   Summary: ICE in check_dtio_interface1, at
fortran/interface.c:4622
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gerhard.steinmetz.fort...@t-online.de
  Target Milestone: ---

With following test skeleton :


$ cat z1.f90
module m
   type t
   end type
   interface read(unformatted)
   end interface
end


$ gfortran-7-20160904 z1.f90
f951: internal compiler error: in check_dtio_interface1, at
fortran/interface.c:4622
0x6929f4 check_dtio_interface1
../../gcc/fortran/interface.c:4622
0x69a2d8 gfc_check_dtio_interfaces(gfc_symbol*)
../../gcc/fortran/interface.c:4741
0x70c87b do_traverse_symtree
../../gcc/fortran/symbol.c:3939
0x6f65c0 resolve_types
../../gcc/fortran/resolve.c:15658
0x6f1d9c gfc_resolve(gfc_namespace*)
../../gcc/fortran/resolve.c:15730
0x6dd3a4 gfc_parse_file()
../../gcc/fortran/parse.c:6056
0x71f602 gfc_be_parse_file
../../gcc/fortran/f95-lang.c:198

[Bug driver/77529] -fno-pie disables -fPIC

[hjl.tools at gmail dot com]

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

--- Comment #4 from H.J. Lu  ---
(In reply to Matthias Klose from comment #0)
> seen with a GCC 6 configured with --enable-default-pie:
> 
> $ gcc -E -dM  - < /dev/null 2>&1|grep -i 'pi[ce]'
> #define __pie__ 2
> #define __PIE__ 2
> #define __pic__ 2
> #define __PIC__ 2
> 
> $ gcc -E -dM -fPIC - < /dev/null 2>&1|grep -i 'pi[ce]'
> #define __pic__ 2
> #define __PIC__ 2
> 
> $ gcc -E -dM -fPIC -fno-pie - < /dev/null 2>&1|grep -i 'pi[ce]'
> $ gcc -E -dM -fno-pie -fPIC - < /dev/null 2>&1|grep -i 'pi[ce]'
> #define __pic__ 2
> #define __PIC__ 2
> 
> I would expect the last behavior to be the default one.

--enable-default-pie should only change the default.  When -fno-pie -fPIC
are used, the driver behavior should be independent of --enable-default-pie.
GCC 6 without --enable-default-pie, I got

[hjl@gnu-6 gas]$ gcc -E -dM  - < /dev/null 2>&1|grep -i 'pi[ce]'
[hjl@gnu-6 gas]$ gcc -E -dM -fPIC - < /dev/null 2>&1|grep -i 'pi[ce]'
#define __pic__ 2
#define __PIC__ 2
[hjl@gnu-6 gas]$ gcc -E -dM -fPIC -fno-pie - < /dev/null 2>&1|grep -i 'pi[ce]'
[hjl@gnu-6 gas]$ gcc -E -dM -fno-pie -fPIC - < /dev/null 2>&1|grep -i 'pi[ce]'
#define __pic__ 2
#define __PIC__ 2
[hjl@gnu-6 gas]$ 

They match what you got with --enable-default-pie when -fPIC or -fno-pie
are used.

[Bug preprocessor/71681] header.gcc file lookup is broken for -remap

[andris at gcc dot gnu.org]

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

--- Comment #3 from Andris Pavenis  ---
Patch in mailing list

https://gcc.gnu.org/ml/gcc-patches/2016-09/msg00395.html

[Bug c/77530] optimization prevents excess precision from being removed with x86/amd64 long double and rounding to 53 bits

[vincent-gcc at vinc17 dot net]

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

--- Comment #3 from Vincent Lefèvre  ---
More precisely, up to NetBSD 6, it is 53 bits (gcc70 is NetBSD 5.1). As of
NetBSD 7, it is 64 bits.

[Bug c/77530] optimization prevents excess precision from being removed with x86/amd64 long double and rounding to 53 bits

[vincent-gcc at vinc17 dot net]

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

--- Comment #2 from Vincent Lefèvre  ---
This seems to depend on the NetBSD version. The default rounding precision has
changed in NetBSD 7.0: https://www.netbsd.org/changes/changes-7.0.html

[Bug c/77530] optimization prevents excess precision from being removed with x86/amd64 long double and rounding to 53 bits

[joseph at codesourcery dot com]

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

--- Comment #1 from joseph at codesourcery dot com  ---
The x86 back end uses TARGET_96_ROUND_53_LONG_DOUBLE only for the case of 
32-bit mode on DragonflyBSD and FreeBSD.  From what you're saying here, it 
needs to do so for NetBSD as well (both 32-bit and 64-bit?).

[Bug c/77531] New: __attribute__((alloc_size(1,2))) could also warn on multiplication overflow

[crrodriguez at opensuse dot org]

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

Bug ID: 77531
   Summary: __attribute__((alloc_size(1,2))) could also warn on
multiplication overflow
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: crrodriguez at opensuse dot org
  Target Milestone: ---

Using the example in the docs:

void* my_calloc(size_t x , size_t y) __attribute__((alloc_size(1,2)))

since alloc_size(1,2) means the function will return memory of  x *y..when the
compiler knows that multiplying x * y will cause an integer overflow..let's say
a obvious case my_calloc(SIZE_MAX, SIZE_MAX); it could either warn, error or
trap before an integer overflow actually happens.. (using the same logic as
__builtin_mul_overflow() I guess)

[Bug driver/77529] -fno-pie disables -fPIC

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||hjl.tools at gmail dot com

--- Comment #3 from Markus Trippelsdorf  ---
CCing H.J.

[Bug driver/77529] -fno-pie disables -fPIC

[trippels at gcc dot gnu.org]

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

--- Comment #2 from Markus Trippelsdorf  ---
Clang behaves exactly the same.

[Bug driver/77529] -fno-pie disables -fPIC

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||trippels at gcc dot gnu.org

--- Comment #1 from Markus Trippelsdorf  ---
Pilot error. Looks like a dup of PR77464.

[Bug debug/61013] [4.9/4.10 Regression] Option parsing difference between < 4.9 and 4.9

[jakub at gcc dot gnu.org]

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

--- Comment #17 from Jakub Jelinek  ---
As mentioned in PR77454, do we want to treat -gdwarf-N the same as -g (in
addition to setting the dwarf version), or should it be treated just like
setting of the DWARF version only if some debug info level is already enabled?
In particular, the questionable option order is
-g1 -gdwarf-4
which is now treated like
-g1 -g2 -gdwarf-4
rather than
-gdwarf-4 -g1

[Bug driver/77497] [5/6/7 Regression] Setting DWARF level and debug level together has flag-ordering-dependent results

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
This changed in r210442 aka PR61013.

[Bug driver/77497] [5/6/7 Regression] Setting DWARF level and debug level together has flag-ordering-dependent results

[torne at google dot com]

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

--- Comment #2 from torne at google dot com ---
Ah. I can see the logic in "-g1 -g" resulting in -g2 level output (as explained
in that bug), but it seems less ideal here where the second -g is only really
intending to define the DWARF level - especially since there's no other choice
than to do it in two flags because you can't set the debug level and the dwarf
level at once, unlike the other debug formats where you can say -gstabs1 or
similar to set both together.

[Bug c/77530] New: optimization prevents excess precision from being removed with x86/amd64 long double and rounding to 53 bits

[vincent-gcc at vinc17 dot net]

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

Bug ID: 77530
   Summary: optimization prevents excess precision from being
removed with x86/amd64 long double and rounding to 53
bits
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vincent-gcc at vinc17 dot net
  Target Milestone: ---

Under NetBSD/amd64, long double is on 80 bits but the processor is configured
to round on 53 bits (IEEE double precision) instead of 64 bits. The problem is
that when evaluating expressions at runtime, GCC seems to assume that the
rounding precision is 64 bits, yielding inconsistencies.

A test case:

#include 
#include 

int main (void)
{
  long double d = LDBL_MAX;
  volatile long double e = 0x8p+16380L;

  d -= 1.0;  /* no excess precision */
  printf ("d=%La e=%La\n", d, e);
  d -= e;
  printf ("d=%La\n", d);
  return 0;
}

When I compile this program with GCC 4.1.3 and the -O option under NetBSD
(gcc70.fsffrance.org), I get:

d=0xf.fffp+16380 e=0x8p+16380
d=0x8p+16380

The excess precision is kept in the first subtraction, but removed in the
second one.

There isn't a more recent GCC version installed on this machine, but I can
simulate this bug under Linux with the options "-std=c99 -mpc64 -O". I get the
same incorrect result with GCC 6.2.0 under Debian/unstable (amd64).

[Bug target/77476] [7 Regression] [AVX-512] illegal kmovb instruction on KNL

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #6 from Jakub Jelinek  ---
Fixed.

[Bug target/77527] [7 Regression] ICE: in make_decl_rtl, at varasm.c:1311 with -mstringop-strategy=libcall

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
So, what I see happening is that lim2 creates a v_lsm.5 VAR_DECL here, and it
is is_gimple_reg and only used in SSA_NAMEs.  As it is a wide vector, it is
BLKmode in the end, and during expansion emit_block_move called because of an
assignment to it calls mark_decl_addressable on the VAR_DECL (which queues
TREE_ADDRESSABLE set for after expansion).  The v_lsm.5 VAR_DECL then appears
in MEM_EXPRs of various MEMs, but because the VAR_DECL has been originally
gimple register, it doesn't have DECL_RTL set during expansion (each SSA_NAME
for it has its own I bet).  Then when nonoverlapping_memrefs_p is called on it
during DSE, it sees  the MEM_EXPR is not is_gimple_reg and uses DECL_RTL, which
ICEs, because it doesn't have the rtl and is not meant to get rtl created that
way.

I wonder if the queued addressable decls set to TREE_ADDRESSABLE after it
shouldn't have DECL_RTL set at that point (but to which one), or alternatively
if nonoverlapping_memrefs_p should use DECL_RTL_IF_SET instead and somehow deal
with the fact when that returns NULL_RTX (dunno if it should handle that
conservatively, by giving up, or if there are cases which it could still
handle).

[Bug driver/77529] New: -fno-pie disables -fPIC

[doko at gcc dot gnu.org]

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

Bug ID: 77529
   Summary: -fno-pie disables -fPIC
   Product: gcc
   Version: 6.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: driver
  Assignee: unassigned at gcc dot gnu.org
  Reporter: doko at gcc dot gnu.org
  Target Milestone: ---

seen with a GCC 6 configured with --enable-default-pie:

$ gcc -E -dM  - < /dev/null 2>&1|grep -i 'pi[ce]'
#define __pie__ 2
#define __PIE__ 2
#define __pic__ 2
#define __PIC__ 2

$ gcc -E -dM -fPIC - < /dev/null 2>&1|grep -i 'pi[ce]'
#define __pic__ 2
#define __PIC__ 2

$ gcc -E -dM -fPIC -fno-pie - < /dev/null 2>&1|grep -i 'pi[ce]'
$ gcc -E -dM -fno-pie -fPIC - < /dev/null 2>&1|grep -i 'pi[ce]'
#define __pic__ 2
#define __PIC__ 2

I would expect the last behavior to be the default one.

[Bug tree-optimization/65068] Improve rewriting for address type induction variables in IVOPT

[wdijkstr at arm dot com]

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

Wilco  changed:

   What|Removed |Added

 CC||wdijkstr at arm dot com

--- Comment #3 from Wilco  ---
Note gcc.target/aarch64/ldp_vec_64_1.c shows the same issue. Same story there,
most cores produce inefficient code, only -mcpu=vulcan gets close:

foo:
add x1, x1, 8
add x2, x0, 8192
.p2align 3
.L2:
ldr d0, [x1, -8]
ldr d1, [x1], 16
add v0.2s, v0.2s, v1.2s
str d0, [x0], 16
cmp x2, x0
bne .L2
ret

That still shows an odd pre-increment in the loop header, which blocks the use
of ldp.

Also in all cases aarch64_legitimize_address is called with offset 32760 on
V2SI - this offset does not occur anywhere in the source, so it should not
matter how we split it. However what we do for that case affects IVOpt, which
is clearly a bug.

[Bug libstdc++/77528] std::queue default constructor unnecessarily creates temporary of underlying Container

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-09-08
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
Untested fix:

--- a/libstdc++-v3/include/bits/stl_queue.h
+++ b/libstdc++-v3/include/bits/stl_queue.h
@@ -143,12 +143,17 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   queue(const _Sequence& __c = _Sequence())
   : c(__c) { }
 #else
+  template::value>::type>
+   queue()
+   : c() { }
+
   explicit
   queue(const _Sequence& __c)
   : c(__c) { }

   explicit
-  queue(_Sequence&& __c = _Sequence())
+  queue(_Sequence&& __c)
   : c(std::move(__c)) { }

   template>

[Bug libstdc++/77524] Empty std::deque allocates unnecessary heap memory

[d.rigby at me dot com]

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

--- Comment #5 from Dave Rigby  ---
(In reply to Jonathan Wakely from comment #4)
> Please create a new bug for those container adaptors, as that can and should
> be fixed for the default configuration. We'll keep this bug for the
> non-backwards-compatible std::deque change to be done at some future date.
> Thanks.

Done - bug 77528

[Bug libstdc++/77528] New: std::queue default constructor unnecessarily creates temporary of underlying Container

[d.rigby at me dot com]

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

Bug ID: 77528
   Summary: std::queue default constructor unnecessarily creates
temporary of underlying Container
   Product: gcc
   Version: 6.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: d.rigby at me dot com
  Target Milestone: ---

Spun out from bug 77524 - std::queue (defaulting to using std::deque as the
underlying Container) performs 4 allocations for an empty std::queue.
Initial analysis from Jonathan Wakely (bug 77524 comment 4):


Ouch. It's caused by the same issue, but the default constructor for std::queue
constructs a temporary of the underlying sequence, then move constructs the
data member from the temporary. With std::deque that means we allocate for the
temporary, then allocate again for the data member, then deallocate the memory
of the temporary. That sucks.

  explicit
  queue(_Sequence&& __c = _Sequence())
  : c(std::move(__c)) { }

 IIRC the "default" constructor is defined that way so that it's possible to
explicitly instantiate std::queue<_Sequence> with a non-DefaultConstructible 
_Sequence. But it means std::queue is horribly inefficient. At
least for an empty std::deque the initial allocation is probably going to
end up being useful, because in most cases the deque doesn't stay empty and the
allocation ends up being useful later. In this std::queue constructor the
temporary is definitely never used (it goes out of scope immediately) so
pre-allocating is entirely useless. std::stack has the same issue.

Please create a new bug for those container adaptors, as that can and should be
fixed for the default configuration. We'll keep this bug for the
non-backwards-compatible std::deque change to be done at some future date.
Thanks.

[Bug libstdc++/77524] Empty std::deque allocates unnecessary heap memory

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
(In reply to Dave Rigby from comment #3)
> As an aside, std::queue<> (defaulting to using std::deque as the underlying
> Container) suffers from a similar issue - I see 4 allocations for an empty
> std::queue. Is this the same underlying issue, or should I raise an
> additional bug on that?

Ouch. It's caused by the same issue, but the default constructor for std::queue
constructs a temporary of the underlying sequence, then move constructs the
data member from the temporary. With std::deque that means we allocate for the
temporary, then allocate again for the data member, then deallocate the memory
of the temporary. That sucks.

  explicit
  queue(_Sequence&& __c = _Sequence())
  : c(std::move(__c)) { }

IIRC the "default" constructor is defined that way so that it's possible to
explicitly instantiate std::queue<_Sequence> with a non-DefaultConstructible
_Sequence. But it means std::queue is horribly inefficient. At
least for an empty std::deque the initial allocation is probably going to
end up being useful, because in most cases the deque doesn't stay empty and the
allocation ends up being useful later. In this std::queue constructor the
temporary is definitely never used (it goes out of scope immediately) so
pre-allocating is entirely useless. std::stack has the same issue.

Please create a new bug for those container adaptors, as that can and should be
fixed for the default configuration. We'll keep this bug for the
non-backwards-compatible std::deque change to be done at some future date.
Thanks.

[Bug fortran/77500] ICE in gfc_trans_omp_atomic, at fortran/trans-openmp.c:2822

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Author: jakub
Date: Thu Sep  8 12:19:21 2016
New Revision: 240038

URL: https://gcc.gnu.org/viewcvs?rev=240038=gcc=rev
Log:
PR fortran/77500
* trans-openmp.c (gfc_trans_omp_atomic): For atomic write or
swap, don't try to look through GFC_ISYM_CONVERSION.  In other cases,
check that value.function.isym is non-NULL before dereferencing it.

* gfortran.dg/gomp/pr77500.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/gomp/pr77500.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-openmp.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/77516] ICE in is_gimple_min_invariant, at gimple-expr.c:706

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek  ---
Author: jakub
Date: Thu Sep  8 12:18:16 2016
New Revision: 240037

URL: https://gcc.gnu.org/viewcvs?rev=240037=gcc=rev
Log:
PR fortran/77516
* omp-low.c (lower_rec_simd_input_clauses): Use max_vf for non-positive
OMP_CLAUSE_SAFELEN_EXPR.

* gfortran.dg/gomp/pr77516.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/gomp/pr77516.f90
Modified:
trunk/gcc/ChangeLog
trunk/gcc/omp-low.c
trunk/gcc/testsuite/ChangeLog

[Bug target/77527] New: [7 Regression] ICE: in make_decl_rtl, at varasm.c:1311 with -mstringop-strategy=libcall

[zsojka at seznam dot cz]

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

Bug ID: 77527
   Summary: [7 Regression] ICE: in make_decl_rtl, at varasm.c:1311
with -mstringop-strategy=libcall
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu
 Build: x86_64-pc-linux-gnu

Created attachment 39584
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39584=edit
reduced testcase

Compiler output:
$ x86_64-pc-linux-gnu-gcc -O -fno-tree-copy-prop -fno-tree-dominator-opts
-fno-tree-forwprop -fno-tree-fre -mstringop-strategy=libcall testcase.c
-Wno-psabi
testcase.c: In function 'foo':
testcase.c:13:1: internal compiler error: in make_decl_rtl, at varasm.c:1311
 }
 ^
0xed0887 make_decl_rtl(tree_node*)
/repo/gcc-trunk/gcc/varasm.c:1307
0x6ed404 nonoverlapping_memrefs_p(rtx_def const*, rtx_def const*, bool)
/repo/gcc-trunk/gcc/alias.c:2757
0x6eef34 true_dependence_1
/repo/gcc-trunk/gcc/alias.c:2924
0x149a018 check_mem_read_rtx
/repo/gcc-trunk/gcc/dse.c:2039
0x149a018 check_mem_read_use
/repo/gcc-trunk/gcc/dse.c:2160
0xb5b154 note_uses(rtx_def**, void (*)(rtx_def**, void*), void*)
/repo/gcc-trunk/gcc/rtlanal.c:1934
0x149b498 scan_insn
/repo/gcc-trunk/gcc/dse.c:2266
0x149c72f dse_step1
/repo/gcc-trunk/gcc/dse.c:2525
0x149c72f rest_of_handle_dse
/repo/gcc-trunk/gcc/dse.c:3413
0x149c72f execute
/repo/gcc-trunk/gcc/dse.c:3511
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.

$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-trunk-240036-checking-yes-rtl-df-extra-nographite-amd64/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-240036-checking-yes-rtl-df-extra-nographite-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--without-cloog --without-ppl --without-isl --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu
--with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-240036-checking-yes-rtl-df-extra-nographite-amd64
Thread model: posix
gcc version 7.0.0 20160908 (experimental) (GCC) 

Tested revisions:
r240036 - ICE
6-branch r239849 - OK

[Bug target/77526] New: [7 Regression] ICE: in verify_dominators, at dominance.c:1039 with -mstringop-strategy=byte_loop

[zsojka at seznam dot cz]

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

Bug ID: 77526
   Summary: [7 Regression] ICE: in verify_dominators, at
dominance.c:1039 with -mstringop-strategy=byte_loop
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu
 Build: x86_64-pc-linux-gnu

Created attachment 39583
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39583=edit
reduced testcase

Compiler output:
$ x86_64-pc-linux-gnu-gcc -Os -fno-forward-propagate -fno-gcse
-fno-rerun-cse-after-loop -mstringop-strategy=byte_loop testcase.c -Wno-psabi
testcase.c: In function 'foo':
testcase.c:9:1: error: dominator of 5 should be 4, not 2
 }
 ^
testcase.c:9:1: internal compiler error: in verify_dominators, at
dominance.c:1039
0x7bd965 verify_dominators(cdi_direction)
/repo/gcc-trunk/gcc/dominance.c:1039
0x7bdb8f checking_verify_dominators
/repo/gcc-trunk/gcc/dominance.h:71
0x7bdb8f calculate_dominance_info(cdi_direction)
/repo/gcc-trunk/gcc/dominance.c:664
0x74acdd flow_loops_find(loops*)
/repo/gcc-trunk/gcc/cfgloop.c:419
0x9ff122 loop_optimizer_init(unsigned int)
/repo/gcc-trunk/gcc/loop-init.c:93
0x14dd398 if_convert
/repo/gcc-trunk/gcc/ifcvt.c:5407
0x14df20d execute
/repo/gcc-trunk/gcc/ifcvt.c:5628
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.

$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-240036-checking-yes-rtl-df-extra-nographite-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--without-cloog --without-ppl --without-isl --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu
--with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-240036-checking-yes-rtl-df-extra-nographite-amd64
Thread model: posix
gcc version 7.0.0 20160908 (experimental) (GCC) 

Tested revisions:
r240036 - ICE
6-branch r239849 - OK

[Bug libstdc++/77524] Empty std::deque allocates unnecessary heap memory

[d.rigby at me dot com]

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

--- Comment #3 from Dave Rigby  ---
As an aside, std::queue<> (defaulting to using std::deque as the underlying
Container) suffers from a similar issue - I see 4 allocations for an empty
std::queue. Is this the same underlying issue, or should I raise an
additional bug on that?

[Bug libstdc++/77524] Empty std::deque allocates unnecessary heap memory

[d.rigby at me dot com]

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

--- Comment #2 from Dave Rigby  ---
Hi Jonathan,

Thanks for the context - useful to know why the current behaviour is the case
(even if not ideal).

[Bug libstdc++/77524] Empty std::deque allocates unnecessary heap memory

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||ABI
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-09-08
 Ever confirmed|0   |1
   Severity|normal  |enhancement

--- Comment #1 from Jonathan Wakely  ---
This is a known "feature" of our std::deque and can't be changed without an ABI
break.

I intend to make some improvements to std::deque, including removing the
allocations for empty deques (which will make move construction and move
assignment non-throwing) and PR 24693 comment 4, but that will not be enabled
by default. Those changes can only be done for explicitly
non-backwards-compatible builds of GCC which are configured to use a different
library SONAME. I don't have any ETA for that.

[Bug fortran/77525] New: wrong requirement of an upper bound for an array argument

[francois.jacq at irsn dot fr]

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

Bug ID: 77525
   Summary: wrong requirement of an upper bound for an array
argument
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: francois.jacq at irsn dot fr
  Target Milestone: ---

The following source file does not compile correctly with gfortran 5.3.0 and
5.3.1 
This is a regression because gfortran 4.9.2 is OK

coul@b10p5001:~/test$ gfortran -c mdb_proc.f90
mdb_proc.f90:41:19:

 call my_proc%f(tx,r)

Error: The upper bound in the last dimension must appear in the reference to
the assumed size array 'tx' at (1)

Source file :

module mdb_proc

   ! module managing external procedures to compute specific models

   implicit none
   private   
   save
   public :: listproc,mdb_proc_t

   abstract interface ! all possible signatures of user procedures
  subroutine p(tx,r)
 real,intent(in)  :: tx(*)
 real,intent(out) :: r
  end subroutine
   end interface

   type mdb_proc_t
  character(32):: cname
  integer  :: mode=0
  procedure(p) ,pointer,nopass :: f
   end type

   integer,parameter:: nprocmax=2048
   type(mdb_proc_t),target  :: listproc(0:nprocmax-1)

end module

subroutine test(tx,r)
use mdb_proc
implicit none
real,intent(in) :: tx(*)
real,intent(out) :: r
type(mdb_proc_t),pointer :: my_proc
my_proc => listproc(5)
call my_proc%f(tx,r)
end subroutine

[Bug c++/64767] Could GCC warn when a pointer is compared against '\0'?

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||mpolacek at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org

--- Comment #6 from Marek Polacek  ---
Looking into this; the C FE part will be harder than the C++ FE part since the
latter has delayed folding.

I'm wondering whether a warning for ptr == (char) 0 would be desirable or not,
but I guess so.

[Bug libstdc++/68210] nothrow operator fails to call default new

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
   Target Milestone|--- |7.0

[Bug fortran/77518] [5/6/7 Regression] ICE in gfc_advance_chain, at fortran/trans.c:58

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-09-08
  Known to work||4.9.4
Summary|ICE in gfc_advance_chain,   |[5/6/7 Regression] ICE in
   |at fortran/trans.c:58   |gfc_advance_chain, at
   ||fortran/trans.c:58
 Ever confirmed|0   |1
  Known to fail||5.4.0, 6.2.0, 7.0

--- Comment #1 from Dominique d'Humieres  ---
Confirmed. The change occurred between revisions r213007 (2014-07-24, compile)
and r213805 (2014-08-11, ICE).

[Bug fortran/57117] [OOP] ICE for sourced allocation of a polymorphic entity using TRANSPOSE

[vehre at gcc dot gnu.org]

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

vehre at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|NEW |ASSIGNED
   Assignee|pault at gcc dot gnu.org   |vehre at gcc dot gnu.org
   Target Milestone|--- |5.5

[Bug rtl-optimization/77499] [7 Regression] Regression after code-hoisting, due to combine pass failing to evaluate known value range

[avieira at gcc dot gnu.org]

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

--- Comment #11 from avieira at gcc dot gnu.org ---
(In reply to Segher Boessenkool from comment #10)
> That is what nonzero_bits etc. is about.  We could do much better nowadays
> with the generic DF framework.
> 
I am not familiar with the generic DF framework, could you point me to it?


> Is code hoisting making the code better at all here?  (At RTL level)

Not as is, but I was hoping that if the zero_extend gets removed, we could end
up with:

movwr6, #45345
.L4:
smull   r5, r4, r7, r1
lsrsr0, r0, #1
sub r4, r4, r1, asr #31
-eor r5, r0, r6
add r4, r4, r4, lsl #1
cmp r1, r4
sub r1, r1, r3
it  ne
-uxthne  r0, r5
+eorne r0, r0, r6
cmp r2, r1
blt .L4

So compared to the no-code-hoisting case it would realize it needs to do the
same shift in both cases and only do it once.

[Bug libstdc++/77524] New: Empty std::deque allocates unnecessary heap memory

[d.rigby at me dot com]

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

Bug ID: 77524
   Summary: Empty std::deque allocates unnecessary heap memory
   Product: gcc
   Version: 6.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: d.rigby at me dot com
  Target Milestone: ---

Created attachment 39582
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39582=edit
deque_alloc_test.cc

I'm observing a performance issue under g++/libstdc++ with std::deque. G++ is
creating two allocations for an empty (and ultimately unused) std::deque,
totalling 576 bytes. Consider the example code:

===cut===
#include 
#include 
#include 
void* operator new(std::size_t sz) {
std::printf("global op new called, size = %zu\n",sz);
return std::malloc(sz);
}
void operator delete(void* ptr) throw()
{
std::puts("global op delete called");
std::free(ptr);
}

int main() {
std::puts("Alloc std::queue");
std::deque q;
}
===cut===

(Tested via http://melpon.org/wandbox/permlink/4AXnmcwWhFs9ueRj)

Under GCC 6.1.0 I see 2 allocations being made:

$ g++ prog.cc -O2 -std=c++11 && ./a.out
Alloc std::deque
global op new called, size = 64
global op new called, size = 512
global op delete called
global op delete called

For comparison, under Clang/libc++ I see zero allocations:

$ clang++ prog.cc -stdlib=libc++ -O2 -std=c++11 && ./a.out
Alloc std::deque

(I encountered this in a use-case where I create a std::queue<> local and
conditionally add items to it, and then pass the std::queue<> onwards to other
function to consume. A non-trivial number of times there are no items added to
the queue, and hence I was surprised to see cost (i.e. the allocations) in
creating something I don't use).

[Bug debug/49750] -gdwarf-4 bug

[aoliva at gcc dot gnu.org]

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

Alexandre Oliva  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||aoliva at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #2 from Alexandre Oliva  ---
The ability to get a successful response from GDB for 'ptype X::t2::t2', given
the program plus a suitable main function, came about in revision 187106.  The
main effect of that patch in this testcase was to add the linkage name to the
declaration DIE of the structure_type, in both .debug_info and .debug_types
sections.  Before that patch, the linkage name was already present in the type
definition DIE, only present in .debug_types, but that wasn't enough for GDB to
be able to find the ctor by name.

[Bug bootstrap/70473] genautomata memory footprint for arm

[lly.dev at gmail dot com]

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

--- Comment #16 from Leonid Lisovskiy  ---
(In reply to Andrew Pinski from comment #15)
> Yes create a separate bug report for that.

bug 77510 created, thank you for your attention!

P.S. Personally, I will be happy if automata will consume less than 256MB for
ARM & 128MB for MIPS.