[Bug libstdc++/79433] __has_include does not conform to SD-6

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|c++ |libstdc++

--- Comment #10 from Andrew Pinski  ---
(In reply to Marc Mutz from comment #9)
> __has_include these days is defined by SD-6, and while not spelled out in
> normative text, the intent is very much for it to be able to detect presence
> of a header for inclusion.

Then the bug is in the header (library) and not in the preprocessor or the
front-end.

[Bug tree-optimization/69823] [6/7 Regression] internal compiler error: in create_pw_aff_from_tree, at graphite-sese-to-poly.c:445

[rguenth at gcc dot gnu.org]

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

--- Comment #9 from Richard Biener  ---
Author: rguenth
Date: Thu Feb  9 07:47:07 2017
New Revision: 245295

URL: https://gcc.gnu.org/viewcvs?rev=245295=gcc=rev
Log:
2017-02-09  Richard Biener  

PR tree-optimization/69823
* graphite-scop-detection.c (scop_detection::harmful_loop_in_region):
Properly enumerate all BBs in the region.  Use auto_vec/auto_bitmap.

* gcc.dg/graphite/pr69823.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/graphite/pr69823.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/graphite-scop-detection.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/79433] __has_include reports wrong result for std headers that #error on __cplusplus

[marc.mutz at kdab dot com]

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

Marc Mutz  changed:

   What|Removed |Added

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

--- Comment #9 from Marc Mutz  ---
__has_include these days is defined by SD-6, and while not spelled out in
normative text, the intent is very much for it to be able to detect presence of
a header for inclusion. Quoting from
https://isocpp.org/std/standing-documents/sd-6-sg10-feature-test-recommendations:

 This demonstrates a way to use a library optional facility only if it is
available.

#ifdef __has_include
#  if __has_include()
#include 
#define have_optional 1
#  elif __has_include()
#include 
#define have_optional 1
#define experimental_optional
#  else
#define have_optional 0
#  endif
#endif

So, IMHO, you do have a bug here, because this example does not work as
intended by its defining norm.

Absent any proof to the contrary, I believe that in order to conform to SD-6,
you have to move such headers under a c++1{1,4,z}/ subdir which only gets added
to the include path if the resp. -std is in effect. This will make the example
from SD-6 work, as well as enabling the use-case Jonathan mentioned in the IRC
log.

Note that removing the #error from the header files, so they can at least be
included, if present, and a corresponding __cpp_lib macro can be evaluated is
still not conforming to SD-6, since the example assumes that availability of
the header implies usability without further checks, making __cpp_lib macros
useful for versioning

[Bug target/79436] [ARM Cortex-M4F] VFMA used in place of subtraction gives inexact results

[pinskia at gcc dot gnu.org]

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

--- Comment #5 from Andrew Pinski  ---
"this default behaviour produces invalid results."

No.
Read http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.22.6768

> The same code compiled at -O2 for x86-64 does not assert. 
That because the default x86_64 target does not have the fused multiple add
instruction.  On a newer Intel (or AMD) machine, add -march=naitve and you will
see the same behavior.

You are not understand what fused multiple add instruction does and how
floating point works.  

VFMA is not just multiply and accumulate but rather fused multiply and add. 
The multiplication is done in infinite precision and then the add is done in
that same infinite precision and then a round happens down to double.  Instead
of what happens with -ffp-contract=off which is not to used the fused multiple
add instruction which means round between the multiply and addition.

[Bug target/79436] [ARM Cortex-M4F] VFMA used in place of subtraction gives inexact results

[freddie_chopin at op dot pl]

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

--- Comment #4 from Freddie Chopin  ---
Hello Andrew and thanks for your answer.

Generally I don't care about the sequence of operations or the exact
instructions that get generated, but in this case this default behaviour
produces invalid results.

Generally the whole calculations are like this:
mx = ex - sx;
my = ey - sy;
distance = sqrtf(mx * mx + my * my) * constant;

The important thing here is that ex and sx are bitwise identical, just as ey
and sy. Thus everything above can be transformed to:

mx = x - x;
my = y - y;
distance = sqrtf(mx * mx + my * my) * constant;

and then:

mx = 0;
my = 0;
distance = sqrtf(0 * 0 + 0 * 0) * constant;

However you rearrange that, the expected result is 0 and I see no place for
"typical" floating point inaccuracies here. Let me reiterate - "startVector"
and "endVector" in my test case are bitwise identical. Yet the code produces
1.34925369e-06 at the end...

The same code compiled at -O2 for x86-64 does not assert. I don't know x86-64
assembly, but I'm pretty sure that it supports this kind of instructions.

If the results of VFMA are considered "good enough" I think that the default
value of -ffp-contract should be changed to "off" - after all
-funsafe-math-optimizations or -ffast-math are not enabled by default either.

BTW - VFMA is used also with "-std=c++11".

Thus I think that the bug is not invalid and I ask you to reconsider. Thanks in
advance!

[Bug rtl-optimization/79438] New: [7 Regression] ICE during RA w/ -O3 (or -Ofast) -funroll-loops for 32-bit BE powerpc target

[asolokha at gmx dot com]

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

Bug ID: 79438
   Summary: [7 Regression] ICE during RA w/ -O3 (or -Ofast)
-funroll-loops for 32-bit BE powerpc target
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code, ra
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---
Target: powerpc-e500v2-linux-gnuspe

1. gcc-7.0.0-alpha20170205 snapshot fails to compile the following snippet w/
-O3 (or -Ofast) -funroll-loops:

int uq;
short int au;

void
sa (int na)
{
  int i7;

  for (i7 = 0; i7 < 81; ++i7)
{
  uq ^= 1;
  au ^= na;
}
}

% powerpc-e500v2-linux-gnuspe-gcc-7.0.0-alpha20170205 -O3 -funroll-loops -c
t0xyp7os.c 
t0xyp7os.c: In function 'sa':
t0xyp7os.c:14:1: internal compiler error: in lra_set_insn_recog_data, at
lra.c:965
 }
 ^
0x30704833833 lra_set_insn_recog_data(rtx_insn*)
   
/var/tmp/portage/cross-powerpc-e500v2-linux-gnuspe/gcc-7.0.0_alpha20170205/work/gcc-7-20170205/gcc/lra.c:963
0x30704834a07 lra_get_insn_recog_data
   
/var/tmp/portage/cross-powerpc-e500v2-linux-gnuspe/gcc-7.0.0_alpha20170205/work/gcc-7-20170205/gcc/lra-int.h:487
0x30704834a07 lra_update_insn_regno_info(rtx_insn*)
   
/var/tmp/portage/cross-powerpc-e500v2-linux-gnuspe/gcc-7.0.0_alpha20170205/work/gcc-7-20170205/gcc/lra.c:1585
0x30704834e60 lra_push_insn_1
   
/var/tmp/portage/cross-powerpc-e500v2-linux-gnuspe/gcc-7.0.0_alpha20170205/work/gcc-7-20170205/gcc/lra.c:1736
0x30704834e60 lra_push_insn(rtx_insn*)
   
/var/tmp/portage/cross-powerpc-e500v2-linux-gnuspe/gcc-7.0.0_alpha20170205/work/gcc-7-20170205/gcc/lra.c:1744
0x307048350ff push_insns
   
/var/tmp/portage/cross-powerpc-e500v2-linux-gnuspe/gcc-7.0.0_alpha20170205/work/gcc-7-20170205/gcc/lra.c:1787
0x30704835702 lra_process_new_insns(rtx_insn*, rtx_insn*, rtx_insn*, char
const*)
   
/var/tmp/portage/cross-powerpc-e500v2-linux-gnuspe/gcc-7.0.0_alpha20170205/work/gcc-7-20170205/gcc/lra.c:1845
0x3070484d747 curr_insn_transform
   
/var/tmp/portage/cross-powerpc-e500v2-linux-gnuspe/gcc-7.0.0_alpha20170205/work/gcc-7-20170205/gcc/lra-constraints.c:4242
0x3070484f1c6 lra_constraints(bool)
   
/var/tmp/portage/cross-powerpc-e500v2-linux-gnuspe/gcc-7.0.0_alpha20170205/work/gcc-7-20170205/gcc/lra-constraints.c:4732
0x30704836522 lra(_IO_FILE*)
   
/var/tmp/portage/cross-powerpc-e500v2-linux-gnuspe/gcc-7.0.0_alpha20170205/work/gcc-7-20170205/gcc/lra.c:2378
0x307047e3570 do_reload
   
/var/tmp/portage/cross-powerpc-e500v2-linux-gnuspe/gcc-7.0.0_alpha20170205/work/gcc-7-20170205/gcc/ira.c:5400
0x307047e3570 execute
   
/var/tmp/portage/cross-powerpc-e500v2-linux-gnuspe/gcc-7.0.0_alpha20170205/work/gcc-7-20170205/gcc/ira.c:5584

2. Turning LRA off yields the following:

% powerpc-e500v2-linux-gnuspe-gcc-7.0.0-alpha20170205 -O3 -funroll-loops -c
t0xyp7os.c -mno-lra
t0xyp7os.c: In function 'sa':
t0xyp7os.c:14:1: error: unrecognizable insn:
 }
 ^
(insn 194 77 53 4 (set (const_vector:V4HI [
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
])
(reg:V4HI 9 9)) "t0xyp7os.c":12 -1
 (nil))
t0xyp7os.c:14:1: internal compiler error: in extract_insn, at recog.c:2311
0x2d7dca3c505 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
   
/var/tmp/portage/cross-powerpc-e500v2-linux-gnuspe/gcc-7.0.0_alpha20170205/work/gcc-7-20170205/gcc/rtl-error.c:108
0x2d7dca3c55c _fatal_insn_not_found(rtx_def const*, char const*, int, char
const*)
   
/var/tmp/portage/cross-powerpc-e500v2-linux-gnuspe/gcc-7.0.0_alpha20170205/work/gcc-7-20170205/gcc/rtl-error.c:116
0x2d7dca076af extract_insn(rtx_insn*)
   
/var/tmp/portage/cross-powerpc-e500v2-linux-gnuspe/gcc-7.0.0_alpha20170205/work/gcc-7-20170205/gcc/recog.c:2311
0x2d7dca0775f extract_insn_cached(rtx_insn*)
   
/var/tmp/portage/cross-powerpc-e500v2-linux-gnuspe/gcc-7.0.0_alpha20170205/work/gcc-7-20170205/gcc/recog.c:2201
0x2d7dc72b68b cleanup_subreg_operands(rtx_insn*)
   
/var/tmp/portage/cross-powerpc-e500v2-linux-gnuspe/gcc-7.0.0_alpha20170205/work/gcc-7-20170205/gcc/final.c:3138
0x2d7dca3a107 reload(rtx_insn*, int)
   
/var/tmp/portage/cross-powerpc-e500v2-linux-gnuspe/gcc-7.0.0_alpha20170205/work/gcc-7-20170205/gcc/reload1.c:1235
0x2d7dc8af1fe do_reload
   
/var/tmp/portage/cross-powerpc-e500v2-linux-gnuspe/gcc-7.0.0_alpha20170205/work/gcc-7-20170205/gcc/ira.c:5412
0x2d7dc8af1fe execute
   
/var/tmp/portage/cross-powerpc-e500v2-linux-gnuspe/gcc-7.0.0_alpha20170205/work/gcc-7-20170205/gcc/ira.c:5584

[Bug fortran/79430] [7 Regression] action of statement incorrectly optimised away

[juergen.reuter at desy dot de]

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

--- Comment #17 from Jürgen Reuter  ---
(In reply to Jerry DeLisle from comment #16)
> (In reply to Jürgen Reuter from comment #15)
> > With -fcheck=all nothing is flagged, but the test works as expected, as well
> > as if I (independently from the fcheck) compile everything with -fno-inline 
> > .
> 
> Also compile with -Wall and see if anything pops out. 
> 
> Try valgrind on executable compiled with and without the -fno-inline as well.

-Wall shows only a lot of unused dummy arguments which are unavoidable for
polymorphism . But when compiled with -Wall also the problem doesn't show up.
We will try to run valgrind on the code without flags and with -fno-inline as
well.

[Bug c++/79435] [7 Regression] ICE on invalid C++ code (with member access into an incomplete type) on x86_64-linux-gnu: Segmentation fault

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||error-recovery,
   ||ice-on-invalid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-02-09
 CC||msebor at gcc dot gnu.org
Summary|ICE on invalid C++ code |[7 Regression] ICE on
   |(with member access into an |invalid C++ code (with
   |incomplete type) on |member access into an
   |x86_64-linux-gnu:   |incomplete type) on
   |Segmentation fault  |x86_64-linux-gnu:
   ||Segmentation fault
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
Confirmed.  I get the following output without -w:

t.C:4:10: warning: ‘a’ has incomplete type
 extern A a;
  ^
t.C:3:8: note: forward declaration of ‘struct A’
 struct A;
^
t.C:5:28: internal compiler error: Segmentation fault
 template < int > int f = a.x;
^

Bisection points to r245223 (gcc 7.0.1):

r245223 | jason | 2017-02-06 16:12:13 -0500 (Mon, 06 Feb 2017) | 4 lines

PR c++/71193 - incomplete types in templates

* parser.c (cp_parser_postfix_dot_deref_expression): In a template
handle incomplete type by pedwarning and then treating as dependent.

[Bug fortran/79430] [7 Regression] action of statement incorrectly optimised away

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

 CC||jvdelisle at gcc dot gnu.org

--- Comment #16 from Jerry DeLisle  ---
(In reply to Jürgen Reuter from comment #15)
> With -fcheck=all nothing is flagged, but the test works as expected, as well
> as if I (independently from the fcheck) compile everything with -fno-inline .

Also compile with -Wall and see if anything pops out. 

Try valgrind on executable compiled with and without the -fno-inline as well.

[Bug c++/79433] __has_include reports wrong result for std headers that #error on __cplusplus

[redi at gcc dot gnu.org]

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

--- Comment #8 from Jonathan Wakely  ---
I guess another, novel, option would be a __try_include directive:

#ifdef __try_include
# if __try_include()
// it was included without error
# else
// it wasn't found, or gave an error
# endif
#endif

[Bug c++/79433] __has_include reports wrong result for std headers that #error on __cplusplus

[redi at gcc dot gnu.org]

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

--- Comment #7 from Jonathan Wakely  ---
(In reply to Marc Mutz from comment #1)
> And no, checking __cplusplus in addition is not an option, since many
> compilers, GCC included (__cplusplus==1, remember?), do not necessarily bump
> __cplusplus when they implement enough core features to make something like
> string_view (which can be implemented in C++11 just fine) work.

I don't follow this comment. The __cplusplus==1 bug was fixed years ago (GCC
4.7.0) and since then the macro has always been bumped when a new -std option
is supported. If it wasn't bumped, the #error directives that are behind this
bug report wouldn't work!

So while some other implementations do make  available for C++11
mode, GCC is not one of them, and I don't understand the "GCC included" part of
your comment.

If you said that some compilers make  available without -std=c++17
(or equivalent) so checking __cplusplus > 201402L would prevent using
 when it's actually usable, then that would be a valid argument.
It's not about bumping __cplusplus or not bumping it, it's about which -std
option is needed for the header to be usable. That varies between compilers, so
checking "__has_include( && __cplusplus > 201402L" works, and is
portable, but is overly conservative.

(In reply to Marc Mutz from comment #5)
> Please explain how one should detect, in a portable way, whether string_view
> and experimental::string_view is available, if not by headers check.

These should work portably and correctly:

#ifdef __has_include
#if __has_include() && __cplusplus > 201402L

#ifdef __has_include
#if __has_include() && __cplusplus >= 201402L

As I said, they're overly conservative, but they shouldn't give false
positives, only false negatives.


I brought the problem up on IRC a few months ago:

  would it be unthinkably ugly to give #include hardcoded
knowledge of standard library headers, and which -std option enables them?
  so that #include  would automatically skip the stdinc
paths if -std=c++98 ?
  otherwise __has_include() says yes, but including it
barfs
  skipping the stdinc paths would allow users to provide their own
fallbacks for when the standard one is not present (or rather, is present, but
gets skipped)
  an alternative would be to put c++11 headers in a new sub-dir of
$includedir/c++/$gccver/ and only add it to the include paths for -std=c++11
and up
  and similarly for c++14 and c++17 headers
  either solution is a bit smelly
   as discussed privately, it seems too smelly to strive for, as
users can check both __cplusplus and __has_include
   and once the include part has been thus properly ifdeffed not to
barf, the rest of the code can use a feature macro

[Bug c++/79433] __has_include reports wrong result for std headers that #error on __cplusplus

[egall at gwmail dot gwu.edu]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egall at gwmail dot gwu.edu

--- Comment #6 from Eric Gallager  ---
(In reply to Marc Mutz from comment #5)
> Andrew, you're taking the easy way out. It might be that it works as
> implemented, but that behaviour is useless.
> 
> Please explain how one should detect, in a portable way, whether string_view
> and experimental::string_view is available, if not by headers check.

Do an autoconf test for it, AC_CHECK_HEADERS tests whether including the header
actually compiles.

[Bug debug/42065] DWARF .debug_macinfo contains unused macros

[egall at gwmail dot gwu.edu]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egall at gwmail dot gwu.edu

--- Comment #4 from Eric Gallager  ---
If -feliminate-unused-debug-symbols and/or -feliminate-unused-debug-types start
removing these, I'd want them to turn on -Wunused-macros automatically for me
as well so I can know about it

[Bug other/79437] Redundant move instruction when getting sign bit of double on 32-bit architecture

[mizvekov at gmail dot com]

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

--- Comment #1 from Matheus Izvekov  ---
Forgot to mention above, all gcc versions including the unreleased 7.0 and
below as far as I could test (4.6) are affected by this.

For comparison, clang generates optimal code for all cases.

[Bug other/79437] New: Redundant move instruction when getting sign bit of double on 32-bit architecture

[mizvekov at gmail dot com]

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

Bug ID: 79437
   Summary: Redundant move instruction when getting sign bit of
double on 32-bit architecture
   Product: gcc
   Version: 6.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mizvekov at gmail dot com
  Target Milestone: ---

Testing this simple example:

#ifdef DO_BOOL
bool
#else
int
#endif
sign(double a) noexcept {
__UINT64_TYPE__ r;
__builtin_memcpy(, , sizeof(r));
return r >> 63 & 1;
}

Compiling with: -march=i686 -m32 -Os -fomit-frame-pointer

With DO_BOOL defined (bool sign(double)), this is the code generated:

sign(double):
mov eax, DWORD PTR [esp+8]
shr eax, 31
ret

Without DO_BOOL (int sign(double)), this is the code generated instead:

sign(double):
mov edx, DWORD PTR [esp+8]
mov eax, edx
shr eax, 31
ret

Notice the redundant moving around, from edx to eax instead of straight to eax.

These are my findings so far when investigating this:

* There is no difference between punning with memcpy or with union.

* Problem only happens when punning from floating point to integer.
Variants of the sign function that accept a void* or an uint64 directly are not
affected (ie either retuning bool or int result in the same optimal code).

* Problem only happens when punning to uint64. When punning to uint32[2], ie:

sign(double a) noexcept {
__UINT32_TYPE__ r[2];
__builtin_memcpy(, , sizeof(r));
return r[1] >> 31 & 1;
}

then again optimal code generation is performed in both cases.

* Inspecting the results of -fdump-tree-all reveals the following
transformation happens early on (on -tree-original already)

--- build_bool/test.cc.003t.original2017-02-08 22:07:22.749603900 -0200
+++ build_int/test.cc.003t.original 2017-02-08 22:07:11.675433300 -0200
@@ -1,5 +1,5 @@

-;; Function bool sign_mcpy1(double) (null)
+;; Function int sign_mcpy1(double) (null)
 ;; enabled by -tree-original


@@ -10,7 +10,7 @@
 long long unsigned int r;
 <;
-return  = (signed long long) r < 0;
+return  = (int) (r >> 63);
   }
>>>;

This basic structure persists until past .211t.optimized:

--- build_bool/test.cc.211t.optimized   2017-02-08 22:07:22.743595700 -0200
+++ build_int/test.cc.211t.optimized2017-02-08 22:07:11.670441000 -0200
@@ -1,16 +1,16 @@

-;; Function bool sign_mcpy1(double) (_Z10sign_mcpy1d, funcdef_no=0,
decl_uid=1665, cgraph_uid=0, symbol_order=0)
+;; Function int sign_mcpy1(double) (_Z10sign_mcpy1d, funcdef_no=0,
decl_uid=1665, cgraph_uid=0, symbol_order=0)

-bool sign_mcpy1(double) (double a)
+int sign_mcpy1(double) (double a)
 {
   long long unsigned int _2;
-  signed long long r.1_3;
-  bool _4;
+  long long unsigned int _3;
+  int _4;

   :
   _2 = VIEW_CONVERT_EXPR(a_5(D));
-  r.1_3 = (signed long long) _2;
-  _4 = r.1_3 < 0;
+  _3 = _2 >> 63;
+  _4 = (int) _3;
   return _4;

 }

So, the return bool case gets a different optimization early (at the
front-end?), and later stages can't fix it.

[Bug libgcc/66955] Bootstrap error: libcc1 compiled as shared library despite --disable-shared

[asbeer at gmail dot com]

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

Austin Beer  changed:

   What|Removed |Added

 CC||asbeer at gmail dot com

--- Comment #1 from Austin Beer  ---
I also encountered this error while trying to build GCC 5.4.0. I don't know
whether or not this issue is still present in GCC 6 or GCC 7. I've worked
around the issue by using --disable-libcc1.

Configuration that failed:
--disable-multilib --disable-nls --disable-libsanitizer --disable-shared
--enable-languages=c,c++,lto --enable-threads=posix --enable-__cxa_atexit

Configuration that succeeded:
--disable-multilib --disable-nls --disable-libsanitizer --disable-shared
--disable-libcc1 --enable-languages=c,c++,lto --enable-threads=posix
--enable-__cxa_atexit

The following email mentions this issue as well:
https://gcc.gnu.org/ml/gcc/2015-02/msg00128.html

[Bug c/79110] FAIL: gcc.dg/format/pr78304.c (test for warnings, line 9)

[danglin at gcc dot gnu.org]

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

John David Anglin  changed:

   What|Removed |Added

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

--- Comment #2 from John David Anglin  ---
No longer fails.

[Bug fortran/79430] [7 Regression] action of statement incorrectly optimised away

[juergen.reuter at desy dot de]

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

--- Comment #15 from Jürgen Reuter  ---
With -fcheck=all nothing is flagged, but the test works as expected, as well
as if I (independently from the fcheck) compile everything with -fno-inline .

[Bug c++/79070] Unhelpful error message for ambiguous type in template parameter

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #2 from Martin Sebor  ---
Confirmed.

[Bug c++/79083] GCC incorrectly compiles calls to constexpr static methods via a non-constexpr variable

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-02-08
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1
  Known to fail||5.3.0, 6.3.0, 7.0

--- Comment #1 from Martin Sebor  ---
Confirmed with today's top of trunk (GCC 7).

[Bug target/79436] [ARM Cortex-M4F] VFMA used in place of subtraction gives inexact results

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #3 from Andrew Pinski  ---
https://gcc.gnu.org/onlinedocs/gcc-6.3.0/gcc/Optimize-Options.html#index-ffp-contract-715

-ffp-contract=style
-ffp-contract=off disables floating-point expression contraction.
-ffp-contract=fast enables floating-point expression contraction such as
forming of fused multiply-add operations if the target has native support for
them. -ffp-contract=on enables floating-point expression contraction if allowed
by the language standard. This is currently not implemented and treated equal
to -ffp-contract=off.
The default is -ffp-contract=fast. 

In this case what is happening is the following:

we get:
a * b - a * b;
Which gets transformed into:
c = a*b
c1 = -c
d = a*b + (c1)

Which is correct but not what you are expecting.  See above above about
-ffp-contract=.

[Bug translation/79183] Hard coded plurals in gimple-ssa-sprintf.c:2050

[msebor at gcc dot gnu.org]

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

--- Comment #5 from Martin Sebor  ---
I see, thanks for the pointer.  Looks like warning_n() is used in
gcc/ipa-devirt.c and error_n() in gcc/cp/pt.c.  gimple-ssa-sprintf.c contains
between 7 and 23 instances of these "%wu byte" vs "%wu bytes" forms so it will
be a fun exercise to fix.

[Bug c/79084] No warning for implicit double with complex specifier

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-02-08
 CC||msebor at gcc dot gnu.org
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=78989,
   ||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=78000,
   ||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=71613
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
Confirmed.  I'm looking for a good pre-existing bug with another example of
this problem to link this to.  PR71613 and PR78000 look close, as does PR78989.

[Bug translation/79183] Hard coded plurals in gimple-ssa-sprintf.c:2050

[jsm28 at gcc dot gnu.org]

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

--- Comment #4 from Joseph S. Myers  ---
See hr.po, ru.po, sr.po and uk.po for GCC translations involving more than just
singular and plural (look at the Plural-Forms line in the .po file).

[Bug translation/79183] Hard coded plurals in gimple-ssa-sprintf.c:2050

[jsm28 at gcc dot gnu.org]

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

Joseph S. Myers  changed:

   What|Removed |Added

 Status|RESOLVED|NEW
   Last reconfirmed||2017-02-08
 Resolution|INVALID |---
 Ever confirmed|0   |1

--- Comment #3 from Joseph S. Myers  ---
Messages involving plurals need to go through ngettext (via warning_n etc.
functions) because some languages have more than just singular and plural forms
(e.g. separate forms to use when n = 2 from n > 2).

[Bug c/79110] FAIL: gcc.dg/format/pr78304.c (test for warnings, line 9)

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-02-08
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
I don't have access to an hppa-unknown-linux-gnu system to confirm what the
problem is.  Can you show us the full compiler output, including the excess
errors?

[Bug rtl-optimization/79386] [7 Regression] ICE: segmentation fault in cprop w/ -O2 on 32-bit BE powerpc

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 CC||law at redhat dot com
 Resolution|--- |FIXED

--- Comment #6 from Jeffrey A. Law  ---
Fixed with Jakub's patch on the trunk.

[Bug rtl-optimization/64081] [5/6/7 Regression] r217827 prevents RTL loop unroll

[law at redhat dot com]

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

--- Comment #59 from Jeffrey A. Law  ---
The work is still incredibly helpful.  After the analysis work is done we can
still decide to defer to gcc-8 stage1 if we feel it's too risky to tackle right
now.

[Bug translation/79397] AltiVec spelled incorrectly in rs6000.opt

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

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

--- Comment #5 from Segher Boessenkool  ---
Fixed everywhere.

[Bug translation/79397] AltiVec spelled incorrectly in rs6000.opt

[segher at gcc dot gnu.org]

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

--- Comment #4 from Segher Boessenkool  ---
Author: segher
Date: Wed Feb  8 21:44:37 2017
New Revision: 245287

URL: https://gcc.gnu.org/viewcvs?rev=245287=gcc=rev
Log:
rs6000: Fix spelling of AltiVec in rs6000.opt (PR79397)

It was spelled Altivec in two user-facing messages in rs6000.opt; let's
be consistent.


PR translation/79397
* config/rs6000/rs6000.opt (maltivec=le, maltivec=be): Fix spelling
of AltiVec.

Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/config/rs6000/rs6000.opt

[Bug target/79436] [ARM Cortex-M4F] VFMA used in place of subtraction gives inexact results

[freddie_chopin at op dot pl]

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

--- Comment #2 from Freddie Chopin  ---
Created attachment 40701
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40701=edit
assembly dump of valid version

[Bug target/79436] [ARM Cortex-M4F] VFMA used in place of subtraction gives inexact results

[freddie_chopin at op dot pl]

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

--- Comment #1 from Freddie Chopin  ---
Created attachment 40700
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40700=edit
assembly dump of invalid version

[Bug target/79436] New: [ARM Cortex-M4F] VFMA used in place of subtraction gives inexact results

[freddie_chopin at op dot pl]

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

Bug ID: 79436
   Summary: [ARM Cortex-M4F] VFMA used in place of subtraction
gives inexact results
   Product: gcc
   Version: 6.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: freddie_chopin at op dot pl
  Target Milestone: ---
Target: arm-none-eabi

Created attachment 40699
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40699=edit
test case

In some very specific code paths with specific optimization compiler generates
VNEG (negate) + VFMA (multiply and accumulate) instead of VSUB + VMUL. Most
likely this is not a problem in most cases, but in the test case I attach this
leads to inexact results in a well-defined code. The variable "distance", which
is basically a length of a difference of two _IDENTICAL_ vectors multiplied by
some constant factor, is expected to be 0. "x - x" for components of each
vector gives zero. "0 * 0" gives zero. "0 + 0" gives zero. "sqrtf(0)" gives
zero. "0 * x" gives 0. These are basically all the operations in the example.
However the value of "distance" is calculated to be 1.34925369e-06 and the
assertion fails.

Several notes:

1. The code seems complicated, but if I simplify it, different sequence of
instructions is generated, and the VNEG + VFMA used instead of VSUB + VMUL is
essential to the problem. To generate slightly different sequence it's enough
to uncomment the assertion that checks equality of vectors.

2. The problem appears on -O2, -O3 and -Os. It does not appear on -O1 and -Og
(probably neither with -O0, but I did not check).

3. The problem can be observed for GCC 6.3.0 and GCC 5.3.1. With or without ARM
patches.

Exact compilation command:

arm-none-eabi-g++ -Wall -Wextra -Wshadow -std=gnu++11 -g -ggdb3 -mcpu=cortex-m4
-mthumb -mfloat-abi=hard -mfpu=fpv4-sp-d16 -O2 -ffunction-sections
-fdata-sections -fno-rtti -fno-exceptions -c vfma.cpp -o vfma.o

I also attach assembly output of the "invalid" version (-O2) and "valid"
version (-O1).

[Bug translation/79397] AltiVec spelled incorrectly in rs6000.opt

[segher at gcc dot gnu.org]

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

--- Comment #3 from Segher Boessenkool  ---
Author: segher
Date: Wed Feb  8 21:41:31 2017
New Revision: 245286

URL: https://gcc.gnu.org/viewcvs?rev=245286=gcc=rev
Log:
rs6000: Fix spelling of AltiVec in rs6000.opt (PR79397)

It was spelled Altivec in two user-facing messages in rs6000.opt; let's
be consistent.


PR translation/79397
* config/rs6000/rs6000.opt (maltivec=le, maltivec=be): Fix spelling
of AltiVec.

Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/config/rs6000/rs6000.opt

[Bug fortran/79430] [7 Regression] action of statement incorrectly optimised away

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #14 from Steve Kargl  ---
On Wed, Feb 08, 2017 at 09:30:45PM +, juergen.reuter at desy dot de wrote:
> > 
> > > Indeed, it looks as if kind=10 would be real128, but as you said this
> > > is wrong and was fixed by you (I guess it is not yet in the trunk, as
> > > of r245197 at least).
> > 
> > You need r245255 to get the fix.  There is, however, some discussion
> > as to whether I should revert the change.
> 
> Ah ok. Why? Because it is too late for anything than regression fixes now? 

That's one reason.  The other reason given is that it changes
the ABI.  I don't think the ABI change is an issue because the
ABI for libgfortran has alraedy changed, which will require 
a recompile of software.

> As far as we can seen all our constants have valid and consistent
> kind type.  Any try to reduce the code, hasn't worked. Putting print
> statements there are trying to pass the corresponding routine to an
> output routine to access it without the heavy machinery of the whole
> program let's the problem go away.

Hmmm. Adding a print statement suggests stepping off the end 
of an array, accessing memory that has been free, and argument
mismatch in a function/subroutine call.  Have you tried adding
-fcheck=all and/or running the failing code under valgrind?

[Bug translation/79183] Hard coded plurals in gimple-ssa-sprintf.c:2050

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||msebor at gcc dot gnu.org
 Resolution|--- |INVALID

--- Comment #2 from Martin Sebor  ---
I don't see anything wrong with the messages.  The plural form is used  when
the byte count is greater than 1.  None of the messages should be issued when
the counter is zero because writing no bytes cannot lead to truncation.  If you
have a test case to the contrary please reopen the bug and provide the test
case.

[Bug c++/79435] New: ICE on invalid C++ code (with member access into an incomplete type) on x86_64-linux-gnu: Segmentation fault

[su at cs dot ucdavis.edu]

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

Bug ID: 79435
   Summary: ICE on invalid C++ code (with member access into an
incomplete type) on x86_64-linux-gnu: Segmentation
fault
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
  Target Milestone: ---

It should be a recent regression. 

$ g++-trunk -v
Using built-in specs.
COLLECT_GCC=g++-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/7.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 7.0.1 20170208 (experimental) [trunk revision 245266] (GCC)
$
$ g++-trunk -c -w small.cpp
small.cpp:3:28: internal compiler error: Segmentation fault
 template < int > int f = a.x;
^
0xe1439f crash_signal
../../gcc-source-trunk/gcc/toplev.c:333
0x6e2a88 type_dependent_expression_p(tree_node*)
../../gcc-source-trunk/gcc/cp/pt.c:23832
0x8dca90 potential_constant_expression_1
../../gcc-source-trunk/gcc/cp/constexpr.c:5159
0x7bcd94 cp_parser_constant_expression
../../gcc-source-trunk/gcc/cp/parser.c:9468
0x7bd4f4 cp_parser_initializer_clause
../../gcc-source-trunk/gcc/cp/parser.c:21595
0x7bee8b cp_parser_initializer
../../gcc-source-trunk/gcc/cp/parser.c:21533
0x7ce618 cp_parser_init_declarator
../../gcc-source-trunk/gcc/cp/parser.c:19352
0x7d59c1 cp_parser_single_declaration
../../gcc-source-trunk/gcc/cp/parser.c:26720
0x7d5afc cp_parser_template_declaration_after_parameters
../../gcc-source-trunk/gcc/cp/parser.c:26321
0x7d6521 cp_parser_explicit_template_declaration
../../gcc-source-trunk/gcc/cp/parser.c:26553
0x7d6521 cp_parser_template_declaration_after_export
../../gcc-source-trunk/gcc/cp/parser.c:26571
0x7d6ad9 cp_parser_declaration
../../gcc-source-trunk/gcc/cp/parser.c:12464
0x7d6de4 cp_parser_declaration_seq_opt
../../gcc-source-trunk/gcc/cp/parser.c:12391
0x7d7128 cp_parser_translation_unit
../../gcc-source-trunk/gcc/cp/parser.c:4366
0x7d7128 c_parse_file()
../../gcc-source-trunk/gcc/cp/parser.c:38406
0x93f2e2 c_common_parse_file()
../../gcc-source-trunk/gcc/c-family/c-opts.c:1107
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
$





struct A;
extern A a;
template < int > int f = a.x;

[Bug rtl-optimization/64081] [5/6/7 Regression] r217827 prevents RTL loop unroll

[segher at gcc dot gnu.org]

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

--- Comment #58 from Segher Boessenkool  ---
You can keep get_simple_loop_desc, find_simple_exit etc.; just make them
inline functions or similar.

I'm sceptical that this will not cause any more problems, we're deep into
stage 4 already :-/

[Bug c++/79301] With -Werror=pedantic outside C++17 mode, __has_cpp_attribute(fallthrough) is nonzero but [[fallthrough]] fails

[jason at gcc dot gnu.org]

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

--- Comment #7 from Jason Merrill  ---
(In reply to Jakub Jelinek from comment #4)
> That said, I think e.g. for maybe_unused or nodiscard attributes we don't
> complain with -pedantic about those attributes used in C++14 code, so either
> we should do that as well, or we shouldn't do that for fallthrough either.
> Jason?

We certainly don't want to both have __has_cpp_attribute(fallthrough) non-zero
and also complain about its usage.  My inclination would be to remove the
diagnostic.

[Bug fortran/79430] [7 Regression] action of statement incorrectly optimised away

[juergen.reuter at desy dot de]

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

--- Comment #13 from Jürgen Reuter  ---
(In reply to Steve Kargl from comment #12)
> On Wed, Feb 08, 2017 at 08:39:43PM +, juergen.reuter at desy dot de
> wrote:
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430
> > 
> > --- Comment #11 from Jürgen Reuter  ---
> > (In reply to Steve Kargl from comment #10)
> > > On Wed, Feb 08, 2017 at 07:32:53PM +, juergen.reuter at desy dot de
> > 
> > > which may lead to conforming code suddening becoming nonconforming
> > > due to violation of storage association.
> > 
> > Interesting. Actually, we are not setting any flags using configure options,
> > except for those that libtool sets for us as default (-g -O2).
> > In our code, we use everywhere variables defined as 
> > real(kind=default) :: foo
> > complex(kind=default) :: foo,
> > and then we use a module kinds.f90 with the definitions:
> >   !!! available REAL kinds   ! prec.  ! ISO ! C
> >   integer, parameter :: single=  4   !  1.. 6 ! real32  ! c_float  
> >   integer, parameter :: double=  8   !  7..15 ! real64  ! c_double 
> >   integer, parameter :: extended  = 10   ! 16..18 ! real128 ! c_long_double
> >   integer, parameter :: quadruple = 16   ! 19..33 ! -1  ! c_float128  
> > 
> > When configuring with no flag or --with-precision=double, then in this file
> > kind.f90 we 
> > set
> > 
> >   integer, parameter :: default   = double   
> > configuring with --with-precision=extended sets
> > integer, parameter :: default   = extended
> > and configuring with --with-precision=quadruple sets
> > integer, parameter :: default   = quadruple
> > 
> > The integers above are determined during configure, depending on the 
> > compiler,
> > and are always the same, only default is set depending on the configure 
> > option. 
> 
> The above should be fine.  This then suggests that you may have
> an unstable algorithm.  Are literal constants properly decolorated,
> e.g., 1.e0_default?  Are kind types included in REAL and CMPLX,
> e.g., real(1.e0, default) and cmplx(1, 2, default)?
> 
> Without a reduced testcase, it will be difficult to track down 
> the problem.
> 
> > Indeed, it looks as if kind=10 would be real128, but as you said this
> > is wrong and was fixed by you (I guess it is not yet in the trunk, as
> > of r245197 at least).
> 
> You need r245255 to get the fix.  There is, however, some discussion
> as to whether I should revert the change.

Ah ok. Why? Because it is too late for anything than regression fixes now? 
As far as we can seen all our constants have valid and consistent kind type.
Any try
to reduce the code, hasn't worked. Putting print statements there are trying to
pass
the corresponding routine to an output routine to access it without the heavy
machinery of the whole program let's the problem go away.

[Bug c++/79258] -Wduplicated-branches false positive?

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||msebor at gcc dot gnu.org
 Resolution|--- |INVALID

--- Comment #3 from Martin Sebor  ---
I'd say the warning is valid.  The two branches are necessarily the same and
there's no way to make them be different because Base::state() and
Derived::state() are one and the same function, regardless of what object
m_Derived points at.  This looks to me a good example of where the warning is
particularly useful.  Thus I resolve this report as invalid.

[Bug c++/79429] [6/7 Regression] ICE in add_stmt, at cp/semantics.c:385

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Known to work||5.3.0
   Keywords||ice-on-invalid-code
   Last reconfirmed||2017-02-08
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1
Summary|ICE in add_stmt, at |[6/7 Regression] ICE in
   |cp/semantics.c:385  |add_stmt, at
   ||cp/semantics.c:385
  Known to fail||6.1.0, 7.0

--- Comment #1 from Martin Sebor  ---
Confirmed.  Bisection points to r228777 (gcc 6.0.0):

r228777 | jakub | 2015-10-13 15:06:23 -0400 (Tue, 13 Oct 2015) | 1087 lines

The revision just prior to it rejects test case in z1.cc with:

z1.cc:1:19: error: expected declaration specifiers before end of line

[Bug tree-optimization/39612] [5/6/7 Regression] LIM inserts loads from uninitialized local memory

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com
   Target Milestone|5.5 |8.0

[Bug c/79431] [6/7 Regression] ICE in get, at cgraph.h:397

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-02-08
 CC||msebor at gcc dot gnu.org
Summary|ICE in get, at cgraph.h:397 |[6/7 Regression] ICE in
   ||get, at cgraph.h:397
 Ever confirmed|0   |1
  Known to fail||6.2.1, 7.0

--- Comment #1 from Martin Sebor  ---
Confirmed.  Bisection of the ICE points to r229814 (gcc 6.0.0):

r229814 | jakub | 2015-11-05 10:08:08 -0500 (Thu, 05 Nov 2015) | 429 lines

Assuming the code is valid the revision that it started to be rejected with is
r203408 (gcc 4.9.0):

r203408 | jakub | 2013-10-11 05:26:50 -0400 (Fri, 11 Oct 2013) | 1006 lines

[Bug fortran/79430] [7 Regression] action of statement incorrectly optimised away

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #12 from Steve Kargl  ---
On Wed, Feb 08, 2017 at 08:39:43PM +, juergen.reuter at desy dot de wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430
> 
> --- Comment #11 from Jürgen Reuter  ---
> (In reply to Steve Kargl from comment #10)
> > On Wed, Feb 08, 2017 at 07:32:53PM +, juergen.reuter at desy dot de
> 
> > which may lead to conforming code suddening becoming nonconforming
> > due to violation of storage association.
> 
> Interesting. Actually, we are not setting any flags using configure options,
> except for those that libtool sets for us as default (-g -O2).
> In our code, we use everywhere variables defined as 
> real(kind=default) :: foo
> complex(kind=default) :: foo,
> and then we use a module kinds.f90 with the definitions:
>   !!! available REAL kinds   ! prec.  ! ISO ! C
>   integer, parameter :: single=  4   !  1.. 6 ! real32  ! c_float  
>   integer, parameter :: double=  8   !  7..15 ! real64  ! c_double 
>   integer, parameter :: extended  = 10   ! 16..18 ! real128 ! c_long_double
>   integer, parameter :: quadruple = 16   ! 19..33 ! -1  ! c_float128  
> 
> When configuring with no flag or --with-precision=double, then in this file
> kind.f90 we 
> set
> 
>   integer, parameter :: default   = double   
> configuring with --with-precision=extended sets
> integer, parameter :: default   = extended
> and configuring with --with-precision=quadruple sets
> integer, parameter :: default   = quadruple
> 
> The integers above are determined during configure, depending on the compiler,
> and are always the same, only default is set depending on the configure 
> option. 

The above should be fine.  This then suggests that you may have
an unstable algorithm.  Are literal constants properly decolorated,
e.g., 1.e0_default?  Are kind types included in REAL and CMPLX,
e.g., real(1.e0, default) and cmplx(1, 2, default)?

Without a reduced testcase, it will be difficult to track down 
the problem.

> Indeed, it looks as if kind=10 would be real128, but as you said this
> is wrong and was fixed by you (I guess it is not yet in the trunk, as
> of r245197 at least).

You need r245255 to get the fix.  There is, however, some discussion
as to whether I should revert the change.

[Bug target/78604] [7 regression] test case gcc.target/powerpc/p8vector-vectorize-1.c fails starting with r242750

[pthaugen at gcc dot gnu.org]

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

Pat Haugen  changed:

   What|Removed |Added

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

--- Comment #9 from Pat Haugen  ---
Fixed.

[Bug target/78604] [7 regression] test case gcc.target/powerpc/p8vector-vectorize-1.c fails starting with r242750

[pthaugen at gcc dot gnu.org]

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

--- Comment #8 from Pat Haugen  ---
Author: pthaugen
Date: Wed Feb  8 20:49:14 2017
New Revision: 245285

URL: https://gcc.gnu.org/viewcvs?rev=245285=gcc=rev
Log:
PR target/78604
* config/rs6000/rs6000.c (rs6000_emit_vector_cond_expr): Invert
condition/operands for integer GE/LE/GEU/LEU operations.

* gcc.target/powerpc/pr78604.c: New.


Added:
trunk/gcc/testsuite/gcc.target/powerpc/pr78604.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/rs6000.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/79433] __has_include reports wrong result for std headers that #error on __cplusplus

[marc.mutz at kdab dot com]

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

--- Comment #5 from Marc Mutz  ---
Andrew, you're taking the easy way out. It might be that it works as
implemented, but that behaviour is useless.

Please explain how one should detect, in a portable way, whether string_view
and experimental::string_view is available, if not by headers check.

[Bug fortran/79430] [7 Regression] action of statement incorrectly optimised away

[juergen.reuter at desy dot de]

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

--- Comment #11 from Jürgen Reuter  ---
(In reply to Steve Kargl from comment #10)
> On Wed, Feb 08, 2017 at 07:32:53PM +, juergen.reuter at desy dot de

> which may lead to conforming code suddening becoming nonconforming
> due to violation of storage association.

Interesting. Actually, we are not setting any flags using configure options,
except for those that libtool sets for us as default (-g -O2).
In our code, we use everywhere variables defined as 
real(kind=default) :: foo
complex(kind=default) :: foo,
and then we use a module kinds.f90 with the definitions:
  !!! available REAL kinds   ! prec.  ! ISO ! C
  integer, parameter :: single=  4   !  1.. 6 ! real32  ! c_float  
  integer, parameter :: double=  8   !  7..15 ! real64  ! c_double 
  integer, parameter :: extended  = 10   ! 16..18 ! real128 ! c_long_double
  integer, parameter :: quadruple = 16   ! 19..33 ! -1  ! c_float128  

When configuring with no flag or --with-precision=double, then in this file
kind.f90 we 
set

  integer, parameter :: default   = double   
configuring with --with-precision=extended sets
integer, parameter :: default   = extended
and configuring with --with-precision=quadruple sets
integer, parameter :: default   = quadruple

The integers above are determined during configure, depending on the compiler,
and are always the same, only default is set depending on the configure option. 
Indeed, it looks as if kind=10 would be real128, but as you said this is wrong
and was
fixed by you (I guess it is not yet in the trunk, as of r245197 at least).
For ifort we get
  !!! available REAL kinds   ! prec.  ! ISO ! C
  integer, parameter :: single=  4   !  1.. 6 ! real32  ! c_float  
  integer, parameter :: double=  8   !  7..15 ! real64  ! c_double 
  integer, parameter :: quadruple = 16   ! 16..33 ! real128 ! c_long_double
and for NAG:
  !!! available REAL kinds   ! prec.  ! ISO ! C
  integer, parameter :: single=  1   !  1.. 6 ! real32  ! c_float  
  integer, parameter :: double=  2   !  7..15 ! real64  ! c_double 
  integer, parameter :: quadruple =  3   ! 16..31 ! real128 ! -1  
(with a different range then gfortran and ifort)
and for PGF
  !!! available REAL kinds   ! prec.  ! ISO ! C
  integer, parameter :: single=  4   !  1.. 6 ! real32  ! c_float  
  integer, parameter :: double=  8   !  7..15 ! real64  ! c_double

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

[Bader at lrz dot de]

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

Bug ID: 79434
   Summary: [submodules] separate module procedure breaks
encapsulation
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Bader at lrz dot de
  Target Milestone: ---

Created attachment 40698
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40698=edit
test case

The attached code (a much simplified version of a bug report on the Intel
software forums) illustrate that the current submodule implementation does not
respect type component encapsulation.

[Bug rtl-optimization/64081] [5/6/7 Regression] r217827 prevents RTL loop unroll

[aldyh at gcc dot gnu.org]

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

--- Comment #57 from Aldy Hernandez  ---
Created attachment 40697
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40697=edit
untested patch possibly solving AIX bootstrap

Taking in Jeff and Segher's suggestions, I propose something like the following
untested patch.  With it we unroll in the original testcase in this PR, while
avoiding the doloop unrolling in the AIX fiasco.

The loop exit check needed by this PR (get_loop_location) is set permissively,
while all the other ones in loop-unroll.c and loop-doloop.c are set
conservatively.  Presumably we can expand the permissiveness at a later date.

This is untested apart from checking that the original PR testcase still
unrolls, while AIX does not generate the CTR instructions.

If this is an acceptable approach, I can adjust all the relevant function
comments, plus update the doc/loop.texi documentation.  And yes, this patch is
on top of the original one, which presumably was already approved at some point
(but reverted).

Testing would involve AIX with the ancient toolchain patched/kludged up, plus
Linux + AIX with trunk.

[Bug fortran/79430] [7 Regression] action of statement incorrectly optimised away

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #10 from Steve Kargl  ---
On Wed, Feb 08, 2017 at 07:32:53PM +, juergen.reuter at desy dot de wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430
> 
> --- Comment #8 from Jürgen Reuter  ---
> We are defining a real(default) which could be 4, 8, 10 or 16, as these are 
> the
> real kinds supported by gfortran. If default = 10, this happens, but this is
> not per se forbidden, is it?
> 

I don't know.  Spent 15-20 minutes looking through the whizard
svn repository, but can't find what --with-precision=extended
actually does.  I assume that this is causing compiler options
to be set.

program foo

   use iso_fortran_env

   implicit none

   character(len=20), parameter :: fmt = '(I2,1X,I3,1X,I2)'

   real(real_kinds(1)) a
   real(real_kinds(2)) b
   real(real_kinds(3)) c
   real(real_kinds(4)) d
   real(real32) e
   real(real64) f
   real(real128) g

   write(*,fmt) kind(a), digits(a), precision(a)
   write(*,fmt) kind(b), digits(b), precision(b)
   write(*,fmt) kind(c), digits(c), precision(c)
   write(*,fmt) kind(d), digits(d), precision(d)
   write(*,*)
   write(*,fmt) kind(e), digits(e), precision(e)
   write(*,fmt) kind(f), digits(f), precision(f)
   write(*,fmt) kind(g), digits(g), precision(g)

end program foo

With trunk on x86_64-*-freebsd with my patch to fix REAL128,

% gfc7 -o z a.f90 && ./z
 4  24  6
 8  53 15
10  64 18
16 113 33

 4  24  6
 8  53 15
16 113 33

With gfortran 6.3.0 on x86_64-*-freebsd without my patch to fix REAL128

% gfortran6 -static -o z a.f90 && ./z
 4  24  6
 8  53 15
10  64 18
16 113 33

 4  24  6
 8  53 15
10  64 18

If --with-precision=extended is setting -freal-4-real-10, you get

%  gfc7 -o z a.f90 -freal-4-real-10 && ./z
10  64 18
 8  53 15
10  64 18
16 113 33

10  64 18
 8  53 15
16 113 33

which may lead to conforming code suddening becoming nonconforming
due to violation of storage association.

[Bug tree-optimization/46639] [5/6 Regression] Missing optimization due to function splitting and redundant conditionals

[ctice at gcc dot gnu.org]

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

--- Comment #20 from ctice at gcc dot gnu.org ---
Author: ctice
Date: Wed Feb  8 19:55:28 2017
New Revision: 245284

URL: https://gcc.gnu.org/viewcvs?rev=245284=gcc=rev
Log:
2017-02-08  Caroline Tice 

Fix PR 46639
in gcc:
* passes.def: Add pass_early_vrp; move pass_profile to before new pass.
* tree-pass.h: Add extern decl for make_pass_early_vrp.
* tree-vrp.c: New file global variable, is_early_vrp (boolean).
(extract_range_basic):  Add test for is_early_vrp before updating
built-in constants -- don't update during early_vrp pass.
(check_array_ref): Retrn immediately if is_early_vrp is true.
(execute_vrp): Add boolean parameter to indicate early pass or not;
set is_early_pass to value of parameter.
(pass_data_early_vrp): New pass_data struct.
(pass_vrp::execute): Call execute_vrp with false -- not early pass.
(class pass_early_vrp): New gimple_opt_pass class.
(make_pass_early_vrp): New function.

in testsuite:

* testsuite/gcc.dg/tree-prof/lipo/val-prof-5_0.c: xfail test.  It is
no longer a correct test with the new pass.
* testsuite/gcc.dg/tree-prof/val-prof-5.c: Ditto.
* testsuite/gcc.dg/tree-ssa/20030709-2.c: Change test to reflect new
(correct) code due to patch changes.
* testsuite/gcc.dg/tree-ssa/20040305-1.c: Ditto.
* testsuite/gcc.dg/tree-ssa/pr20702.c: Ditto.
* testsuite/gcc.dg/tree-ssa/pr21086.c: Ditto.
* testsuite/gcc.dg/tree-ssa/vrp02.c: Ditto.
* testsuite/gcc.dg/tree-ssa/vrp07.c: Ditto.
* testsuite/gcc.dg/tree-ssa/vrp08.c: Ditto.
* testsuite/gcc.dg/tree-ssa/vrp55.c: Ditto.
* testsuite/gcc.dg/vect/slp-perm-7.c: Ditto.
* testsuite/gcc.dg/fold-compare-2.c: Update to scan correct pass.
* testsuite/gcc.dg/tree-ssa/pr20318.c: Ditto.
* testsuite/gcc.dg/tree-ssa/pr20657.c: Ditto.
* testsuite/gcc.dg/tree-ssa/pr21001.c: Ditto.
* testsuite/gcc.dg/tree-ssa/pr21090.c: Ditto.
* testsuite/gcc.dg/tree-ssa/pr21294.c: Ditto.
* testsuite/gcc.dg/tree-ssa/pr21458.c: Ditto.
* testsuite/gcc.dg/tree-ssa/pr21559.c: Ditto.
* testsuite/gcc.dg/tree-ssa/pr21563.c: Ditto.
* testsuite/gcc.dg/tree-ssa/pr22117.c: Ditto.
* testsuite/gcc.dg/tree-ssa/pr23744.c: Ditto.
* testsuite/gcc.dg/tree-ssa/pr25382.c: Ditto.
* testsuite/gcc.dg/tree-ssa/pr37508.c: Ditto.
* testsuite/gcc.dg/tree-ssa/pr49039.c: Ditto.
* testsuite/gcc.dg/tree-ssa/pr58480.c: Ditto.
* testsuite/gcc.dg/tree-ssa/pr59597.c: Ditto.
* testsuite/gcc.dg/tree-ssa/ssa-dom-thread-2.c: Ditto.
* testsuite/gcc.dg/tree-ssa/ssa-vrp-thread-1.c: Ditto.
* testsuite/gcc.dg/tree-ssa/vrp01.c: Ditto.
* testsuite/gcc.dg/tree-ssa/vrp03.c: Ditto.
* testsuite/gcc.dg/tree-ssa/vrp04.c: Ditto.
* testsuite/gcc.dg/tree-ssa/vrp06.c: Ditto.
* testsuite/gcc.dg/tree-ssa/vrp09.c: Ditto.
* testsuite/gcc.dg/tree-ssa/vrp16.c: Ditto.
* testsuite/gcc.dg/tree-ssa/vrp17.c: Ditto.
* testsuite/gcc.dg/tree-ssa/vrp18.c: Ditto.
* testsuite/gcc.dg/tree-ssa/vrp19.c: Ditto.
* testsuite/gcc.dg/tree-ssa/vrp20.c: Ditto.
* testsuite/gcc.dg/tree-ssa/vrp23.c: Ditto.
* testsuite/gcc.dg/tree-ssa/vrp24.c: Ditto.
* testsuite/gcc.dg/tree-ssa/vrp25.c: Ditto.
* testsuite/gcc.dg/tree-ssa/vrp33.c: Ditto.
* testsuite/gcc.dg/tree-ssa/vrp34.c: Ditto.
* testsuite/gcc.dg/tree-ssa/vrp46.c: Ditto.
* testsuite/gcc.dg/tree-ssa/vrp56.c: Ditto.
* testsuite/gcc.dg/tree-ssa/vrp58.c: Ditto.
* testsuite/gcc.dg/tree-ssa/vrp67.c: Ditto.
* testsuite/gcc.dg/tree-ssa/vrp87.c: Ditto.


Modified:
branches/google/gcc-4_9-mobile/gcc/passes.def
branches/google/gcc-4_9-mobile/gcc/testsuite/gcc.dg/fold-compare-2.c
   
branches/google/gcc-4_9-mobile/gcc/testsuite/gcc.dg/tree-prof/lipo/val-prof-5_0.c
branches/google/gcc-4_9-mobile/gcc/testsuite/gcc.dg/tree-prof/val-prof-5.c
branches/google/gcc-4_9-mobile/gcc/testsuite/gcc.dg/tree-ssa/20030709-2.c
branches/google/gcc-4_9-mobile/gcc/testsuite/gcc.dg/tree-ssa/20040305-1.c
branches/google/gcc-4_9-mobile/gcc/testsuite/gcc.dg/tree-ssa/pr20318.c
branches/google/gcc-4_9-mobile/gcc/testsuite/gcc.dg/tree-ssa/pr20657.c
branches/google/gcc-4_9-mobile/gcc/testsuite/gcc.dg/tree-ssa/pr20702.c
branches/google/gcc-4_9-mobile/gcc/testsuite/gcc.dg/tree-ssa/pr21001.c
branches/google/gcc-4_9-mobile/gcc/testsuite/gcc.dg/tree-ssa/pr21086.c
branches/google/gcc-4_9-mobile/gcc/testsuite/gcc.dg/tree-ssa/pr21090.c
branches/google/gcc-4_9-mobile/gcc/testsuite/gcc.dg/tree-ssa/pr21294.c
branches/google/gcc-4_9-mobile/gcc/testsuite/gcc.dg/tree-ssa/pr21458.c

[Bug fortran/79430] [7 Regression] action of statement incorrectly optimised away

[juergen.reuter at desy dot de]

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

--- Comment #9 from Jürgen Reuter  ---
(In reply to kargl from comment #7)
> (In reply to Jürgen Reuter from comment #6)
> > (In reply to Dominique d'Humieres from comment #5)
> > > What does --with-precision=extended?
> > 
> > It sets the default precision of real and complex floats (kind type
> > parameter) to 80 bit instead of 64 bit (double) or 128bit (quadruple)
> > precision according to:
> > 
> >   !!! available REAL kinds   ! prec.  ! ISO ! C
> >   integer, parameter :: single=  4   !  1.. 6 ! real32  ! c_float  
> >   integer, parameter :: double=  8   !  7..15 ! real64  ! c_double 
> >   integer, parameter :: extended  = 10   ! 16..18 ! real128 ! c_long_double
> >   integer, parameter :: quadruple = 16   ! 19..33 ! -1  ! c_float128 
> > 
> >   integer, parameter :: default   = extended
> 
> Your use of terminology is unclear.  The default real type in
> Fortran is REAL.  Real has a default real kind type value of 4.
> This means that REAL == REAL(4), which is 32 bits.  If you are
> using some configure magic to map REAL to REAL(10), your version
> of gfortran is too broken to save.
> 
> Also note, I just fixed gfortran so that your table above is wrong.
> If the four real types with kind = 4, 8, 10, and 16 are available.
> Then the mapping is REAL(4) == REAL32, REAL(8) == REAL64, and 
> REAL(16) == REAL128.  
> 
> If a clever user messes up what default precision means, then
> that clever user gets what they deserve.


see my comment #8.

[Bug fortran/79430] [7 Regression] action of statement incorrectly optimised away

[juergen.reuter at desy dot de]

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

--- Comment #8 from Jürgen Reuter  ---
We are defining a real(default) which could be 4, 8, 10 or 16, as these are the
real kinds supported by gfortran. If default = 10, this happens, but this is
not per se forbidden, is it?

[Bug c++/79433] __has_include reports wrong result for std headers that #error on __cplusplus

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #4 from Andrew Pinski  ---
.

[Bug c++/79433] __has_include reports wrong result for std headers that #error on __cplusplus

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski  ---
__has_include just says the include exists and not if the include file works.

[Bug c++/79301] With -Werror=pedantic outside C++17 mode, __has_cpp_attribute(fallthrough) is nonzero but [[fallthrough]] fails

[msebor at gcc dot gnu.org]

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

--- Comment #6 from Martin Sebor  ---
The (__has_cpp_attribute(fallthrough) >= __cplusplus) test doesn't help because
the built-in evaluates to 201603 (in all conformance modes) and __cplusplus to
at most 201500L (in C++ 17 mode), so it's as good as the original test alone.

It might be worth to bring this up in the WG21 Feature Test study group (SG10)
to make sure the interplay between pedantic conformance warnings (and errors)
and the feature test macros has been given adequate consideration.  The
__has_cpp_attribute example in the latest draft is basically a copy of the test
case in comment #0.

[Bug c++/79433] __has_include reports wrong result for std headers that #error on __cplusplus

[marc.mutz at kdab dot com]

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

--- Comment #2 from Marc Mutz  ---
Ok, there is __cpp_lib_experimental_string_view, at least, but it's defined ...
wait for it ... in , which you can't include.

[Bug testsuite/79427] g++.dg/tls/thread_local-order2.C fails starting with r245249

[seurer at gcc dot gnu.org]

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

--- Comment #2 from seurer at gcc dot gnu.org ---
I checked and on the first system where I noticed this glibc is the distro
(Ubuntu 14.04) default 2.17.  Other Be systems where it also failed are that or
older.

[Bug c++/79433] __has_include reports wrong result for std headers that #error on __cplusplus

[marc.mutz at kdab dot com]

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

--- Comment #1 from Marc Mutz  ---
And no, checking __cplusplus in addition is not an option, since many
compilers, GCC included (__cplusplus==1, remember?), do not necessarily bump
__cplusplus when they implement enough core features to make something like
string_view (which can be implemented in C++11 just fine) work.

[Bug testsuite/79427] g++.dg/tls/thread_local-order2.C fails starting with r245249

[segher at gcc dot gnu.org]

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

--- Comment #1 from Segher Boessenkool  ---
I get the correct output on BE (gcc110).  This is glibc 2.18, maybe
that is the difference?

[Bug c++/79433] New: __has_include reports wrong result headers that #error on __cplusplus

[marc.mutz at kdab dot com]

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

Bug ID: 79433
   Summary: __has_include reports wrong result headers that #error
on __cplusplus
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marc.mutz at kdab dot com
  Target Milestone: ---

Code that attempts to detect, say, string_view support by
__has_include() or __has_include() and
then attempts to #include those headers is greeted with an #error that these
headers require C++17 and C++14, resp.

Since there's no SG-10 SD-6 feature test macro for string_view, this means that
no portable way of detecting string_view support is possible.

Expected behaviour: __has_include should behave consistent with the header's
#error mechanism.

[Bug rtl-optimization/64081] [5/6/7 Regression] r217827 prevents RTL loop unroll

[segher at gcc dot gnu.org]

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

--- Comment #56 from Segher Boessenkool  ---
Yes, and a function that computes a "more permissive" version should
not have "simple_loop" in its name, it is very misleading.  Reusing
existing functions to do something different may seem attractive at
first ("less churn") but is more expensive in the long run; we have
spent more time on this PR alone than doing things properly would have
taken in the first place.

[Bug c/79432] [Regression 7] ICE: verify_ssa failed

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

   Keywords||ice-checking
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-02-08
 CC||dmalcolm at gcc dot gnu.org
Summary|ICE: verify_ssa failed  |[Regression 7] ICE:
   ||verify_ssa failed
 Ever confirmed|0   |1

--- Comment #1 from David Malcolm  ---
Thanks for filing this bug.

Appears to still affect trunk; bisecting shows ICE starts with r235817.

[Bug fortran/79430] [7 Regression] action of statement incorrectly optimised away

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #7 from kargl at gcc dot gnu.org ---
(In reply to Jürgen Reuter from comment #6)
> (In reply to Dominique d'Humieres from comment #5)
> > What does --with-precision=extended?
> 
> It sets the default precision of real and complex floats (kind type
> parameter) to 80 bit instead of 64 bit (double) or 128bit (quadruple)
> precision according to:
> 
>   !!! available REAL kinds   ! prec.  ! ISO ! C
>   integer, parameter :: single=  4   !  1.. 6 ! real32  ! c_float  
>   integer, parameter :: double=  8   !  7..15 ! real64  ! c_double 
>   integer, parameter :: extended  = 10   ! 16..18 ! real128 ! c_long_double
>   integer, parameter :: quadruple = 16   ! 19..33 ! -1  ! c_float128 
> 
>   integer, parameter :: default   = extended

Your use of terminology is unclear.  The default real type in
Fortran is REAL.  Real has a default real kind type value of 4.
This means that REAL == REAL(4), which is 32 bits.  If you are
using some configure magic to map REAL to REAL(10), your version
of gfortran is too broken to save.

Also note, I just fixed gfortran so that your table above is wrong.
If the four real types with kind = 4, 8, 10, and 16 are available.
Then the mapping is REAL(4) == REAL32, REAL(8) == REAL64, and 
REAL(16) == REAL128.  

If a clever user messes up what default precision means, then
that clever user gets what they deserve.

[Bug c/79428] [6/7 Regression] ICE in c_parser_consume_token, at c/c-parser.c:770

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Keywords||error-recovery,
   ||ice-on-invalid-code
   Target Milestone|--- |6.5
Summary|ICE in  |[6/7 Regression] ICE in
   |c_parser_consume_token, at  |c_parser_consume_token, at
   |c/c-parser.c:770|c/c-parser.c:770

--- Comment #4 from Marek Polacek  ---
Started with r228777.

[Bug fortran/79430] [7 Regression] action of statement incorrectly optimised away

[juergen.reuter at desy dot de]

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

--- Comment #6 from Jürgen Reuter  ---
(In reply to Dominique d'Humieres from comment #5)
> What does --with-precision=extended?

It sets the default precision of real and complex floats (kind type parameter)
to 80 bit instead of 64 bit (double) or 128bit (quadruple) precision according
to:

  !!! available REAL kinds   ! prec.  ! ISO ! C
  integer, parameter :: single=  4   !  1.. 6 ! real32  ! c_float  
  integer, parameter :: double=  8   !  7..15 ! real64  ! c_double 
  integer, parameter :: extended  = 10   ! 16..18 ! real128 ! c_long_double
  integer, parameter :: quadruple = 16   ! 19..33 ! -1  ! c_float128 

  integer, parameter :: default   = extended

[Bug c/79428] ICE in c_parser_consume_token, at c/c-parser.c:770

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #3 from Marek Polacek  ---
It works for the testcase.  Let me see if I can handle this.

[Bug c/79428] ICE in c_parser_consume_token, at c/c-parser.c:770

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
If that works, we probably need to adjust all the other spots that do this +
construct testcases that test that.

[Bug fortran/79430] [7 Regression] action of statement incorrectly optimised away

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-02-08
 Ever confirmed|0   |1

--- Comment #5 from Dominique d'Humieres  ---
What does --with-precision=extended?

[Bug fortran/79430] [7 Regression] action of statement incorrectly optimised away

[juergen.reuter at desy dot de]

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

--- Comment #4 from Jürgen Reuter  ---
(In reply to Andrew Pinski from comment #3)
> (In reply to Jürgen Reuter from comment #2)
> > (In reply to Andrew Pinski from comment #1)
> > > What target is this on?
> > 
> > We reproduced it under MAC OS X as well as under Ubuntu Linux 14.04 and
> > Scientific Linux 6.8. x86_64.
> 
> Have you tried any non x86_64 targets?

No, we haven't any 32bit machines left.

[Bug c/79428] ICE in c_parser_consume_token, at c/c-parser.c:770

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-02-08
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Confirmed.

We hit this:
770   gcc_assert (!parser->in_pragma || parser->tokens[0].type !=
CPP_PRAGMA_EOL);
because
  173   /* True if we're processing a pragma, and shouldn't automatically
  174  consume CPP_PRAGMA_EOL.  */
  175   BOOL_BITFIELD in_pragma : 1;

So maybe just
--- a/gcc/c/c-parser.c
+++ b/gcc/c/c-parser.c
@@ -15460,7 +15460,7 @@ c_parser_omp_ordered (c_parser *parser, enum
pragma_context context,
   if (context != pragma_stmt && context != pragma_compound)
 {
   c_parser_error (parser, "expected declaration specifiers");
-  c_parser_skip_until_found (parser, CPP_PRAGMA_EOL, NULL);
+  c_parser_skip_to_pragma_eol (parser, false);
   return false;
 }

[Bug fortran/79417] -Wconversion warns wrongly of real(16) to real(8)

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #1 from Dominique d'Humieres  ---
If I replace the lines

  integer,parameter:: qp = selected_real_kind(30), dp = kind(1d0)
  real(qp),parameter:: q1 = 1, q23(1) = 2*q1/3

with

  real(qp),parameter:: q1(1) = 1, q23(1) = 2*q1/3
  real(dp),parameter:: d1 = 1, d23(1) = real(2*q1(1)/3,dp)

I get

   real(dp),parameter:: d1 = 1, d23(1) = real(2*q1(1)/3,dp)
 1
Warning: Change of value in conversion from 'REAL(16)' to 'REAL(8)' at (1)
[-Wconversion]

I don't get any warning with gfortran 5.4.0.

[Bug fortran/79430] [7 Regression] action of statement incorrectly optimised away

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Target||x86_64-*-*

--- Comment #3 from Andrew Pinski  ---
(In reply to Jürgen Reuter from comment #2)
> (In reply to Andrew Pinski from comment #1)
> > What target is this on?
> 
> We reproduced it under MAC OS X as well as under Ubuntu Linux 14.04 and
> Scientific Linux 6.8. x86_64.

Have you tried any non x86_64 targets?

[Bug fortran/79430] [7 Regression] action of statement incorrectly optimised away

[juergen.reuter at desy dot de]

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

--- Comment #2 from Jürgen Reuter  ---
(In reply to Andrew Pinski from comment #1)
> What target is this on?

We reproduced it under MAC OS X as well as under Ubuntu Linux 14.04 and
Scientific Linux 6.8. x86_64.

[Bug tree-optimization/68823] [6/7 Regression][graphite] tramp3d-v4 compiled with -floop-nest-optimize crashes

[spop at gcc dot gnu.org]

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

--- Comment #11 from Sebastian Pop  ---
(In reply to Richard Biener from comment #10)
> But then with different number of subscripts (and also likely different
> DR_BASE_OBJECT) you can't do anything with them and have to assume
> dependence.  See initialize_data_dependence_relation:
> 
>   /* If the references do not access the same object, we do not know
>  whether they alias or not.  We do not care about TBAA or alignment
>  info so we can use OEP_ADDRESS_OF to avoid false negatives.
>  But the accesses have to use compatible types as otherwise the
>  built indices would not match.  */
>   if (!operand_equal_p (DR_BASE_OBJECT (a), DR_BASE_OBJECT (b),
> OEP_ADDRESS_OF)
>   || !types_compatible_p (TREE_TYPE (DR_BASE_OBJECT (a)),
>   TREE_TYPE (DR_BASE_OBJECT (b
> {
>   DDR_ARE_DEPENDENT (res) = chrec_dont_know;
>   return res;
> 
> not sure how you communicate that to ISL of course...  is it what you
> use "alias-sets" for?  To create extra dependence egdes?

alias-sets differ for two arrays with bases that have been proven to be
different.
If they may point to the same thing, they will have the same number.

[Bug fortran/79430] [7 Regression] action of statement incorrectly optimised away

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
What target is this on?

[Bug testsuite/68972] g++.dg/cpp1y/vla-initlist1.C test case fails on powerpc64le

[kelvin at gcc dot gnu.org]

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

--- Comment #12 from kelvin at gcc dot gnu.org ---
Author: kelvin
Date: Wed Feb  8 17:33:57 2017
New Revision: 245280

URL: https://gcc.gnu.org/viewcvs?rev=245280=gcc=rev
Log:
gcc/testsuite/ChangeLog:

2017-02-08  Kelvin Nilsen  

PR target/68972
* g++.dg/cpp1y/vla-initlist1.C: Add dg-skip-if directive to
disable this test on power architecture.


Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/cpp1y/vla-initlist1.C

[Bug c++/79387] Internal compiler error in convert_nontype_argument

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-02-08
 Ever confirmed|0   |1
  Known to fail||6.2.1

--- Comment #1 from Georg-Johann Lay  ---
Confirmed with avr-g++-6 from today (gcc-6-branch HEAD) and avr-g++-7 (trunk
HEAD).

../../gcc.gnu.org/trunk/configure --target=avr
--prefix=/local/gnu/install/gcc-7 --disable-shared --disable-nls --with-dwarf2
--enable-target-optspace=yes --with-gnu-as --with-gnu-ld target_alias=avr
--enable-checking=release --enable-languages=c,c++,lto

[Bug fortran/79426] [5/6/7 Regression] fortran - internal compiler error: in fold_convert_loc, at fold-const.c:2251

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 CC||janus at gcc dot gnu.org,
   ||vehre at gcc dot gnu.org
  Known to work||4.8.5
Summary|fortran - internal compiler |[5/6/7 Regression] fortran
   |error: in fold_convert_loc, |- internal compiler error:
   |at fold-const.c:2251|in fold_convert_loc, at
   ||fold-const.c:2251
  Known to fail||4.9.3, 5.4.0, 6.3.0, 7.0.1

--- Comment #2 from Dominique d'Humieres  ---
The test compiles with gfortran 4.8.5. The change occurred between revisions
r219823 (2015-01-18, compiles and executes) and r219830 (2015-01-19, ICE),
likely r219827 (pr60255) for gcc5 and r221591 for gcc4.9.

[Bug c/79432] New: ICE: verify_ssa failed

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

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

Bug ID: 79432
   Summary: ICE: verify_ssa failed
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gerhard.steinmetz.fort...@t-online.de
  Target Milestone: ---

Seen with version 7 only, on x86_64 GNU/Linux.
(not depending on any options)


$ cat z1.c
int fn1 (void);
int vfork (void);
void fn2 ()
{
  int a;
  a = fn1() + vfork();
}


$ gcc-6 -c z1.c
$ gcc-7-20170205 -c z1.c
z1.c: In function 'fn2':
z1.c:7:1: error: definition in block 3 does not dominate use in block 6
 }
 ^
for SSA_NAME: _1 in statement:
a_10 = _1 + _2;
z1.c:7:1: internal compiler error: verify_ssa failed
0xe10883 verify_ssa(bool, bool)
../../gcc/tree-ssa.c:1184
0xb167fd execute_function_todo
../../gcc/passes.c:1973
0xb170e5 execute_todo
../../gcc/passes.c:2016

[Bug c/79431] New: ICE in get, at cgraph.h:397

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

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

Bug ID: 79431
   Summary: ICE in get, at cgraph.h:397
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gerhard.steinmetz.fort...@t-online.de
  Target Milestone: ---

Affects versions 6 and 7 (configured with --enable-checking=yes) :
(compiles with "static int a")


$ cat z1.c
void fn1 ()
{
  int a;
  #pragma omp declare target (a)
}


$ gcc-6 -fopenmp -c z1.c   # official release 6.3.1 20170131
$
$ gcc-7-20170205 -fopenmp -c z1.c
z1.c: In function 'fn1':
z1.c:4:11: internal compiler error: in get, at cgraph.h:397
   #pragma omp declare target (a)
   ^~~
0x6d14d9 symtab_node::get(tree_node const*)
../../gcc/cgraph.h:394
0x6d14d9 c_parser_omp_declare_target
../../gcc/c/c-parser.c:16850
0x6d14d9 c_parser_omp_declare
../../gcc/c/c-parser.c:17290
0x6b406b c_parser_pragma
../../gcc/c/c-parser.c:10313
0x6d3f0e c_parser_compound_statement_nostart
../../gcc/c/c-parser.c:4875
0x6d44ce c_parser_compound_statement
../../gcc/c/c-parser.c:4740
0x6cf90c c_parser_declaration_or_fndef
../../gcc/c/c-parser.c:2112
0x6d791b c_parser_external_declaration
../../gcc/c/c-parser.c:1468
0x6d8379 c_parser_translation_unit
../../gcc/c/c-parser.c:1348
0x6d8379 c_parse_file()
../../gcc/c/c-parser.c:18185
0x736892 c_common_parse_file()
../../gcc/c-family/c-opts.c:1107

[Bug fortran/79430] New: [7 Regression] action of statement incorrectly optimised away

[juergen.reuter at desy dot de]

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

Bug ID: 79430
   Summary: [7 Regression] action of statement incorrectly
optimised away
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: juergen.reuter at desy dot de
  Target Milestone: ---

Unfortunately this is only in a very large test case at the moment, which needs
both gfortran and OCaml, using: 
http://whizard.hepforge.org/versions/unofficial/whizard-2.4.1_alpha-20170131.tar.gz
and configuring with ./configure --with-precision=extended
Then make and make check. In the test suite, the functional test
mlm_matching_isr
will show a discrepancy coming from the fact that in the function
integral_over_z_isr 
in shower_core.f90 the if clause after 'call integral_over_z_part_isr', namely
if (integral > final) then
  return
end if 
is not correctly executed, either optimised away or scrambled. 
Funnily, this happens only if the default precision for real types is set to
extended precision, for double and quadruple precision it works as in previous
gfortran versions. 
The attempt to reduce this case made this behaviour disappear.

[Bug c++/79429] New: ICE in add_stmt, at cp/semantics.c:385

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

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

Bug ID: 79429
   Summary: ICE in add_stmt, at cp/semantics.c:385
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gerhard.steinmetz.fort...@t-online.de
  Target Milestone: ---

Affects versions 6 and 7 (configured with --enable-checking=yes).
Issue similar to that from pr79428.


$ cat z1.cc
#pragma omp target


$ cat z2.cc
#pragma omp ordered


$ g++-5 -fopenmp -c z1.cc
z1.cc:1:19: error: expected declaration specifiers before end of line
$
$
$ g++-7-20170205 -fopenmp -c z1.cc
z1.cc:1:19: error: expected declaration specifiers before end of line
 #pragma omp target
   ^
z1.cc:1:19: internal compiler error: in add_stmt, at cp/semantics.c:385
0x8213ab add_stmt(tree_node*)
../../gcc/cp/semantics.c:385
0x834fdb pop_omp_privatization_clauses(tree_node*)
../../gcc/cp/semantics.c:7424
0x79a9ac cp_parser_pragma
../../gcc/cp/parser.c:38256
0x7c6b9b cp_parser_declaration_seq_opt
../../gcc/cp/parser.c:12362
0x7c6e58 cp_parser_translation_unit
../../gcc/cp/parser.c:4366
0x7c6e58 c_parse_file()
../../gcc/cp/parser.c:38382
0x9292b2 c_common_parse_file()
../../gcc/c-family/c-opts.c:1107

[Bug c++/79420] [7 Regression] ICE on invalid C++ code on x86_64-linux-gnu: in tsubst_copy, at cp/pt.c:14573

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-02-08
 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Started with r245223.

[Bug c/79428] New: ICE in c_parser_consume_token, at c/c-parser.c:770

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

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

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

Affects versions 6 and 7 (configured with --enable-checking=yes) :


$ cat z1.c
#pragma omp ordered


$ gcc-5 -fopenmp -c z1.c
z1.c:1:9: error: expected declaration specifiers before '#pragma'
 #pragma omp ordered
 ^
$
$ gcc-7-20170205 -fopenmp -c z1.c
z1.c:1:20: error: expected declaration specifiers before end of line
 #pragma omp ordered
^
z1.c:1:20: internal compiler error: in c_parser_consume_token, at
c/c-parser.c:770
0x6ac0d8 c_parser_consume_token(c_parser*)
../../gcc/c/c-parser.c:770
0x6ad0ea c_parser_require(c_parser*, cpp_ttype, char const*)
../../gcc/c/c-parser.c:908
0x6ad20e c_parser_skip_until_found(c_parser*, cpp_ttype, char const*)
../../gcc/c/c-parser.c:951
0x6b47e1 c_parser_omp_ordered
../../gcc/c/c-parser.c:15463
0x6b47e1 c_parser_pragma
../../gcc/c/c-parser.c:10317
0x6d78cd c_parser_external_declaration
../../gcc/c/c-parser.c:1448
0x6d8379 c_parser_translation_unit
../../gcc/c/c-parser.c:1348
0x6d8379 c_parse_file()
../../gcc/c/c-parser.c:18185
0x736892 c_common_parse_file()
../../gcc/c-family/c-opts.c:1107

[Bug c++/79414] [7 Regression] internal compiler error after "error: expected unqualified-id at end of input"

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Started with r245223.

[Bug middle-end/60085] ICE in get_frame_type on weird code

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

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

--- Comment #4 from Gerhard Steinmetz  
---
Another variant (invalid) :

$ cat z1.c
void fn1 ()
{
void fnx ()
  int n;
  int a[n];
}


$ gcc-7-20170205 -c z1.c
z1.c: In function 'fnx':
z1.c:6:1: error: expected declaration specifiers before '}' token
 }
 ^
z1.c:5:7: error: declaration for parameter 'a' but no such parameter
   int a[n];
   ^
z1.c:4:7: error: declaration for parameter 'n' but no such parameter
   int n;
   ^
z1.c:6:1: error: expected '{' at end of input
 }
 ^
z1.c: In function 'fn1':
z1.c:6:1: error: expected declaration or statement at end of input
z1.c:1:6: internal compiler error: Segmentation fault
 void fn1 ()
  ^~~
0xbf633f crash_signal
../../gcc/toplev.c:333
0xc9053a get_frame_type
../../gcc/tree-nested.c:211
0xc9053a get_chain_decl
../../gcc/tree-nested.c:317
0xc93d89 get_chain_decl
../../gcc/tree-nested.c:909
0xc93d89 get_nonlocal_debug_decl
../../gcc/tree-nested.c:913
0xc94138 convert_nonlocal_reference_op
../../gcc/tree-nested.c:992
0xec walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*, tree_node*
(*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*), void*,
hash_set >*))
../../gcc/tree.c:11796
0x9649e0 walk_gimple_op(gimple*, tree_node* (*)(tree_node**, int*, void*),
walk_stmt_info*)
../../gcc/gimple-walk.c:203
0x964f5c walk_gimple_stmt(gimple_stmt_iterator*, tree_node*
(*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**,
int*, void*), walk_stmt_info*)
../../gcc/gimple-walk.c:586
0x965148 walk_gimple_seq_mod(gimple**, tree_node* (*)(gimple_stmt_iterator*,
bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*),
walk_stmt_info*)
../../gcc/gimple-walk.c:51
0x965002 walk_gimple_stmt(gimple_stmt_iterator*, tree_node*
(*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**,
int*, void*), walk_stmt_info*)
../../gcc/gimple-walk.c:596
0x965148 walk_gimple_seq_mod(gimple**, tree_node* (*)(gimple_stmt_iterator*,
bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*),
walk_stmt_info*)
../../gcc/gimple-walk.c:51
0xc8ff41 walk_body
../../gcc/tree-nested.c:656
0xc8ff98 walk_function
../../gcc/tree-nested.c:667
0xc8ff98 walk_all_functions
../../gcc/tree-nested.c:732
0xc98c32 lower_nested_functions(tree_node*)
../../gcc/tree-nested.c:3345
0x7f1670 cgraph_node::analyze()
../../gcc/cgraphunit.c:661
0x7f4ce3 analyze_functions
../../gcc/cgraphunit.c:1116
0x7f5a3a symbol_table::finalize_compilation_unit()
../../gcc/cgraphunit.c:2597

[Bug middle-end/60085] ICE in get_frame_type on weird code

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

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

Gerhard Steinmetz  changed:

   What|Removed |Added

 CC||gerhard.steinmetz.fortran@t
   ||-online.de

--- Comment #3 from Gerhard Steinmetz  
---
Update :


$ gcc-7-20170205 -c pr60085.c
pr60085.c: In function 'foo':
pr60085.c:3:6: internal compiler error: Segmentation fault
 void foo (void)
  ^~~
0xbf633f crash_signal
../../gcc/toplev.c:333
0xc9053a get_frame_type
../../gcc/tree-nested.c:211
0xc9053a get_chain_decl
../../gcc/tree-nested.c:317
0xc93d89 get_chain_decl
../../gcc/tree-nested.c:909
0xc93d89 get_nonlocal_debug_decl
../../gcc/tree-nested.c:913
0xc94138 convert_nonlocal_reference_op
../../gcc/tree-nested.c:992
0xec walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*, tree_node*
(*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*), void*,
hash_set >*))
../../gcc/tree.c:11796
0x964b0c walk_gimple_op(gimple*, tree_node* (*)(tree_node**, int*, void*),
walk_stmt_info*)
../../gcc/gimple-walk.c:221
0x964f5c walk_gimple_stmt(gimple_stmt_iterator*, tree_node*
(*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**,
int*, void*), walk_stmt_info*)
../../gcc/gimple-walk.c:586
0x965148 walk_gimple_seq_mod(gimple**, tree_node* (*)(gimple_stmt_iterator*,
bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*),
walk_stmt_info*)
../../gcc/gimple-walk.c:51
0x965002 walk_gimple_stmt(gimple_stmt_iterator*, tree_node*
(*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**,
int*, void*), walk_stmt_info*)
../../gcc/gimple-walk.c:596
0x965148 walk_gimple_seq_mod(gimple**, tree_node* (*)(gimple_stmt_iterator*,
bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*),
walk_stmt_info*)
../../gcc/gimple-walk.c:51
0x965002 walk_gimple_stmt(gimple_stmt_iterator*, tree_node*
(*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**,
int*, void*), walk_stmt_info*)
../../gcc/gimple-walk.c:596
0x965148 walk_gimple_seq_mod(gimple**, tree_node* (*)(gimple_stmt_iterator*,
bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*),
walk_stmt_info*)
../../gcc/gimple-walk.c:51
0xc8ff41 walk_body
../../gcc/tree-nested.c:656
0xc8ff98 walk_function
../../gcc/tree-nested.c:667
0xc8ff98 walk_all_functions
../../gcc/tree-nested.c:732
0xc98c32 lower_nested_functions(tree_node*)
../../gcc/tree-nested.c:3345
0x7f1670 cgraph_node::analyze()
../../gcc/cgraphunit.c:661
0x7f4ce3 analyze_functions
../../gcc/cgraphunit.c:1116

[Bug debug/77589] [6/7 Regression] fortran: Missing DW_AT_byte_stride for an array record field selection

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

Untested fix (introduces DW_OP_GNU_variable_value, something GDB/elfutils would
need to implement too).

[Bug rtl-optimization/64081] [5/6/7 Regression] r217827 prevents RTL loop unroll

[law at redhat dot com]

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

--- Comment #55 from Jeffrey A. Law  ---
And presumably other calls to get_simple_loop_desc need the more permissive
definition to re-enable loop unrolling.  Ugh.

I think at the least we're going to have to look at each caller of
get_simple_loop_desc and decide if that use is safe with the more permissive
definition.

Hopefully the important one for loop unrolling is safe and we can then look at
how to untangle things a bit.  Perhaps with a boolean indicating if the strict
or permissive definition is needed, or perhaps by storing into the returned
descriptor which definition was used, then the callers decide what to do with
that information, or something along those lines.

[Bug c/79413] [7 Regression] ICE in make_ssa_name_fn, at tree-ssanames.c:265

[mpolacek at gcc dot gnu.org]

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

--- Comment #4 from Marek Polacek  ---
The typeof is not needed to trigger the ICE:

void fn1 ()
{
  int a[1/0];
}
void fn2 ()
{
  fn1();
}

But we create a DECL_EXPR for 'a' in finish_decl:
 5098   add_stmt (build_stmt (DECL_SOURCE_LOCATION (decl),
 5099 DECL_EXPR, decl));

So it doesn't seem to be the problem?

[Bug target/41557] gcc.exe: Internal error: (null) (program cc1plus)

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #8 from Martin Sebor  ---
Thanks.  Resolving as fixed then.

[Bug fortran/79426] fortran - internal compiler error: in fold_convert_loc, at fold-const.c:2251

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-02-08
 CC||dmalcolm at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from David Malcolm  ---
Confirmed with trunk (e.g. r245213).

The ICE is a failure of this assertion, within fold_convert_loc:
2238  gcc_assert (TREE_CODE (orig) == VECTOR_TYPE
2239  && tree_int_cst_equal (TYPE_SIZE (type), TYPE_SIZE
(orig)));

where "orig" is a RECORD_TYPE

as called by fortran/trans-stmt.c:trans_associate_var:1765:

1761  /* Prevent adding a noop len= len.  */
1762  if (tmp != charlen)
1763{
1764  gfc_add_modify (, charlen,
1765  fold_convert (TREE_TYPE (charlen), tmp));
1766  gfc_add_init_cleanup (block, gfc_finish_block (),
1767gfc_finish_block ());
1768}

[Bug translation/79423] Translation of warnings breaks IDE parsing of output

[sgh at sgh dot dk]

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

--- Comment #3 from Søren Holm  ---
Yes - it sound much like what I want.

The diagnostics stuff in gcc7 seem a bit overkill when the real issue is just
the translation of "error" and "warning"

A commandline flag that forcesg gcc to call setenv("LANG", "1", 1) would be the
easy solution. But I do not know if it would have maintainance sideeffects.

[Bug testsuite/79427] New: g++.dg/tls/thread_local-order2.C fails starting with r245249

[seurer at gcc dot gnu.org]

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

Bug ID: 79427
   Summary: g++.dg/tls/thread_local-order2.C fails starting with
r245249
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

FAIL: g++.dg/tls/thread_local-order2.C  -std=c++11 execution test
FAIL: g++.dg/tls/thread_local-order2.C  -std=c++14 execution test

It looks like on BE the destructors are firing in an unepected order.

Taking out the #define of printf I get this output on power BE:

A(1)
A(0)
~A(0)
Program received signal SIGABRT, Aborted.


And this output on power LE:

A(1)
A(0)
~A(1)
~A(0)


BTW, the comment in the test case says "The standard says that a1 should be
destroyed before a0 even though that isn't reverse order of construction." 
Where does it say this in the standard?

[Bug translation/79423] Translation of warnings breaks IDE parsing of output

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

   Keywords||diagnostic
 CC||dmalcolm at gcc dot gnu.org

--- Comment #2 from David Malcolm  ---
It sounds like what you want is an "IDE mode" for output, which could be
basically the same as LANG=C, but as a command-line flag.

Am I right in thinking that you want to be able to suppress just the
translation of "error" and "warning" etc, so that instead of output of the
form:

[with LANG=ja_JP.utf-8]

/tmp/test.cc: 関数 ‘int x2()’ 内:
/tmp/test.cc:3:4: エラー: some translated message here
 x0 x3 = x3.
^~
/tmp/test.cc:1:7: 備考: some other translated message here
 class x0;
   ^~

you get:

/tmp/test.cc: In function ‘int x2()’:
/tmp/test.cc:3:4: error: the same *translated* message here
 x0 x3 = x3.
^~
/tmp/test.cc:1:7: note: again, the message is still translated here
 class x0;
   ^~

i.e. that the content of the messages themselves should still be translated,
even when in some kind of IDE mode; it's just the "error"/"warning" etc
boilerplate that shouldn't be?

As of gcc 7 we already have -fdiagnostics-parseable-fixits; presumably you'd
want some kind of -fdiagnostics-output-format=VALUE or somesuch.

Note to self:
currently supported diagnostics format options for GCC:
https://gcc.gnu.org/onlinedocs/gcc/Diagnostic-Message-Formatting-Options.html#Diagnostic-Message-Formatting-Options

for clang:
http://clang.llvm.org/docs/UsersManual.html#formatting-of-diagnostics

[Bug c++/79425] Inline assembly getting clobbered in some case

[mini at cs dot technion.ac.il]

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

--- Comment #3 from Marina Minkin  ---
What do you mean by "You need to set the section to verify correct in top level
inline-asm and then"?

This is a stripped code just to reproduce this behavior.
What I initially tried to do, was to make a function (not main) not to clobber
the registers.
Basically I needed what the attribute no_caller_saved_registers does. But this
attribute is not supported in my gcc version.

This trick of pushing and popping registers worked well, until I removed the
function that was defined before this one. At this point my code began
crashing. Definitely an unexpected behavior.

[Bug translation/79423] Translation of warnings breaks IDE parsing of output

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
Note translation happens by standard library support and might be hard to
control by a command line.

Does make, etc. Also translate their error messages too.