[Bug testsuite/85865] [9 regression] Many libgomp fortran test cases fails starting with r260433

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #5 from janus at gcc dot gnu.org ---
All the failures should be fixed with r260487. Closing.

[Bug fortran/85841] [F2018] reject deleted features

[janus at gcc dot gnu.org]

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

--- Comment #6 from janus at gcc dot gnu.org ---
Author: janus
Date: Tue May 22 05:41:45 2018
New Revision: 260499

URL: https://gcc.gnu.org/viewcvs?rev=260499=gcc=rev
Log:
2018-05-22  Janus Weil  

PR fortran/85841
* libgfortran.h: Remove the macros GFC_STD_F2008_TS and
GFC_STD_OPT_F08TS.
* error.c (notify_std_msg): Remove GFC_STD_F2008_TS.
* options.c (set_default_std_flags): Ditto.
(gfc_handle_option): Make -std=f2008ts an alias for -std=f2018.
* array.c (gfc_match_array_spec): Replace GFC_STD_F2008_TS by
GFC_STD_F2018.
* check.c (gfc_check_atomic, gfc_check_event_query,
gfc_check_c_f_pointer, gfc_check_c_f_procpointer, gfc_check_c_funloc,
gfc_check_c_loc, gfc_check_num_images, gfc_check_this_image): Ditto.
* decl.c (gfc_verify_c_interop_param, gfc_match_decl_type_spec): Ditto.
* intrinsic.c (add_functions, add_subroutines,
gfc_check_intrinsic_standard): Ditto.
* iso-c-binding.def: Ditto.
* iso-fortran-env.def: Ditto.
* match.c (gfc_match_event_post, gfc_match_event_wait,
gfc_match_fail_image, gfc_match_form_team, gfc_match_change_team,
gfc_match_end_team, gfc_match_sync_team): Ditto.
* gfortran.texi: Remove mention of -std=f2008ts.
Move TSs into F2018 section.
* invoke.texi: Update documentation of -std=f2008ts.


2018-05-22  Janus Weil  

PR fortran/85841
* gfortran.dg/assumed_rank_5.f90: Update error message.
* gfortran.dg/assumed_type_4.f90: Ditto.
* gfortran.dg/bind_c_array_params.f03: Ditto.
* gfortran.dg/bind_c_usage_28.f90: Ditto.
* gfortran.dg/c_funloc_tests_5.f03: Ditto.
* gfortran.dg/c_funloc_tests_6.f90: Ditto.
* gfortran.dg/c_loc_tests_11.f03: Ditto.
* gfortran.dg/coarray_atomic_2.f90: Ditto.
* gfortran.dg/coarray_collectives_2.f90: Ditto.
* gfortran.dg/coarray_collectives_10.f90: Ditto.
* gfortran.dg/coarray_collectives_13.f90: Ditto.
* gfortran.dg/rank_3.f90: Ditto.
* gfortran.dg/error_stop_4.f90: Replace -std=f2008ts by -std=f2008.
* gfortran.dg/implicit_14.f90: Ditto.

Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/array.c
trunk/gcc/fortran/check.c
trunk/gcc/fortran/decl.c
trunk/gcc/fortran/error.c
trunk/gcc/fortran/gfortran.texi
trunk/gcc/fortran/intrinsic.c
trunk/gcc/fortran/invoke.texi
trunk/gcc/fortran/iso-c-binding.def
trunk/gcc/fortran/iso-fortran-env.def
trunk/gcc/fortran/libgfortran.h
trunk/gcc/fortran/match.c
trunk/gcc/fortran/options.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/assumed_rank_5.f90
trunk/gcc/testsuite/gfortran.dg/assumed_type_4.f90
trunk/gcc/testsuite/gfortran.dg/bind_c_array_params.f03
trunk/gcc/testsuite/gfortran.dg/bind_c_usage_28.f90
trunk/gcc/testsuite/gfortran.dg/c_funloc_tests_5.f03
trunk/gcc/testsuite/gfortran.dg/c_funloc_tests_6.f90
trunk/gcc/testsuite/gfortran.dg/c_loc_tests_11.f03
trunk/gcc/testsuite/gfortran.dg/coarray_atomic_2.f90
trunk/gcc/testsuite/gfortran.dg/coarray_collectives_10.f90
trunk/gcc/testsuite/gfortran.dg/coarray_collectives_13.f90
trunk/gcc/testsuite/gfortran.dg/coarray_collectives_2.f90
trunk/gcc/testsuite/gfortran.dg/error_stop_4.f90
trunk/gcc/testsuite/gfortran.dg/implicit_14.f90
trunk/gcc/testsuite/gfortran.dg/rank_3.f90

[Bug c++/85867] New: Subscript operator applied to an temporary array results in an lvalue

[yaghmour.shafik at gmail dot com]

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

Bug ID: 85867
   Summary: Subscript operator applied to an temporary array
results in an lvalue
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: yaghmour.shafik at gmail dot com
  Target Milestone: ---

This Stackoverflow question https://stackoverflow.com/q/33161003/1708801
provides the following code:

using Y = int[10];

int main() {
(Y { })[0] = 1;
}

which compiles without diagnostic, CWG defect report 1213:
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1213 says the
result of the  subscript operator should be an xvalue and therefore not
assignable to.

Also see the following clang bug report on the same issue, which was resolved
at the end of 2017: https://bugs.llvm.org/show_bug.cgi?id=25357

I have a godbolt for it here: https://godbolt.org/g/AmzbFh 

We can see that clang no longer allows this but gcc does.

[Bug c++/85866] [8 Regression] too few arguments to function when sfinae on calling pointer to member function

[gufideg at gmail dot com]

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

--- Comment #1 from Guillaume Racicot  ---
I tried some similar cases, and It seems it only happens when the expression
`(std::declval().*std::declval())()` is inside template parameters. In
the return type and normal function parameter it works as usual:

#include 

template
using void_t = void;

template
void_t boom(){}

struct Foo {
void bar(){}
};

int main() {
boom();
}

Live example: https://godbolt.org/g/vTE9Sr

[Bug c++/85866] New: [8 Regression] too few arguments to function when sfinae on calling pointer to member function

[gufideg at gmail dot com]

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

Bug ID: 85866
   Summary: [8 Regression] too few arguments to function when
sfinae on calling pointer to member function
   Product: gcc
   Version: 8.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gufideg at gmail dot com
  Target Milestone: ---

This code fails under GCC 8:

#include 

template
using void_t = void;

template().*std::declval())()
)>* = nullptr>
void boom(){}

struct Foo {
void bar(){}
};

int main() {
boom();
}

This particular code compiles on all other GCC versions since 4.7
It also compiles on all versions of clang since version 3.4

Live example: https://godbolt.org/g/viHnMn

[Bug fortran/25829] [F03] Asynchronous IO support

[jvdelisle at gcc dot gnu.org]

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

--- Comment #42 from Jerry DeLisle  ---
(In reply to Nicolas Koenig from comment #41)
> Created attachment 44151 [details]
> Next version of patch.
--- snip ---

> real0m15.465s
> user0m15.313s
> sys 0m0.152s
> 
> With the "no" replaced by "yes":
> 
> real0m5.558s
> user0m16.253s
> sys 0m0.152s
> 
> If you ask me, that's quite nice :)

Yes, very impressive.

[Bug c++/85858] -Weffc++ should not require copy ctor for const pointers

[msharov at users dot sourceforge.net]

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

--- Comment #8 from Mike Sharov  ---
(In reply to Jonathan Wakely from comment #7)
> Your mental model of C++ is simply not how the language works.

My mental model here is actually of const correctness, not C++ specifically.
When I pass around a const object I expect it to stay unmodified. Consider a
function that takes a const T* argument. The signature suggests that the
passed-in object will only be read and will not be modified. If that function
deletes the pointer, "bad things" will likely happen. Suddenly the object
contains garbage and you can't figure out how it happened. All called functions
took it as const, so they shouldn't have messed with it. You assume memory
corruption and onto valgrind we go.

> The const qualifier affects modification of the object, not its destruction.

This is precisely the part I have a problem with. It seems downright loony to
state that destruction is not modification when the object is most definitely
modified by it. It's like saying that if I break into your house and take
stuff, I am a criminal, but if I burn it down, it's all perfectly fine.

> void f() { const int i = 0; }
> 
> Do you think this stack variable can't be destroyed, because it's const?

What it boils down to is this: const restricts access, and so prevents
ownership. If you can't destroy a thing, you don't really own it. The standard
appears to have taken the position that ownership beats const correctness. I
instead argue in favor of const correctness, and its guarantee of invariance.

The stack variable in the example illustrates the difference between access and
ownership. f() has read-only access to i, and therefore does not own it. Who
owns i? The stack does. The stack passes i to f() with limited access, and
then, when f() terminates, the stack destroys i. This way ownership is clearly
delineated. If f() were to say delete i (assuming i were a pointer), it should
be prevented from doing so.

>   using const_int = const int;
>   const int* p = new const_int();
> 
> Do you expect to never be able to delete this object,
> instead being forced to leak it?

Consequently, const objects created with new are owned by nobody, and simply do
not make sense. Somebody has to own the allocated object, so creating a const
object should be an invalid operation.

I suppose it doesn't really matter what my opinion is in this matter. Neither I
nor you write the standard, so I'll just leave this as a closing footnote in a
bug correctly resolved INVALID.

[Bug c++/85864] [8/9 Regression] template argument string literal operator with default argument doesnt work in templates

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||rejects-valid
 CC||jason at gcc dot gnu.org
  Known to work||7.3.0
Summary|template argument string|[8/9 Regression] template
   |literal operator with   |argument string literal
   |default argument doesnt |operator with default
   |work in templates   |argument doesnt work in
   ||templates
  Known to fail||8.1.0, 9.0

--- Comment #1 from Jonathan Wakely  ---
I'm not sure if this is valid, but it started to be rejected with with r258039

PR c++/84489 - dependent default template argument

* pt.c (type_unification_real): Handle early substitution failure.

[Bug c++/81930] [meta-bug] Issues with -Weffc++

[redi at gcc dot gnu.org]

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

Bug 85858 Summary: -Weffc++ should not require copy ctor for const pointers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85858

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |INVALID

[Bug c++/85858] -Weffc++ should not require copy ctor for const pointers

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |INVALID

--- Comment #7 from Jonathan Wakely  ---
It's completely logical.

  using const_int = const int;
  const int* p = new const_int();

Do you expect to never be able to delete this object, instead being forced to
leak it?

What about:

void f() { const int i = 0; }

Do you think this stack variable can't be destroyed, because it's const?

The const qualifier affects modification of the object, not its destruction.
Your mental model of C++ is simply not how the language works.

[Bug target/85657] Make __ibm128 a separate type, even if long double uses the IBM double-double format

[meissner at gcc dot gnu.org]

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

--- Comment #3 from Michael Meissner  ---
Author: meissner
Date: Mon May 21 22:25:03 2018
New Revision: 260490

URL: https://gcc.gnu.org/viewcvs?rev=260490=gcc=rev
Log:
2018-05-21  Michael Meissner  

PR target/85657
* config/rs6000/rs6000-c.c (rs6000_cpu_cpp_builtins): Do not
define __ibm128 as long double.
* config/rs6000/rs6000.c (rs6000_init_builtins): Create __ibm128
as a distinct type with IEEE 128-bit floating point is supported.
(init_float128_ieee): Fix up conversions between IFmode and IEEE
128-bit types to use the correct functions.
(rs6000_expand_float128_convert): Use explicit FLOAT_EXTEND to
convert between 128-bit floating point types that have different
modes but the same representation, instead of using gen_lowpart to
makean alias.
* config/rs6000/rs6000.md (IFKF): New iterator for IFmode and
KFmode.
(IFKF_reg): New attributes to give the register constraints for
IFmode and KFmode.
(extendtf2_internal): New insns to mark an explicit
conversion between 128-bit floating point types that have a
different mode but share the same representation.

[gcc/testsuite]
2018-05-21  Michael Meissner  

PR target/85657
* gcc.target/powerpc/pr85657-1.c: New test for converting between
__float128, __ibm128, and long double.
* gcc.target/powerpc/pr85657-2.c: Likewise.
* gcc.target/powerpc/pr85657-3.c: Likewise.
* g++.dg/pr85667.C: New test to make sure __ibm128 is
implementated as a separate type internally, and is not just an
alias for long double.


Modified:
trunk/gcc/ChangeLog

[Bug target/85657] Make __ibm128 a separate type, even if long double uses the IBM double-double format

[meissner at gcc dot gnu.org]

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

--- Comment #2 from Michael Meissner  ---
Author: meissner
Date: Mon May 21 22:21:40 2018
New Revision: 260489

URL: https://gcc.gnu.org/viewcvs?rev=260489=gcc=rev
Log:
[gcc]
2018-05-21  Michael Meissner  

PR target/85657
* config/rs6000/rs6000-c.c (rs6000_cpu_cpp_builtins): Do not
define __ibm128 as long double.
* config/rs6000/rs6000.c (rs6000_init_builtins): Always create
__ibm128 as a distinct type.
(init_float128_ieee): Fix up conversions between IFmode and IEEE
128-bit types to use the correct functions.
(rs6000_expand_float128_convert): Use explicit FLOAT_EXTEND to
convert between 128-bit floating point types that have different
modes but the same representation, instead of using gen_lowpart to
makean alias.
* config/rs6000/rs6000.md (IFKF): New iterator for IFmode and
KFmode.
(IFKF_reg): New attributes to give the register constraints for
IFmode and KFmode.
(extendtf2_internal): New insns to mark an explicit
conversion between 128-bit floating point types that have a
different mode but share the same representation.

[gcc/testsuite]
2018-05-21  Michael Meissner  

PR target/85657
* gcc.target/powerpc/pr85657-1.c: New test for converting between
__float128, __ibm128, and long double.
* gcc.target/powerpc/pr85657-2.c: Likewise.
* gcc.target/powerpc/pr85657-3.c: Likewise.
* g++.dg/pr85667.C: New test to make sure __ibm128 is
implementated as a separate type internally, and is not just an
alias for long double.


Added:
trunk/gcc/testsuite/g++.dg/pr85657.C
trunk/gcc/testsuite/gcc.target/powerpc/pr85657-1.c
trunk/gcc/testsuite/gcc.target/powerpc/pr85657-2.c
trunk/gcc/testsuite/gcc.target/powerpc/pr85657-3.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/rs6000-c.c
trunk/gcc/config/rs6000/rs6000.c
trunk/gcc/config/rs6000/rs6000.md
trunk/gcc/testsuite/ChangeLog

[Bug c++/85861] g++ -Wconversion misses int to size_t

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #5 from Eric Gallager  ---
(In reply to Jonny Grant from comment #2)
> Thank you for your replies.
> 
> I tested on 64bit ubuntu. But yes with -Wsign-conversion I now see the
> warnings/errors.
> 
> Could it be enabled by default? to match C behaviour visible in GCC.

I think you mean by -Wconversion, not by default, right?

[Bug tree-optimization/85814] [8 Regression] ICE Segmentation fault during GIMPLE pass: strlen -O3 and above

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

Summary|[8/9 Regression] ICE|[8 Regression] ICE
   |Segmentation fault during   |Segmentation fault during
   |GIMPLE pass: strlen -O3 and |GIMPLE pass: strlen -O3 and
   |above   |above

--- Comment #8 from rsandifo at gcc dot gnu.org  
---
Fixed on trunk so far.  Will apply to the branch tomorrow.

[Bug tree-optimization/85814] [8/9 Regression] ICE Segmentation fault during GIMPLE pass: strlen -O3 and above

[rsandifo at gcc dot gnu.org]

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

--- Comment #7 from rsandifo at gcc dot gnu.org  
---
Author: rsandifo
Date: Mon May 21 22:02:35 2018
New Revision: 260488

URL: https://gcc.gnu.org/viewcvs?rev=260488=gcc=rev
Log:
Fix tree-ssa-strlen handling of partial clobbers (PR85814)

In this PR we have:

  c_5 = c_4(D) + 4;
  c_12 = c_5 + 1;
  *c_5 = 2;
  a = 2;// A
  c_21 = c_12 + 1;
  *c_12 = 2;
  a = 2;// B
  c_28 = c_21 + 1;
  *c_21 = 2;
  a = 2;
  c_7 = c_28 + 1;
  *c_28 = 2;

where a is a global int.  We decide that A can't clobber *c_5 == c_4[4]
because the latter implies that c_4 is an object of 5 bytes or more,
whereas a has exactly 4 bytes.

The assumption for B and *c_5 is the same, but when considering B and
*c_12, we only follow the definition of c_12 to c_5 + 1 (for good
reason) and so have *c_12 == c_5[1].  We then don't have the same
size guarantee and so assume that B could clobber *c_12.  This leads
to a situation in which the strinfo for c_5 is still valid but the
next strinfo (c_12) isn't.  We then segfaulted while trying to get
the strinfo for c_21 + 1 == c_5 + 3 because get_stridx_plus_constant
assumed that c_5's next strinfo (c_12) would be valid too.

And of course it should be valid really.  It doesn't make sense for the
string based at c_5 to be valid but a substring of it to be invalid.
I don't think we can guarantee that such weird corner cases never
happen though, even if we tried to avoid this one.

One possibility would be to mark c_12 as valid on the basis that c_5
is valid, but I'm not sure the complication is worth it given that it
seems to trigger very rarely.  A better optimisation would be to get
the unroller to clean up after itself a bit more...

Although this particular instance of the bug relies on r249880, I think
we could have similar problems in GCC 7.  It would be much harder to
trigger though, especially since it relies on unfolded IR like the above.

2018-05-21  Richard Sandiford  

gcc/
PR tree-optimization/85814
* tree-ssa-strlen.c (get_stridx_plus_constant): Cope with
a null return from get_strinfo when unsharing the next
strinfo in the chain.

gcc/testsuite/
PR tree-optimization/85814
* gcc.dg/torture/pr85814.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr85814.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-strlen.c

[Bug fortran/85855] [7 Regression] (Maybe) uninitialized descriptor fields of an allocatable array component of a function result

[vladimir.fuka at gmail dot com]

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

--- Comment #2 from Vladimir Fuka  ---
Yes, that is quite possible, although I tried to search  first, because I had
this problem without reporting for a long time, but may main compiler version
to use was an older one so I didn't car that much for just a warning and hoped
it will be gone when I move to 7.

[Bug c++/85858] -Weffc++ should not require copy ctor for const pointers

[msharov at users dot sourceforge.net]

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

--- Comment #6 from Mike Sharov  ---
(In reply to Jonathan Wakely from comment #5)
> Nope, see the C++ standard:
> 
>   [ Note: A pointer to a const type can be the operand of a
> delete-expression;

Ok, I guess; you have to follow the standard, after all. But I would like to
see the rationale for this, because it sure looks like a violation of const
correctness. I certainly feel violated.

[Bug fortran/85851] [8/9 Regression] ICE in gfc_conv_structure Segmentation fault at trans-expr.c:7810

[foreese at gcc dot gnu.org]

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

Fritz Reese  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Last reconfirmed|2018-05-20 00:00:00 |2018-5-21
 Depends on||82972
   Assignee|unassigned at gcc dot gnu.org  |foreese at gcc dot 
gnu.org

--- Comment #2 from Fritz Reese  ---
Probable duplicate of pr82972 and pr83088. Sorry I have not tracked this issue
down yet. My solution for -finit-derived requires special consideration for the
iso-c-binding structures such as c_ptr since the structure intialization
expression currently generated is invalid for those structures. Something in
the middle-end changed with 8.x that has further invalidated my solution for
-finit-derived. I am [still] working on this and a few other issues with
-finit-derived.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82972
[Bug 82972] [8/9 Regression] ICE with -finit-derived in gfc_conv_structure, at
fortran/trans-expr.c:7733 (and others)

[Bug fortran/85841] [F2018] reject deleted features

[janus at gcc dot gnu.org]

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

--- Comment #5 from janus at gcc dot gnu.org ---
Author: janus
Date: Mon May 21 20:48:59 2018
New Revision: 260487

URL: https://gcc.gnu.org/viewcvs?rev=260487=gcc=rev
Log:
2018-05-21  Janus Weil  

PR fortran/85841
PR testsuite/85865
* testsuite/libgomp.fortran/collapse2.f90: Add option "-std=legacy".
* testsuite/libgomp.fortran/omp_atomic2.f90: Ditto.
* testsuite/libgomp.fortran/omp_parse1.f90: Ditto.
* testsuite/libgomp.fortran/omp_parse3.f90: Ditto.
* testsuite/libgomp.fortran/task2.f90: Ditto.
* testsuite/libgomp.fortran/vla1.f90: Ditto.
* testsuite/libgomp.fortran/vla2.f90: Ditto.
* testsuite/libgomp.fortran/vla3.f90: Ditto.
* testsuite/libgomp.fortran/vla4.f90: Ditto.
* testsuite/libgomp.fortran/vla5.f90: Ditto.
* testsuite/libgomp.fortran/vla6.f90: Ditto.
* testsuite/libgomp.fortran/vla8.f90: Ditto.
* testsuite/libgomp.oacc-fortran/collapse-2.f90: Ditto.
* testsuite/libgomp.oacc-fortran/nested-function-1.f90: Ditto.

Modified:
trunk/libgomp/ChangeLog
trunk/libgomp/testsuite/libgomp.fortran/collapse2.f90
trunk/libgomp/testsuite/libgomp.fortran/omp_atomic2.f90
trunk/libgomp/testsuite/libgomp.fortran/omp_parse1.f90
trunk/libgomp/testsuite/libgomp.fortran/omp_parse3.f90
trunk/libgomp/testsuite/libgomp.fortran/task2.f90
trunk/libgomp/testsuite/libgomp.fortran/vla1.f90
trunk/libgomp/testsuite/libgomp.fortran/vla2.f90
trunk/libgomp/testsuite/libgomp.fortran/vla3.f90
trunk/libgomp/testsuite/libgomp.fortran/vla4.f90
trunk/libgomp/testsuite/libgomp.fortran/vla5.f90
trunk/libgomp/testsuite/libgomp.fortran/vla6.f90
trunk/libgomp/testsuite/libgomp.fortran/vla8.f90
trunk/libgomp/testsuite/libgomp.oacc-fortran/collapse-2.f90
trunk/libgomp/testsuite/libgomp.oacc-fortran/nested-function-1.f90

[Bug testsuite/85865] [9 regression] Many libgomp fortran test cases fails starting with r260433

[janus at gcc dot gnu.org]

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

--- Comment #4 from janus at gcc dot gnu.org ---
Author: janus
Date: Mon May 21 20:48:59 2018
New Revision: 260487

URL: https://gcc.gnu.org/viewcvs?rev=260487=gcc=rev
Log:
2018-05-21  Janus Weil  

PR fortran/85841
PR testsuite/85865
* testsuite/libgomp.fortran/collapse2.f90: Add option "-std=legacy".
* testsuite/libgomp.fortran/omp_atomic2.f90: Ditto.
* testsuite/libgomp.fortran/omp_parse1.f90: Ditto.
* testsuite/libgomp.fortran/omp_parse3.f90: Ditto.
* testsuite/libgomp.fortran/task2.f90: Ditto.
* testsuite/libgomp.fortran/vla1.f90: Ditto.
* testsuite/libgomp.fortran/vla2.f90: Ditto.
* testsuite/libgomp.fortran/vla3.f90: Ditto.
* testsuite/libgomp.fortran/vla4.f90: Ditto.
* testsuite/libgomp.fortran/vla5.f90: Ditto.
* testsuite/libgomp.fortran/vla6.f90: Ditto.
* testsuite/libgomp.fortran/vla8.f90: Ditto.
* testsuite/libgomp.oacc-fortran/collapse-2.f90: Ditto.
* testsuite/libgomp.oacc-fortran/nested-function-1.f90: Ditto.

Modified:
trunk/libgomp/ChangeLog
trunk/libgomp/testsuite/libgomp.fortran/collapse2.f90
trunk/libgomp/testsuite/libgomp.fortran/omp_atomic2.f90
trunk/libgomp/testsuite/libgomp.fortran/omp_parse1.f90
trunk/libgomp/testsuite/libgomp.fortran/omp_parse3.f90
trunk/libgomp/testsuite/libgomp.fortran/task2.f90
trunk/libgomp/testsuite/libgomp.fortran/vla1.f90
trunk/libgomp/testsuite/libgomp.fortran/vla2.f90
trunk/libgomp/testsuite/libgomp.fortran/vla3.f90
trunk/libgomp/testsuite/libgomp.fortran/vla4.f90
trunk/libgomp/testsuite/libgomp.fortran/vla5.f90
trunk/libgomp/testsuite/libgomp.fortran/vla6.f90
trunk/libgomp/testsuite/libgomp.fortran/vla8.f90
trunk/libgomp/testsuite/libgomp.oacc-fortran/collapse-2.f90
trunk/libgomp/testsuite/libgomp.oacc-fortran/nested-function-1.f90

[Bug testsuite/85865] [9 regression] Many libgomp fortran test cases fails starting with r260433

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-05-21
   Assignee|unassigned at gcc dot gnu.org  |janus at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #3 from janus at gcc dot gnu.org ---
(In reply to seurer from comment #1)
>   PR fortran/85841
>   * gfortran.dg/g77/19990826-3.f: Add option "-std=legacy".
>   * gfortran.dg/g77/20020307-1.f: Ditto.
> ...
> 
> Probably this just needs to be added to all the failing test cases, too.

Yes, I'm on it.

[Bug testsuite/85865] [9 regression] Many libgomp fortran test cases fails starting with r260433

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #2 from kargl at gcc dot gnu.org ---
(In reply to seurer from comment #1)
> r260433 | janus | 2018-05-21 01:45:55 -0500 (Mon, 21 May 2018) | 42 lines
> 
> 2018-05-21  Janus Weil  
> 
>   PR fortran/85841
>   * gfortran.dg/g77/19990826-3.f: Add option "-std=legacy".
>   * gfortran.dg/g77/20020307-1.f: Ditto.
> ...
> 
> Probably this just needs to be added to all the failing test cases, too.

Yes, Janus and I are aware of the failures.  Unfortunately,

make check-fortran

does not run over the Fortran code in libgomp.fortran, so the
above list of failures were missed.

[Bug testsuite/85865] [9 regression] Many libgomp fortran test cases fails starting with r260433

[seurer at gcc dot gnu.org]

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

--- Comment #1 from seurer at gcc dot gnu.org ---
r260433 | janus | 2018-05-21 01:45:55 -0500 (Mon, 21 May 2018) | 42 lines

2018-05-21  Janus Weil  

PR fortran/85841
* gfortran.dg/g77/19990826-3.f: Add option "-std=legacy".
* gfortran.dg/g77/20020307-1.f: Ditto.
...

Probably this just needs to be added to all the failing test cases, too.

[Bug testsuite/85865] New: [9 regression] Many libgomp fortran test cases fails starting with r260433

[seurer at gcc dot gnu.org]

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

Bug ID: 85865
   Summary: [9 regression] Many libgomp fortran test cases fails
starting with r260433
   Product: gcc
   Version: 9.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: ---

There are a whole bunch of fortran tests that fail starting with r260433.  This
is (I believe) the whole list:

FAIL: libgomp.fortran/collapse2.f90   -O0  (test for excess errors)
FAIL: libgomp.fortran/collapse2.f90   -O1  (test for excess errors)
FAIL: libgomp.fortran/collapse2.f90   -O2  (test for excess errors)
FAIL: libgomp.fortran/collapse2.f90   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  (test for excess errors)
FAIL: libgomp.fortran/collapse2.f90   -O3 -g  (test for excess errors)
FAIL: libgomp.fortran/collapse2.f90   -Os  (test for excess errors)
FAIL: libgomp.fortran/omp_atomic2.f90   -O0  (test for excess errors)
FAIL: libgomp.fortran/omp_atomic2.f90   -O1  (test for excess errors)
FAIL: libgomp.fortran/omp_atomic2.f90   -O2  (test for excess errors)
FAIL: libgomp.fortran/omp_atomic2.f90   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  (test for excess errors)
FAIL: libgomp.fortran/omp_atomic2.f90   -O3 -g  (test for excess errors)
FAIL: libgomp.fortran/omp_atomic2.f90   -Os  (test for excess errors)
FAIL: libgomp.fortran/omp_parse1.f90   -O0  (test for excess errors)
FAIL: libgomp.fortran/omp_parse1.f90   -O1  (test for excess errors)
FAIL: libgomp.fortran/omp_parse1.f90   -O2  (test for excess errors)
FAIL: libgomp.fortran/omp_parse1.f90   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  (test for excess errors)
FAIL: libgomp.fortran/omp_parse1.f90   -O3 -g  (test for excess errors)
FAIL: libgomp.fortran/omp_parse1.f90   -Os  (test for excess errors)
FAIL: libgomp.fortran/omp_parse3.f90   -O0  (test for excess errors)
FAIL: libgomp.fortran/omp_parse3.f90   -O1  (test for excess errors)
FAIL: libgomp.fortran/omp_parse3.f90   -O2  (test for excess errors)
FAIL: libgomp.fortran/omp_parse3.f90   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  (test for excess errors)
FAIL: libgomp.fortran/omp_parse3.f90   -O3 -g  (test for excess errors)
FAIL: libgomp.fortran/omp_parse3.f90   -Os  (test for excess errors)
FAIL: libgomp.fortran/task2.f90   -O  (test for excess errors)
FAIL: libgomp.fortran/vla1.f90   -O0  (test for excess errors)
FAIL: libgomp.fortran/vla1.f90   -O1  (test for excess errors)
FAIL: libgomp.fortran/vla1.f90   -O2  (test for excess errors)
FAIL: libgomp.fortran/vla1.f90   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  (test for excess errors)
FAIL: libgomp.fortran/vla1.f90   -O3 -g  (test for excess errors)
FAIL: libgomp.fortran/vla1.f90   -Os  (test for excess errors)
FAIL: libgomp.fortran/vla2.f90   -O0  (test for excess errors)
FAIL: libgomp.fortran/vla2.f90   -O1  (test for excess errors)
FAIL: libgomp.fortran/vla2.f90   -O2  (test for excess errors)
FAIL: libgomp.fortran/vla2.f90   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  (test for excess errors)
FAIL: libgomp.fortran/vla2.f90   -O3 -g  (test for excess errors)
FAIL: libgomp.fortran/vla2.f90   -Os  (test for excess errors)
FAIL: libgomp.fortran/vla3.f90   -O0  (test for excess errors)
FAIL: libgomp.fortran/vla3.f90   -O1  (test for excess errors)
FAIL: libgomp.fortran/vla3.f90   -O2  (test for excess errors)
FAIL: libgomp.fortran/vla3.f90   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  (test for excess errors)
FAIL: libgomp.fortran/vla3.f90   -O3 -g  (test for excess errors)
FAIL: libgomp.fortran/vla3.f90   -Os  (test for excess errors)
FAIL: libgomp.fortran/vla4.f90   -O0  (test for excess errors)
FAIL: libgomp.fortran/vla4.f90   -O1  (test for excess errors)
FAIL: libgomp.fortran/vla4.f90   -O2  (test for excess errors)
FAIL: libgomp.fortran/vla4.f90   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  (test for excess errors)
FAIL: libgomp.fortran/vla4.f90   -O3 -g  (test for excess errors)
FAIL: libgomp.fortran/vla4.f90   -Os  (test for excess errors)
FAIL: libgomp.fortran/vla5.f90   -O0  (test for excess errors)
FAIL: libgomp.fortran/vla5.f90   -O1  (test for excess errors)
FAIL: libgomp.fortran/vla5.f90   -O2  (test for excess errors)
FAIL: libgomp.fortran/vla5.f90   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  (test for excess errors)
FAIL: libgomp.fortran/vla5.f90   -O3 -g  (test for excess errors)
FAIL: libgomp.fortran/vla5.f90   -Os  (test for excess errors)
FAIL: libgomp.fortran/vla6.f90   -O0  (test for excess errors)
FAIL: 

[Bug target/84923] [8 regression] gcc.dg/attr-weakref-1.c failed on aarch64

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com
Summary|[8/9 regression]|[8 regression]
   |gcc.dg/attr-weakref-1.c |gcc.dg/attr-weakref-1.c
   |failed on aarch64   |failed on aarch64

--- Comment #9 from Jeffrey A. Law  ---
Fixed on trunk so far.

[Bug target/84923] [8/9 regression] gcc.dg/attr-weakref-1.c failed on aarch64

[law at gcc dot gnu.org]

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

--- Comment #8 from Jeffrey A. Law  ---
Author: law
Date: Mon May 21 20:30:00 2018
New Revision: 260485

URL: https://gcc.gnu.org/viewcvs?rev=260485=gcc=rev
Log:
PR gcc/84923
* varasm.c (weak_finish): Clean up weak_decls.

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

[Bug c++/85858] -Weffc++ should not require copy ctor for const pointers

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  ---
Nope, see the C++ standard:

  [ Note: A pointer to a const type can be the operand of a delete-expression;
  it is not necessary to cast away the constness (8.5.1.11) of the pointer
  expression before it is used as the operand of the delete-expression. — end
  note ]

The deallocation function 'operator delete(void*)' is not the same as a
delete-expression such as delete[] p.

[Bug c++/85858] -Weffc++ should not require copy ctor for const pointers

[msharov at users dot sourceforge.net]

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

--- Comment #4 from Mike Sharov  ---
(In reply to Jonathan Wakely from comment #3)
> Nothing stops you deallocating a const pointer.

According to http://en.cppreference.com/w/cpp/memory/new/operator_delete
The delete operator takes a void* and attempting to delete a const pointer
would require a const_cast. This is logical, since freeing a memory block is a
modification operation that changes the block's contents by marking it invalid.

To my surprise, I found that g++ actually does currently accept delete of a
const pointer. I believe that should be a bug.

[Bug c++/85864] New: template argument string literal operator with default argument doesnt work in templates

[dummyddd at gmail dot com]

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

Bug ID: 85864
   Summary: template argument string literal operator with default
argument doesnt work in templates
   Product: gcc
   Version: 8.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dummyddd at gmail dot com
  Target Milestone: ---

The following code compiles with GCC 7.3.0 and earlier, but errors with GCC
8.1.0 and trunk.

template struct String_template {};

template
constexpr String_template operator""_template() {
return String_template {};
}

template
int hex(T v) { return 1; }

template 
void tt2() {
auto h2 = hex(1);
auto h = hex(2);
}

int main() {
auto h = hex(2);
return h;
}

: In function 'void tt2()':

:14:19: error: no matching function for call to 'hex(int)'

 auto h = hex(2);

   ^

:9:5: note: candidate: 'template int hex(T)'

 int hex(T v) { return 1; }

 ^~~

:9:5: note:   template argument deduction/substitution failed:

The error is only triggered by hex(2).
The error may be related to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85731

[Bug rtl-optimization/85852] [9 Regression] ICE: Segmentation fault (in contains_struct_check)

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

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

--- Comment #3 from rsandifo at gcc dot gnu.org  
---
Mine.

[Bug c++/85858] -Weffc++ should not require copy ctor for const pointers

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2018-05-21
 Ever confirmed|0   |1

[Bug c++/85858] -Weffc++ should not require copy ctor for const pointers

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
(In reply to Mike Sharov from comment #2)
> (In reply to Jonathan Wakely from comment #1)
> > (In reply to Mike Sharov from comment #0)
> > > When the pointer is const, it can not point to owned memory
> > Why not?
> 
> Because a const pointer can not be freed.

That's what I thought you meant, and it's wrong.

> By "owned memory" I mean memory
> that was explicitly allocated by the object, which I assume was the
> situation that Effective C++ rule was referring to, or memory the ownership
> of which was passed to the object. In both cases the object has to keep a
> non-const pointer in order to be able to free it or to pass on the ability
> to free it to some other object.

Nothing stops you deallocating a const pointer.

struct X {
  const int* const p;
  X() : p(new int[10]) { }
  ~X() { delete[] p; }
};

This type should have a user-defined copy constructor (it doesn't need a
user-defined assignment operator though, because it's implicitly defined as
deleted).

[Bug c++/84588] [8 Regression] internal compiler error: Segmentation fault (contains_struct_check())

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

Summary|[8/9 Regression] internal   |[8 Regression] internal
   |compiler error: |compiler error:
   |Segmentation fault  |Segmentation fault
   |(contains_struct_check())   |(contains_struct_check())

--- Comment #14 from Paolo Carlini  ---
Should be really fixed in trunk. Note, what I applied doesn't have much to do
with the idea posted in Comment 12 and goes well beyond handling correctly the
testcase originally provided by bug submitter.

[Bug c++/85858] -Weffc++ should not require copy ctor for const pointers

[msharov at users dot sourceforge.net]

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

--- Comment #2 from Mike Sharov  ---
(In reply to Jonathan Wakely from comment #1)
> (In reply to Mike Sharov from comment #0)
> > When the pointer is const, it can not point to owned memory
> Why not?

Because a const pointer can not be freed. By "owned memory" I mean memory that
was explicitly allocated by the object, which I assume was the situation that
Effective C++ rule was referring to, or memory the ownership of which was
passed to the object. In both cases the object has to keep a non-const pointer
in order to be able to free it or to pass on the ability to free it to some
other object. I can't think of any case for an owned const pointer; can you?

[Bug c++/85861] g++ -Wconversion misses int to size_t

[jg at jguk dot org]

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

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

[Bug c++/84588] [8/9 Regression] internal compiler error: Segmentation fault (contains_struct_check())

[paolo at gcc dot gnu.org]

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

--- Comment #13 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Mon May 21 19:25:50 2018
New Revision: 260482

URL: https://gcc.gnu.org/viewcvs?rev=260482=gcc=rev
Log:
/cp
2018-05-21  Paolo Carlini  

PR c++/84588
* parser.c (cp_parser_maybe_commit_to_declaration,
cp_parser_check_condition_declarator): New.
(cp_parser_simple_declaration): Use the first above.
(cp_parser_condition): Use both the above; enforce
[stmt.stmt]/2 about the declarator not specifying
a function or an array; improve error-recovery.

/testsuite
2018-05-21  Paolo Carlini  

PR c++/84588
* g++.dg/cpp0x/cond1.C: New.
* g++.dg/cpp1y/pr84588-1.C: Likewise.
* g++.dg/cpp1y/pr84588-2.C: Likewise.
* g++.dg/cpp1y/pr84588-3.C: Likewise.
* g++.dg/parse/cond6.C: Likewise.
* g++.dg/parse/cond7.C: Likewise.
* g++.dg/parse/cond8.C: Likewise.
* g++.dg/cpp1z/decomp16.C: Update.
* g++.old-deja/g++.jason/cond.C: Likewise.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/cond1.C
trunk/gcc/testsuite/g++.dg/cpp1y/pr84588-1.C
trunk/gcc/testsuite/g++.dg/cpp1y/pr84588-2.C
trunk/gcc/testsuite/g++.dg/cpp1y/pr84588-3.C
trunk/gcc/testsuite/g++.dg/parse/cond6.C
trunk/gcc/testsuite/g++.dg/parse/cond7.C
trunk/gcc/testsuite/g++.dg/parse/cond8.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/parser.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/cpp1z/decomp16.C
trunk/gcc/testsuite/g++.old-deja/g++.jason/cond.C

[Bug c++/85861] g++ -Wconversion misses int to size_t

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|WAITING |NEW
   Severity|normal  |enhancement

--- Comment #3 from Jonathan Wakely  ---
(In reply to Jonny Grant from comment #2)
> Could it be enabled by default? to match C behaviour visible in GCC.

Confirming as a request for that. I have no idea what the history behind the
difference is (but it's intentional and documented).

[Bug tree-optimization/85863] New: [9 Regression] ICE in compiling spec2006 fortran test case solib.fppized.f starting with r260283

[seurer at gcc dot gnu.org]

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

Bug ID: 85863
   Summary: [9 Regression] ICE in compiling spec2006 fortran test
case solib.fppized.f starting with r260283
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

I think the test case (part of 416.gamess) is generated by the spec2006 test
run as it appears in the build directory.  Unfortunately it is a large test
case and I don't know fortran well enough to extract a smaller example of
failing code.

I see this with both powerpc64 BE and LE.

seurer@genoa:~/gcc/cpu2006$ /home/seurer/gcc/install/gcc-test2/bin/gfortran -c
-o solib.fppized.o -m64 -O3 -mcpu=power8 -ffast-math -funroll-loops
-fpeel-loops -fvect-cost-model -mpopcntd -mrecip=rsqrt -funconstrained-commons
-std=legacy
./benchspec/CPU2006/416.gamess/build/build_base_ppc64./solib.fppized.f
./benchspec/CPU2006/416.gamess/build/build_base_ppc64./solib.fppized.f:1300:72:

   CALL GETSTSYM(X(LSTSYM),X(JSODA),IROOTS)
1
Warning: Type mismatch in argument 'istsym' at (1); passed REAL(8) to
INTEGER(4) [-Wargument-mismatch]
./benchspec/CPU2006/416.gamess/build/build_base_ppc64./solib.fppized.f:1301:72:

   CALL ASSORCI(X(LSTSYM),X(LNCIOR),X(LIRCIOR),IROOTS)
1
Warning: Type mismatch in argument 'istsym' at (1); passed REAL(8) to
INTEGER(4) [-Wargument-mismatch]
./benchspec/CPU2006/416.gamess/build/build_base_ppc64./solib.fppized.f:1303:72:

   CALL INTSYM(MULST,IROOTS,X(LSTSYM),IRRL,GSYLYES)
1
Warning: Type mismatch in argument 'istsym' at (1); passed REAL(8) to
INTEGER(4) [-Wargument-mismatch]
./benchspec/CPU2006/416.gamess/build/build_base_ppc64./solib.fppized.f:1488:0:

   SUBROUTINE SOBOOK(IW,ICI1,ICI2,IROOTS,SOL1MUL,SOL2MUL,STMMUL,

Error: invalid vector comparison resulting type
vector(2) 
vect__ifc__995.2248_892 = VEC_COND_EXPR ;
during GIMPLE pass: vect
./benchspec/CPU2006/416.gamess/build/build_base_ppc64./solib.fppized.f:1488:0:
internal compiler error: verify_gimple failed
0x10ae2d37 verify_gimple_in_cfg(function*, bool)
/home/seurer/gcc/gcc-test2/gcc/tree-cfg.c:5361
0x1094d5c3 execute_function_todo
/home/seurer/gcc/gcc-test2/gcc/passes.c:1994
0x1094edab do_per_function
/home/seurer/gcc/gcc-test2/gcc/passes.c:1659
0x1094efbb execute_todo
/home/seurer/gcc/gcc-test2/gcc/passes.c:2048

[Bug rtl-optimization/85862] New: infinite loop in find_base_term()

[matthew.weber at rockwellcollins dot com]

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

Bug ID: 85862
   Summary: infinite loop in find_base_term()
   Product: gcc
   Version: 6.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: matthew.weber at rockwellcollins dot com
  Target Milestone: ---

Posted a comment on this
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85180#c20)  bug as the patch
proposed their resolved this issue as well.

libnss 3.35 fails to build on the microblaze arch (uclibc) with any of the 6.x
series and this patch resolves that
(https://github.com/gcc-mirror/gcc/commit/df03ebc3574a0d7893127e3b9754a01abf2d8b70).
 

microblazeel-buildroot-linux-uclibc-gcc -o
Linux2.6_microblazeel_microblazeel-buildroot-linux-uclibc-gcc.br_real_glibc_PTH_OPT.OBJ/sslgrp.o
-c -O2 -fPIC   -pipe -ffunction-sections -fdata-sections -DHAVE_STRERROR
-DLINUX -Dlinux -Wall -Werror -DXP_UNIX -UDEBUG -DNDEBUG -D_REENTRANT
-DNSS_NO_INIT_SUPPORT -DUSE_UTIL_DIRECTLY -DNO_NSPR_10_SUPPORT
-DSSL_DISABLE_DEPRECATED_CIPHER_SUITE_NAMES -Isysroot/usr/include/nspr
-Ilibnss-3.35/dist/include -I../../../dist/public/nss
-I../../../dist/private/nss  sslgrp.c
(Buildroot failure link:
http://autobuild.buildroot.net/results/158e8ebb39713e1b436a5cc1a1916f46c30694df)

However the libnss build works fine with the 7.x branch and master.  I've been
bisecting all 3 branches for a few days and figured I should just try that
patch before debugging the 6.x branch further.  I even went back and tried to
find common ancestors between the 6.x and 7.x and couldn't get a point where
the good/bad builds matched up.  Guessing backports on 6.x from master
introduced the libnss bug variant, as the gcc/cse* and gcc/alias.x files had a
lot of updates from 5.x to 7.x.

Here's the stack trace on cc1 when its hung building a libnss sslgrp.c
file...
( A lot more find_base_terms() before this one)
#71 0x005ae67d in find_base_term(rtx_def*) ()
#72 0x005ae532 in find_base_term(rtx_def*) ()
#73 0x005ae67d in find_base_term(rtx_def*) ()
#74 0x005ae532 in find_base_term(rtx_def*) ()
#75 0x005ae67d in find_base_term(rtx_def*) ()
#76 0x005ae568 in find_base_term(rtx_def*) ()
#77 0x005b137d in write_dependence_p(rtx_def const*, rtx_def const*,
machine_mode, rtx_def*, bool, bool, bool) ()
#78 0x005b1585 in canon_anti_dependence(rtx_def const*, bool, rtx_def
const*, machine_mode, rtx_def*) ()
#79 0x0061c5e3 in cselib_invalidate_mem(rtx_def*) ()
#80 0x0061d32d in cselib_record_sets(rtx_insn*) ()
#81 0x0061e5c8 in cselib_process_insn(rtx_insn*) ()
#82 0x008774b8 in reload_cse_regs_1() ()
#83 0x008777dc in (anonymous
namespace)::pass_postreload_cse::execute(function*) ()
#84 0x0086714d in execute_one_pass(opt_pass*) ()

[Bug c++/85861] g++ -Wconversion misses int to size_t

[jg at jguk dot org]

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

--- Comment #2 from Jonny Grant  ---
Thank you for your replies.

I tested on 64bit ubuntu. But yes with -Wsign-conversion I now see the
warnings/errors.

Could it be enabled by default? to match C behaviour visible in GCC.

[Bug fortran/85855] [7 Regression] (Maybe) uninitialized descriptor fields of an allocatable array component of a function result

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2018-05-21
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
I am pretty sure that it is a duplicate, but I don't have the energy to hunt it
down right now!-(

[Bug c++/22406] -Weffc++ warns about missing op= and copy ctor, even when base classes have already disabled these

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||msharov at users dot 
sourceforge.n
   ||et

--- Comment #5 from Jonathan Wakely  ---
*** Bug 85856 has been marked as a duplicate of this bug. ***

[Bug c++/81930] [meta-bug] Issues with -Weffc++

[redi at gcc dot gnu.org]

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

Bug 85856 Summary: -Weffc++ can't see implicitly deleted constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85856

   What|Removed |Added

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

[Bug c++/85856] -Weffc++ can't see implicitly deleted constructor

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
There are loads of problems with -Weffc++, all related to the fact they are
outdated rules based on the first edition of a book based on C++98.

This seems like a dup of PR 22406

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

[Bug c++/85858] -Weffc++ should not require copy ctor for const pointers

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
(In reply to Mike Sharov from comment #0)
> When the pointer is const, it can not point to owned memory

Why not?

[Bug c++/85861] g++ -Wconversion misses int to size_t

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2018-05-21
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
You didn't provide the output of `gcc -v` as required, but I suspect you're
compiling for 32-bit, otherwise you'd get a warning:

mozilla_jwakely0/main.c: In function 'int main()':
mozilla_jwakely0/main.c:11:12: error: conversion to 'int' from 'size_t {aka
long unsigned int}' may alter its value [-Werror=conversion]
 return converted;
^
cc1plus: all warnings being treated as errors

For 32-bit where int and size_t are the same size you need to use
-Wsign-conversion, as documented in the manual:

  Warnings about conversions between signed and unsigned integers are
  disabled by default in C++ unless -Wsign-conversion is explicitly enabled.

https://godbolt.org/g/6J4rtS

[Bug target/85769] [8/9 Regression] ICE in extract_constrain_insn, at recog.c:2205 for -mcpu=thunderx

[tnfchris at gcc dot gnu.org]

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

--- Comment #4 from Tamar Christina  ---
I have a patch to add the missing case, but that'll just mask the reload bug,
so I'm holding up on posting it while looking at reload.

[Bug libstdc++/85845] [9 Regression] Many libstdc++ test failures

[fdumont at gcc dot gnu.org]

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

--- Comment #2 from François Dumont  ---
Author: fdumont
Date: Mon May 21 16:51:47 2018
New Revision: 260478

URL: https://gcc.gnu.org/viewcvs?rev=260478=gcc=rev
Log:
2018-05-21  François Dumont  

PR libstdc++/85845
* include/bits/stl_tree.h
(_Rb_tree_impl(_Rb_tree_impl&&, _Node_allocator&&)): Fix noexcept
qualification.

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

[Bug tree-optimization/85698] [8/9 Regression] CPU2017 525.x264_r fails starting with r257581

[pthaugen at gcc dot gnu.org]

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

--- Comment #13 from Pat Haugen  ---
Author: pthaugen
Date: Mon May 21 16:41:09 2018
New Revision: 260477

URL: https://gcc.gnu.org/viewcvs?rev=260477=gcc=rev
Log:
PR target/85698
* gcc.target/powerpc/vec-setup-be-long.c: Remove XFAIL.


Modified:
branches/gcc-8-branch/gcc/testsuite/ChangeLog
branches/gcc-8-branch/gcc/testsuite/gcc.target/powerpc/vec-setup-be-long.c

[Bug tree-optimization/85698] [8/9 Regression] CPU2017 525.x264_r fails starting with r257581

[pthaugen at gcc dot gnu.org]

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

--- Comment #12 from Pat Haugen  ---
Author: pthaugen
Date: Mon May 21 16:34:44 2018
New Revision: 260476

URL: https://gcc.gnu.org/viewcvs?rev=260476=gcc=rev
Log:
PR target/85698
* config/rs6000/rs6000.c (rs6000_output_move_128bit): Check dest
operand.

* gcc.target/powerpc/pr85698.c: New test.


Added:
branches/gcc-7-branch/gcc/testsuite/gcc.target/powerpc/pr85698.c
Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/config/rs6000/rs6000.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog

[Bug tree-optimization/85698] [8/9 Regression] CPU2017 525.x264_r fails starting with r257581

[pthaugen at gcc dot gnu.org]

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

--- Comment #11 from Pat Haugen  ---
Author: pthaugen
Date: Mon May 21 16:23:20 2018
New Revision: 260475

URL: https://gcc.gnu.org/viewcvs?rev=260475=gcc=rev
Log:
PR target/85698
* config/rs6000/rs6000.c (rs6000_output_move_128bit): Check dest
operand.

* gcc.target/powerpc/pr85698.c: New test.


Added:
branches/gcc-8-branch/gcc/testsuite/gcc.target/powerpc/pr85698.c
Modified:
branches/gcc-8-branch/gcc/ChangeLog
branches/gcc-8-branch/gcc/config/rs6000/rs6000.c
branches/gcc-8-branch/gcc/testsuite/ChangeLog

[Bug c++/85861] New: g++ -Wconversion misses int to size_t

[jg at jguk dot org]

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

Bug ID: 85861
   Summary: g++  -Wconversion misses int to size_t
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jg at jguk dot org
  Target Milestone: ---

Created attachment 44158
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44158=edit
C code example

g++ has a missing warning that gcc does display. please see below

Sorry I do not have a newer version of GCC myself. Although I did test online
with G++ 8.1 here: https://godbolt.org/ and same issue


jonny@asus:~$ gcc --version
gcc (Ubuntu 5.4.0-6ubuntu1~16.04.9) 5.4.0 20160609

jonny@asus:~$ g++ -o main main.c -Wall -Werror -Wconversion
main.c: In function ‘int main()’:
main.c:11:12: error: conversion to ‘int’ from ‘size_t {aka long unsigned int}’
may alter its value [-Werror=conversion]
 return converted;
^
cc1plus: all warnings being treated as errors

jonny@asus:~$
jonny@asus:~$
jonny@asus:~$
jonny@asus:~$ gcc -o main main.c -Wall -Werror -Wconversion
main.c: In function ‘main’:
main.c:9:24: error: conversion to ‘size_t {aka long unsigned int}’ from ‘int’
may change the sign of the result [-Werror=sign-conversion]
 size_t converted = value;
^
main.c:11:12: error: conversion to ‘int’ from ‘size_t {aka long unsigned int}’
may alter its value [-Werror=conversion]
 return converted;
^
cc1: all warnings being treated as errors

[Bug target/85860] New: [8/9 Regression] ICE: in lra_split_hard_reg_for, at lra-assigns.c:1810: unable to find a register to spill with -flive-range-shrinkage -mbmi2

[zsojka at seznam dot cz]

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

Bug ID: 85860
   Summary: [8/9 Regression] ICE: in lra_split_hard_reg_for, at
lra-assigns.c:1810: unable to find a register to spill
with -flive-range-shrinkage -mbmi2
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu

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

Compiler output:
$ x86_64-pc-linux-gnu-gcc -O2 -fno-guess-branch-probability
-flive-range-shrinkage -mbmi2 testcase.c 
testcase.c: In function 'foo':
testcase.c:20:1: error: unable to find a register to spill
 }
 ^
testcase.c:20:1: error: this is the insn:
(insn 214 65 201 3 (set (reg:DI 208)
(reg:DI 1 dx)) "testcase.c":15 85 {*movdi_internal}
 (expr_list:REG_DEAD (reg:DI 1 dx)
(nil)))
during RTL pass: reload
testcase.c:20:1: internal compiler error: in lra_split_hard_reg_for, at
lra-assigns.c:1810
0x67a94c _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/repo/gcc-trunk/gcc/rtl-error.c:108
0xc47293 lra_split_hard_reg_for()
/repo/gcc-trunk/gcc/lra-assigns.c:1810
0xc40ee9 lra(_IO_FILE*)
/repo/gcc-trunk/gcc/lra.c:2507
0xbef719 do_reload
/repo/gcc-trunk/gcc/ira.c:5465
0xbef719 execute
/repo/gcc-trunk/gcc/ira.c:5649
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.


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

[Bug tree-optimization/85859] New: [6/7/8/9 Regression] wrong code with -fno-isolate-erroneous-paths-dereference

[zsojka at seznam dot cz]

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

Bug ID: 85859
   Summary: [6/7/8/9 Regression] wrong code with
-fno-isolate-erroneous-paths-dereference
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu

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

Output:
$ x86_64-pc-linux-gnu-gcc -O2 -fno-dce -fno-isolate-erroneous-paths-dereference
-fno-tree-dce -fno-tree-vrp testcase.c
testcase.c: In function 'foo':
testcase.c:6:5: warning: division by zero [-Wdiv-by-zero]
   f %= 0;
 ^~
$ ./a.out 
Floating point exception

The division by zero should not be executed.

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

[Bug c++/85858] New: -Weffc++ should not require copy ctor for const pointers

[msharov at users dot sourceforge.net]

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

Bug ID: 85858
   Summary: -Weffc++ should not require copy ctor for const
pointers
   Product: gcc
   Version: 8.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msharov at users dot sourceforge.net
  Target Milestone: ---

-Weffc++ warns about missing operator= and copy ctor in a class containing a
const pointer. The intent of the warning is to detect manually allocated memory
owned by the class, and to ensure copying operation was explicitly considered.
When the pointer is const, it can not point to owned memory and so should not
result in a warning.

[Bug other/85857] New: configure problem using local mpfr and gmp

[seurer at gcc dot gnu.org]

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

Bug ID: 85857
   Summary: configure problem using local mpfr and gmp
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

There is a problem with configure if you use a local copy of mpfr and gmp
(grabbed via contrib/download_prerequisites) and then use
--enable-decimal-float on the configure for gcc itself.  It occurs in gcc 7 as
well as in trunk (didn't try 6 or 8 but probably there, too).


$ $GCC_SRC/configure --prefix=$GCC_INSTALL --enable-languages=c,fortran,c++
--disable-bootstrap --disable-multilib --enable-decimal-float
$ make
. . .
configure: error: decimal float support requires --with-gmp-build
make[1]: *** [configure-mpfr] Error 1


I ran into this on a powerpc64 system but have duplicated it on an x86 system.


Adding --with-gmp-build as suggested doesn't work, either:

configure: error: in `/home/seurer/gcc/build/gcc-test/mpfr':
configure: error: Do not use --with-gmp-build and other --with-gmp options
simultaneously.
make[1]: *** [configure-mpfr] Error 1


Details from the config.log for mpfr:

$ cat mpfr/config.log
. . .
  $ /home/seurer/gcc/gcc-test/mpfr/configure
--srcdir=/home/seurer/gcc/gcc-test/mpfr --cache-file=./config.cache
--prefix=/home/seurer/gcc/install/gcc-test --disable-bootstrap
--disable-multilib --enable-decimal-float --enable-languages=c,c++,fortran,lto
--program-transform-name=s,y,y, --disable-option-checking
--build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu
--target=x86_64-pc-linux-gnu --disable-shared
--with-gmp-include=/home/seurer/gcc/build/gcc-test/./gmp
--with-gmp-lib=/home/seurer/gcc/build/gcc-test/./gmp/.libs
. . .
configure:5164: checking if compiler knows _Decimal64
configure:5177: /usr/bin/gcc -c -g -O2  -I/home/seurer/gcc/build/gcc-test/gmp
conftest.c >&5
configure:5177: $? = 0
configure:5178: result: yes
configure:5181: error: decimal float support requires --with-gmp-build

[Bug c++/85856] New: -Weffc++ can't see implicitly deleted constructor

[msharov at users dot sourceforge.net]

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

Bug ID: 85856
   Summary: -Weffc++ can't see implicitly deleted constructor
   Product: gcc
   Version: 8.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msharov at users dot sourceforge.net
  Target Milestone: ---

#include 

struct A {
A (void) {}
virtual ~A (void) {}
A (const A&) = delete;
void operator= (const A&) = delete;
};

struct B : public A {
B (const char* p) :A(),_p(p) {}
const char* _p;
};

int main (void)
{
B b ("hello");
puts (b._p);
return 0;
}

When compiling with -Weffc++ enabled, generates:

t.cc:10:8: warning: ‘struct B’ has pointer data members [-Weffc++]
 struct B : public A {
^
t.cc:10:8: warning:   but does not override ‘B(const B&)’ [-Weffc++]
t.cc:10:8: warning:   or ‘operator=(const B&)’ [-Weffc++]

B already has an implicitly deleted copy constructor and operator= because A
implements them deleted. The compiler will correctly give a warning about it on
B b2=b, for example.

[Bug fortran/85855] New: [7 Regression] (Maybe) uninitialized descriptor fields of an allocatable array component of a function result

[vladimir.fuka at gmail dot com]

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

Bug ID: 85855
   Summary: [7 Regression] (Maybe) uninitialized descriptor fields
of an allocatable array component of a function result
   Product: gcc
   Version: 7.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vladimir.fuka at gmail dot com
  Target Milestone: ---

This code does not issue any warning in GCC 4.8 to 6 but does for GCC 7.3.1:

module test

  implicit none

  type grid
integer, allocatable :: mask(:,:,:)
  end type

contains

  function reduce(g) result(res)
type(grid) :: res
class(grid), intent(in) :: g
res%mask = g%mask
  end function

end module


> gfortran-7 -c uninit2.f90 -fbacktrace -g -Wall
uninit2.f90:14:0:

 res%mask = g%mask

Warning: ‘res.mask.offset’ is used uninitialized in this function
[-Wuninitialized]
uninit2.f90:14:0: Warning: ‘res.mask.dim[0].lbound’ is used uninitialized in
this function [-Wuninitialized]
uninit2.f90:14:0: Warning: ‘res.mask.dim[0].ubound’ is used uninitialized in
this function [-Wuninitialized]
uninit2.f90:14:0: Warning: ‘res.mask.dim[1].lbound’ is used uninitialized in
this function [-Wuninitialized]
uninit2.f90:14:0: Warning: ‘res.mask.dim[1].ubound’ is used uninitialized in
this function [-Wuninitialized]
uninit2.f90:14:0: Warning: ‘res.mask.dim[2].lbound’ is used uninitialized in
this function [-Wuninitialized]
uninit2.f90:14:0: Warning: ‘res.mask.dim[2].ubound’ is used uninitialized in
this function [-Wuninitialized]
uninit2.f90:14:0:

 res%mask = g%mask

Warning: ‘res.mask.dim[0].lbound’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
uninit2.f90:14:0: Warning: ‘res.mask.dim[0].ubound’ may be used uninitialized
in this function [-Wmaybe-uninitialized]
uninit2.f90:14:0: Warning: ‘res.mask.dim[1].lbound’ may be used uninitialized
in this function [-Wmaybe-uninitialized]
uninit2.f90:14:0: Warning: ‘res.mask.dim[1].ubound’ may be used uninitialized
in this function [-Wmaybe-uninitialized]
uninit2.f90:14:0: Warning: ‘res.mask.dim[2].lbound’ may be used uninitialized
in this function [-Wmaybe-uninitialized]
uninit2.f90:14:0: Warning: ‘res.mask.dim[2].ubound’ may be used uninitialized
in this function [-Wmaybe-uninitialized]
uninit2.f90:14:0: Warning: ‘res.mask.dim[0].ubound’ may be used uninitialized
in this function [-Wmaybe-uninitialized]
uninit2.f90:14:0: Warning: ‘res.mask.dim[0].lbound’ may be used uninitialized
in this function [-Wmaybe-uninitialized]
uninit2.f90:14:0: Warning: ‘res.mask.dim[1].ubound’ may be used uninitialized
in this function [-Wmaybe-uninitialized]
uninit2.f90:14:0: Warning: ‘res.mask.dim[1].lbound’ may be used uninitialized
in this function [-Wmaybe-uninitialized]
uninit2.f90:14:0: Warning: ‘res.mask.dim[2].ubound’ may be used uninitialized
in this function [-Wmaybe-uninitialized]
uninit2.f90:14:0: Warning: ‘res.mask.dim[2].lbound’ may be used uninitialized
in this function [-Wmaybe-uninitialized]

[Bug libstdc++/81771] __basic_file::sys_open is not a reserved name

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
*** Bug 70727 has been marked as a duplicate of this bug. ***

[Bug libstdc++/70727] Non-reserved names in std::__basic_file

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #1 from Jonathan Wakely  ---
.

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

[Bug target/85832] [AVX512] possible shorter code when comparing with vector of zeros

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

Untested full patch.

[Bug target/45996] -falign-functions=X does not work

[vda.linux at googlemail dot com]

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

Denis Vlasenko  changed:

   What|Removed |Added

 CC||vda.linux at googlemail dot com

--- Comment #8 from Denis Vlasenko  ---
See bug 66240

[Bug middle-end/66240] RFE: extend -falign-xyz syntax

[vda.linux at googlemail dot com]

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

--- Comment #7 from Denis Vlasenko  ---
Patch v8

https://gcc.gnu.org/ml/gcc-patches/2017-04/msg00792.html
https://gcc.gnu.org/ml/gcc-patches/2017-04/msg00793.html
https://gcc.gnu.org/ml/gcc-patches/2017-04/msg00794.html
https://gcc.gnu.org/ml/gcc-patches/2017-04/msg00795.html

[Bug libstdc++/85818] [8/9 Regression] undefined reference to `std::experimental::filesystem::v1::__cxx11::path::preferred_separator'

[sudi at gcc dot gnu.org]

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

--- Comment #9 from sudi at gcc dot gnu.org ---
Thanks!

[Bug c/85854] New: Performance regression from gcc 4.9.2

[beldmit at gmail dot com]

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

Bug ID: 85854
   Summary: Performance regression from gcc 4.9.2
   Product: gcc
   Version: 8.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: beldmit at gmail dot com
  Target Milestone: ---

Created attachment 44154
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44154=edit
Preprocessing file.

I got a serious (10%) performance degradation using cross-compiler for ARM.

Compiler version: 
arm-linux-gnueabihf-gcc-8 -v
Using built-in specs.
COLLECT_GCC=arm-linux-gnueabihf-gcc-8
COLLECT_LTO_WRAPPER=/usr/lib/gcc-cross/arm-linux-gnueabihf/8/lto-wrapper
Target: arm-linux-gnueabihf
Configured with: ../src/configure -v --with-pkgversion='Debian 8.1.0-3'
--with-bugurl=file:///usr/share/doc/gcc-8/README.Bugs
--enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++ --prefix=/usr
--with-gcc-major-version-only --program-suffix=-8 --enable-shared
--enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/
--enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-libitm
--disable-libquadmath --disable-libquadmath-support --enable-plugin
--enable-default-pie --with-system-zlib --with-target-system-zlib
--enable-multiarch --disable-sjlj-exceptions --with-arch=armv7-a
--with-fpu=vfpv3-d16 --with-float=hard --with-mode=thumb --disable-werror
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=arm-linux-gnueabihf --program-prefix=arm-linux-gnueabihf-
--includedir=/usr/arm-linux-gnueabihf/include
Thread model: posix
gcc version 8.1.0 (Debian 8.1.0-3) 

System: Linux x-debian 4.16.0-1-amd64 #1 SMP Debian 4.16.5-1 (2018-04-29)
x86_64 GNU/Linux

Compiler options:
arm-linux-gnueabihf-gcc-8 -c  -DSTRICT_OFFSET -mfpu=neon -O1 -D_REENTRANT 
-DTHREAD_TYPE=THREAD_TYPE_PTHREADS -fPIC -DNDEBUG -DCC_NO_RDS_SOCKET
-DCC_NO_RDS_FILECNT -DCC_NO_RDS_NP -D_GNU_SOURCE -pedantic -Wall -Wextra
-Wno-long-long -g -save-temps gosthash2012.c

The preprocessed file is attached. The most time-taking part of the code is the
function named g.

The new version does not use neon vector ops (such as veor) at all, but the
4.9.2 on native ARM system does.

The system withoud degradation is 
Linux odroid 3.10.107 #1 SMP PREEMPT Wed Sep 13 18:48:10 CEST 2017 armv7l
GNU/Linux

gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabihf/4.9/lto-wrapper
Target: arm-linux-gnueabihf
Configured with: ../src/configure -v --with-pkgversion='Debian 4.9.2-10'
--with-bugurl=file:///usr/share/doc/gcc-4.9/README.Bugs
--enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.9 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.9 --libdir=/usr/lib --enable-nls
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-libitm
--disable-libquadmath --enable-plugin --with-system-zlib
--disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.9-armhf/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.9-armhf
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.9-armhf
--with-arch-directory=arm --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --disable-sjlj-exceptions
--with-arch=armv7-a --with-fpu=vfpv3-d16 --with-float=hard --with-mode=thumb
--enable-checking=release --build=arm-linux-gnueabihf
--host=arm-linux-gnueabihf --target=arm-linux-gnueabihf
Thread model: posix
gcc version 4.9.2 (Debian 4.9.2-10)

[Bug libstdc++/85818] [8/9 Regression] undefined reference to `std::experimental::filesystem::v1::__cxx11::path::preferred_separator'

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #8 from Jonathan Wakely  ---
Should be OK now.

[Bug libstdc++/85818] [8/9 Regression] undefined reference to `std::experimental::filesystem::v1::__cxx11::path::preferred_separator'

[redi at gcc dot gnu.org]

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

--- Comment #7 from Jonathan Wakely  ---
Author: redi
Date: Mon May 21 12:29:33 2018
New Revision: 260440

URL: https://gcc.gnu.org/viewcvs?rev=260440=gcc=rev
Log:
PR libstdc++/85818 make new test require Filesystem support

PR libstdc++/85818
* testsuite/experimental/filesystem/path/preferred_separator.cc: Add
dg-require-filesystem-ts.

Modified:
branches/gcc-8-branch/libstdc++-v3/ChangeLog
   
branches/gcc-8-branch/libstdc++-v3/testsuite/experimental/filesystem/path/preferred_separator.cc

[Bug libstdc++/85818] [8/9 Regression] undefined reference to `std::experimental::filesystem::v1::__cxx11::path::preferred_separator'

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #8 from Jonathan Wakely  ---
Should be OK now.

[Bug libstdc++/85818] [8/9 Regression] undefined reference to `std::experimental::filesystem::v1::__cxx11::path::preferred_separator'

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  ---
Author: redi
Date: Mon May 21 12:27:00 2018
New Revision: 260439

URL: https://gcc.gnu.org/viewcvs?rev=260439=gcc=rev
Log:
PR libstdc++/85818 make new test require Filesystem support

PR libstdc++/85818
* testsuite/experimental/filesystem/path/preferred_separator.cc: Add
dg-require-filesystem-ts.

Modified:
trunk/libstdc++-v3/ChangeLog
   
trunk/libstdc++-v3/testsuite/experimental/filesystem/path/preferred_separator.cc

[Bug target/85832] [AVX512] possible shorter code when comparing with vector of zeros

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-05-21
 CC||jakub at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Untested fix:
--- gcc/config/i386/sse.md.jj   2018-05-21 13:15:43.478581765 +0200
+++ gcc/config/i386/sse.md  2018-05-21 14:15:00.523635533 +0200
@@ -11210,26 +11210,30 @@
   "ix86_fixup_binary_operands_no_copy (EQ, mode, operands);")

 (define_insn "_eq3_1"
-  [(set (match_operand: 0 "register_operand" "=Yk")
+  [(set (match_operand: 0 "register_operand" "=Yk,Yk")
(unspec:
- [(match_operand:VI12_AVX512VL 1 "nonimmediate_operand" "%v")
-  (match_operand:VI12_AVX512VL 2 "nonimmediate_operand" "vm")]
+ [(match_operand:VI12_AVX512VL 1 "nonimmediate_operand" "%v,v")
+  (match_operand:VI12_AVX512VL 2 "vector_move_operand" "vm,C")]
  UNSPEC_MASKED_EQ))]
-  "TARGET_AVX512F && !(MEM_P (operands[1]) && MEM_P (operands[2]))"
-  "vpcmpeq\t{%2, %1,
%0|%0, %1, %2}"
+  "TARGET_AVX512BW && !(MEM_P (operands[1]) && MEM_P (operands[2]))"
+  "@
+   vpcmpeq\t{%2, %1,
%0|%0, %1, %2}
+   vptestm\t{%1, %1,
%0|%0, %1, %1}"
   [(set_attr "type" "ssecmp")
(set_attr "prefix_extra" "1")
(set_attr "prefix" "evex")
(set_attr "mode" "")])

 (define_insn "_eq3_1"
-  [(set (match_operand: 0 "register_operand" "=Yk")
+  [(set (match_operand: 0 "register_operand" "=Yk,Yk")
(unspec:
- [(match_operand:VI48_AVX512VL 1 "nonimmediate_operand" "%v")
-  (match_operand:VI48_AVX512VL 2 "nonimmediate_operand" "vm")]
+ [(match_operand:VI48_AVX512VL 1 "nonimmediate_operand" "%v,v")
+  (match_operand:VI48_AVX512VL 2 "vector_move_operand" "vm,C")]
  UNSPEC_MASKED_EQ))]
   "TARGET_AVX512F && !(MEM_P (operands[1]) && MEM_P (operands[2]))"
-  "vpcmpeq\t{%2, %1,
%0|%0, %1, %2}"
+  "@
+   vpcmpeq\t{%2, %1,
%0|%0, %1, %2}
+   vptestm\t{%1, %1,
%0|%0, %1, %1}"
   [(set_attr "type" "ssecmp")
(set_attr "prefix_extra" "1")
(set_attr "prefix" "evex")

[Bug libstdc++/85818] [8/9 Regression] undefined reference to `std::experimental::filesystem::v1::__cxx11::path::preferred_separator'

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #5 from Jonathan Wakely  ---
Oops, the test should be disabled on that target.

[Bug libstdc++/85818] [8/9 Regression] undefined reference to `std::experimental::filesystem::v1::__cxx11::path::preferred_separator'

[sudi at gcc dot gnu.org]

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

sudi at gcc dot gnu.org changed:

   What|Removed |Added

 CC||sudi at gcc dot gnu.org

--- Comment #4 from sudi at gcc dot gnu.org ---
I have observed the following failures on baremetals aarch64-none-elf,
aarch64_be-none-elf and arm-none-eabi nightly tests for both trunk and gcc-8
branch.

FAIL: experimental/filesystem/path/preferred_separator.cc (test for excess
errors)

with

compilation terminated.

compiler exited with status 1
output is:
/build/src/gcc/libstdc++-v3/testsuite/experimental/filesystem/path/preferred_separator.cc:21:
fatal error: experimental/filesystem: No such file or directory

compilation terminated.

[Bug target/85666] gcc-8.0.1 fails to build mmix target: gcc/libgcc/libgcc2.h:203:20: internal compiler error: in leaf_function_p, at final.c:4488

[wilco at gcc dot gnu.org]

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

--- Comment #8 from Wilco  ---
(In reply to Hans-Peter Nilsson from comment #7)
> Thank you for your interest in the MMIX port.
> 
> (In reply to Wilco from comment #3)
> > (In reply to Sergei Trofimovich from comment #1)
> > 
> > >  #define MMIX_CFUN_NEEDS_SAVED_EH_RETURN_ADDRESS  \
> > >   (flag_exceptions\
> > >&& ((reload_completed && df_regs_ever_live_p (MMIX_rJ_REGNUM)) \
> > >  || !leaf_function_p ())) /// <- here
> > 
> > 
> > Yes that looks like a bug. leaf_function_p cannot be called on a sequence as
> > it will incorrectly return true on non-leaf functions. So
> > MMIX_CFUN_NEEDS_SAVED_EH_RETURN_ADDRESS will randomly change its result if
> > called again later. starting_frame_offset should however return a fixed
> > value, so the reload_completed part also looks wrong.
> 
> Kindly refer to the comment above that macro:
> 
> /* We have no means to tell DWARF 2 about the register stack, so we need
>to store the return address on the stack if an exception can get into
>this function.  FIXME: Narrow condition.  Before any whole-function
>analysis, df_regs_ever_live_p () isn't initialized.  We know it's
> up-to-date
>after reload_completed; it may contain incorrect information some time
>before that.  Within a RTL sequence (after a call to start_sequence,
>such as in RTL expanders), leaf_function_p doesn't see all insns
>(perhaps any insn).  But regs_ever_live is up-to-date when
>leaf_function_p () isn't, so we "or" them together to get accurate
>information.  FIXME: Some tweak to leaf_function_p might be
>preferable.  */
> 
> So, it looks like the time has come for "some tweak to leaf_function_p",
> or...some other tweak.  Yes, this was a brittle solution and someone saw fit
> to pull the rug.  Maybe I'll have to compute the starting frame offset some
> other way.

I don't think that comment is accurate. The failure happens in cfgexpand before
any RTL has been generated, so leaf_function_p must not be called this early.
If starting_frame_offset doesn't remain constant things can go badly wrong.

The easiest fix is to always allocate an extra stack slot with exceptions and
then avoid generating extra code in the prolog/epilog if it happens to be a
leaf function.

[Bug c/85850] [9.0 Regression] gcc 9.0 doesn't compile with Xcode 9.3.1

[juergen.reuter at desy dot de]

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

--- Comment #4 from Jürgen Reuter  ---
Sorry, I meant Marc, of course. Confused this was another PR.


(In reply to Jürgen Reuter from comment #3)
> Indeed, Janne is correct, this change in libcpp/system.h solves the problem,
> i.e. moving the  definition up:
> # diff -u system.h system.h.260425 
> --- system.h  2018-05-20 23:00:01.0 +0200
> +++ system.h.260425   2018-05-20 22:55:27.0 +0200
> @@ -370,10 +370,6 @@
>  #include "libiberty.h"
>  #include "safe-ctype.h"
>  
> -#ifdef __cplusplus
> -#include 
> -#endif 
> -
>  /* 1 if we have C99 designated initializers.
>  
> ??? C99 designated initializers are not supported by most C++
> @@ -442,6 +438,10 @@
>  /* Some compilers do not allow the use of unsigned char in bitfields.  */
>  #define BOOL_BITFIELD unsigned int
>  
> +#ifdef __cplusplus
> +#include 
> +#endif
> +
>  /* Poison identifiers we do not want to use.  */
>  #if (GCC_VERSION >= 3000)
>  #undef calloc

[Bug target/82855] AVX512: replace OP+movemask with OP_mask+ktest

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||wojciech_mula at poczta dot 
onet.p
   ||l

--- Comment #8 from Jakub Jelinek  ---
*** Bug 85833 has been marked as a duplicate of this bug. ***

[Bug target/85833] [AVX512] use mask registers instructions instead of scalar code

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #2 from Jakub Jelinek  ---
And with -mavx512dq this is a dup of already fixed PR82855.

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

[Bug c/85850] [9.0 Regression] gcc 9.0 doesn't compile with Xcode 9.3.1

[juergen.reuter at desy dot de]

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

--- Comment #3 from Jürgen Reuter  ---
Indeed, Janne is correct, this change in libcpp/system.h solves the problem,
i.e. moving the  definition up:
# diff -u system.h system.h.260425 
--- system.h2018-05-20 23:00:01.0 +0200
+++ system.h.260425 2018-05-20 22:55:27.0 +0200
@@ -370,10 +370,6 @@
 #include "libiberty.h"
 #include "safe-ctype.h"

-#ifdef __cplusplus
-#include 
-#endif 
-
 /* 1 if we have C99 designated initializers.

??? C99 designated initializers are not supported by most C++
@@ -442,6 +438,10 @@
 /* Some compilers do not allow the use of unsigned char in bitfields.  */
 #define BOOL_BITFIELD unsigned int

+#ifdef __cplusplus
+#include 
+#endif
+
 /* Poison identifiers we do not want to use.  */
 #if (GCC_VERSION >= 3000)
 #undef calloc

[Bug tree-optimization/85853] ICE in vect_is_simple_use, at tree-vect-stmts.c:10233 on ppc64le

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-05-21
   Target Milestone|--- |9.0
 Ever confirmed|0   |1

[Bug tree-optimization/85853] New: ICE in vect_is_simple_use, at tree-vect-stmts.c:10233 on ppc64le

[marxin at gcc dot gnu.org]

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

Bug ID: 85853
   Summary: ICE in vect_is_simple_use, at tree-vect-stmts.c:10233
on ppc64le
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: rguenth at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-linux-gnu
Target: ppc64le-linux-gnu

Following ICEs with current trunk:

$ ppc64-linux-gnu-gfortran
/home/marxin/Programming/gcc/gcc/testsuite/gfortran.fortran-torture/execute/where_2.f90
-O3 -fno-tree-loop-vectorize
during GIMPLE pass: slp
/home/marxin/Programming/gcc/gcc/testsuite/gfortran.fortran-torture/execute/where_2.f90:22:0:

 end program

internal compiler error: in vect_is_simple_use, at tree-vect-stmts.c:10233
0xe6d140 vect_is_simple_use(tree_node*, vec_info*, gimple**, vect_def_type*,
tree_node**)
.././../gcc/tree-vect-stmts.c:10233
0xe701d7 vect_get_mask_type_for_stmt(_stmt_vec_info*)
.././../gcc/tree-vect-stmts.c:10904
0xeae87c vect_slp_analyze_node_operations
.././../gcc/tree-vect-slp.c:2540
0xeae5a0 vect_slp_analyze_node_operations
.././../gcc/tree-vect-slp.c:2517
0xeb0fbf vect_slp_analyze_operations(vec_info*)
.././../gcc/tree-vect-slp.c:2613
0xeb1d7f vect_slp_analyze_bb_1
.././../gcc/tree-vect-slp.c:2919
0xeb1d7f vect_slp_bb(basic_block_def*)
.././../gcc/tree-vect-slp.c:3006
0xeb42d5 execute
.././../gcc/tree-vectorizer.c:1069

[Bug rtl-optimization/85852] [9 Regression] ICE: Segmentation fault (in contains_struct_check)

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-05-21
 CC||marxin at gcc dot gnu.org,
   ||rdsandiford at googlemail dot 
com
  Known to work||8.1.0
Summary|ICE: Segmentation fault (in |[9 Regression] ICE:
   |contains_struct_check)  |Segmentation fault (in
   ||contains_struct_check)
 Ever confirmed|0   |1
  Known to fail||9.0

--- Comment #2 from Martin Liška  ---
Confirmed, started with r260348.

[Bug fortran/85841] [F2018] reject deleted features

[janus at gcc dot gnu.org]

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

--- Comment #4 from janus at gcc dot gnu.org ---
The diagnostics for the deleted features have been implemented in r260433.

As a minor follow-up, one should get rid of the GFC_STD_F2008_TS macro and make
-std=f2008ts an alias for -std=f2018.

[Bug fortran/85841] [F2018] reject deleted features

[janus at gcc dot gnu.org]

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

--- Comment #3 from janus at gcc dot gnu.org ---
Author: janus
Date: Mon May 21 06:45:55 2018
New Revision: 260433

URL: https://gcc.gnu.org/viewcvs?rev=260433=gcc=rev
Log:
2018-05-21  Janus Weil  

PR fortran/85841
* libgfortran.h: New macros GFC_STD_OPT_*.
* error.c (notify_std_msg): New function.
(gfc_notify_std): Adjust such that it can handle combinations of
GFC_STD_* flags in the 'std' argument, not just a single one.
* match.c (match_arithmetic_if, gfc_match_if): Reject arithmetic if
in Fortran 2018.
(gfc_match_stopcode): Use GFC_STD_OPT_* macros.
* options.c (set_default_std_flags): Warn for F2018 deleted features
by default.
(gfc_handle_option): F2018 deleted features are allowed in earlier
standards.
* symbol.c (gfc_define_st_label, gfc_reference_st_label): Reject
nonblock do constructs in Fortran 2018.


2018-05-21  Janus Weil  

PR fortran/85841
* gfortran.dg/g77/19990826-3.f: Add option "-std=legacy".
* gfortran.dg/g77/20020307-1.f: Ditto.
* gfortran.dg/g77/980310-3.f: Ditto.
* gfortran.dg/goacc/loop-1-2.f95: Ditto.
* gfortran.dg/goacc/loop-1.f95: Ditto.
* gfortran.dg/gomp/appendix-a/a.6.1.f90: Ditto.
* gfortran.dg/gomp/appendix-a/a.6.2.f90: Ditto.
* gfortran.dg/gomp/do-1.f90: Ditto.
* gfortran.dg/gomp/omp_do1.f90: Ditto.
* gfortran.dg/pr17229.f: Ditto.
* gfortran.dg/pr37243.f: Ditto.
* gfortran.dg/pr49721-1.f: Ditto.
* gfortran.dg/pr58484.f: Ditto.
* gfortran.dg/pr81175.f: Ditto.
* gfortran.dg/pr81723.f: Ditto.
* gfortran.dg/predcom-2.f: Ditto.
* gfortran.dg/vect/Ofast-pr50414.f90: Ditto.
* gfortran.dg/vect/cost-model-pr34445a.f: Ditto.
* gfortran.dg/vect/fast-math-mgrid-resid.f: Ditto.
* gfortran.dg/vect/pr52580.f: Ditto.

Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/error.c
trunk/gcc/fortran/libgfortran.h
trunk/gcc/fortran/match.c
trunk/gcc/fortran/options.c
trunk/gcc/fortran/symbol.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/g77/19990826-3.f
trunk/gcc/testsuite/gfortran.dg/g77/20020307-1.f
trunk/gcc/testsuite/gfortran.dg/g77/980310-3.f
trunk/gcc/testsuite/gfortran.dg/goacc/loop-1-2.f95
trunk/gcc/testsuite/gfortran.dg/goacc/loop-1.f95
trunk/gcc/testsuite/gfortran.dg/gomp/appendix-a/a.6.1.f90
trunk/gcc/testsuite/gfortran.dg/gomp/appendix-a/a.6.2.f90
trunk/gcc/testsuite/gfortran.dg/gomp/do-1.f90
trunk/gcc/testsuite/gfortran.dg/gomp/omp_do1.f90
trunk/gcc/testsuite/gfortran.dg/pr17229.f
trunk/gcc/testsuite/gfortran.dg/pr37243.f
trunk/gcc/testsuite/gfortran.dg/pr49721-1.f
trunk/gcc/testsuite/gfortran.dg/pr58484.f
trunk/gcc/testsuite/gfortran.dg/pr81175.f
trunk/gcc/testsuite/gfortran.dg/pr81723.f
trunk/gcc/testsuite/gfortran.dg/predcom-2.f
trunk/gcc/testsuite/gfortran.dg/vect/Ofast-pr50414.f90
trunk/gcc/testsuite/gfortran.dg/vect/cost-model-pr34445a.f
trunk/gcc/testsuite/gfortran.dg/vect/fast-math-mgrid-resid.f
trunk/gcc/testsuite/gfortran.dg/vect/pr52580.f

[Bug fortran/85841] [F2018] reject deleted features

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||accepts-invalid, diagnostic
 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |janus at gcc dot gnu.org