[Bug fortran/38822] Compile-time simplification of x**(real)

[kargl at gcc dot gnu.org]

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

--- Comment #21 from kargl at gcc dot gnu.org ---
(In reply to Dominique d'Humieres from comment #19)
> > AFAICS everthing is fixed here. Can we close this PR?
> 
> Without objection I'll proceed.

Should the bug be fixed before proceeding?  See comment #2 and #3.

module funcs
   implicit none
   contains
  recursive function initialization(x) result(f)
 logical f
 integer x
 integer z(0*transfer(2.D0**2,1)+2)
 save

 z = 0
 if(x > 0) then
z = 1
f = initialization(x-1)
 end if
 f = z(1) == 0
  end function initialization

  recursive function non_initialization(x) result(f)
 logical f
 integer x
 integer z(0*transfer(2.D0**2.,1)+2)
 save

 z = 0
 if(x > 0) then
z = 1
f = non_initialization(x-1)

 end if
 f = z(1) == 0
  end function non_initialization
end module funcs

program exponent_test
   use funcs
   implicit none

   write(*,*) initialization(1), non_initialization(1)
end program exponent_test

[Bug fortran/38822] Compile-time simplification of x**(real)

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #20 from kargl at gcc dot gnu.org ---
(In reply to janus from comment #18)
> AFAICS everthing is fixed here. Can we close this PR?

The bug is not fixed.  Please see comment #2 and #3.

[Bug c/80199] Wlogical-op inconsistent from int to float ?

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-03-26
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
The implementation of the warning relies on the make_range function which in,
in turn, calls make_range_step.  As the comment indicates copied below,
make_range_step has no support for floating point values and so it doesn't
simplify the comparison involving floating point expressions the same way it
does one with integers.  This in turn prevents the warn_logical_operator
function that implements the warning from detecting that the result is always
false.

It seems this should be doable in the constant propagation pass that is able to
figure this out for floats.  I'll confirm it on that basis.

make_range_step (location_t loc, enum tree_code code, tree arg0, tree arg1,
 tree exp_type, tree *p_low, tree *p_high, int *p_in_p,
 bool *strict_overflow_p)
{
...
case EQ_EXPR: case NE_EXPR:
case LT_EXPR: case LE_EXPR: case GE_EXPR: case GT_EXPR:
  /* We can only do something if the range is testing for zero
 and if the second operand is an integer constant.  Note that
 saying something is "in" the range we make is done by
 complementing IN_P since it will set in the initial case of
 being not equal to zero; "out" is leaving it alone.  */
  if (low == NULL_TREE || high == NULL_TREE

[Bug c++/80191] diagnostic placeholder "new initializer" must be marked for translation

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org

--- Comment #3 from Martin Sebor  ---
I wonder if it would be worthwhile to add format specifier to the pretty
printer for terms of the grammar (say %T or something).  That would make it
possible to a) clearly distinguish them from plain English text that must be
translated and perhaps also help diagnose unquoted %s arguments via -Wformat,
and b) format them in a distinct font (such as italics or terminals that
support it, as for instance Gnome terminal does).

[Bug c/80204] New: macosx-version-min wrong for macOS Sierra 10.12.3

[simon at pushface dot org]

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

Bug ID: 80204
   Summary: macosx-version-min wrong for macOS Sierra 10.12.3
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: simon at pushface dot org
  Target Milestone: ---
  Host: x86_64-apple-darwin

In gcc/config/darwin-driver.c, darwin_find_version_from_kernel() assumes
that the minor version in the Darwin kernel version (16.4.0, => minor
version 4) is equal to the bugfix component of the macOS version, so that
the compiler receives -mmacosx-version-min=10.12.4 and the linker receives
-macosx_version_min 10.12.4.

Unfortunately, Apple don’t apply this algorithm; the macOS version is
actually 10.12.3.

Getting this wrong means that it’s impossible to run an executable from 
within a bundle: Sierra complains "You have macOS 10.12.3. The application
requires macOS 10.12.4 or later".

A workround would perhaps be to link the executable with
-Wl,-macosx_version_min,`sw_vers -productVersion` (I assume that it’s only
the linker phase that matters?)

There are several suggestions at e.g. http://stackoverflow.com/q/11072804/40851
which are perhaps unsatisfactory because of using objective-C. Perhaps we
could set up an environment variable during configure, using sw_vers as
above?

As an alternative, I see that Apple’s gcc (Apple LLVM version 8.0.0
(clang-800.0.42.1)) specifies - only at link time -
   -macosx_version_min 10.12.0
Maybe we don’t need to include a specific bugfix component at all? That 
would make life a lot easier!

[Bug fortran/78670] [F03] Incorrect file position with namelist read under DTIO

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

 CC||janus at gcc dot gnu.org
 Depends on||78661

--- Comment #4 from Jerry DeLisle  ---
Janus, the fix for this bug depends on your patch for pr78661. I would like to
incorporate yours into the solution to this PR if ok with you.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78661
[Bug 78661] [OOP] Namelist output missing object designator under DTIO

[Bug other/80203] New: libiberty fails to compile regex.c correctly when gcc is configured --with-sysroot

[jeremyhu at macports dot org]

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

Bug ID: 80203
   Summary: libiberty fails to compile regex.c correctly when gcc
is configured --with-sysroot
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jeremyhu at macports dot org
  Target Milestone: ---

During a build of gcc6, libiberty fails to compile because -isysroot is not
passed to the compiler.  gcc was configured with
--with-sysroot="/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk",
and this is passed elsewhere, but not when building regex.c

 /opt/local/bin/clang-mp-3.9 -arch x86_64 -c -DHAVE_CONFIG_H -pipe -Os
-isysroot/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk
 -I.
-I/opt/local/var/macports/build/_Users_jeremy_src_macports_macports-ports_lang_gcc6/libgcc/work/gcc-6.3.0/libiberty/../include
 -W -Wall -Wwrite-strings -Wc++-compat -Wstrict-prototypes -pedantic 
-D_GNU_SOURCE 
/opt/local/var/macports/build/_Users_jeremy_src_macports_macports-ports_lang_gcc6/libgcc/work/gcc-6.3.0/libiberty/physmem.c

...

if [ x"-fno-common" != x ]; then \
  /opt/local/bin/clang-mp-3.9 -arch x86_64 -c -DHAVE_CONFIG_H -g   -I.
-I/opt/local/var/macports/build/_Users_jeremy_src_macports_macports-ports_lang_gcc6/libgcc/work/gcc-6.3.0/libiberty/../include
 -W -Wall -Wwrite-strings -Wc++-compat -Wstrict-prototypes -pedantic 
-D_GNU_SOURCE -fno-common
/opt/local/var/macports/build/_Users_jeremy_src_macports_macports-ports_lang_gcc6/libgcc/work/gcc-6.3.0/libiberty/regex.c
-o pic/regex.o; \
else true; fi
/opt/local/var/macports/build/_Users_jeremy_src_macports_macports-ports_lang_gcc6/libgcc/work/gcc-6.3.0/libiberty/regex.c:52:12:
fatal error: 'sys/types.h' file not found
#  include 
   ^
1 error generated.

gcc was configured with:

--prefix=/opt/local --build=x86_64-apple-darwin16
--enable-languages=c,c++,objc,obj-c++,lto,fortran
--includedir=/opt/local/include/gcc6 --infodir=/opt/local/share/info
--mandir=/opt/local/share/man --datarootdir=/opt/local/share/gcc-6
--with-local-prefix=/opt/local --with-system-zlib --disable-nls
--program-suffix=-mp-6 --with-gxx-include-dir=/opt/local/include/gcc6/c++/
--with-gmp=/opt/local --with-mpfr=/opt/local --with-mpc=/opt/local
--with-isl=/opt/local --enable-stage1-checking --disable-multilib --enable-lto
--enable-libstdcxx-time --with-build-config=bootstrap-debug
--with-as=/opt/local/bin/as --with-ld=/opt/local/bin/ld
--with-ar=/opt/local/bin/ar --with-bugurl=https://trac.macports.org/newticket
--libdir=/opt/local/lib/libgcc --with-pkgversion="MacPorts gcc6 6.3.0_0"
--with-sysroot="/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk"

Note that we're not using --with-build-sysroot because of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79885

[Bug fortran/79434] [submodules] separate module procedure breaks encapsulation

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

--- Comment #6 from Paul Thomas  ---
Fixed on trunk and 6-branch.

Thanks for the report.

Paul

[Bug fortran/79434] [submodules] separate module procedure breaks encapsulation

[pault at gcc dot gnu.org]

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

--- Comment #5 from Paul Thomas  ---
Author: pault
Date: Sun Mar 26 20:01:07 2017
New Revision: 246486

URL: https://gcc.gnu.org/viewcvs?rev=246486=gcc=rev
Log:
2017-03-26  Paul Thomas  

PR fortran/79434
* parse.c (check_component, parse_union): Whitespace.
(set_syms_host_assoc): For a derived type, check if the module
in which it was declared is one of the submodule ancestors. If
it is, make the components public. Otherwise, reset attribute
'host_assoc' and set 'use-assoc' so that encapsulation is
preserved.

2017-03-26  Paul Thomas  

PR fortran/79434
* gfortran.dg/submodule_25.f08 : New test.

Added:
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/submodule_25.f08
Modified:
branches/gcc-6-branch/gcc/fortran/ChangeLog
branches/gcc-6-branch/gcc/fortran/parse.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug translation/80189] gimplify.c: check whether parallel/task/teams should be translated

[roland.illig at gmx dot de]

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

--- Comment #3 from Roland Illig  ---
To me that would be fine since then I had not even looked at what the %qs might
be. But like the code is now, I suspected the %s to be part of the grammar of
the diagnostic.

[Bug libstdc++/80183] [7 Regression] Conditional jump or move depends on uninitialised value: std::local_Rb_tree_decrement(std::_Rb_tree_node_base*) (tree.cc:97)

[fdumont at gcc dot gnu.org]

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

--- Comment #7 from François Dumont  ---
(In reply to Jonathan Wakely from comment #4)
> I think this is my fault, I asked François to remove a store to _M_color
> that I thought was redundant.

I was surprised that _M_color wasn't move along with other members, with your
patch it is now.

However to strictly restore previous behavior you could have only set _M_color
to red in the move constructor whether _M_move_data or _M_reset was called. But
I prefer current code of course.

[Bug c++/80202] New: Spurious warning "array subscript is below array bounds" with if-statement and char to unsigned int conversion

[mchtly at gmail dot com]

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

Bug ID: 80202
   Summary: Spurious warning "array subscript is below array
bounds" with if-statement and char to unsigned int
conversion
   Product: gcc
   Version: 6.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mchtly at gmail dot com
  Target Milestone: ---

When compiling the following example with "g++ -Warray-bounds -O2", I get
spurious warnings:

// This type doesn't matter.
#define T int

T ac[2]; // No warning if this is static.
void foo(T); // No warning if this is defined.

enum {
  ACM0 = 1, // This value must be greater than zero.
  ACM1 // This value may be any non-negative integer.
};

// The parameter to srs() must be unsigned, the parameter to read()
// must be signed, and the first must be smaller than the second.
static_assert(sizeof(unsigned char) < sizeof(int), "");

T read(int reg) {
  switch (reg) {
  // No warning if either case statement is removed. Additional cases
  // may be added anywhere.
  case ACM0:
  case ACM1:
return ac[reg - ACM0];
  // The default case statement may be removed, and is only included
  // for completeness.
  default:
return 0;
  }
}

void srs(unsigned char reg) {
  if (reg < ACM0)
// Warning only if the return value of read() is passed to foo()
// at some point.
foo(read(reg));
}


And the output from GCC is:

$ g++ -c test.cpp -Warray-bounds -O2
test.cpp: In function 'void srs(unsigned char)':
test.cpp:22:25: warning: array subscript is below array bounds [-Warray-bounds]
 return ac[reg - ACM0];
~^

[Bug c/80201] New: groff build fails with -floop-nest-optimize -fgraphite-identity

[fjeldse at hotmail dot com]

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

Bug ID: 80201
   Summary: groff build fails with -floop-nest-optimize
-fgraphite-identity
   Product: gcc
   Version: 6.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fjeldse at hotmail dot com
  Target Milestone: ---

Created attachment 41054
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41054=edit
getopt.c preprocessed source

When building groff-1.22.2 (Gentoo) on GCC 6.3.0, I receive the following
error:

i686-pc-linux-gnu-gcc -I. -I.
-I/var/tmp/portage/sys-apps/groff-1.22.2/work/groff-1.22.2/src/include
-I/var/tmp/portage/sys-apps/groff-1.22.2/work/groff-1.22.2/src/include
-I/var/tmp/portage/sys-apps/groff-1.22.2/work/groff-1.22.2/src/libs/gnulib/lib
-DHAVE_CONFIG_H -O2 -pipe -floop-nest-optimize -fgraphite-identity
-march=native  -c -D__GETOPT_PREFIX=groff_ -DENABLE_RELOCATABLE=1
-DLIBDIR=\"/usr/lib\" getopt.c

getopt.c: In function 'exchange':
getopt.c:171:1: internal compiler error: in add_loop_constraints, at
graphite-sese-to-poly.c:933
 exchange (char **argv, struct _getopt_data *d)
 ^~~~
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

GCC specs are as follows:
Using built-in specs.
COLLECT_GCC=/usr/i686-pc-linux-gnu/gcc-bin/6.3.0/i686-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/i686-pc-linux-gnu/6.3.0/lto-wrapper
Target: i686-pc-linux-gnu
Configured with: /var/tmp/portage/sys-devel/gcc-6.3.0/work/gcc-6.3.0/configure
--host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --prefix=/usr
--bindir=/usr/i686-pc-linux-gnu/gcc-bin/6.3.0
--includedir=/usr/lib/gcc/i686-pc-linux-gnu/6.3.0/include
--datadir=/usr/share/gcc-data/i686-pc-linux-gnu/6.3.0
--mandir=/usr/share/gcc-data/i686-pc-linux-gnu/6.3.0/man
--infodir=/usr/share/gcc-data/i686-pc-linux-gnu/6.3.0/info
--with-gxx-include-dir=/usr/lib/gcc/i686-pc-linux-gnu/6.3.0/include/g++-v6
--with-python-dir=/share/gcc-data/i686-pc-linux-gnu/6.3.0/python
--enable-languages=c,c++ --enable-obsolete --enable-secureplt --disable-werror
--with-system-zlib --enable-nls --without-included-gettext
--enable-checking=release --with-bugurl=https://bugs.gentoo.org/
--with-pkgversion='Gentoo Hardened 6.3.0 p1.0' --enable-esp
--enable-libstdcxx-time --disable-libstdcxx-pch --enable-shared
--enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu
--disable-multilib --disable-altivec --disable-fixed-point --with-arch=i686
--enable-targets=all --disable-libgcj --enable-libgomp --disable-libmudflap
--disable-libssp --disable-libcilkrts --disable-libmpx --enable-vtable-verify
--enable-libvtv --disable-libquadmath --enable-lto --with-isl
--disable-isl-version-check --disable-libsanitizer --disable-default-pie
--enable-default-ssp
Thread model: posix
gcc version 6.3.0 (Gentoo Hardened 6.3.0 p1.0)

[Bug libstdc++/80196] fenv_t not declared

[roman.morokutti at googlemail dot com]

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

Roman  changed:

   What|Removed |Added

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

--- Comment #5 from Roman  ---
Thank you, Jonathan.

Disable the pre compiled header for libstdc++-v3,
did solve the problem. However, a new one occured
for which I filed a new bug (80200).

Best regards,
Roman

[Bug c++/80200] New: decNumber.c : error : #include_next is a GCC extension

[roman.morokutti at googlemail dot com]

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

Bug ID: 80200
   Summary: decNumber.c : error : #include_next is a GCC extension
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: roman.morokutti at googlemail dot com
  Target Milestone: ---

Hello,

while building the Subversion tree (Revision 246482) the following error
occurs:

In file included from /home/roman/gcc-source/libdecnumber/decNumber.c:175:0:
/usr/local/include/c++/7.0.0/stdlib.h:30:3: error: #include_next is a GCC
extension [-Werror]
 # include_next 
   ^~~~
In file included from
/home/roman/gcc-source/libdecnumber/decNumberLocal.h:40:0,
 from /home/roman/gcc-source/libdecnumber/decNumber.c:181:
/usr/local/include/c++/7.0.0/stdlib.h:30:3: error: #include_next is a GCC
extension [-Werror]
 # include_next 
   ^~~~
cc1: all warnings being treated as errors
Makefile:193: recipe for target 'decNumber.o' failed.



Operating System: Gentoo

Build System:
/usr/local/bin/gcc --version
gcc (GCC) 7.0.1 20170304 (experimental)
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Configure:
/home/roman/gcc-source/configure --disable-libstdcxx-pch

Please resolve this bug.

Thank you in advance.

Best regards,
Roman

[Bug tree-optimization/65917] [6 Regression] XFAIL: gcc.dg/tree-ssa/20030922-2.c scan-tree-dump-times dom1 "if " 2

[jtaylor.debian at googlemail dot com]

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

Julian Taylor  changed:

   What|Removed |Added

 CC||jtaylor.debian at googlemail 
dot c
   ||om

--- Comment #12 from Julian Taylor  ---
this fixed appears to have caused this performance regression:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80198

[Bug tree-optimization/80198] regression [6/7], does not vectorize generic inplace integer operation

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski  ---
r233207

[Bug tree-optimization/80198] regression [6/7], does not vectorize generic inplace integer operation

[jtaylor.debian at googlemail dot com]

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

Julian Taylor  changed:

   What|Removed |Added

Summary|regression, does not|regression [6/7], does not
   |vectorize generic inplace   |vectorize generic inplace
   |integer operation   |integer operation

--- Comment #2 from Julian Taylor  ---
the regression occurred in 07c0f1caa31079d8f4edd7ff4a06656e2a4441c5 svn 233207
current trunk/master is still affected

[Bug fortran/79434] [submodules] separate module procedure breaks encapsulation

[paul.richard.thomas at gmail dot com]

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

--- Comment #4 from paul.richard.thomas at gmail dot com  ---
Hi Dominiq,

As soon as I have a minute or two, I will back port it. My business is
taking me 7/7 at the moment.

Thanks for the reminder.

Paul

On 26 March 2017 at 17:36, dominiq at lps dot ens.fr
 wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79434
>
> Dominique d'Humieres  changed:
>
>What|Removed |Added
> 
>  Status|NEW |WAITING
>
> --- Comment #3 from Dominique d'Humieres  ---
> Any plan to back port r245595 to 6.4? or should the PR closed as FIXED?
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.
> You are the assignee for the bug.

[Bug testsuite/80184] FAIL: gcc.dg/torture/pr79732.c -O* (test for excess errors) on darwin

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #1 from Dominique d'Humieres  ---
Fixed by revision r246485.

[Bug c/80199] New: Wlogical-op inconsistent from int to float ?

[dcb314 at hotmail dot com]

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

Bug ID: 80199
   Summary: Wlogical-op inconsistent from int to float ?
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

For the following C++ code:

void g1( float );
void g2( int );

void
f1( float a)
{
if (a < 0.0 && a > 1.0)
g1( a);
}

void
f2( int a)
{
if (a < 0 && a > 1)
g2( a);
}

I get only one warning, not the expected two:

$ ~/gcc/results/bin/g++ -g -O2 -Wall -Wlogical-op -Wextra -c mar26e.cc
mar26e.cc: In function ‘void f2(int)’:
mar26e.cc:15:12: warning: logical ‘and’ of mutually exclusive tests is always
false [-Wlogical-op]
  if (a < 0 && a > 1)
  ~~^~~~
$ ~/gcc/results/bin/g++ -v
Using built-in specs.
COLLECT_GCC=/home/dcb/gcc/results/bin/g++
COLLECT_LTO_WRAPPER=/home/dcb/gcc/results.246474/libexec/gcc/x86_64-pc-linux-gnu/7.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../trunk/configure --prefix=/home/dcb/gcc/results.246474
--disable-bootstrap --disable-multilib --disable-werror
--enable-checking=df,extra,fold,rtl,yes --enable-languages=c,c++,fortran
Thread model: posix
gcc version 7.0.1 20170325 (experimental) (GCC) 
$

[Bug fortran/79434] [submodules] separate module procedure breaks encapsulation

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|NEW |WAITING

--- Comment #3 from Dominique d'Humieres  ---
Any plan to back port r245595 to 6.4? or should the PR closed as FIXED?

[Bug tree-optimization/80198] regression, does not vectorize generic inplace integer operation

[jtaylor.debian at googlemail dot com]

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

Julian Taylor  changed:

   What|Removed |Added

Summary|does not vectorize generic  |regression, does not
   |inplace integer operation   |vectorize generic inplace
   ||integer operation

--- Comment #1 from Julian Taylor  ---
actually this seems to be a regression.
Compiled with gcc 4.6 it does chose the vectorized path for the inplace
function arguments.

[Bug fortran/53542] Diagnostic of USE-associated variables shows original instead of renamed symbol name

[dominiq at lps dot ens.fr]

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

--- Comment #2 from Dominique d'Humieres  ---
From comment 0, obvious patch

--- ../_clean/gcc/fortran/expr.c2017-03-22 17:29:45.0 +0100
+++ gcc/fortran/expr.c  2017-03-26 16:12:21.0 +0200
@@ -2591,7 +2591,7 @@ gfc_check_init_expr (gfc_expr *e)
   else
gfc_error ("Parameter %qs at %L has not been declared or is "
   "a variable, which does not reduce to a constant "
-  "expression", e->symtree->n.sym->name, >where);
+  "expression", e->symtree->name, >where);

   break;

[Bug tree-optimization/80198] New: does not vectorize generic inplace integer operation

[jtaylor.debian at googlemail dot com]

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

Bug ID: 80198
   Summary: does not vectorize generic inplace integer operation
   Product: gcc
   Version: 6.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jtaylor.debian at googlemail dot com
  Target Milestone: ---

In the following code the generic function does not vectorize when provided
with arguments that do an inplace operation. GCC does emit vector code but the
code is only executed in out of place operations where |a - b| > 16.
This is despite the explicit hint to the compiler that the two pointers are the
same.

As the explicit inplace variant does execute the same vectorized code there
should be no issue with the method chosen and GCC should allow the inplace
operations to choose the vector path.

void __attribute__((noinline)) fun(int * a, int * b, int c)
{
int i;
if (a == b) {
for (i=0; i < 256; i++) {
a[i] = b[i] | c;
}
}
else {
for (i=0; i < 256; i++) {
a[i] = b[i] | c;
}
}
}


void __attribute__((noinline)) inplace(int * a, int c)
{
int i;
for (i=0; i < 256; i++) {
a[i] = a[i] | c;
}
}

int main()
{
int a[256];
generic(a, a, 0);
inplace(a, 0);
}


$ gcc -v
Using built-in specs.
COLLECT_GCC=/usr/bin/gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/6/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 6.2.0-5ubuntu12'
--with-bugurl=file:///usr/share/doc/gcc-6/README.Bugs
--enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-6 --program-prefix=x86_64-linux-gnu- --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 --enable-default-pie
--with-system-zlib --disable-browser-plugin --enable-java-awt=gtk
--enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-6-amd64/jre
--enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-6-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-6-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 6.2.0 20161005 (Ubuntu 6.2.0-5ubuntu12) 

$ gcc test.c  -ftree-vectorize -g -O2

[Bug libstdc++/80187] C++ variant should be trivially copy constructible if possible

[timshen at gcc dot gnu.org]

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

Tim Shen  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-03-26
 CC||timshen at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |timshen at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Tim Shen  ---
Assign to myself.

Implementation idea:
  https://godbolt.org/g/ulh4V7

The idea is to avoid multiple-layer hierarchy that libc++ uses, while remains
easy to extend to fine-grained triviality (one for each of big five). It
requires more or less a rewrite of the storage part. It's not hard for now,
because we don't have ABI compatibility constraints.

[Bug rtl-optimization/80197] New: pgo dramatically pessimizes scimark2 MonteCarlo benchmark

[vincenzo.innocente at cern dot ch]

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

Bug ID: 80197
   Summary: pgo dramatically pessimizes scimark2 MonteCarlo
benchmark
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vincenzo.innocente at cern dot ch
  Target Milestone: ---

Created attachment 41053
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41053=edit
self contained benchmark of scimark2 MC

while chasing the regression I then found identified and solved in #79389
I discovered that pgo manages to do much worse than the regression above.
The symptom is the same: a huge increase in branch-miss.
This is not a regression: it is the same at least since gcc5.3
Attached a self contained single file, copy of scimark2 MC, and a couple of
scripts to compile and run it

just
tar -xzf fullMC.tgz
cd fullMC
# standard compilation -O2 -O3
./runit 
# same with pgo passes
./dopgo

or just do
[innocent@vinavx3 fullMC]$ rm -rf pgo/* ; c++ -O3 fullMC.c -g
-fprofile-generate=pgo ; time ./a.out
1.848u 0.000s 0:01.85 99.4% 0+0k 0+8io 0pf+0w
[innocent@vinavx3 fullMC]$ c++ -O3 fullMC.c -g -fprofile-use=./pgo ; time
./a.out
0.967u 0.001s 0:00.96 100.0%0+0k 0+0io 0pf+0w
[innocent@vinavx3 fullMC]$ c++ -O3 fullMC.c -g; time ./a.out
0.328u 0.000s 0:00.32 100.0%0+0k 0+0io 0pf+0w


for reference:
cat dopgo
cat /proc/cpuinfo | grep name | head -n 1
gcc -v
rm -rf pgo/*;gcc -O2 fullMC.c -g -fprofile-generate=pgo; ./a.out
gcc -O2 fullMC.c -g -fprofile-use=pgo; ./a.out
perf stat -e task-clock -e cycles -e instructions -e branches -e branch-misses
./a.out
rm -rf pgo/*;gcc -O3 fullMC.c -g -fprofile-generate=pgo; ./a.out
gcc -O3 fullMC.c -g -fprofile-use=pgo; ./a.out
perf stat -e task-clock -e cycles -e instructions -e branches -e branch-misses
./a.out


on my machine the result is
# standard compilation
[innocent@vinavx3 fullMC]$ ./runit 
model name  : Intel(R) Core(TM) i7-6700K CPU @ 4.00GHz
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/afs/cern.ch/work/i/innocent/public/w5/bin/../libexec/gcc/x86_64-pc-linux-gnu/7.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk//configure
--prefix=/afs/cern.ch/user/i/innocent/w5 -enable-languages=c,c++,lto,fortran
--enable-lto -enable-libitm -disable-multilib
Thread model: posix
gcc version 7.0.1 20170326 (experimental) [trunk revision 246482] (GCC) 
gcc -O2 fullMC.c -g

real0m0.489s
user0m0.485s
sys 0m0.002s

 Performance counter stats for './a.out':

486.303424  task-clock (msec) #0.999 CPUs utilized  
1901271534  cycles#3.910 GHz
6403589598  instructions  #3.37  insn per cycle 
 700683389  branches  # 1440.836 M/sec  
 13582  branch-misses #0.00% of all branches

   0.486571089 seconds time elapsed

gcc -O3 fullMC.c -g

real0m0.330s
user0m0.330s
sys 0m0.000s

 Performance counter stats for './a.out':

327.385696  task-clock (msec) #0.999 CPUs utilized  
1279958668  cycles#3.910 GHz
5009002909  instructions  #3.91  insn per cycle 
 306481761  branches  #  936.149 M/sec  
 10805  branch-misses #0.00% of all branches

   0.327637485 seconds time elapsed


// pro generation and use (perf after use...)
[innocent@vinavx3 fullMC]$ ./dopgo 
model name  : Intel(R) Core(TM) i7-6700K CPU @ 4.00GHz
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/afs/cern.ch/work/i/innocent/public/w5/bin/../libexec/gcc/x86_64-pc-linux-gnu/7.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk//configure
--prefix=/afs/cern.ch/user/i/innocent/w5 -enable-languages=c,c++,lto,fortran
--enable-lto -enable-libitm -disable-multilib
Thread model: posix
gcc version 7.0.1 20170326 (experimental) [trunk revision 246482] (GCC) 

 Performance counter stats for './a.out':

964.399833  task-clock (msec) #1.000 CPUs utilized  
3770455888  cycles#3.910 GHz
5007987488  instructions  #1.33  insn per cycle 
 816525627  branches  #  846.667 M/sec  
  88982233  branch-misses #   10.90% of all branches

   0.964699603 seconds time elapsed


 Performance counter stats for './a.out':

964.540691  task-clock (msec) #1.000 CPUs utilized  
3771010753  cycles#3.910 GHz
5007957589  instructi

[Bug fortran/38822] Compile-time simplification of x**(real)

[dominiq at lps dot ens.fr]

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

--- Comment #19 from Dominique d'Humieres  ---
> AFAICS everthing is fixed here. Can we close this PR?

Without objection I'll proceed.

[Bug c++/80191] diagnostic placeholder "new initializer" must be marked for translation

[roland.illig at gmx dot de]

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

--- Comment #2 from Roland Illig  ---
But then shouldn't it be spelled "new-initializer", not "new initializer"?

[Bug libstdc++/80196] fenv_t not declared

[roman.morokutti at googlemail dot com]

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

--- Comment #4 from Roman  ---
Thank you for your quick response.

I am using Gentoo. I'll give that option a try.

The build system is:
/usr/local/bin/gcc --version
gcc (GCC) 7.0.1 20170304 (experimental)
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

I'll report the result, when the build has finished, either by failure, or by
success, respectively.

Best regards,
Roman

[Bug libstdc++/80183] [7 Regression] Conditional jump or move depends on uninitialised value: std::local_Rb_tree_decrement(std::_Rb_tree_node_base*) (tree.cc:97)

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

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

--- Comment #6 from Markus Trippelsdorf  ---
Fixed.

[Bug libstdc++/80196] fenv_t not declared

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
Maybe PR 40974 again, which nobody can reproduce as it only happens due to some
system-specific weirdness. We need more information about your system, what
kind of OS distro are you using? etc. etc.

Could you try adding --disable-libstdcxx-pch to the configure command?

[Bug libstdc++/80183] [7 Regression] Conditional jump or move depends on uninitialised value: std::local_Rb_tree_decrement(std::_Rb_tree_node_base*) (tree.cc:97)

[trippels at gcc dot gnu.org]

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

--- Comment #5 from Markus Trippelsdorf  ---
Author: trippels
Date: Sun Mar 26 12:33:35 2017
New Revision: 246483

URL: https://gcc.gnu.org/viewcvs?rev=246483=gcc=rev
Log:
Fix PR80183 : _M_color not moved

PR libstdc++/80183
* include/bits/stl_tree.h:
(_Rb_tree_header::_M_move_data(_Rb_tree_header&)): Also save _M_color.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/stl_tree.h

[Bug c++/80191] diagnostic placeholder "new initializer" must be marked for translation

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #1 from Jonathan Wakely  ---
"new-initializer" is a grammar term in the C++ standard, so maybe it shouldn't
be translated.

[Bug libstdc++/80183] [7 Regression] Conditional jump or move depends on uninitialised value: std::local_Rb_tree_decrement(std::_Rb_tree_node_base*) (tree.cc:97)

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--- Comment #4 from Jonathan Wakely  ---
I think this is my fault, I asked François to remove a store to _M_color that I
thought was redundant.

[Bug libstdc++/80196] fenv_t not declared

[roman.morokutti at googlemail dot com]

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

--- Comment #2 from Roman  ---
Revision 246482.

[Bug libstdc++/80196] fenv_t not declared

[roman.morokutti at googlemail dot com]

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

--- Comment #1 from Roman  ---
I configured the build as follows:

/home/roman/gcc-source/configure

Best regards,
Roman

[Bug libstdc++/80196] New: fenv_t not declared

[roman.morokutti at googlemail dot com]

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

Bug ID: 80196
   Summary: fenv_t not declared
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: roman.morokutti at googlemail dot com
  Target Milestone: ---

Hello,

with the current Subversion tree I get the following error while building
libstdc++-v3:

In file included from
/var/tmp/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/include/cfenv:41:0,
 from
/home/roman/gcc-source/libstdc++-v3/include/precompiled/stdc++.h:53:
/var/tmp/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/include/fenv.h:58:11:
error: ‘::fenv_t’ has not been declared
   using ::fenv_t;
   ^~
/var/tmp/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/include/fenv.h:59:11:
error: ‘::fexcept_t’ has not been declared
   using ::fexcept_t;
   ^
/var/tmp/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/include/fenv.h:62:11:
error: ‘::feclearexcept’ has not been declared
   using ::feclearexcept;
   ^
/var/tmp/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/include/fenv.h:63:11:
error: ‘::fegetexceptflag’ has not been declared
   using ::fegetexceptflag;
   ^~~
/var/tmp/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/include/fenv.h:64:11:
error: ‘::feraiseexcept’ has not been declared
   using ::feraiseexcept;
   ^
/var/tmp/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/include/fenv.h:65:11:
error: ‘::fesetexceptflag’ has not been declared
   using ::fesetexceptflag;
   ^~~
/var/tmp/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/include/fenv.h:66:11:
error: ‘::fetestexcept’ has not been declared
   using ::fetestexcept;
   ^~~~
/var/tmp/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/include/fenv.h:68:11:
error: ‘::fegetround’ has not been declared
   using ::fegetround;
   ^~
/var/tmp/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/include/fenv.h:69:11:
error: ‘::fesetround’ has not been declared
   using ::fesetround;
   ^~
/var/tmp/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/include/fenv.h:71:11:
error: ‘::fegetenv’ has not been declared
   using ::fegetenv;
   ^~~~
/var/tmp/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/include/fenv.h:72:11:
error: ‘::feholdexcept’ has not been declared
   using ::feholdexcept;
   ^~~~
/var/tmp/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/include/fenv.h:73:11:
error: ‘::fesetenv’ has not been declared
   using ::fesetenv;
   ^~~~
/var/tmp/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/include/fenv.h:74:11:
error: ‘::feupdateenv’ has not been declared
   using ::feupdateenv;
   ^~~
In file included from
/home/roman/gcc-source/libstdc++-v3/include/precompiled/stdc++.h:53:0:
/var/tmp/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/include/cfenv:61:11:
error:::fenv_t’ has not been declared
   using ::fenv_t;
   ^~
/var/tmp/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/include/cfenv:62:11:
error:::fexcept_t’ has not been declared
   using ::fexcept_t;
   ^
/var/tmp/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/include/cfenv:65:11:
error:::feclearexcept’ has not been declared
   using ::feclearexcept;
   ^
/var/tmp/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/include/cfenv:66:11:
error:::fegetexceptflag’ has not been declared
   using ::fegetexceptflag;
   ^~~
/var/tmp/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/include/cfenv:67:11:
error:::feraiseexcept’ has not been declared
   using ::feraiseexcept;
   ^
/var/tmp/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/include/cfenv:68:11:
error:::fesetexceptflag’ has not been declared
   using ::fesetexceptflag;
   ^~~
/var/tmp/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/include/cfenv:69:11:
error:::fetestexcept’ has not been declared
   using ::fetestexcept;
   ^~~~
/var/tmp/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/include/cfenv:71:11:
error:::fegetround’ has not been declared
   using ::fegetround;
   ^~
/var/tmp/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/include/cfenv:72:11:
error:::fesetround’ has not been declared
   using ::fesetround;
   ^~
/var/tmp/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/include/cfenv:74:11:
error:::fegetenv’ has not been declared
   using ::fegetenv;
   ^~~~
/var/tmp/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/include/cfenv:75:11:
error:::feholdexcept’ has not been declared
   using ::feholdexcept;
   ^~~~
/var/tmp/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/include/cfenv:76:11:
error:::fesetenv’ has not been declared
   using ::fesetenv;
   ^~~~
/var/tmp/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/include/cfenv:77:11:
error:::feupdateenv’ has 

[Bug translation/80189] gimplify.c: check whether parallel/task/teams should be translated

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Yeah, these are all keywords.  Perhaps we should use %qs instead of %s in both
strings though.

[Bug translation/80195] New: Message build from untranslated string concatenation in fortran/resolve.c:14529

[fmarchal at perso dot be]

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

Bug ID: 80195
   Summary: Message build from untranslated string concatenation
in fortran/resolve.c:14529
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: translation
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fmarchal at perso dot be
  Target Milestone: ---

In fortran/resolve.c at line 14529:

  if (sym->ts.type == BT_DERIVED
  && sym->ns->proc_name && sym->ns->proc_name->attr.flavor == FL_MODULE
  && !sym->ts.u.derived->attr.use_assoc
  && gfc_check_symbol_access (sym)
  && !gfc_check_symbol_access (sym->ts.u.derived)
  && !gfc_notify_std (GFC_STD_F2003, "PUBLIC %s %qs at %L of PRIVATE "
  "derived type %qs",
  (sym->attr.flavor == FL_PARAMETER)
  ? "parameter" : "variable",
  sym->name, >declared_at,
  sym->ts.u.derived->name))
return;

The first %s is replaced with one of the untranslated strings literal
"parameter" or "variable".

That message can't be translated because it is constructed by concatenating
strings fragments.

[Bug libstdc++/80183] [7 Regression] Conditional jump or move depends on uninitialised value: std::local_Rb_tree_decrement(std::_Rb_tree_node_base*) (tree.cc:97)

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

   Target Milestone|--- |7.0

--- Comment #3 from Markus Trippelsdorf  ---
The problem is here libstdc++-v3/include/bits/stl_tree.h:


 179 #if __cplusplus >= 201103L 
 180 _Rb_tree_header(_Rb_tree_header&& __x) noexcept
 181 {  
 182   if (__x._M_header._M_parent != nullptr)  
 183 _M_move_data(__x); 
 184   else 
 185 {  
 186   _M_header._M_color = _S_red; 
 187   _M_reset();  
 188 }  
 189 }  
 190 #endif 
 191
 192 void   
 193 _M_move_data(_Rb_tree_header& __from)  
 194 {  
 195   _M_header._M_parent = __from._M_header._M_parent;
 196   _M_header._M_left = __from._M_header._M_left;
 197   _M_header._M_right = __from._M_header._M_right;  
 198   _M_header._M_parent->_M_parent = &_M_header; 
 199   _M_node_count = __from._M_node_count;
 200
 201   __from._M_reset();   
 202 }  
 203
 204 void   
 205 _M_reset() 
 206 {  
 207   _M_header._M_parent = 0; 
 208   _M_header._M_left = &_M_header;  
 209   _M_header._M_right = &_M_header; 
 210   _M_node_count = 0;   
 211 }  
 212   }; 

on line 183 _M_move_data(__x) doesn't set _M_header._M_color to any value.
So either hard set it to _S_red or augment _M_move_data to copy the color.