[Bug middle-end/68855] PAREN_EXPR not "ignored" where possible

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug middle-end/68855] PAREN_EXPR not "ignored" where possible

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
Confirmed, it might be easy to do this now on with match.pd.

[Bug middle-end/68855] PAREN_EXPR not "ignored" where possible

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

[Bug target/72802] powerpc64le: -mcpu=power9 emits lxssp instruction with offset that isn't a multiple of 4

[amodra at gmail dot com]

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

Alan Modra  changed:

   What|Removed |Added

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

--- Comment #10 from Alan Modra  ---
Fixed

[Bug middle-end/66872] fold a & ((1 << b) - 1) to a & ~(-1 << b)

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||missed-optimization
 CC||pinskia at gcc dot gnu.org
   Severity|normal  |enhancement

[Bug target/72802] powerpc64le: -mcpu=power9 emits lxssp instruction with offset that isn't a multiple of 4

[amodra at gcc dot gnu.org]

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

--- Comment #9 from Alan Modra  ---
Author: amodra
Date: Tue Aug  9 05:44:39 2016
New Revision: 239270

URL: https://gcc.gnu.org/viewcvs?rev=239270=gcc=rev
Log:
[RS6000] PR72802 part 2, reload ICE

PR target/72802
* config/rs6000/rs6000.md (mov_hardfloat): Sort
alternatives.  Put loads first, then stores, and reg/reg moves
within same class later.  Delete attr length.
testsuite/
* gcc.c-torture/compile/pr72802.c: New.

Added:
branches/gcc-6-branch/gcc/testsuite/gcc.c-torture/compile/pr72802.c
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/config/rs6000/rs6000.md
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug target/72802] powerpc64le: -mcpu=power9 emits lxssp instruction with offset that isn't a multiple of 4

[amodra at gcc dot gnu.org]

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

--- Comment #8 from Alan Modra  ---
Author: amodra
Date: Tue Aug  9 05:43:29 2016
New Revision: 239269

URL: https://gcc.gnu.org/viewcvs?rev=239269=gcc=rev
Log:
[RS6000] PR72802 part 1, fix constraints for lxssp/stxssp

PR target/72802
* config/rs6000/rs6000.c (mem_operand_gpr): Remove vsx dform test.
(mem_operand_ds_form): New predicate.
* config/rs6000/rs6000-protos.h (mem_operand_ds_form): Declare.
* config/rs6000/constraints.md (wY): New constraint.
* config/rs6000/rs6000.md (f32_lm2, f32_sm2): Use wY for SF.
(extendsfdf2_fpr): Replace o constraint with wY.

Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/config/rs6000/constraints.md
branches/gcc-6-branch/gcc/config/rs6000/rs6000-protos.h
branches/gcc-6-branch/gcc/config/rs6000/rs6000.c
branches/gcc-6-branch/gcc/config/rs6000/rs6000.md

[Bug c++/67131] [6 Regression] ICE: Segmentation fault

[jason at gcc dot gnu.org]

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

--- Comment #7 from Jason Merrill  ---
Author: jason
Date: Tue Aug  9 04:33:42 2016
New Revision: 239267

URL: https://gcc.gnu.org/viewcvs?rev=239267=gcc=rev
Log:
Fix empty class parameters with constexpr.

PR c++/67131
* class.c (is_really_empty_class): Call complete_type.
* constexpr.c (cxx_eval_constant_expression): Check
is_really_empty_class.
(potential_constant_expression_1): Likewise.  Check for error type.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-empty12.C
trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-empty13.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/class.c
trunk/gcc/cp/constexpr.c
trunk/gcc/testsuite/g++.dg/cpp1y/var-templ42.C

[Bug rtl-optimization/71724] [5/6/7 Regression] ICE: Segmentation fault, deep recursion between combine_simplify_rtx and subst

[amodra at gmail dot com]

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

Alan Modra  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-08-09
 CC||amodra at gmail dot com
 Ever confirmed|0   |1

--- Comment #1 from Alan Modra  ---
combine goes into infinite recursion inside this call:
 newpat = subst (newpat, i0dest, i0src, 0, 0, 0);

The args of the failing subst are:
x:
(parallel [
(set (reg:SI 181)
(plus:SI (ltu:SI (plus:SI (reg:SI 165)
(reg:SI 174 [ t9.0_1+4 ]))
(reg:SI 165))
(reg:SI 173 [ t9.0_1 ])))
(clobber (reg:SI 76 ca))
])
from:
(reg:SI 174 [ t9.0_1+4 ])
to:
(if_then_else:SI (eq (reg:CC 185)
(const_int 0 [0]))
(reg:SI 165)
(reg:SI 174 [ t9.0_1+4 ]))

[Bug tree-optimization/71815] SLSR misses several PHI candidate cases

[wschmidt at gcc dot gnu.org]

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

--- Comment #8 from Bill Schmidt  ---
Created attachment 39085
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39085=edit
Patch under test

Attaching a patch that passes regstrap.  I want to do a little benchmarking
before submitting it upstream, and invite other targets to try it out also.  I
expect overall mildly positive to neutral results, but since it will cause us
to optimize more cases that are right on the cost bubble, it's worth checking
out first.

[Bug gcov-profile/58306] Broken profiling for unrar sources: error: corrupted value profile: value profile counter (X out of Y) inconsistent with basic-block count

[tulipawn at gmail dot com]

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

--- Comment #25 from PeteVine  ---
Great news, thanks! What about backporting to 4.9? There's not going to be
another official release but manual patching could still be useful.

[Bug c++/72836] global variable read clashes with reading from cin with sync_stdio(false)

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
read is a standard ISO C/C++ function.  This is an ODR violation which is not
required be diagnosed.

Basically you re-declared read as a variable rather than a function.

[Bug c/64955] RFE: have -Wformat suggest the correct format string to use

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #7 from David Malcolm  ---
Marking as resolved.

[Bug c/64955] RFE: have -Wformat suggest the correct format string to use

[dmalcolm at gcc dot gnu.org]

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

--- Comment #6 from David Malcolm  ---
Author: dmalcolm
Date: Mon Aug  8 22:50:47 2016
New Revision: 239260

URL: https://gcc.gnu.org/viewcvs?rev=239260=gcc=rev
Log:
c-format.c: suggest the correct format string to use (PR c/64955)

This adds fix-it hints to c-format.c so that it can (sometimes) suggest
the format string the user should have used.

The patch adds selftests for the new code in c-format.c.  These
selftests are thus lang-specific.  This is the first time we've had
lang-specific selftests, and hence the patch also adds a langhook for
running them.  (Note that currently the Makefile only invokes the
selftests for cc1).

gcc/c-family/ChangeLog:
PR c/64955
* c-common.h (selftest::c_format_c_tests): New declaration.
(selftest::run_c_tests): New declaration.
* c-format.c: Include "selftest.h.
(format_warning_va): Add param "corrected_substring" and use
it to add a replacement fix-it hint.
(format_warning_at_substring): Likewise.
(format_warning_at_char): Update for new param of
format_warning_va.
(argument_parser::check_argument_type): Pass "fki" to
check_format_types.
(check_format_types): Add param "fki" and pass it to
format_type_warning.
(deref_n_times): New function.
(get_modifier_for_format_len): New function.
(selftest::test_get_modifier_for_format_len): New function.
(get_format_for_type): New function.
(format_type_warning): Add param "fki" and use it to attempt
to provide hints for argument types when calling
format_warning_at_substring.
(selftest::get_info): New function.
(selftest::assert_format_for_type_streq): New function.
(ASSERT_FORMAT_FOR_TYPE_STREQ): New macro.
(selftest::test_get_format_for_type_printf): New function.
(selftest::test_get_format_for_type_scanf): New function.
(selftest::c_format_c_tests): New function.

gcc/c/ChangeLog:
PR c/64955
* c-lang.c (LANG_HOOKS_RUN_LANG_SELFTESTS): If CHECKING_P, wire
this up to selftest::run_c_tests.
(selftest::run_c_tests): New function.

gcc/ChangeLog:
PR c/64955
* langhooks-def.h (LANG_HOOKS_RUN_LANG_SELFTESTS): New default
do-nothing langhook.
(LANG_HOOKS_INITIALIZER): Add LANG_HOOKS_RUN_LANG_SELFTESTS.
* langhooks.h (struct lang_hooks): Add run_lang_selftests.
* selftest-run-tests.c: Include "tree.h" and "langhooks.h".
(selftest::run_tests): Call lang_hooks.run_lang_selftests.

gcc/testsuite/ChangeLog:
PR c/64955
* gcc.dg/format/diagnostic-ranges.c: Add fix-it hints to expected
output.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-common.h
trunk/gcc/c-family/c-format.c
trunk/gcc/c/ChangeLog
trunk/gcc/c/c-lang.c
trunk/gcc/langhooks-def.h
trunk/gcc/langhooks.h
trunk/gcc/selftest-run-tests.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/format/diagnostic-ranges.c

[Bug fortran/60526] [5 Regression] Accepts-invalid: Variable name same as type name

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

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

--- Comment #18 from Thomas Koenig  ---
Fixed on all affected and still-open branches, closing.

[Bug fortran/60526] [5 Regression] Accepts-invalid: Variable name same as type name

[tkoenig at gcc dot gnu.org]

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

--- Comment #17 from Thomas Koenig  ---
Author: tkoenig
Date: Mon Aug  8 22:00:37 2016
New Revision: 239259

URL: https://gcc.gnu.org/viewcvs?rev=239259=gcc=rev
Log:
2016-08-08  Thomas Koenig  

Backport from trunk
PR fortran/60526
* decl.c (build_sym):  If the name has already been defined as a
type, it has a symtree with an upper case letter at the beginning.
If such a symtree exists, issue an error and exit.  Don't do
this if there is no corresponding upper case letter.

2016-08-08  Thomas Koenig  

PR fortran/60526
* gfortran.dg/type_decl_4.f90:  New test.


Added:
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/type_decl_4.f90
Modified:
branches/gcc-5-branch/gcc/fortran/ChangeLog
branches/gcc-5-branch/gcc/fortran/decl.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug debug/72828] [5/6/7 Regression] ICE in clone_tree_partial when compiling with -fdebug-types-section

[ott at fb dot com]

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

--- Comment #4 from Giuseppe Ottaviano  ---
Thanks, I just wanted to clarify that this is not a regression, as far as I can
tell.

[Bug debug/72828] [5/6/7 Regression] ICE in clone_tree_partial when compiling with -fdebug-types-section

[marxin at gcc dot gnu.org]

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

--- Comment #3 from Martin Liška  ---
(In reply to Giuseppe Ottaviano from comment #2)
> Martin, I noticed you marked this as "[5/6/7 Regression]", but to be clear
> the bug is present since at least 4.9 (the oldest version I tested).
> It's only the attached reduction that is sensitive to compiler version. I
> can provide repros for 4.9 and 5.1 as well.

Ah, OK. However as 4.9 branch is already closed, we create Regression prefix
just for active branches.

[Bug gcov-profile/58306] Broken profiling for unrar sources: error: corrupted value profile: value profile counter (X out of Y) inconsistent with basic-block count

[marxin at gcc dot gnu.org]

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

--- Comment #24 from Martin Liška  ---
> Wonderful! What are the chances of this patch being merged with GCC 4.9.x?

Any, because 4.9 was closed last week and there's not going to be any release.
If you are interested, I can back-port patches to both 5 and 6 branches?

[Bug c++/72842] non-type template-parameter of type void

[daniel.kruegler at googlemail dot com]

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

--- Comment #7 from Daniel Krügler  ---
(In reply to Daniel Krügler from comment #5)
> (In reply to Barry Revzin from comment #4)
> > I'll just email. Instantiating foo creates a function template with a
> > non-type template parameter of type void. That's not an allowed type of a
> > non-type template parameter, so I think it should be ill-formed.
> 
> It truely is ill-formed, but the question is whether an implementation is
> required to diagnose it. For the non-depending case the diagnostics is a
> hard requirement. But for the dependent case we have [temp.res] p8:
> 
> "The program is ill-formed, no diagnostic required, if:
> [..]
> — every valid specialization of a variadic template requires an empty
> template parameter pack, or [..]"
> 
> My argument is that this is the case we are entering here: Ill-formed, but
> no diagnostics required.

After a second look at your original foo template I need to correct myself a
bit, so let me be more precise:

1) Your second bar() example is ill-formed, no diagnostics required, as
explained above. But it is nonetheless diagnosed here (because the case is
simple).

2) Your original foo example is simply valid, because the pack is empty and so
there is no non-type template parameter of type void, as I described in my very
first response. For this example my [temp.res] quote doesn't hold, because one
can produce several other valid specializations of that template without an
empty parameter pack (e.g. when selecting T=int). Of-course it would still not
be valid to attempt to generate a non-empty pack expansion of the second
parameter using void or other types that are not valid as non-type parameters.

[Bug bootstrap/72844] Revision 293175 breaks gcc on FreeBSD

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #8 from David Malcolm  ---
Should be fixed now.  Thanks for testing it, and sorry again about the
breakage.

[Bug bootstrap/72844] Revision 293175 breaks gcc on FreeBSD

[dmalcolm at gcc dot gnu.org]

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

--- Comment #7 from David Malcolm  ---
Author: dmalcolm
Date: Mon Aug  8 20:46:19 2016
New Revision: 239257

URL: https://gcc.gnu.org/viewcvs?rev=239257=gcc=rev
Log:
Fix selftest::test_lexer_string_locations_ebcdic for systems without iconv (PR
bootstrap/72844)

selftest::test_lexer_string_locations_ebcdic has this clause:

  /* EBCDIC support requires iconv.  */
  if (!HAVE_ICONV)
return;

leading to a build failure on systems without iconv.  This conditional
works in libcpp due to this in libcpp/internal.h:

  #if HAVE_ICONV
  #include 
  #else
  #define HAVE_ICONV 0
  typedef int iconv_t;  /* dummy */
  #endif

Fix the problem by ensuring that HAVE_ICONV is always defined within
gcc/input.c.

gcc/ChangeLog:
PR bootstrap/72844
* input.c: Ensure that HAVE_ICONV is defined.


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

[Bug rtl-optimization/72843] [7 Regression] internal compiler error: in lra_set_insn_recog_data, at lra.c:964

[ubizjak at gmail dot com]

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

--- Comment #3 from Uroš Bizjak  ---
Created attachment 39084
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39084=edit
Proposed patch

HJ, can you please test this patch?

[Bug bootstrap/72848] New: profiledbootstrap: internal compiler error: in streamer_write_gcov_count_stream, at data-streamer-out.c:366

[mikulas at artax dot karlin.mff.cuni.cz]

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

Bug ID: 72848
   Summary: profiledbootstrap: internal compiler error: in
streamer_write_gcov_count_stream, at
data-streamer-out.c:366
   Product: gcc
   Version: 5.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mikulas at artax dot karlin.mff.cuni.cz
  Target Milestone: ---
  Host: sparc64-unknown-linux-gnu
Target: sparc64-unknown-linux-gnu
 Build: sparc64-unknown-linux-gnu

Gcc profiledbootstrap fails on sparc.

The system is Debian Squeeze Sparc. Gcc is compiled as a 32-bit sparc
application. Gcc is compiled with this script:

#!/bin/sh
set -e
CFLAGS="-O3 -mcpu=ultrasparc"
export CFLAGS
CXXFLAGS="$CFLAGS"
export CXXFLAGS
../gcc-5.4.0/configure  \
--prefix=/usr/local/gcc/\
--enable-lto\
--with-system-zlib  \
--enable-languages=c\
--enable-multilib   \
--with-multilib-list=m32,m64\
--with-build-config=bootstrap-lto   \
&&
nice -n 20 make BOOT_CFLAGS="$CFLAGS" profiledbootstrap

The failing command is:
make[3]: Entering directory `/usr/src/gcc-5.4.0-build/libcpp'
/usr/src/gcc-5.4.0-build/./prev-gcc/xg++ -B/usr/src/gcc-5.4.0-build/./prev-gcc/
-B/usr/local/gcc/sparc64-unknown-linux-gnu/bin/ -nostd
inc++
-B/usr/src/gcc-5.4.0-build/prev-sparc64-unknown-linux-gnu/libstdc++-v3/src/.libs
-B/usr/src/gcc-5.4.0-build/prev-sparc64-unknown
-linux-gnu/libstdc++-v3/libsupc++/.libs 
-I/usr/src/gcc-5.4.0-build/prev-sparc64-unknown-linux-gnu/libstdc++-v3/include/sparc64-unknown-linux-gnu
 -I/usr/src/gcc-5.4.0-build/prev-sparc64-unknown-linux-gnu/libstdc++-v3/include
 -I/usr/src/gcc-5.4.0/libstdc++-v3/libsupc++
-L/usr/src/gcc-5.4.0-build/prev-sparc64-unknown-linux-gnu/libstdc++-v3/src/.libs
-L/usr/src/gcc-5.4.0-build/prev-sparc64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs
 -I../../gcc-5.4.0/libcpp -I. -I../../gcc-5.4.0/libcpp/../include
-I../../gcc-5.4.0/libcpp/include  -O3 -mcpu=ultrasparc -flto=jobserver
-frandom-seed=1 -fprofile-use -W -Wall -Wno-narrowing -Wwrite-strings
-Wmissing-format-attribute -pedantic -Wno-long-long  -fno-exceptions -fno-rtti
-I../../gcc-5.4.0/libcpp -I. -I../../gcc-5.4.0/libcpp/../include
-I../../gcc-5.4.0/libcpp/include   -c -o charset.o -MT charset.o -MMD -MP -MF
.deps/charset.Tpo ../../gcc-5.4.0/libcpp/charset.c
/usr/src/gcc-5.4.0-build/./prev-gcc/xg++ -B/usr/src/gcc-5.4.0-build/./prev-gcc/
-B/usr/local/gcc/sparc64-unknown-linux-gnu/bin/ -nostdinc++
-B/usr/src/gcc-5.4.0-build/prev-sparc64-unknown-linux-gnu/libstdc++-v3/src/.libs
-B/usr/src/gcc-5.4.0-build/prev-sparc64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs

-I/usr/src/gcc-5.4.0-build/prev-sparc64-unknown-linux-gnu/libstdc++-v3/include/sparc64-unknown-linux-gnu
 -I/usr/src/gcc-5.4.0-build/prev-sparc64-unknown-linux-gnu/libstdc++-v3/include
 -I/usr/src/gcc-5.4.0/libstdc++-v3/libsupc++
-L/usr/src/gcc-5.4.0-build/prev-sparc64-unknown-linux-gnu/libstdc++-v3/src/.libs
-L/usr/src/gcc-5.4.0-build/prev-sparc64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs
 -I../../gcc-5.4.0/libcpp -I. -I../../gcc-5.4.0/libcpp/../include
-I../../gcc-5.4.0/libcpp/include  -O3 -mcpu=ultrasparc -flto=jobserver
-frandom-seed=1 -fprofile-use -W -Wall -Wno-narrowing -Wwrite-strings
-Wmissing-format-attribute -pedantic -Wno-long-long  -fno-exceptions -fno-rtti
-I../../gcc-5.4.0/libcpp -I. -I../../gcc-5.4.0/libcpp/../include
-I../../gcc-5.4.0/libcpp/include   -c -o directives.o -MT directives.o -MMD -MP
-MF .deps/directives.Tpo ../../gcc-5.4.0/libcpp/directives.c
../../gcc-5.4.0/libcpp/directives.c: In function 'do_assert(cpp_reader*)':
../../gcc-5.4.0/libcpp/directives.c:2631:1: internal compiler error: in
streamer_write_gcov_count_stream, at data-streamer-out.c:366
 }
 ^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[3]: *** [directives.o] Error 1

The bug is caused by -fprofile-use. When I remove -fprofile-use from the
commandline and re-execute the command manually, it works.

[Bug bootstrap/72844] Revision 293175 breaks gcc on FreeBSD

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #6 from Steve Kargl  ---
On Mon, Aug 08, 2016 at 07:13:56PM +, dmalcolm at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72844
> 
> --- Comment #4 from David Malcolm  ---
> (In reply to David Malcolm from comment #3)
> > Created attachment 39081 [details]
> > Ensure that HAVE_ICONV is usable as a conditional
> 
> Steve: this fixes the problem for me on a Linux box with iconv hacked out. 
> Does it fix it for you?
> 

Bootstrap just completed.  Thanks for the quick fix.

[Bug bootstrap/72844] Revision 293175 breaks gcc on FreeBSD

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

 CC||gerald at pfeifer dot com

--- Comment #5 from David Malcolm  ---
*** Bug 72846 has been marked as a duplicate of this bug. ***

[Bug bootstrap/72846] [7 regression]

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||dmalcolm at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #1 from David Malcolm  ---
Sorry about this.

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

[Bug libstdc++/72847] New: vector copy-assignment basic exception safety

[dyp-cpp at gmx dot net]

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

Bug ID: 72847
   Summary: vector copy-assignment basic exception safety
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dyp-cpp at gmx dot net
  Target Milestone: ---

vector's copy-assignment operator uses a very simple algorithm if
resizing is required: first, free the current allocation, then create a new
allocation. The pointer data member that holds the allocation is not touched by
the first step, then assigned-to by the second step. Therefore, if the second
step (the allocation) fails via exception, that pointer (_M_end_of_storage -
size()) is dangling. Destruction of a vector in such a state leads to a
double deletion.

[Bug bootstrap/72846] New: [7 regression]

[gerald at pfeifer dot com]

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

Bug ID: 72846
   Summary: [7 regression]
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: dmalcolm at redhat dot com
  Reporter: gerald at pfeifer dot com
  Target Milestone: ---

r239175 | dmalcolm | 2016-08-05 18:08:33 + (Fri, 05 Aug 2016) | 124 line
introduced a bootstrap failure on an automated tester I have running on
FreeBSD 9/amd64:

/scratch/tmp/gerald/gcc-HEAD/gcc/input.c:2137: error: 'HAVE_ICONV' was not
decla
red in this scope

The code in question is the following:

test_lexer_string_locations_ebcdic (const line_table_case _) 
{
  /* EBCDIC support requires iconv.  */
  if (!HAVE_ICONV)
return;

HAVE_ICONV is not defined when iconv is not present.

[Bug c/52952] Wformat location info is bad (wrong column number)

[dmalcolm at gcc dot gnu.org]

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

--- Comment #45 from David Malcolm  ---
Author: dmalcolm
Date: Mon Aug  8 20:10:19 2016
New Revision: 239253

URL: https://gcc.gnu.org/viewcvs?rev=239253=gcc=rev
Log:
Use class substring_loc in c-format.c (PR c/52952)

gcc/c-family/ChangeLog:
PR c/52952
* c-format.c: Include "diagnostic.h".
(location_column_from_byte_offset): Delete.
(location_from_offset): Delete.
(format_warning_va): New function.
(format_warning_at_substring): New function.
(format_warning_at_char): New function.
(check_format_arg): Capture location of format_tree and pass to
check_format_info_main.
(argument_parser): Add fields "start_of_this_format" and
"format_string_cst".
(flag_chars_t::validate): Add param "format_string_cst".  Convert
warning_at call using location_from_offset to call to
format_warning_at_char.
(argument_parser::argument_parser): Add param "format_string_cst_"
and use use it to initialize field "format_string_cst".
Initialize new field "start_of_this_format".
(argument_parser::read_format_flags): Convert warning_at call
using location_from_offset to a call to format_warning_at_char.
(argument_parser::read_any_format_left_precision): Likewise.
(argument_parser::read_any_format_precision): Likewise.
(argument_parser::read_any_other_modifier): Likewise.
(argument_parser::find_format_char_info): Likewise, in three places.
(argument_parser::parse_any_scan_set): Likewise, in one place.
(argument_parser::handle_conversions): Likewise, in two places.
(argument_parser::check_argument_type): Add param "fmt_param_loc"
and use it to make a substring_loc.  Pass the latter to
check_format_types.
(check_format_info_main): Add params "fmt_param_loc" and
"format_string_cst".  Convert warning_at calls using
location_from_offset to calls to format_warning_at_char.  Pass the
new params to the arg_parser ctor.  Pass "format_string_cst" to
flag_chars.validate.  Pass "fmt_param_loc" to
arg_parser.check_argument_type.
(check_format_types): Convert first param from a location_t
to a const substring_loc & and rename to "fmt_loc".  Attempt
to extract the range of the relevant parameter and pass it
to format_type_warning.
(format_type_warning): Convert first param from a location_t
to a const substring_loc & and rename to "fmt_loc".  Add
params "param_range" and "type".  Replace calls to warning_at
with calls to format_warning_at_substring.

gcc/testsuite/ChangeLog:
PR c/52952
* gcc.dg/cpp/pr66415-1.c: Likewise.
* gcc.dg/format/asm_fprintf-1.c: Update column numbers.
* gcc.dg/format/c90-printf-1.c: Likewise.
* gcc.dg/format/diagnostic-ranges.c: New test case.


Added:
trunk/gcc/testsuite/gcc.dg/format/diagnostic-ranges.c
Modified:
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-format.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/cpp/pr66415-1.c
trunk/gcc/testsuite/gcc.dg/format/asm_fprintf-1.c
trunk/gcc/testsuite/gcc.dg/format/c90-printf-1.c

[Bug go/72814] reflect FAILs on 32-bit Solaris/SPARC: SIGILL

[ian at airs dot com]

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

Ian Lance Taylor  changed:

   What|Removed |Added

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

--- Comment #3 from Ian Lance Taylor  ---
Fixed.

[Bug go/72814] reflect FAILs on 32-bit Solaris/SPARC: SIGILL

[ian at gcc dot gnu.org]

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

--- Comment #2 from ian at gcc dot gnu.org  ---
Author: ian
Date: Mon Aug  8 19:53:44 2016
New Revision: 239252

URL: https://gcc.gnu.org/viewcvs?rev=239252=gcc=rev
Log:
PR go/72814

runtime: treat zero-sized result value as void

Change the FFI interface to treat a call to a function that returns a
zero-sized result as a call to a function that returns void.

This is part of the fix for https://gcc.gnu.org/PR72814.  On 32-bit
SPARC systems, a call to a function that returns a non-zero-sized struct
is followed by an unimp instruction that describes the size of the
struct.  The function returns to the address after the unimp
instruction.  The libffi library can not represent a zero-sized struct,
so we wind up treating it as a 1-byte struct.  Thus in that case libffi
calls the function with an unimp instruction, but the function does not
adjust the return address.  The result is that the program attempts to
execute the unimp instruction, causing a crash.

This is part of a change that fixes the crash by treating all functions
that return zero bytes as functions that return void.

Reviewed-on: https://go-review.googlesource.com/25585

* go-gcc.cc (Gcc_backend::function_type): If the return type is
zero bytes, treat the function as returning void.
(return_statement): If the return type is zero bytes, don't
actually return any values.

Modified:
trunk/gcc/go/ChangeLog
trunk/gcc/go/go-gcc.cc
trunk/gcc/go/gofrontend/MERGE
trunk/libgo/runtime/go-ffi.c

[Bug c++/72842] non-type template-parameter of type void

[daniel.kruegler at googlemail dot com]

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

--- Comment #6 from Daniel Krügler  ---
(In reply to Daniel Krügler from comment #5)
> (In reply to Barry Revzin from comment #4)
> > I'll just email. Instantiating foo creates a function template with a
> > non-type template parameter of type void. That's not an allowed type of a
> > non-type template parameter, so I think it should be ill-formed.
> 
> It truely is ill-formed, but the question is whether an implementation is
> required to diagnose it. For the non-depending case the diagnostics is a
> hard requirement. But for the dependent case we have [temp.res] p8:
> 
> "The program is ill-formed, no diagnostic required, if:
> [..]
> — every valid specialization of a variadic template requires an empty
> template parameter pack, or [..]"
> 
> My argument is that this is the case we are entering here: Ill-formed, but
> no diagnostics required.

Having said that, it might be worth to point out that there are at least two
core issues involving this area:

http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#1785
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#2067

[Bug c++/58706] ICE with lambda in OpenMP for-loop

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Mon Aug  8 19:50:29 2016
New Revision: 239251

URL: https://gcc.gnu.org/viewcvs?rev=239251=gcc=rev
Log:
PR c++/58706
* parser.c: Include tree-iterator.h.
(cp_parser_omp_for_loop_init): Move lambda DECL_EXPRs from init
to FOR_BLOCK.
(cp_parser_omp_for_loop): Handle non-STATEMENT_LIST FOR_BLOCK
entries.

* testsuite/libgomp.c++/pr58706.C: New test.

Added:
trunk/libgomp/testsuite/libgomp.c++/pr58706.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/parser.c
trunk/libgomp/ChangeLog

[Bug fortran/72716] [5/6/7 Regression] ICE in gfc_resolve_omp_declare_simd, at fortran/openmp.c:5156

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Mon Aug  8 19:48:48 2016
New Revision: 239250

URL: https://gcc.gnu.org/viewcvs?rev=239250=gcc=rev
Log:
PR fortran/72716
* openmp.c (gfc_match_omp_declare_simd): Don't stick anything into
BLOCK DATA ns, it will be rejected later.

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

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

[Bug middle-end/72781] -Wuninitialized false positives in OpenMP code

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Author: jakub
Date: Mon Aug  8 19:46:36 2016
New Revision: 239249

URL: https://gcc.gnu.org/viewcvs?rev=239249=gcc=rev
Log:
PR middle-end/72781
* omp-low.c (lower_lastprivate_clauses): Set TREE_NO_WARNING on the
private vars for lastprivate and for linear iterator.

* gcc.dg/gomp/pr72781.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/gomp/pr72781.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/omp-low.c
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/68762] link error for inline function decorated with OpenMP declare simd

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Mon Aug  8 19:45:53 2016
New Revision: 239248

URL: https://gcc.gnu.org/viewcvs?rev=239248=gcc=rev
Log:
PR middle-end/68762
* omp-simd-clone.c: Include varasm.h.
(simd_clone_create): Copy over DECL_COMDAT, DECL_WEAK, DECL_EXTERNAL,
DECL_VISIBILITY, DECL_VISIBILITY_SPECIFIED, DECL_DLLIMPORT_P and for
DECL_ONE_ONLY call make_decl_one_only.  Fix up spelling in comment and
update function name.

* g++.dg/vect/pr68762-1.cc: New test.
* g++.dg/vect/pr68762-2.cc: New test.
* g++.dg/vect/pr68762.h: New file.

Added:
trunk/gcc/testsuite/g++.dg/vect/pr68762-1.cc
trunk/gcc/testsuite/g++.dg/vect/pr68762-2.cc
trunk/gcc/testsuite/g++.dg/vect/pr68762.h
Modified:
trunk/gcc/ChangeLog
trunk/gcc/omp-simd-clone.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/72842] non-type template-parameter of type void

[daniel.kruegler at googlemail dot com]

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

--- Comment #5 from Daniel Krügler  ---
(In reply to Barry Revzin from comment #4)
> I'll just email. Instantiating foo creates a function template with a
> non-type template parameter of type void. That's not an allowed type of a
> non-type template parameter, so I think it should be ill-formed.

It truely is ill-formed, but the question is whether an implementation is
required to diagnose it. For the non-depending case the diagnostics is a hard
requirement. But for the dependent case we have [temp.res] p8:

"The program is ill-formed, no diagnostic required, if:
[..]
— every valid specialization of a variadic template requires an empty template
parameter pack, or [..]"

My argument is that this is the case we are entering here: Ill-formed, but no
diagnostics required.

[Bug c++/72845] New: gcc crashes (ICE) when compiling program with complex noexcept declaration

[beck.ct at gmail dot com]

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

Bug ID: 72845
   Summary: gcc crashes (ICE) when compiling program with complex
noexcept declaration
   Product: gcc
   Version: 6.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: beck.ct at gmail dot com
  Target Milestone: ---

Created attachment 39083
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39083=edit
variant.cpp compiling at C++11 causes ICE in versions 5+ of gcc that I tested

* Exact version of gcc:

  I reproduced this bug against 

gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.1)

  and

gcc version 6.1.1 20160510 (Ubuntu 6.1.1-2ubuntu12~16.04)

  I don't get an ICE with gcc 4.9.

* System type is Ubuntu linux:

  DISTRIB_DESCRIPTION="Ubuntu 16.04.1 LTS"


* Configuration options used to build gcc:

  My `gcc-6 -v` reports this:

  $ gcc-6 -v
  Using built-in specs.
  COLLECT_GCC=gcc-6
  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.1.1-2ubuntu12~16.04' --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 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --with-system-zlib
--disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-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.1.1 20160510 (Ubuntu 6.1.1-2ubuntu12~16.04) 

* Complete command line that triggers the crash:

  $(CXX) -std=c++11 variant.cpp

* the compiler output (error messages, warnings, etc.):

  $ gcc-5 -std=c++11 variant.cpp
variant.cpp: In instantiation of ‘template
decltype
(declval().get_visitor_dispatch()(declval().which(),
forward(declval()).storage(),
forward(declval( strict_variant::apply_visitor(Visitor&&,
Visitable&&)’:
variant.cpp:578:15:   required from ‘class strict_variant::variant’
variant.cpp:637:89:   required from here
variant.cpp:578:15: internal compiler error: in push_access_scope, at
cp/pt.c:232
   friend auto apply_visitor(Visitor &&, Visitable &&)
noexcept(APPLY_VISITOR_UNEVALUATED_EXPR)
   ^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

  $ gcc-6 -std=c++11 variant.cpp
variant.cpp: In instantiation of ‘template
decltype
(declval().get_visitor_dispatch()(declval().which(),
forward(declval()).storage(),
forward(declval( strict_variant::apply_visitor(Visitor&&,
Visitable&&)’:
variant.cpp:578:15:   required from ‘class strict_variant::variant’
variant.cpp:637:89:   required from here
variant.cpp:578:15: internal compiler error: in push_access_scope, at
cp/pt.c:229
   friend auto apply_visitor(Visitor &&, Visitable &&)
noexcept(APPLY_VISITOR_UNEVALUATED_EXPR)
   ^
0x5fb0bb push_access_scope
../../src/gcc/cp/pt.c:228
0x62122f maybe_instantiate_noexcept(tree_node*)
../../src/gcc/cp/pt.c:21603
0x5dce98 check_redeclaration_exception_specification
../../src/gcc/cp/decl.c:1221
0x5eb12d duplicate_decls(tree_node*, tree_node*, bool)
../../src/gcc/cp/decl.c:2022
0x6e020f push_overloaded_decl_1
../../src/gcc/cp/name-lookup.c:2396
0x6e020f push_overloaded_decl
../../src/gcc/cp/name-lookup.c:2491
0x6e2d12 pushdecl_maybe_friend_1
../../src/gcc/cp/name-lookup.c:915
0x6e2d12 pushdecl_maybe_friend(tree_node*, bool)
../../src/gcc/cp/name-lookup.c:1298
0x6e3e43 pushdecl_with_scope_1
../../src/gcc/cp/name-lookup.c:2295
0x6e3f2c pushdecl_with_scope(tree_node*, cp_binding_level*, bool)
../../src/gcc/cp/name-lookup.c:2309
0x6e3fa8 pushdecl_namespace_level(tree_node*, bool)
../../src/gcc/cp/name-lookup.c:3915
0x6223ae tsubst_friend_function
../../src/gcc/cp/pt.c:9265
0x6223ae instantiate_class_template_1
../../src/gcc/cp/pt.c:10261
0x6223ae instantiate_class_template(tree_node*)
../../src/gcc/cp/pt.c:10360
0x6813ad 

[Bug c++/72842] non-type template-parameter of type void

[barry.revzin at gmail dot com]

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

--- Comment #4 from Barry Revzin  ---
I'll just email. Instantiating foo creates a function template with a
non-type template parameter of type void. That's not an allowed type of a
non-type template parameter, so I think it should be ill-formed.

This would arise when doing something like "enable_if_t..." for
SFINAE purposes, I just wanted a more minimal example.

If that's not the case, what allows a void non-type template parameter to
be used for parameter packs?

On Mon, Aug 8, 2016, 2:25 PM daniel.kruegler at googlemail dot com <
gcc-bugzi...@gcc.gnu.org> wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72842
>
> --- Comment #3 from Daniel Krügler 
> ---
> Since this is not a newsgroup, let me ask differently: Can you please
> elaborate
> what you consider as a concrete compiler defect, violating the existing
> standard? I fail to see the point.
>
> --
> You are receiving this mail because:
> You reported the bug.

[Bug c++/72837] -Wundef is not being ignored with pragma

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||manu at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #1 from Manuel López-Ibáñez  ---
(In reply to Trevor Hickey from comment #0)
> **How can I suppress `-Wundef` warnings in `g++`?**  

You can't using #pragma.

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

[Bug c++/53431] C++ preprocessor ignores #pragma GCC diagnostic

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||TrevorJamesHickey at gmail dot 
com

--- Comment #28 from Manuel López-Ibáñez  ---
*** Bug 72837 has been marked as a duplicate of this bug. ***

[Bug c++/72842] non-type template-parameter of type void

[daniel.kruegler at googlemail dot com]

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

--- Comment #3 from Daniel Krügler  ---
Since this is not a newsgroup, let me ask differently: Can you please elaborate
what you consider as a concrete compiler defect, violating the existing
standard? I fail to see the point.

[Bug bootstrap/72833] [7 regression] error in fortran/parse.c (unexpected_eof) on Mac OS X 10.7

[bernd.edlinger at hotmail dot de]

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

--- Comment #12 from Bernd Edlinger  ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #10)

> True: the Solaris fix missed this, probably because the issue never came
> up.  The Mac OS X 10.8+  has the annotation, so it's probably
> best to fix both while you're at it.
> 

That's clear: before my clean-up of special_function_p
*anything* with the name longjmp and siglongjmp was implicitly
noreturn, even if the header file said something different.

[Bug rtl-optimization/72821] [7 regression] RTL check: expected elt 2 type 'B', have '0' (rtx barrier) in BLOCK_FOR_INSN, at rtl.h:1424

[dimhen at gmail dot com]

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

Dmitry G. Dyachenko  changed:

   What|Removed |Added

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

--- Comment #4 from Dmitry G. Dyachenko  ---
r239241 PASS

Thank you!

[Bug bootstrap/72833] [7 regression] error in fortran/parse.c (unexpected_eof) on Mac OS X 10.7

[bernd.edlinger at hotmail dot de]

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

Bernd Edlinger  changed:

   What|Removed |Added

  Attachment #39079|0   |1
is obsolete||

--- Comment #11 from Bernd Edlinger  ---
Created attachment 39082
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39082=edit
updated patch

patch both variants of longjmp.
this time make check-fixincludes should pass.

[Bug bootstrap/72844] Revision 293175 breaks gcc on FreeBSD

[dmalcolm at gcc dot gnu.org]

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

--- Comment #4 from David Malcolm  ---
(In reply to David Malcolm from comment #3)
> Created attachment 39081 [details]
> Ensure that HAVE_ICONV is usable as a conditional

Steve: this fixes the problem for me on a Linux box with iconv hacked out. 
Does it fix it for you?

[Bug bootstrap/72844] Revision 293175 breaks gcc on FreeBSD

[dmalcolm at gcc dot gnu.org]

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

--- Comment #3 from David Malcolm  ---
Created attachment 39081
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39081=edit
Ensure that HAVE_ICONV is usable as a conditional

[Bug bootstrap/72844] Revision 293175 breaks gcc on FreeBSD

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #2 from David Malcolm  ---
Sorry about this.  I'm working on a fix.

[Bug c++/72842] non-type template-parameter of type void

[barry.revzin at gmail dot com]

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

--- Comment #2 from Barry Revzin  ---
This non-dependent version:

template  void bar() { }

fails to compile, even if we never call bar(), even if we wanted to call it
with an empty pack.

foo in the original example is this same thing with an extra template
type parameter. Why the difference?

[Bug sanitizer/71042] libtsan requires __pointer_chk_guard@GLIBC_PRIVATE (6)

[adhemerval.zanella at linaro dot org]

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

--- Comment #9 from Adhemerval Zanella  
---
Right, I wasn't aware of this RPM symbol handling.  I see that guard pointer
can be obtained on aarch64 by:

uintptr_t get_guard_ptr (void)
{ 
  jmp_buf jb;
  uintptr_t expected, mangled;

  setjmp (jb);
  asm volatile ("adr %0, ." : "=r" (expected));
  mangled = ((uintptr_t*)jb)[11];
  return expected ^ mangled;
}

So I think we can add a local variable to hold its value and set
tsan_rtl_aarch64.S to use it instead.

[Bug bootstrap/72833] [7 regression] error in fortran/parse.c (unexpected_eof) on Mac OS X 10.7

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #10 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #9 from Bernd Edlinger  ---
>> In progress.  Two comments:
>> 
>> * Why the fixincl.tpl change?  Is this necessary with upstream autogen
>>   or only due to some Ubuntu-local change?  Bruce will probably know
>>   when he reviews the patch, though.
>> 
>
> Don't know, all I know from autogen is that it is not easy to build locally.
>
> So far I never encountered any difficulties with it under linux.
>
> I tried different settings, and it looks like the code that is
> enabled for autogen >= 5.18, but apparently the 5.18 behaves
> like the old version, so this is probably not a back-port of a
> new feature.  My guess is that simply the version should be
> checked for autogen >= 5.18.1 ?

Just leave it as it for Bruce to decide.

>> * Your comment
>> 
>>  /*
>>   *  Before Mac OS X 10.7  doesn't mark longjump noreturn.
>>   */
>> 
>>   is wrong, however: even the 10.7  does lack the
>>   annotation, and in 10.8 (as I'd seen in 10.11 and 10.12) the
>>   declaration has moved to  and is properly annotated.  I
>>   suspect the bypass can just go, even if it does no harm.
>> 
>
> Then I change it to "Before Mac OS X 10.8"

Not fully right either: there is no  in 10.8+ ;-)

>>   You can find the 10.8  at
>> 
>>  http://opensource.apple.com/source/Libc/Libc-825.24/include/setjmp.h
>> 
>>   while the 10.7.5 one (the latest 10.7 update) is at
>> 
>>  http://opensource.apple.com/source/Libc/Libc-763.13/include/setjmp.h
>> 
>>   and the corresponding  at
>> 
>>  http://opensource.apple.com/source/xnu/xnu-1699.32.7/bsd/i386/setjmp.h
>> 
>>  Rainer
>
>
> BTW: I noticed that the fix-rule misses the siglongjmp,
> because the parameter is sigjmp_buf.

True: the Solaris fix missed this, probably because the issue never came
up.  The Mac OS X 10.8+  has the annotation, so it's probably
best to fix both while you're at it.

> Do you want an updated patch with these changes?

Can't hurt: I'll also run a i686-apple-darwin11 bootstrap which I can
use to verify it.

Rainer

[Bug bootstrap/72844] Revision 293175 breaks gcc on FreeBSD

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #1 from Steve Kargl  ---
On Mon, Aug 08, 2016 at 06:30:17PM +, kargl at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72844
> 
> Bug ID: 72844
>Summary: Revision 293175 breaks gcc on FreeBSD
>Product: gcc
>Version: 7.0
> Status: UNCONFIRMED
>   Severity: blocker
>   Priority: P3
>  Component: bootstrap
>   Assignee: unassigned at gcc dot gnu.org
>   Reporter: kargl at gcc dot gnu.org
>   Target Milestone: ---
> 
> % cd gcc7
> % svn update
> % cd ../obj7
> % ../gcc7/configure  --prefix=$HOME/work/7 --with-isl=/usr/local \
> --enable-languages=c,fortran,c++ --disable-libmudflap --disable-nls
> % gmake bootstrap
> 
> ../../gcc7/gcc/input.c: In function 'void
> selftest::test_lexer_string_locations_ebcdic(const
> selftest::line_table_case&)':
> ../../gcc7/gcc/input.c:2137:8: error: 'HAVE_ICONV' was not declared in this
> scope
>if (!HAVE_ICONV)
> ^~
> ../../gcc7/gcc/input.c:2137:8: note: suggested alternative: 'HAVE_ICONV_H'
>if (!HAVE_ICONV)
> ^~
> HAVE_ICONV_H
> 

The obvious patch (as inferred from the suggested alternative)
does not work.

/mnt/sgk/gcc/obj7/./prev-gcc/xg++ -B/mnt/sgk/gcc/obj7/./prev-gcc/
-B/mnt/sgk/work/7/x86_64-unknown-freebsd12.0/bin/ -nostdinc++
-B/mnt/sgk/gcc/obj7/prev-x86_64-unknown-freebsd12.0/libstdc++-v3/src/.libs
-B/mnt/sgk/gcc/obj7/prev-x86_64-unknown-freebsd12.0/libstdc++-v3/libsupc++/.libs

-I/mnt/sgk/gcc/obj7/prev-x86_64-unknown-freebsd12.0/libstdc++-v3/include/x86_64-unknown-freebsd12.0
 -I/mnt/sgk/gcc/obj7/prev-x86_64-unknown-freebsd12.0/libstdc++-v3/include 
-I/mnt/sgk/gcc/gcc7/libstdc++-v3/libsupc++
-L/mnt/sgk/gcc/obj7/prev-x86_64-unknown-freebsd12.0/libstdc++-v3/src/.libs
-L/mnt/sgk/gcc/obj7/prev-x86_64-unknown-freebsd12.0/libstdc++-v3/libsupc++/.libs
-no-pie   -g -O2 -gtoggle -DIN_GCC -fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic
-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common
 -DHAVE_CONFIG_H -static-libstdc++ -static-libgcc  -o lto1 \
lto/lto-lang.o lto/lto.o lto/lto-object.o attribs.o lto/lto-partition.o
lto/lto-symtab.o libbackend.a main.o libcommon-target.a libcommon.a
../libcpp/libcpp.a ../libdecnumber/libdecnumber.a -L/usr/local/lib -lisl
-L/usr/local/lib -lmpc -lmpfr -lgmp -rdynamic  -L./../zlib -lz libcommon.a
../libcpp/libcpp.a   ../libbacktrace/.libs/libbacktrace.a
../libiberty/libiberty.a ../libdecnumber/libdecnumber.a 
/mnt/sgk/gcc/obj7/./gcc/xgcc -B/mnt/sgk/gcc/obj7/./gcc/ -xc -S -c /dev/null
-fself-test
cc1: internal compiler error: in on_error, at input.c:1894
Please submit a full bug report,
with preprocessed source if appropriate.

[Bug bootstrap/72833] [7 regression] error in fortran/parse.c (unexpected_eof) on Mac OS X 10.7

[bernd.edlinger at hotmail dot de]

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

--- Comment #9 from Bernd Edlinger  ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #8)
> > --- Comment #6 from Bernd Edlinger  ---
> [...]
> > Completely untested patch.
> >
> > Based on the gcc-4.9 solaris patch:
> > just s/solaris/darwin/
> > and s/__NORETURN/__dead2/
> >
> >
> > Could you try a boot-strap with it?
> 
> In progress.  Two comments:
> 
> * Why the fixincl.tpl change?  Is this necessary with upstream autogen
>   or only due to some Ubuntu-local change?  Bruce will probably know
>   when he reviews the patch, though.
> 

Don't know, all I know from autogen is that it is not easy to build locally.

So far I never encountered any difficulties with it under linux.

I tried different settings, and it looks like the code that is
enabled for autogen >= 5.18, but apparently the 5.18 behaves
like the old version, so this is probably not a back-port of a
new feature.  My guess is that simply the version should be
checked for autogen >= 5.18.1 ?

> * Your comment
> 
>  /*
>   *  Before Mac OS X 10.7  doesn't mark longjump noreturn.
>   */
> 
>   is wrong, however: even the 10.7  does lack the
>   annotation, and in 10.8 (as I'd seen in 10.11 and 10.12) the
>   declaration has moved to  and is properly annotated.  I
>   suspect the bypass can just go, even if it does no harm.
> 

Then I change it to "Before Mac OS X 10.8"

>   You can find the 10.8  at
> 
>   http://opensource.apple.com/source/Libc/Libc-825.24/include/setjmp.h
> 
>   while the 10.7.5 one (the latest 10.7 update) is at
> 
>   http://opensource.apple.com/source/Libc/Libc-763.13/include/setjmp.h
> 
>   and the corresponding  at
> 
>   http://opensource.apple.com/source/xnu/xnu-1699.32.7/bsd/i386/setjmp.h
> 
>   Rainer


BTW: I noticed that the fix-rule misses the siglongjmp,
because the parameter is sigjmp_buf.

Do you want an updated patch with these changes?


Bernd.

[Bug rtl-optimization/72843] [7 Regression] internal compiler error: in lra_set_insn_recog_data, at lra.c:964

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 CC||ubizjak at gmail dot com

--- Comment #2 from H.J. Lu  ---
LRA ICEs on

(insn 1932 1931 1791 22 (set (reg/v:TF 1001 [orig:161 t ] [161])
(const_double:TF 0.0 [0x0.0p+0])) /tmp/x.c:85 -1
 (nil))

due to

(define_insn "*movtf_internal"
  [(set (match_operand:TF 0 "nonimmediate_operand" "=v,v ,m,?*r ,!o") 
(match_operand:TF 1 "general_operand"  "C ,vm,v,*roF,*rC"))]
  "(TARGET_64BIT || TARGET_SSE)
   && !(MEM_P (operands[0]) && MEM_P (operands[1]))
   && (!can_create_pseudo_p ()
   || !CONST_DOUBLE_P (operands[1])
   || ((optimize_function_for_size_p (cfun)
|| (ix86_cmodel == CM_LARGE || ix86_cmodel == CM_LARGE_PIC))
   && standard_sse_constant_p (operands[1], TFmode) == 1
   && !memory_operand (operands[0], TFmode))
   || (!TARGET_MEMORY_MISMATCH_STALL
   && memory_operand (operands[0], TFmode)))"

[Bug bootstrap/72844] New: Revision 293175 breaks gcc on FreeBSD

[kargl at gcc dot gnu.org]

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

Bug ID: 72844
   Summary: Revision 293175 breaks gcc on FreeBSD
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: blocker
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kargl at gcc dot gnu.org
  Target Milestone: ---

% cd gcc7
% svn update
% cd ../obj7
% ../gcc7/configure  --prefix=$HOME/work/7 --with-isl=/usr/local \
--enable-languages=c,fortran,c++ --disable-libmudflap --disable-nls
% gmake bootstrap

../../gcc7/gcc/input.c: In function 'void
selftest::test_lexer_string_locations_ebcdic(const
selftest::line_table_case&)':
../../gcc7/gcc/input.c:2137:8: error: 'HAVE_ICONV' was not declared in this
scope
   if (!HAVE_ICONV)
^~
../../gcc7/gcc/input.c:2137:8: note: suggested alternative: 'HAVE_ICONV_H'
   if (!HAVE_ICONV)
^~
HAVE_ICONV_H

[Bug rtl-optimization/72843] [7 Regression] internal compiler error: in lra_set_insn_recog_data, at lra.c:964

[hjl.tools at gmail dot com]

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

--- Comment #1 from H.J. Lu  ---
Created attachment 39080
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39080=edit
A testcase

[Bug rtl-optimization/72843] [7 Regression] internal compiler error: in lra_set_insn_recog_data, at lra.c:964

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-08-08
   Target Milestone|--- |7.0
 Ever confirmed|0   |1

[Bug bootstrap/72833] [7 regression] error in fortran/parse.c (unexpected_eof) on Mac OS X 10.7

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #8 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #6 from Bernd Edlinger  ---
[...]
> Completely untested patch.
>
> Based on the gcc-4.9 solaris patch:
> just s/solaris/darwin/
> and s/__NORETURN/__dead2/
>
>
> Could you try a boot-strap with it?

In progress.  Two comments:

* Why the fixincl.tpl change?  Is this necessary with upstream autogen
  or only due to some Ubuntu-local change?  Bruce will probably know
  when he reviews the patch, though.

* Your comment

 /*
  *  Before Mac OS X 10.7  doesn't mark longjump noreturn.
  */

  is wrong, however: even the 10.7  does lack the
  annotation, and in 10.8 (as I'd seen in 10.11 and 10.12) the
  declaration has moved to  and is properly annotated.  I
  suspect the bypass can just go, even if it does no harm.

  You can find the 10.8  at

http://opensource.apple.com/source/Libc/Libc-825.24/include/setjmp.h

  while the 10.7.5 one (the latest 10.7 update) is at

http://opensource.apple.com/source/Libc/Libc-763.13/include/setjmp.h

  and the corresponding  at

http://opensource.apple.com/source/xnu/xnu-1699.32.7/bsd/i386/setjmp.h

Rainer

[Bug c++/72842] non-type template-parameter of type void

[daniel.kruegler at googlemail dot com]

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

--- Comment #1 from Daniel Krügler  ---
I don't see anything wrong with that code, since the parameter pack is empty,
so there is never any attempt to declare void as non-type template parameter
type. The standard has this restriction only for a non-type parameter type, but
there is none in your example.

[Bug rtl-optimization/72843] New: [7 Regression] internal compiler error: in lra_set_insn_recog_data, at lra.c:964

[hjl.tools at gmail dot com]

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

Bug ID: 72843
   Summary: [7 Regression] internal compiler error: in
lra_set_insn_recog_data, at lra.c:964
   Product: gcc
   Version: 6.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: vmakarov at redhat dot com
  Target Milestone: ---

On Linux/x86, when compiled with

-mtune=slm -O2 -march=i686 -msse2 -mfpmath=sse -m32

r239180 caused:

/export/gnu/import/git/gcc-regression/gcc/libquadmath/math/asinq.c: In function
‘asinq’:
/export/gnu/import/git/gcc-regression/gcc/libquadmath/math/asinq.c:254:1:
internal compiler error: in lra_set_insn_recog_data, at lra.c:964
 }
 ^
0x87ea563 lra_set_insn_recog_data(rtx_insn*)
/export/gnu/import/git/gcc-regression/gcc/gcc/lra.c:962
0x87e8913 lra_get_insn_recog_data
/export/gnu/import/git/gcc-regression/gcc/gcc/lra-int.h:487
0x87ebc17 lra_update_insn_regno_info(rtx_insn*)
/export/gnu/import/git/gcc-regression/gcc/gcc/lra.c:1584
0x87ec0c0 lra_push_insn_1
/export/gnu/import/git/gcc-regression/gcc/gcc/lra.c:1735
0x87ec0ef lra_push_insn(rtx_insn*)
/export/gnu/import/git/gcc-regression/gcc/gcc/lra.c:1743
0x87ec1e4 push_insns
/export/gnu/import/git/gcc-regression/gcc/gcc/lra.c:1786
0x87ec47b lra_process_new_insns(rtx_insn*, rtx_insn*, rtx_insn*, char const*)
/export/gnu/import/git/gcc-regression/gcc/gcc/lra.c:1844
0x8804827 remove_inheritance_pseudos
/export/gnu/import/git/gcc-regression/gcc/gcc/lra-constraints.c:6352
0x880578b lra_undo_inheritance()
/export/gnu/import/git/gcc-regression/gcc/gcc/lra-constraints.c:6672
0x87ed6bf lra(_IO_FILE*)
/export/gnu/import/git/gcc-regression/gcc/gcc/lra.c:2423
0x87a3db0 do_reload
/export/gnu/import/git/gcc-regression/gcc/gcc/ira.c:5384
0x87a4200 execute
/export/gnu/import/git/gcc-regression/gcc/gcc/ira.c:5568
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug c++/68703] __attribute__((vector_size(N))) template member confusion

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Not really sure if this is about dependent type or not, because the following
fails too:
template 
struct D {
  V v;
  int f1 () { return this->v[N-1]; }
  int f2 () { return v[N-1]; }
};

int
main ()
{
  typedef int V1 __attribute__((vector_size (4 * sizeof (int;
  typedef int V2 __attribute__((vector_size (8 * sizeof (int;
  D a = { { 0, 1, 2, 3 } };
  D b = { { 0, 1, 2, 3, 4, 5, 6, 7 } };
  if (a.f1 () != 3 || a.f2 () != 3
  || b.f1 () != 7 || b.f2 () != 7)
__builtin_abort ();
}

I've tried:
--- pt.c.jj42016-08-06 12:11:45.0 +0200
+++ pt.c (TREE_C2016-08-08 20:03:33.217898449 +0200
@@ -22687,6 +22687,11 @@ dependent_type_p_r (tree type)D (expression, 0));
  if   (INNERMOST_TEMPLATE_ARGS (DECL_TI_ARGS (scope)
 return true;_CODE (expression) == OFFSET_REF)
{
+  /* Types with dependent vector_size attribute are dependent.  */, 0)))
+  tree a = lookup_attribute ("vector_size", TYPE_ATTRIBUTES (type));
+  if (a && ATTR_IS_DEPENDENT (a))D (expression, 1);
+return true;ntifier_p (expression))
+   return false;
   /* Other types are non-dependent.  */
   return false;EF with non-null TREE_TYPE is always non-dependent.  */
 }
@@ -23166,6 +23171,18 @@ type_dependent_expression_p (tree expres
   if (TREE_CODE (expression) == EXPR_PACK_EXPANSION)
 return true;

+  /* Decls where the type is going to have dependent vector_size attribute
+ are dependent.  */
+  if (VAR_P (expression)
+  || TREE_CODE (expression) == PARM_DECL
+  || TREE_CODE (expression) == RESULT_DECL
+  || TREE_CODE (expression) == FIELD_DECL)
+{
+  tree a = lookup_attribute ("vector_size", DECL_ATTRIBUTES (expression));
+  if (a && ATTR_IS_DEPENDENT (a))
+   return true;
+}
+
   if (TREE_TYPE (expression) == unknown_type_node)
 {
   if (TREE_CODE (expression) == ADDR_EXPR)

so far but it didn't make any difference, neither on
template 
struct D {
  int v __attribute__((vector_size (N * sizeof (int;
  int f1 () { return this->v[N-1]; }
  int f2 () { return v[N-1]; }
};

int
main ()
{
  D<4> a = { { 0, 1, 2, 3 } };
  D<8> b = { { 0, 1, 2, 3, 4, 5, 6, 7 } };
  if (a.f1 () != 3 || a.f2 () != 3
  || b.f1 () != 7 || b.f2 () != 7)
__builtin_abort ();
}

nor on
template 
struct D {
  typedef int V __attribute__((vector_size (N * sizeof (int;
  V v;
  int f1 () { return this->v[N-1]; }
  int f2 () { return v[N-1]; }
};

int
main ()
{
  D<4> a = { { 0, 1, 2, 3 } };
  D<8> b = { { 0, 1, 2, 3, 4, 5, 6, 7 } };
  if (a.f1 () != 3 || a.f2 () != 3
  || b.f1 () != 7 || b.f2 () != 7)
__builtin_abort ();
}

[Bug c++/68703] __attribute__((vector_size(N))) template member confusion

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org

--- Comment #3 from Martin Sebor  ---
This problem isn't limited to attribute vector_size but affects attribute
aligned as well, to an even greater extent:  While G++ makes it possible to
overload functions on the former, it rejects overloads on the latter (it seems
to "lose" the attribute from a type).  The manual doesn't make it clear which
is intended, leading to confusion such as in bug 71463 where users don't know
whether to expect an attribute to affect the type of an object or in what
contexts (__typeof__, decltype, template parameters, etc.)

$ (cat y.C && set -x && for a in aligned vector_size; do
/build/gcc-trunk-svn/gcc/xgcc -B /build/gcc-trunk-svn/gcc -DX=$a -S -Wall
-Wextra y.C; done)
typedef int X16 __attribute__ ((X (16)));
typedef int X32 __attribute__ ((X (32)));

int f (X16*);
void f (X32*);

int g16 ()
{
  X16 x; 
  return f ();
}

void g32 ()
{
  X32 x;
  return f ();
}

template 
auto h ()
{
  int x __attribute__ ((X (N)));
  return f ();
}

+ for a in aligned vector_size
+ /home/msebor/build/gcc-trunk-svn/gcc/xgcc -B
/home/msebor/build/gcc-trunk-svn/gcc -DX=aligned -S -Wall -Wextra y.C
y.C:5:6: error: ambiguating new declaration of ‘void f(X32*)’
 void f (X32*);
  ^
y.C:4:5: note: old declaration ‘int f(X16*)’
 int f (X16*);
 ^
y.C: In function ‘void g32()’:
y.C:16:15: error: return-statement with a value, in function returning 'void'
[-fpermissive]
   return f ();
   ^
+ for a in aligned vector_size
+ /home/msebor/build/gcc-trunk-svn/gcc/xgcc -B
/home/msebor/build/gcc-trunk-svn/gcc -DX=vector_size -S -Wall -Wextra y.C
y.C: In function ‘auto h()’:
y.C:23:15: error: no matching function for call to ‘f(int*)’
   return f ();
   ^
y.C:4:5: note: candidate: int f(X16*)
 int f (X16*);
 ^
y.C:4:5: note:   no known conversion for argument 1 from ‘int*’ to ‘X16* {aka
__vector(4) int*}’
y.C:5:6: note: candidate: void f(X32*)
 void f (X32*);
  ^
y.C:5:6: note:   no known conversion for argument 1 from ‘int*’ to ‘X32* {aka
__vector(8) int*}’

[Bug c++/72842] New: non-type template-parameter of type void

[barry.revzin at gmail dot com]

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

Bug ID: 72842
   Summary: non-type template-parameter of type void
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: barry.revzin at gmail dot com
  Target Milestone: ---

The following compiles on gcc (and clang), across all versions I've tried:

template 
void foo() { }

int main() {
foo();
}

But void isn't a valid non-type template parameter type.

[Bug bootstrap/72833] [7 regression] error in fortran/parse.c (unexpected_eof) on Mac OS X 10.7

[bernd.edlinger at hotmail dot de]

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

Bernd Edlinger  changed:

   What|Removed |Added

  Attachment #39078|0   |1
is obsolete||

--- Comment #7 from Bernd Edlinger  ---
Created attachment 39079
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39079=edit
updated patch

Hi,

my autogen 5.18 (ubuntu 14.04)
did not work right, and messed up the comment.
So it won't compile.

That should (hopefully) be fixed now.

Sorry.

[Bug sanitizer/71042] libtsan requires __pointer_chk_guard@GLIBC_PRIVATE (6)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||law at gcc dot gnu.org

--- Comment #8 from Jakub Jelinek  ---
rpm tracks symbol versioning dependencies of binaries/libraries, and filters
out GLIBC_PRIVATE symbols to make sure apps don't use the private symbols (the
only exception is that glibc libraries/binaries can use those symbols
themselves).
The GLIBC_PRIVATE stands for symbols that aren't part of the exported glibc
ABI, can be changed at any time.  So dlsym would be only ugly cheating here.

In theory you could get the pointer mangling value for the current thread e.g.
by calling the original libc setjmp function or some other function where glibc
performs pointer mangling, and if you know which field glibc mangles and the
expected unmangled value there, you should be able to recover the
__pointer_chk_guard value from the pair of mangled and unmangled pointers,
because the mangling is just xor + rotate.

[Bug go/72814] reflect FAILs on 32-bit Solaris/SPARC: SIGILL

[ian at airs dot com]

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

Ian Lance Taylor  changed:

   What|Removed |Added

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

--- Comment #1 from Ian Lance Taylor  ---
The failing test is a function that returns a zero-sized struct.  The libffi
library does not support a zero-sized struct, so libgo and libffi togther wind
up treating the return type as a struct whose size is 1 byte.  On 32-bit SPARC,
a call to a function that returns a struct whose size is larger than 0 is
followed by an unimp instruction.  The function is compiled to skip the unimp
instruction when it returns.  See the handling of %) in sparc_print_operand in
gcc/config/sparc/sparc.c.  So libffi, thinking that the function returns a
non-empty struct, provides an unimp instruction to be skipped.  But the actual
function returns an empty struct, and therefore does not expect the unimp
instruction, and therefore does not skip it.  The result is an attempt to
execute the instruction, causing the SIGILL.

[Bug sanitizer/71042] libtsan requires __pointer_chk_guard@GLIBC_PRIVATE (6)

[adhemerval.zanella at linaro dot org]

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

--- Comment #7 from Adhemerval Zanella  
---
I do have a better solution to fix it, since for aarch64 glibc port, the stack
guard is a global variable (different than x86_64 where it in tcbhead
accessible through thread pointer).

We can just disable the jump fuction interposing for aarch64 and set it as
unavailable, but I would prefer to use if there is no alternative.

Jakub's solution can work and I will check it, but could you describe the issue
with RPM with more details?

[Bug debug/72828] [5/6/7 Regression] ICE in clone_tree_partial when compiling with -fdebug-types-section

[ott at fb dot com]

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

--- Comment #2 from Giuseppe Ottaviano  ---
Martin, I noticed you marked this as "[5/6/7 Regression]", but to be clear the
bug is present since at least 4.9 (the oldest version I tested).
It's only the attached reduction that is sensitive to compiler version. I can
provide repros for 4.9 and 5.1 as well.

[Bug gcov-profile/58306] Broken profiling for unrar sources: error: corrupted value profile: value profile counter (X out of Y) inconsistent with basic-block count

[t.artem at mailcity dot com]

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

--- Comment #23 from Artem S. Tashkinov  ---
(In reply to Martin Liška from comment #22)
> Sure, as Nathan suggested, we'll select the proper default value according
> to -pthread argument.

Wonderful! What are the chances of this patch being merged with GCC 4.9.x?

[Bug gcov-profile/58306] Broken profiling for unrar sources: error: corrupted value profile: value profile counter (X out of Y) inconsistent with basic-block count

[marxin at gcc dot gnu.org]

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

--- Comment #22 from Martin Liška  ---
(In reply to Artem S. Tashkinov from comment #21)
> (In reply to Martin Liška from comment #20)
> > > Do I understand the patch correctly that it requires
> > > "-fprofile-update=atomic" option in order to eliminate this bug?
> > 
> > Exactly, I hope I'll be able to merge the whole patchset (5) to mainline
> > soon.
> 
> What's the rationale behind this decision? This looks a bit counter
> intuitive and counter productive. People just enable profiling and don't
> think twice about extra requirements it might ensue.

Sure, as Nathan suggested, we'll select the proper default value according to
-pthread argument.

[Bug bootstrap/72833] [7 regression] error in fortran/parse.c (unexpected_eof) on Mac OS X 10.7

[bernd.edlinger at hotmail dot de]

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

--- Comment #6 from Bernd Edlinger  ---
Created attachment 39078
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39078=edit
untested patch

Completely untested patch.

Based on the gcc-4.9 solaris patch:
just s/solaris/darwin/
and s/__NORETURN/__dead2/


Could you try a boot-strap with it?


Thanks.

[Bug bootstrap/72833] [7 regression] error in fortran/parse.c (unexpected_eof) on Mac OS X 10.7

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #5 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE  Uni-Bielefeld.DE> ---
>> Could you please attach a faulty setjmp.h and a good setjmp.h
>
> I'm attaching the Mac OS X 10.7 one (i386/setjmp.h).  Need to get home
> first for the 10.12 one and the annotation they use for noreturn
> functions.

I've just checked: on Mac OS X 10.11 and macOS 10.12, there simply is no
.  Instead, longjmp is declared directly in 
with a __dead2 annotation (which expands to __attribute__((noreturn))).
No idea if there were any intermediate versions with the declaration in
 but some annotation (__dead2 or otherwise) present.

Rainer

[Bug gcov-profile/58306] Broken profiling for unrar sources: error: corrupted value profile: value profile counter (X out of Y) inconsistent with basic-block count

[t.artem at mailcity dot com]

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

--- Comment #21 from Artem S. Tashkinov  ---
(In reply to Martin Liška from comment #20)
> > Do I understand the patch correctly that it requires
> > "-fprofile-update=atomic" option in order to eliminate this bug?
> 
> Exactly, I hope I'll be able to merge the whole patchset (5) to mainline
> soon.

What's the rationale behind this decision? This looks a bit counter intuitive
and counter productive. People just enable profiling and don't think twice
about extra requirements it might ensue.

[Bug tree-optimization/71083] [5/6/7 Regression] Unaligned bit-field address when predictive commoning

[bernd.edlinger at hotmail dot de]

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

Bernd Edlinger  changed:

   What|Removed |Added

  Attachment #39068|0   |1
is obsolete||

--- Comment #8 from Bernd Edlinger  ---
Created attachment 39077
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39077=edit
proposed patch

the previous version hit an assertion,
because it can happen that inner == NULL and coff != 0 ...

fixed assertion and survives reg-testing.

[Bug testsuite/72841] New: PASS->NA: 20_util/tuple/cons/66338.cc execution test

[thopre01 at gcc dot gnu.org]

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

Bug ID: 72841
   Summary: PASS->NA: 20_util/tuple/cons/66338.cc execution test
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: thopre01 at gcc dot gnu.org
CC: redi at gcc dot gnu.org
  Target Milestone: ---
Target: arm-none-eabi

Hi,

r238945 has changed the following two tests from runtime tests to compile test
only:

PASS->NA: 20_util/tuple/cons/66338.cc execution test
PASS->NA: 20_util/tuple/cons/element_accepts_anything_byval.cc execution test

I believe this was not intended because the commit message reads (emphasis is
mine):

Limit std::tuple tests to *run* for C++11 and later


If I made a mistake and this was indeed intended, please accept my apologize
and discard this bug report.

Best regards.

[Bug testsuite/72840] New: PASS->NA: 20_util/ratio/cons/cons_overflow_neg.cc

[thopre01 at gcc dot gnu.org]

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

Bug ID: 72840
   Summary: PASS->NA: 20_util/ratio/cons/cons_overflow_neg.cc
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: thopre01 at gcc dot gnu.org
CC: redi at gcc dot gnu.org
  Target Milestone: ---

Hi,

2 error checks have stopped being run in
20_util/ratio/cons/cons_overflow_neg.cc due to syntax error on the dg-error
line.

Indeed, the dg-error directives at lines 40 and 46 are missing the closing
curly braces:

l40
  std::ratio<1, INTMAX_MIN> r1 __attribute__((unused)); // { dg-error "required
from here"

l46
  std::ratio<1,0> r1 __attribute__((unused)); // { dg-error "required from
here"

[Bug rtl-optimization/71976] insn-combiner deletes a live 64-bit shift

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

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

--- Comment #11 from Georg-Johann Lay  ---
Fixed in 5.5 and 6.2+.

[Bug gcov-profile/46266] gcov generates data for non-existing file

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #3 from Martin Liška  ---
Confirmed on current trunk.

[Bug testsuite/72838] FAIL: g++.dg/cpp0x/constexpr-cast.C

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #4 from Martin Sebor  ---
Tests adjusted in r239242.

[Bug testsuite/72838] FAIL: g++.dg/cpp0x/constexpr-cast.C

[msebor at gcc dot gnu.org]

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

--- Comment #3 from Martin Sebor  ---
Author: msebor
Date: Mon Aug  8 15:32:16 2016
New Revision: 239242

URL: https://gcc.gnu.org/viewcvs?rev=239242=gcc=rev
Log:
PR testsuite/72838 - FAIL: g++.dg/cpp0x/constexpr-cast.C

gcc/testsuite/ChangeLog:
* gcc/testsuite/g++.dg/cpp0x/constexpr-cast.C: Correct target selector.
* gcc/testsuite/g++.dg/warn/overflow-warn-3.C: Same.
* gcc/testsuite/g++.dg/warn/overflow-warn-4.C: Same.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-cast.C
trunk/gcc/testsuite/g++.dg/warn/overflow-warn-3.C
trunk/gcc/testsuite/g++.dg/warn/overflow-warn-4.C

[Bug target/72839] New: MOVE_RATIO is too small for Lakemont

[hjl.tools at gmail dot com]

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

Bug ID: 72839
   Summary: MOVE_RATIO is too small for Lakemont
   Product: gcc
   Version: 6.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: ubizjak at gmail dot com
  Target Milestone: ---
  Host: i386

[hjl@gnu-6 stringops-1]$ cat x.i
extern char *strcpy (char *, const char *);

void
foo (char *s)
{
  strcpy (s,
  "12345678123456781234567812345678123456781234567812345678"
  "1234567");
}
[hjl@gnu-6 stringops-1]$ gcc -O2 -mtune=lakemont -m32 -S x.i
[hjl@gnu-6 stringops-1]$ cat x.s
.file   "x.i"
.section.rodata.str1.4,"aMS",@progbits,1
.align 4
.LC0:
.string
"123456781234567812345678123456781234567812345678123456781234567"
.text
.p2align 4,,15
.globl  foo
.type   foo, @function
foo:
.LFB0:
.cfi_startproc
pushl   %edi
.cfi_def_cfa_offset 8
.cfi_offset 7, -8
pushl   %esi
.cfi_def_cfa_offset 12
.cfi_offset 6, -12
movl12(%esp), %edi
movl$.LC0, %esi
movl$64, %eax
testl   $1, %edi
jne .L21
testl   $2, %edi
jne .L22
.L3:
movl%eax, %ecx
xorl%edx, %edx
shrl$2, %ecx
testb   $2, %al
rep movsl
je  .L4
movw(%esi), %dx
movw%dx, (%edi)
movl$2, %edx
.L4:
testb   $1, %al
je  .L1
movb(%esi,%edx), %al
movb%al, (%edi,%edx)
.L1:
popl%esi
.cfi_remember_state
.cfi_restore 6
.cfi_def_cfa_offset 8
popl%edi
.cfi_restore 7
.cfi_def_cfa_offset 4
ret
.p2align 4,,7
.p2align 3
.L21:
.cfi_restore_state
movb.LC0, %al
incl%edi
movb%al, -1(%edi)
movl$.LC0+1, %esi
movl$63, %eax
testl   $2, %edi
je  .L3
.p2align 4,,7
.p2align 3
.L22:
movw(%esi), %dx
addl$2, %edi
movw%dx, -2(%edi)
addl$2, %esi
subl$2, %eax
jmp .L3
.cfi_endproc
.LFE0:
.size   foo, .-foo

The code is bigger and slower.

[Bug testsuite/72838] FAIL: g++.dg/cpp0x/constexpr-cast.C

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #2 from Martin Sebor  ---
Thanks.  Let me correct the target selector.

[Bug bootstrap/72833] [7 regression] error in fortran/parse.c (unexpected_eof) on Mac OS X 10.7

[ro at gcc dot gnu.org]

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

--- Comment #4 from Rainer Orth  ---
Created attachment 39076
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39076=edit
Mac OS X 10.7 

[Bug bootstrap/72833] [7 regression] error in fortran/parse.c (unexpected_eof) on Mac OS X 10.7

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #2 from Bernd Edlinger  ---
[...]
> I see we had previously a solaris_longjmp_noreturn
> fixinclude rule, maybe that would be a starting point.

Certainly: up to Solaris 9, there was the same issue.

> Could you please attach a faulty setjmp.h and a good setjmp.h

I'm attaching the Mac OS X 10.7 one (i386/setjmp.h).  Need to get home
first for the 10.12 one and the annotation they use for noreturn
functions.

> from your MAC OS X?
> And by the way what is the canonical target name here?

I'd just use *-*-darwin* here, and bypass on the noreturn annotation,
similar to what the solaris_longjmp_noreturn fix did.

Rainer

[Bug target/72802] powerpc64le: -mcpu=power9 emits lxssp instruction with offset that isn't a multiple of 4

[amodra at gmail dot com]

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

Alan Modra  changed:

   What|Removed |Added

 CC|amodra at gmail dot com|

--- Comment #7 from Alan Modra  ---
Fixed on trunk.  The problem exists on gcc-6 since we have wrong "o"
constraints on lsxxp/stxssp there.  Triggered by:

float foo (void *p)
{
  register float f __asm__ ("v0");
  f = *(float *)((char *) p + 2);
  __asm__ ("#%0" : "+wa" (f));
  return f;
}

[Bug testsuite/72838] FAIL: g++.dg/cpp0x/constexpr-cast.C

[thopre01 at gcc dot gnu.org]

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

--- Comment #1 from Thomas Preud'homme  ---
Note, the same error happens in:

PASS->NA: g++.dg/warn/overflow-warn-3.C  -std=gnu++11 const (test for errors,
line 67)
PASS->FAIL: g++.dg/warn/overflow-warn-3.C  -std=gnu++11 (test for excess
errors)
PASS->NA: g++.dg/warn/overflow-warn-3.C  -std=gnu++14 const (test for errors,
line 67)
PASS->FAIL: g++.dg/warn/overflow-warn-3.C  -std=gnu++14 (test for excess
errors)
PASS->NA: g++.dg/warn/overflow-warn-3.C  -std=gnu++98 const (test for errors,
line 67)
PASS->FAIL: g++.dg/warn/overflow-warn-3.C  -std=gnu++98 (test for excess
errors)
PASS->NA: g++.dg/warn/overflow-warn-4.C  -std=gnu++11 const (test for errors,
line 70)
PASS->FAIL: g++.dg/warn/overflow-warn-4.C  -std=gnu++11 (test for excess
errors)
PASS->NA: g++.dg/warn/overflow-warn-4.C  -std=gnu++14 const (test for errors,
line 70)
PASS->FAIL: g++.dg/warn/overflow-warn-4.C  -std=gnu++14 (test for excess
errors)
PASS->NA: g++.dg/warn/overflow-warn-4.C  -std=gnu++98 const (test for errors,
line 70)
PASS->FAIL: g++.dg/warn/overflow-warn-4.C  -std=gnu++98 (test for excess
errors)

Best regards.

[Bug testsuite/72838] New: FAIL: g++.dg/cpp0x/constexpr-cast.C

[thopre01 at gcc dot gnu.org]

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

Bug ID: 72838
   Summary: FAIL: g++.dg/cpp0x/constexpr-cast.C
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: thopre01 at gcc dot gnu.org
CC: msebor at gcc dot gnu.org
  Target Milestone: ---
Target: arm-none-eabi

Hi,

g++.dg/cpp0x/constexpr-cast.C fails on arm-none-eabi on the dg-error at line 8:

NA->FAIL: g++.dg/cpp0x/constexpr-cast.C  -std=c++11 bug c++/49171 (test for
errors, line 8)
NA->FAIL: g++.dg/cpp0x/constexpr-cast.C  -std=c++14 bug c++/49171 (test for
errors, line 8)

I believe this is due to the target triplet which is *-*-*-* rather than *-*-*.

Best regards.

[Bug c++/58706] ICE with lambda in OpenMP for-loop

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
This isn't valid code, as OpenMP doesn't support C++11 and later, so in order
to stay in the well defined territory, you shouldn't use C++11 and later
constructs in OpenMP constructs.

[Bug gcov-profile/58306] Broken profiling for unrar sources: error: corrupted value profile: value profile counter (X out of Y) inconsistent with basic-block count

[marxin at gcc dot gnu.org]

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

--- Comment #20 from Martin Liška  ---
(In reply to Artem S. Tashkinov from comment #19)
> (In reply to Martin Liška from comment #18)
> > Ok, problem is that various value profilers are not updated atomically,
> > fixed in:
> > https://gcc.gnu.org/ml/gcc-patches/2016-08/msg00600.html
> 
> Thank you!
> 
> Do I understand the patch correctly that it requires
> "-fprofile-update=atomic" option in order to eliminate this bug?

Exactly, I hope I'll be able to merge the whole patchset (5) to mainline soon.

[Bug gcov-profile/58306] Broken profiling for unrar sources: error: corrupted value profile: value profile counter (X out of Y) inconsistent with basic-block count

[t.artem at mailcity dot com]

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

--- Comment #19 from Artem S. Tashkinov  ---
(In reply to Martin Liška from comment #18)
> Ok, problem is that various value profilers are not updated atomically,
> fixed in:
> https://gcc.gnu.org/ml/gcc-patches/2016-08/msg00600.html

Thank you!

Do I understand the patch correctly that it requires "-fprofile-update=atomic"
option in order to eliminate this bug?

[Bug tree-optimization/72817] [7 Regression] wrong code at -O3 on x86_64-linux-gnu (in both 32-bit and 64-bit modes)

[amker at gcc dot gnu.org]

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

amker at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #2 from amker at gcc dot gnu.org ---
mine.

[Bug gcov-profile/67097] gcov-tool merge (can) crash when dir2 contains files not in dir1

[marxin at gcc dot gnu.org]

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

--- Comment #8 from Martin Liška  ---
(In reply to Gilles Gouaillardet from comment #6)
> as a side note, would you be interested in me providing a patch so
> gcov-tool merge
> can merge n directories (currently, we are limited to n=2) ?
> 
> i would implement that via a binary tree, so under the hood, that would
> require o(log(n)) elementary merge of two directories.
> 
> for extreme merge, i can also add an option that specifies the temporary
> directory to be used (e.g. something different that /tmp/$TMPDIR)

If you have a use-case where it would be beneficial, why not ;)

[Bug c++/72837] New: -Wundef is not being ignored with pragma

[TrevorJamesHickey at gmail dot com]

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

Bug ID: 72837
   Summary: -Wundef is not being ignored with pragma
   Product: gcc
   Version: 5.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: TrevorJamesHickey at gmail dot com
  Target Milestone: ---

Given the following code:  

#if MACRO_WITHOUT_A_VALUE
int var;
#endif

int main(){}
When compiled with, `g++ -std=c++1z -Wundef -o main main.cpp`,  
it produces the following warning:  

main.cpp:1:5: warning: "MACRO_WITHOUT_A_VALUE" is not defined [-Wundef]
 #if MACRO_WITHOUT_A_VALUE
 ^
I'd like to keep the warning flag enabled, but suppress this particular
instance.  
I apply the following:

#ifdef __GNUC__
#pragma GCC diagnostic ignored "-Wundef"
#pragma GCC diagnostic push
#endif

#if MACRO_WITHOUT_A_VALUE
int var;
#endif

#ifdef __GNUC__
#pragma GCC diagnostic pop
#endif

int main(){}
This only solves the problem in `clang++`.  

The command `clang++ -std=c++1z -Wundef -o main main.cpp` builds without
warnings.  
The command `g++ -std=c++1z -Wundef -o main main.cpp` builds with the same
`[-Wundef]` warning as before.

**How can I suppress `-Wundef` warnings in `g++`?**  

g++ (Ubuntu 5.1.0-0ubuntu11~14.04.1) 5.1.0
clang version 3.8.0

http://stackoverflow.com/questions/38831058/wundef-is-not-being-ignored-with-pragma-in-g

[Bug tree-optimization/72817] [7 Regression] wrong code at -O3 on x86_64-linux-gnu (in both 32-bit and 64-bit modes)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|--- |7.0
Summary|wrong code at -O3 on|[7 Regression] wrong code
   |x86_64-linux-gnu (in both   |at -O3 on x86_64-linux-gnu
   |32-bit and 64-bit modes)|(in both 32-bit and 64-bit
   ||modes)

[Bug gcov-profile/67097] gcov-tool merge (can) crash when dir2 contains files not in dir1

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|REOPENED|NEW

--- Comment #7 from Martin Liška  ---
Confirmed with current trunk.

[Bug gcov-profile/58306] Broken profiling for unrar sources: error: corrupted value profile: value profile counter (X out of Y) inconsistent with basic-block count

[marxin at gcc dot gnu.org]

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

--- Comment #18 from Martin Liška  ---
Ok, problem is that various value profilers are not updated atomically, fixed
in:
https://gcc.gnu.org/ml/gcc-patches/2016-08/msg00600.html

[Bug rtl-optimization/72821] [7 regression] RTL check: expected elt 2 type 'B', have '0' (rtx barrier) in BLOCK_FOR_INSN, at rtl.h:1424

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Mon Aug  8 13:58:46 2016
New Revision: 239241

URL: https://gcc.gnu.org/viewcvs?rev=239241=gcc=rev
Log:
PR rtl-optimization/72821
* lra-spills.c (regno_in_use_p): Don't use BLOCK_FOR_INSN on barriers,
just return false for them.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/lra-spills.c

[Bug middle-end/71937] out of memory on very large function

[jmgjdubois at gmail dot com]

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

--- Comment #15 from Jean-Michel Dubois  ---
I am back. I built gcc 6.1 with the --enable-decimal-float I need. I can now
compile successfully in about 2'30 with gcc -O2.

Thanks for your help.

[Bug fortran/72716] [5/6/7 Regression] ICE in gfc_resolve_omp_declare_simd, at fortran/openmp.c:5156

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #2 from Jakub Jelinek  ---
Created attachment 39075
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39075=edit
gcc7-pr72716.patch

Untested fix.