[Bug c/84190] [7/8 Regression] double arithmetic on x86 no longer rounds to nearest

[rguenth at gcc dot gnu.org]

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

--- Comment #13 from Richard Biener  ---
Author: rguenth
Date: Fri Feb 16 07:57:56 2018
New Revision: 257722

URL: https://gcc.gnu.org/viewcvs?rev=257722=gcc=rev
Log:
2018-02-16  Richard Biener  

PR tree-optimization/84190
* tree-ssa.c (non_rewritable_mem_ref_base): Do not touch
volatile accesses if the decl isn't volatile.

* g++.dg/torture/pr84190.C: New testcase.

Added:
branches/gcc-7-branch/gcc/testsuite/g++.dg/torture/pr84190.C
Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/testsuite/ChangeLog
branches/gcc-7-branch/gcc/tree-ssa.c

[Bug c/84190] [7/8 Regression] double arithmetic on x86 no longer rounds to nearest

[rguenth at gcc dot gnu.org]

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

--- Comment #12 from Richard Biener  ---
Author: rguenth
Date: Fri Feb 16 07:56:16 2018
New Revision: 257721

URL: https://gcc.gnu.org/viewcvs?rev=257721=gcc=rev
Log:
2018-02-16  Richard Biener  

PR tree-optimization/84190
* tree-ssa.c (non_rewritable_mem_ref_base): Do not touch
volatile accesses if the decl isn't volatile.

* g++.dg/torture/pr84190.C: New testcase.

Added:
trunk/gcc/testsuite/g++.dg/torture/pr84190.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa.c

[Bug middle-end/70920] if ((intptr_t)ptr == 0) doesn't get simplified to if (ptr == 0)

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

   Keywords||patch
 CC||egallager at gcc dot gnu.org

--- Comment #6 from Eric Gallager  ---
(In reply to prathamesh3492 from comment #5)
> (In reply to mwahab from comment #4)
> > (In reply to prathamesh3492 from comment #3)
> > > Fixed on trunk.
> > 
> > I think that this is the cause of a failure in gcc.dg/tree-ssa/pr22051-2.c
> > for arm-none-linux-gnueabihf and arm-none-eabi. 
> > 
> > With the patch, the scan-tree-dump match in the test file fails because the
> > conditional becomes
> > 
> > if (q_2(D) != 0B)
> > 
> > rather than the expected
> > 
> > if (r_3 != 0)
> > 
> > 
> > The comment in the test file suggests that the optimization might be wrong.
> Sorry for the breakage.
> Patch posted for this case:
> https://gcc.gnu.org/ml/gcc-patches/2016-08/msg00246.html
> 
> Thanks,
> Prathamesh

An updated version of this patch was approved.

[Bug target/59833] ARM soft-float extendsfdf2 fails to quiet signaling NaN

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=56828

--- Comment #15 from Eric Gallager  ---
(In reply to jos...@codesourcery.com from comment #14)
> powerpc failure of floating-point extensions to quiet signaling NaNs 
> (because loads implicitly extend from float to double in a way that's 
> defined as bit-manipulation rather than a convertFormat operation) is bug 
> 56828.

but bug 56828 was closed as INVALID...

[Bug tree-optimization/37239] peeling last iteration of a <= loop

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

   Keywords||patch
 CC||egallager at gcc dot gnu.org

--- Comment #6 from Eric Gallager  ---
(In reply to Andrew Pinski from comment #5)
> https://gcc.gnu.org/ml/gcc-patches/2015-12/msg00253.html

This was approved with a minor nit fixed

[Bug c++/84415] New: Using __m128 as a template parameter causes warnings

[myriachan at gmail dot com]

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

Bug ID: 84415
   Summary: Using __m128 as a template parameter causes warnings
   Product: gcc
   Version: 7.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: myriachan at gmail dot com
  Target Milestone: ---

Attempting to use one of the intrinsic x86 vector types like __m128 causes a
warning:

:9:30: warning: ignoring attributes on template argument '__m128 {aka
__vector(4) float}' [-Wignored-attributes]
 __m128 Purr(const Meow<__m128> )
 ^
This is really annoying in warnings-as-errors mode.

This doesn't happen for uint64x2_t on ARM or ARM64.


#include 
template 
struct Meow
{
T x;
};
__m128 Purr(const Meow<__m128> )
{
return m.x;
}

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

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-02-16
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
One less unconfirmed bug.

[Bug c++/81853] [ 6/7/8 Regression] "using namespace" is not a constant expression in a statement expression

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-02-16
 CC||msebor at gcc dot gnu.org
  Known to work||4.5.4
Summary|[C++14] "using namespace"   |[ 6/7/8 Regression] "using
   |is not a constant   |namespace" is not a
   |expression in function-like |constant expression in a
   |macro   |statement expression
 Ever confirmed|0   |1
  Known to fail||4.6.4, 4.7.4, 4.8.4, 4.9.4,
   ||5.5.0, 6.4.0, 7.2.0, 8.0

--- Comment #1 from Martin Sebor  ---
Confirmed with the simplified test case below.  GCC 4.5 compiles the test case
without a complaint so the failure is a regression introduced in r166167.

$ cat t.C && gcc -S -Wall -Wextra -Wpedantic t.C
namespace N {
  enum { i };
}

int g ()
{
  constexpr int j = ({ using namespace N; i; });
  return j;
}
t.C: In function ‘int g()’:
t.C:7:21: warning: ISO C++ forbids braced-groups within expressions
[-Wpedantic]
   constexpr int j = ({ using namespace N; i; });
 ^
t.C:7:40: error: statement is not a constant expression
   constexpr int j = ({ using namespace N; i; });
^

[Bug c/67999] Wrong optimization of pointer comparisons

[danielmicay at gmail dot com]

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

--- Comment #28 from Daniel Micay  ---
I got jemalloc / Bionic libc (Android) to report errors for malloc and
mmap/mremap larger than PTRDIFF_MAX a while ago (along with fixing a missing
case for mremap in musl), but glibc needs to be convinced to do the same. It
would be a lot easier to convince them with this officially documented. I think
it's perfectly reasonable if it's clearly stated that objects larger than
PTRDIFF_MAX are not supported and that the libc implementation needs to deal
with it.

[Bug other/81831] -Wno-psabi is not documented

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-02-16
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Martin Sebor  ---
Confirmed.  The option is referred to by other options but it itself is not
documented as it should be.

$ grep -e Wpsabi -e Wno-psabi
gcc/doc/invoke.texi:you use the @option{-Wno-psabi} option.
gcc/doc/invoke.texi:you use the @option{-Wno-psabi} option.
gcc/doc/invoke.texi.orig:you use the @option{-Wno-psabi} option.
gcc/doc/invoke.texi.orig:you use the @option{-Wno-psabi} option.

[Bug c/67999] Wrong optimization of pointer comparisons

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org

--- Comment #27 from Martin Sebor  ---
(In reply to Alexander Cherepanov from comment #4)
> Interesting. In particular, this means that the warning "Argument 'size' of
> function malloc has a fishy (possibly negative) value" from valgrind is a
> serious thing. Is this gcc limitation documented somewhere? Is there a
> better reference than this bug?

GCC 7 and later mention it in the documentation of the
-Walloc-size-larger-than=n option.  It should be documented more prominently. 
They also diagnose the program in comment #0:

pr67999.c: In function ‘main’:
pr67999.c:7:15: warning: argument 1 value ‘3221225472’ exceeds maximum object
size 2147483647 [-Walloc-size-larger-than=]
   char *buf = malloc(len);
   ^~~
In file included from pr67999.c:2:
/usr/include/stdlib.h:427:14: note: in a call to allocation function ‘malloc’
declared here
 extern void *malloc (size_t __size) __THROW __attribute_malloc__ __wur;
  ^~
> 
> Am I right that the C standards do not allow for such a limitation (and
> hence this should not be reported to glibc as a bug) and gcc is not
> standards-compliant in this regard? Or I'm missing something?

I think malloc() should fail for such large requests because objects that big
don't satisfy the basic requirements on pointer arithmetic.

[Bug c++/84414] miscompile due to assuming that object returned by value cannot alias its own member pointer values

[richard-gccbugzilla at metafoo dot co.uk]

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

--- Comment #2 from Richard Smith  ---
> Where does the scope of object A inside Foo begin and end?

There is formally only one object. The object constructed in the return
statement of Foo is simply the same object that is named 'a' within Bar.


> Maybe it is time to file a DR to the C++ language folks about this case
> if there is not one already.

Hmm, the [class.temporary]/3 rule already gets very close to allowing this:

"When an object of class type X is passed to or returned from a function, if
each copy constructor, move constructor, and destructor of X is either trivial
or deleted, and X has at least one non-deleted copy or move constructor,
implementations are permitted to create a temporary object to hold the function
parameter or result object. The temporary object is constructed from the
function argument or return value, respectively, and the function’s parameter
or return object is initialized as if by using the non-deleted trivial
constructor to copy the temporary (even if that constructor is inaccessible or
would not be selected by overload resolution to perform a copy or move of the
object). [ Note: This latitude is granted to allow objects of class type to be
passed to or returned from functions in registers. — end note ]"

In fact, I think the *only* problem here is that the above rule does not allow
the caller and the callee to observe the objects having the same address.

I'll take this to the committee and see whether we can get that rule relaxed
slightly.

Would you be OK with this optimization only being permitted for the above class
types (those that can be passed/returned in registers)?

[Bug c++/81789] CWG1687 performed too soon

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||accepts-invalid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-02-16
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
Confirmed.  This was never rejected, so it's not a regression.  Looks like the
issue resolution is not implemented yet.

[Bug c++/83227] [7/8 Regression] internal compiler error: in process_init_constructor_array

[jason at gcc dot gnu.org]

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

--- Comment #3 from Jason Merrill  ---
Author: jason
Date: Fri Feb 16 02:47:19 2018
New Revision: 257720

URL: https://gcc.gnu.org/viewcvs?rev=257720=gcc=rev
Log:
PR c++/83227 - C++17 ICE with init-list derived-to-base conversion.

* call.c (convert_like_real): Don't use the copy-list-initialization
shortcut for ck_base.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/initlist98.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/call.c

[Bug c++/84349] [6/7/8 Regression] ICE with auto in function cast

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

[Bug c++/84349] [6/7/8 Regression] ICE with auto in function cast

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

  Known to work||4.8.4
  Known to fail||4.9.4, 5.5.0, 6.4.0, 7.2.0,
   ||8.0

--- Comment #2 from Martin Sebor  ---
A slightly simpler test case:

  void *p = (int(*)(auto))0;

The bug seems to be that the auto isn't rejected in this context (namespace
scope).  The same initializer is rejected in local scope.

Accepting it in an initializer expression results in incrementing the
processing_template_decl counter in the test case from its initial value of
zero to 1.  The counter doesn't get decremented back to zero which then
triggers the unpaired call to finish_lambda_scope() below:

  if (!member_p && processing_template_decl)
start_lambda_scope (decl);
  initializer = cp_parser_initializer (parser,
   _direct_init,
   _non_constant_init);
  if (!member_p && processing_template_decl)
finish_lambda_scope ();

AFAICS, the problem is somewhere in cp_parser_decl_specifier_seq() that creates
a decl_specifiers.type for the initializer at global scope for which
type_uses_auto() returns null.

[Bug debug/84404] Several "leb128 operand is an undefined symbol" in go testsuite with latest debug improvements

[asolokha at gmx dot com]

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

--- Comment #4 from Arseny Solokha  ---
(In reply to Arseny Solokha from comment #3)
> I see the same issue

This is x86_64-pc-linux-gnu.

[Bug debug/84404] Several "leb128 operand is an undefined symbol" in go testsuite with latest debug improvements

[asolokha at gmx dot com]

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

Arseny Solokha  changed:

   What|Removed |Added

 CC||asolokha at gmx dot com

--- Comment #3 from Arseny Solokha  ---
I see the same issue w/ the following snippet compiled w/ -O2
-ftree-parallelize-loops=2 -floop-nest-optimize -g:

int te[9];

void
dt (int cz)
{
  while (cz < 1)
{
  int xy;

  for (xy = 0; xy < 9; ++xy)
te[xy] = 0;

  ++cz;
}
}

% gcc-8.0.0-alpha20180211 -O2 -ftree-parallelize-loops=2 -floop-nest-optimize
-g -c pr84404.c
/tmp/ccfu80w2.s: Assembler messages:
/tmp/ccfu80w2.s:700: Error: leb128 operand is an undefined symbol: .LVU12

as of r257571.

GNU as 2.30 seems to be the key here.

[Bug fortran/84389] Defined output: unexpected compiler error with the use of ":" edit descriptor

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #5 from Steve Kargl  ---
This patch fixes the problem, but I'm in an area of
the compiler that I do not too well.  It might open
gfortran to other problems.  Jerry, any comments?

Index: io.c
===
--- io.c(revision 257695)
+++ io.c(working copy)
@@ -1012,8 +1012,7 @@ data_desc:
  goto between_desc;

default:
- error = unexpected_element;
- goto syntax;
+ goto format_item_1;
}
   break;

[Bug c++/84414] miscompile due to assuming that object returned by value cannot alias its own member pointer values

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
To me, the temp object A inside Foo ends its scope at the end function (even
with guaranteed copy elision).

Because this would mean the compiler will have to assume nothing about any
structs that are returned which seems backwards and even counter to the
language itself.

Maybe it is time to file a DR to the C++ language folks about this case if
there is not one already.  Where does the scope of object A inside Foo begin
and end?

[Bug libstdc++/83982] Exception guarantee of C++14 vector::resize(size_type) is not met

[dtrebbien at gmail dot com]

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

--- Comment #5 from Daniel Trebbien  ---
Ah! Thank you for letting me know.

[Bug c++/84414] New: miscompile due to assuming that object returned by value cannot alias its own member pointer values

[richard-gccbugzilla at metafoo dot co.uk]

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

Bug ID: 84414
   Summary: miscompile due to assuming that object returned by
value cannot alias its own member pointer values
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: richard-gccbugzilla at metafoo dot co.uk
CC: timshen at gcc dot gnu.org
  Target Milestone: ---

GCC (all versions) miscompiles this code:


struct A {
  A *children;
  long long arr[100];

  A() : children() {}
  A(int) : children(this) {}
};

__attribute__((noinline))
A Foo() {
  return A(0);
}

A x[3] = {};

void Bar(int n) {
  A a = Foo();
  for (int i = 0; i < n; i++) {
a.children[i].children = x;
  }
}

int main() {
Bar(3);
return x[0].children || !x[1].children || !x[2].children;
}


A correct compilation must return 0 from main, but GCC at -O2 returns 1. The
reason is that it fails to reload 'a.children' on each iteration of the loop in
'Bar', reasoning (incorrectly) that the store to 'a.children[i].children'
cannot alias 'a.children' because 'a' has not escaped.

The above code has defined behavior in C++17, where the 'guaranteed copy
elision' rules mean that the 'this' pointer inside the A::A(int) constructor
points to the 'a' object inside 'Bar'. But since GCC chooses to perform copy
elision on this code in all language modes (and always has done so), and the
fact that it performed copy-elision is observable, this is not a C++17-specific
bug. (The same miscompile can also be observed via NRVO.)

[Bug c++/84355] [7/8 Regression] ICE with failing template argument deduction

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #2 from Martin Sebor  ---
Patch: https://gcc.gnu.org/ml/gcc-patches/2018-02/msg00944.html

[Bug fortran/80945] Invalid code with allocatable character array in READ/WRITE statement

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

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

--- Comment #9 from Paul Thomas  ---
Created attachment 43438
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43438=edit
A demo patch for the PR

This does the job but sucks stylistically. I will sort out something better.

It does regtest fine, though :-) It also fixes:

program main
implicit none
integer:: i
integer, parameter:: N = 10
character(len=:), dimension(:),allocatable:: ca
character(len=:), dimension(:,:),allocatable:: cb
allocate(character(len=N) :: ca(3))
ca(1) = "foo"
ca(2) = "bar"
ca(3) = "xyzzy"
write (*, '(3A5)') ca(1:3)
allocate(character(len=N) :: cb(3,2))
cb(1,1) = "foo"
cb(2,1) = "bar"
cb(3,1) = "xyzzy"
write (*, '(3A5)') cb(1:3,1) ! Hence the assignment of the rank!  
end program

Paul

[Bug c++/84355] [7/8 Regression] ICE with failing template argument deduction

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

[Bug c++/70076] no exception for excess initializer elements in a multidimensional VLA

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

   Keywords||patch
 CC||egallager at gcc dot gnu.org,
   ||jason at gcc dot gnu.org
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=69517

--- Comment #2 from Eric Gallager  ---
(In reply to Martin Sebor from comment #1)
> Patch for bug 69517 posted for review (below) includes a fix for this bug as
> well:
> https://gcc.gnu.org/ml/gcc-patches/2016-03/msg00441.html

Adding "patch" keyword then

[Bug fortran/84354] Replace '%qs' with %qs in fortran/decl.c

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

   Keywords||easyhack
 CC||egallager at gcc dot gnu.org
   Severity|normal  |trivial

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

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #62 from Eric Gallager  ---
(In reply to Jeffrey A. Law from comment #61)
> Punting to gcc-8.  The patch needs additional work and Aldy is poking at
> something else at this point.  The Aldy's analysis of the AIX issue should
> allow this to be pushed forward in the gcc-8 development cycle.

Same logic to punt to gcc-9 at this point?

[Bug middle-end/49899] ICE when redeclaring a static function as weak

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

   Keywords||patch
 CC||egallager at gcc dot gnu.org

--- Comment #3 from Eric Gallager  ---
(In reply to Nick Clifton from comment #2)
> I have proposed the patch on the gcc-patches list:
> 
>   https://gcc.gnu.org/ml/gcc-patches/2016-02/msg01180.html

Adding "patch" keyword

[Bug c++/83227] [7/8 Regression] internal compiler error: in process_init_constructor_array

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug target/84413] -march=skylake-avx512 disables BT instruction

[ubizjak at gmail dot com]

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

--- Comment #1 from Uroš Bizjak  ---
Besides X86_TUNE_USE_BT, there is probably a long list of flags that have to be
enabled for m_SKYLAKE_AVX512 (and m_CANNONLAKE and m_ICELAKE).

Somebody will have to go through all tune flags for the above mentioned
targets.

[Bug fortran/84381] replace non-std 'call abort' by 'stop 1' in gfortran testsuite

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-02-15
  Component|testsuite   |fortran
 Ever confirmed|0   |1

--- Comment #4 from Thomas Koenig  ---
Better as a fortran issue - I searched for it in
the Fortran bugs, and missed it at first.

Confirming.

[Bug fortran/84094] several correctness issues in gfortran.dg

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

  Component|testsuite   |fortran

--- Comment #4 from Thomas Koenig  ---
Makes more sense as a Fortran issue, IMHO.

[Bug target/84363] [8 Regression] Assembler error in stage1/libgcc: Error: view number mismatch

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

--- Comment #2 from Jeffrey A. Law  ---
Should be fixed by r257631.

[Bug c++/82468] [7/8 Regression] ICE with deduction guide template

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |paolo.carlini at oracle 
dot com

--- Comment #3 from Paolo Carlini  ---
Looking into it.

[Bug c++/84045] [7 Regression] ICE when is_nothrow_default_constructible is used before #include

[jason at gcc dot gnu.org]

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

--- Comment #4 from Jason Merrill  ---
Author: jason
Date: Thu Feb 15 22:01:33 2018
New Revision: 257713

URL: https://gcc.gnu.org/viewcvs?rev=257713=gcc=rev
Log:
PR c++/84045 - ICE with typedef and noexcept.
* except.c (build_noexcept_spec): Use strip_typedefs_expr.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/noexcept32.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/except.c

[Bug tree-optimization/81611] [8 Regression] gcc un-learned loop / post-increment optimization

[law at redhat dot com]

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

--- Comment #23 from Jeffrey A. Law  ---
No, the DOM change is only a partial fix.  I've largely approved the auto-inc
change.  I recommend the additional tests in c#19 be pulled into a distinct BZ
and the gcc8 regression marker removed once the auto-inc changes are committed.

[Bug target/84406] [8 Regression][MSP430] ICE on valid code in find_widening_optab_handler_and_mode, at optabs-query.c:476

[jozefl.gcc at gmail dot com]

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

--- Comment #12 from Jozef Lawrynowicz  ---
(In reply to rsand...@gcc.gnu.org from comment #11)
> Created attachment 43437 [details]
> Possible patch v2
> 
> This time for real.

Thanks, patch looks good to me, and the original testcase does indeed pass with
it applied.

Trunk still doesn't build for msp430-elf, but that seems to be an unrelated bug
in libstdc++.

[Bug tree-optimization/81611] [8 Regression] gcc un-learned loop / post-increment optimization

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #22 from Eric Gallager  ---
(In reply to Alexandre Oliva from comment #21)
> Author: aoliva
> Date: Tue Jan 30 17:40:50 2018
> New Revision: 257194
> 
> URL: https://gcc.gnu.org/viewcvs?rev=257194=gcc=rev
> Log:
> [PR81611] accept copies in simple_iv_increment_p
> 
> If there are copies between the GIMPLE_PHI at the loop body and the
> increment that reaches it (presumably through a back edge), still
> regard it as a simple_iv_increment, so that we won't consider the
> value in the back edge eligible for forwprop.  Doing so would risk
> making the phi node and the incremented conflicting value live
> within the loop, and the phi node to be preserved for propagated
> uses after the loop.
> 
> for  gcc/ChangeLog
> 
>   PR tree-optimization/81611
>   * tree-ssa-dom.c (simple_iv_increment_p): Skip intervening
>   copies.
> 
> Modified:
> trunk/gcc/ChangeLog
> trunk/gcc/tree-ssa-dom.c

Did this fix it?

[Bug bootstrap/84405] [8 Regression] Fails to bootstrap with GCC 4.1.2, GCC 4.2.4

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Another testcase that could in theory affect vec_default_construct is:
extern "C" void abort ();
typedef __typeof (sizeof (0)) size_t;
inline void *operator new (size_t, void * p) { return p; }
extern "C" void *memset (void *, int, size_t);
template
struct A { T t; U u; };
struct B { B (); ~B (); int b; };
B::B () : b (9) {}
B::~B () {}

template 
void foo (char *p) { new (p) T (); }

int
main ()
{
  int a;
  struct S
  {
A b;
char c[sizeof (A)];
  } s;
  A *p = (A *) 
  memset (s.c, 0x55, sizeof (s.c));
  foo  (s.c);
  if (p->t)
abort ();
}

and that was fixed in PR11309 / r138355 only in 4.4.
And Jon mentions another one value initialization related - PR30111.

[Bug target/65604] MIPS -fno-delayed-branch generates incorrect code with -mcheck-zero-division

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #6 from Eric Gallager  ---
(In reply to Steve Ellcey from comment #4)
> Author: sje
> Date: Fri Jan 29 16:29:58 2016
> New Revision: 232985
> 
> URL: https://gcc.gnu.org/viewcvs?rev=232985=gcc=rev
> Log:
>   PR target/65604
>   * config/mips/mips.c (mips_output_division): Check flag_delayed_branch.
> 
> Modified:
> trunk/gcc/ChangeLog
> trunk/gcc/config/mips/mips.c

(In reply to Steve Ellcey from comment #5)
> Author: sje
> Date: Fri Jan 29 16:31:18 2016
> New Revision: 232986
> 
> URL: https://gcc.gnu.org/viewcvs?rev=232986=gcc=rev
> Log:
>   PR target/65604
>   * gcc.target/mips/div-delay.c: New test.
> 
> Added:
> trunk/gcc/testsuite/gcc.target/mips/div-delay.c
> Modified:
> trunk/gcc/testsuite/ChangeLog

Did these commits fix this bug?

[Bug fortran/84389] Defined output: unexpected compiler error with the use of ":" edit descriptor

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-02-15
 Ever confirmed|0   |1

--- Comment #4 from kargl at gcc dot gnu.org ---
Confirmed.

[Bug fortran/84389] Defined output: unexpected compiler error with the use of ":" edit descriptor

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #3 from Steve Kargl  ---
On Thu, Feb 15, 2018 at 09:04:24PM +, fortranfan at outlook dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84389
> 
> --- Comment #2 from Vipul Parekh  ---
> Thank for your response.
> 
> Per section 1.4.1 in 10-007r1 toward Fortran 2008 on syntax rules toward the
> BNF convention in the document, line 16 says [] encloses an optional item.
> 
> R1303 format-items  is format-item [ [ , ] format-item ]
> 
> then suggests the comma in the format item is optional and the format in the
> first post should work as shown.
> 

Ah, indeed!  You are correct.  I simply missed the enclosing [ ]
in looking through all of the ENBDF rules.

[Bug testsuite/84094] several correctness issues in gfortran.dg

[janus at gcc dot gnu.org]

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

Bug 84409 Summary: [F03] check DTIO arguments for character len
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84409

   What|Removed |Added

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

[Bug fortran/84409] [F03] check DTIO arguments for character len

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #3 from janus at gcc dot gnu.org ---
Fixed with r257711. Closing.

[Bug libstdc++/83982] Exception guarantee of C++14 vector::resize(size_type) is not met

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
The trunk is currently closed for non-regression changes, as we prepare for the
GCC 8 release.

[Bug fortran/84409] [F03] check DTIO arguments for character len

[janus at gcc dot gnu.org]

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

--- Comment #2 from janus at gcc dot gnu.org ---
Author: janus
Date: Thu Feb 15 21:16:00 2018
New Revision: 257711

URL: https://gcc.gnu.org/viewcvs?rev=257711=gcc=rev
Log:
2018-02-15  Janus Weil  

PR fortran/84409
* interface.c (check_dtio_arg_TKR_intent): Add a check for character
length.


2018-02-15  Janus Weil  

PR fortran/84409
* gfortran.dg/dtio_21.f03: Add an error message.
* gfortran.dg/dtio_22.f90: Fix invalid test case.

Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/interface.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/dtio_21.f90
trunk/gcc/testsuite/gfortran.dg/dtio_22.f90

[Bug libstdc++/81797] gcc 7.1.0 fails to build on macOS 10.13 (High Sierra):

[redi at gcc dot gnu.org]

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

--- Comment #59 from Jonathan Wakely  ---
Should be fixed on trunk, please test and confirm.

[Bug debug/68771] Darwin: Profile guided optimisation with cold sections and invalid symbol redefinition

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #1 from Eric Gallager  ---
There's been recent changes to the __cold_sect_of_*-affecting code on Darwin;
can you check and see if this is still an issue?

[Bug fortran/84389] Defined output: unexpected compiler error with the use of ":" edit descriptor

[fortranfan at outlook dot com]

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

--- Comment #2 from Vipul Parekh  ---
Thank for your response.

Per section 1.4.1 in 10-007r1 toward Fortran 2008 on syntax rules toward the
BNF convention in the document, line 16 says [] encloses an optional item.

R1303 format-items  is format-item [ [ , ] format-item ]

then suggests the comma in the format item is optional and the format in the
first post should work as shown.

[Bug libstdc++/81797] gcc 7.1.0 fails to build on macOS 10.13 (High Sierra):

[redi at gcc dot gnu.org]

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

--- Comment #58 from Jonathan Wakely  ---
Author: redi
Date: Thu Feb 15 20:56:41 2018
New Revision: 257710

URL: https://gcc.gnu.org/viewcvs?rev=257710=gcc=rev
Log:
PR libstdc++/81797 Add .NOTPARALLEL to include/Makefile for darwin

PR libstdc++/81797
* configure.ac (INCLUDE_DIR_NOTPARALLEL): Define.
* configure: Regenerate.
* include/Makefile.am (INCLUDE_DIR_NOTPARALLEL): Add .NOTPARALLEL when
defined.
* include/Makefile.in: Regenerate.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/configure
trunk/libstdc++-v3/configure.ac
trunk/libstdc++-v3/include/Makefile.am
trunk/libstdc++-v3/include/Makefile.in

[Bug target/84413] New: -march=skylake-avx512 disables BT instruction

[hjl.tools at gmail dot com]

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

Bug ID: 84413
   Summary: -march=skylake-avx512 disables BT instruction
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: ubizjak at gmail dot com
  Target Milestone: ---
Target: x86

[hjl@gnu-skx-1 gcc]$ cat x.c
unsigned long long bextr64_demanded(unsigned long long x)
{
return x | 0x80;
}
[hjl@gnu-skx-1 gcc]$ ./xgcc -B./ -S -O2 x.c -march=skylake-avx512
[hjl@gnu-skx-1 gcc]$ cat x.s
.file   "x.c"
.text
.p2align 4,,15
.globl  bextr64_demanded
.type   bextr64_demanded, @function
bextr64_demanded:
.LFB0:
.cfi_startproc
movabsq $549755813888, %rax
orq %rdi, %rax
xorl%edi, %edi
ret
.cfi_endproc
.LFE0:
.size   bextr64_demanded, .-bextr64_demanded
.ident  "GCC: (GNU) 8.0.1 20180212 (experimental)"
.section.note.GNU-stack,"",@progbits
[hjl@gnu-skx-1 gcc]$ ./xgcc -B./ -S -O2 x.c 
[hjl@gnu-skx-1 gcc]$ cat x.s
.file   "x.c"
.text
.p2align 4,,15
.globl  bextr64_demanded
.type   bextr64_demanded, @function
bextr64_demanded:
.LFB0:
.cfi_startproc
movq%rdi, %rax
xorl%edi, %edi
btsq$39, %rax
ret
.cfi_endproc
.LFE0:
.size   bextr64_demanded, .-bextr64_demanded
.ident  "GCC: (GNU) 8.0.1 20180212 (experimental)"
.section.note.GNU-stack,"",@progbits
[hjl@gnu-skx-1 gcc]$

[Bug tree-optimization/82518] [8 regression] gfortran.fortran-torture/execute/in-pack.f90 fails on armeb since r252917

[wilco.dijkstra at arm dot com]

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

--- Comment #42 from Wilco  ---
Cut down example:

typedef struct { int x, y; } X;

void f (X *p, int n)
{
  for (int i = 0; i < n; i++)
  { p[i].x = i;
p[i].y = i + 1;
  }
}

[Bug testsuite/84381] replace non-std 'call abort' by 'stop 1' in gfortran testsuite

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 CC||tkoenig at gcc dot gnu.org

--- Comment #3 from Thomas Koenig  ---
The actual commit was r257702 .

[Bug target/82989] [7/8 regression ] Inexplicable use of NEON for 64-bit math

[matthijsvanduin at gmail dot com]

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

--- Comment #9 from Matthijs van Duin  ---
I can still reproduce the same test case with:  arm-linux-gnueabihf-gcc-8
(Debian 8-20180207-2) 8.0.1 20180207 (experimental) [trunk revision 257435]


-mfloat-abi=hard is implicit for arm-linux-gnueabihf, although overriding that
to -mfloat-abi=softfp produces exactly the same result for me.

(-mfloat-abi=soft completely disables all use of VFP/Neon hence obviously
suppresses this problem.)

[Bug c++/84045] [7/8 Regression] ICE when is_nothrow_default_constructible is used before #include

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug target/84154] [7 Regression] PowerPC GCC 7 and 8 have regression in converting fp to short/char and returning it

[meissner at gcc dot gnu.org]

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

--- Comment #10 from Michael Meissner  ---
Author: meissner
Date: Thu Feb 15 19:57:46 2018
New Revision: 257707

URL: https://gcc.gnu.org/viewcvs?rev=257707=gcc=rev
Log:
2018-02-15  Michael Meissner  

Back port from trunk
2018-02-06  Michael Meissner  

PR target/84154
* config/rs6000/rs6000.md (su code attribute): Use "u" for
unsigned_fix, not "s".


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

[Bug c++/81764] [6/7/8 Regression] Visibility attributes for explicitly instantiated template class get warned if it has been implicitly instantiated

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Known to work||4.1.0
   Keywords||diagnostic
   Last reconfirmed||2018-02-15
 CC||msebor at gcc dot gnu.org
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=84318
 Ever confirmed|0   |1
Summary|Visibility attributes for   |[6/7/8 Regression]
   |explicitly instantiated |Visibility attributes for
   |template class get warned   |explicitly instantiated
   |if it has been implicitly   |template class get warned
   |instantiated|if it has been implicitly
   ||instantiated
  Known to fail||4.2.2, 4.3.2, 4.6.0, 5.4.0,
   ||6.3.0, 7.2.0, 8.0

--- Comment #1 from Martin Sebor  ---
The warning might be helpful if the explicit specialization declaration
attempted to specify different visibility that the primary template (assuming
the declaration of the specialization inherits the attribute from the template)
but it's pointless when it simply reiterates the same visibility, and it would
be wrong if the specialization didn't "inherit" its attributes from the
primary.  With that, I would say that it's not desirable (even though it is
intended in other cases). With that I confirm it as a bug.

The warning wasn't issued prior to r115086 (committed into GCC 4.2) so it's
also aa regression, albeit a very old one.

As the test case below shows, the warning isn't unique to the visibility
attribute.  It affects other type attributes as well.  Here too the warning is
pointless regardless of how attributes are treated.

Unfortunately, specifying an attribute on the declaration of an explicit
instantiation isn't specified either in C++ or in G++ and it not clear that we
know or have consensus what we want it to mean (see for example bug 84318), so
this bug isn't likely to get a lot attention until the confusion around
attributes and templates has been cleared up.

$ cat t.C && gcc -S -Wall -Wextra -Wpedantic t.C
template  class A;

template 
struct alignas (32) A
{
  static int f () { return A<>::f (); }
};

extern template struct alignas (32) A<>;

static_assert (alignof (A<>) == 32, "");
t.C:9:37: warning: type attributes ignored after type is already defined
[-Wattributes]
 extern template struct alignas (32) A<>;
 ^~~

[Bug target/84406] [8 Regression][MSP430] ICE on valid code in find_widening_optab_handler_and_mode, at optabs-query.c:476

[rsandifo at gcc dot gnu.org]

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

--- Comment #11 from rsandifo at gcc dot gnu.org  
---
Created attachment 43437
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43437=edit
Possible patch v2

This time for real.

[Bug jit/84288] Support jit on Solaris

[ro at gcc dot gnu.org]

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

--- Comment #4 from Rainer Orth  ---
(In reply to Rainer Orth from comment #0)
[...]
> * In the 32-bit case, two tests FAIL like this:
> 
>   PASSED: test-vector-rvalues.cc.exe iteration 1 of 5: verify_vec_code: 
> fn is
> non-null
>   FAILED: test-vector-rvalues.cc.exe iteration 1 of 5: check_div: actual:
> c[i] != expected: a[i] / b[i]
> incorrect value
[...]
> FAILED: test-vector-types.cc.exe iteration 1 of 5: check_div:
> actual: c[i] != expected: a[i] / b[i]
> incorrect value
[...]
>   ISTM that check_div needs to use CHECK_DOUBLE_VALUE here.

I've just run an i686-pc-linux-gnu build and see exactly the same errors.  So
this
seems to be a 32-bit (or 32-bit x86) issue.

[Bug target/84406] [8 Regression][MSP430] ICE on valid code in find_widening_optab_handler_and_mode, at optabs-query.c:476

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

  Attachment #43435|0   |1
is obsolete||

--- Comment #10 from rsandifo at gcc dot gnu.org  
---
Created attachment 43436
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43436=edit
Possible patch v2

Sigh, attached wrong file last time.

[Bug c++/84376] [7/8 Regression] ICE with missing template parameter

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|7.4 |8.0

--- Comment #2 from Jason Merrill  ---
Fixed for GCC 8.

[Bug c++/84376] [7/8 Regression] ICE with missing template parameter

[jason at gcc dot gnu.org]

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

--- Comment #3 from Jason Merrill  ---
Author: jason
Date: Thu Feb 15 19:46:13 2018
New Revision: 257706

URL: https://gcc.gnu.org/viewcvs?rev=257706=gcc=rev
Log:
PR c++/84376 - ICE with omitted template arguments.

* pt.c (dguide_name_p): Check for IDENTIFIER_NODE.

Added:
trunk/gcc/testsuite/g++.dg/cpp1z/class-deduction47.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c

[Bug target/84406] [8 Regression][MSP430] ICE on valid code in find_widening_optab_handler_and_mode, at optabs-query.c:476

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

  Attachment #43434|0   |1
is obsolete||

--- Comment #9 from rsandifo at gcc dot gnu.org  
---
Created attachment 43435
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43435=edit
Possible patch v2

(In reply to Jakub Jelinek from comment #8)
> From the above comments, from_mode can be also MODE_INT and to_mode
> MODE_PARTIAL_INT, though I wonder how, because it clearly couldn't reach the
> PSImode by FOR_EACH_MODE.

Ah, missed that.  So in those cases, the limit mode should
be the containing MODE_INT rather than to_mode itself.

Second try.

[Bug tree-optimization/84114] global reassociation pass prevents fma usage, generates slower code

[sje at gcc dot gnu.org]

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

--- Comment #4 from Steve Ellcey  ---
While teaching the reassociation pass about fma's seems like the right answer
would it be reasonable (and simpler) to do the fma pass
(pass_optimize_widening_mul) before
the reassociation pass (pass_reassoc) to get the most fma's?

That fixes my small test case but I haven't done a bigger performance check
to see what the overall impact would be.

[Bug fortran/84412] New: Erroneous "Inquire statement identifies an internal file" error

[abensonca at gmail dot com]

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

Bug ID: 84412
   Summary: Erroneous "Inquire statement identifies an internal
file" error
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: abensonca at gmail dot com
  Target Milestone: ---

Using gfortran 8.0.1 (r257607) the following produces an erroneous error of
"Inquire statement identifies an internal file":

program bug
  implicit none
  integer  :: i
  character(len=1) :: s
  write (s,'(i1)') 0
  open(newUnit=i,file='bug.txt',status='unknown')
  inquire(unit=i)
end program bug

$ gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/home/abenson/Galacticus/Tools/libexec/gcc/x86_64-pc-linux-gnu/8.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --prefix=/home/abenson/Galacticus/Tools
--enable-languages=c,c++,fortran --disable-multilib
Thread model: posix
gcc version 8.0.1 20180212 (experimental) (GCC) 

$ gfortran bug.F90

$ a.out 
At line 7 of file bug.F90
Fortran runtime error: Inquire statement identifies an internal file

Error termination. Backtrace:
#0  0x7fd470750d44 in inquire_via_unit
at ../../../gcc-trunk/libgfortran/io/inquire.c:47
#1  0x400969 in ???
#2  0x4009a0 in ???
#3  0x7fd46fb7ed0c in __libc_start_main
at /data001/abenson/Galacticus/Tools/glibc-2.12.1/csu/libc-start.c:226
#4  0x4006f8 in ???

If the WRITE statement is removed the error does not occur.

[Bug bootstrap/84405] [8 Regression] Fails to bootstrap with GCC 4.1.2, GCC 4.2.4

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
So, seems it is that hash-table.h change that really doesn't work in GCC
r132088, not just 4.2.*, but any (tried even 3.2).

The implicitly defined default constructor for A (hash_map<...>::hash_entry in
gcc) doesn't initialize the POD t field (which is correct I assume, current
trunk doesn't do that either), but the value initialization before r132088 only
constructs the non-POD u field of A and doesn't initialize t at all (in GCC
that is the m_key, in the stuck case with type edge_def *).

extern "C" void abort ();
template
struct A { T t; U u; };
struct B { B (); ~B (); int b; };
B::B () : b (9) {}
B::~B () {}
template 
void foo (T *p) { *p = T (); }

int
main ()
{
  int a;
  A h;
  h.t = 
  foo ();
  if (h.t)
abort ();
}

So, either we need to conditionally revert (for say
#if GCC_VERSION != 0 && GCC_VERSION < 4003 && !defined(__clang__)
) the hash-table.h change and use memset.h for old GCCs, or we need some
template hackery to determine if value_type is hash_map::hash_entry
from hash-map.h and instead of using *entries = value_type (); do
entries->m_key = value_type::compare_type ();
entries->m_value = something ();

Ugh.

[Bug libstdc++/83982] Exception guarantee of C++14 vector::resize(size_type) is not met

[dtrebbien at gmail dot com]

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

--- Comment #3 from Daniel Trebbien  ---
Friendly reminder: I have attached a patch for this issue which I would like to
have reviewed and committed.

[Bug target/84406] [8 Regression][MSP430] ICE on valid code in find_widening_optab_handler_and_mode, at optabs-query.c:476

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  ---
Comment on attachment 43434
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43434
Possible patch

From the above comments, from_mode can be also MODE_INT and to_mode
MODE_PARTIAL_INT, though I wonder how, because it clearly couldn't reach the
PSImode by FOR_EACH_MODE.

[Bug target/84406] [8 Regression][MSP430] ICE on valid code in find_widening_optab_handler_and_mode, at optabs-query.c:476

[rsandifo at gcc dot gnu.org]

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

--- Comment #7 from rsandifo at gcc dot gnu.org  
---
Created attachment 43434
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43434=edit
Possible patch

This is the kind of change I was thinking of.

[Bug target/84406] [8 Regression][MSP430] ICE on valid code in find_widening_optab_handler_and_mode, at optabs-query.c:476

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #6 from Jakub Jelinek  ---
Well, there are two assertions, and without the first one the second one
doesn't work either, modes from different classes aren't well ordered.

[Bug c++/84411] New: Missed optimization: static guard variable generated for empty virtual destructor

[arthur.j.odwyer at gmail dot com]

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

Bug ID: 84411
   Summary: Missed optimization: static guard variable generated
for empty virtual destructor
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: arthur.j.odwyer at gmail dot com
  Target Milestone: ---

Consider the following program:

struct Base {
constexpr Base() = default;
virtual int foo();
// virtual ~Base() = default;
};
struct Derived : public Base {
constexpr Derived() = default;
virtual int foo() override;
};
Base& get_base() {
static Derived d;
return d;
}

This is a simplified version of the current idioms around `std::error_category`
and `std::pmr::memory_resource`, except that for now I have commented-out the
virtual destructor.
Notice that because `Derived d` is trivially destructible, no atomic guard
variable is generated to register its destructor with __cxa_atexit.

Now uncomment the defaulted virtual destructor of `Base`. The semantics of
`Derived d` have not changed: we are still expecting to call ~Derived by
non-virtual dispatch, and ~Derived is still known statically to be a no-op. But
now suddenly GCC decides to generate an atomic guard variable and a call to
`__cxa_atexit`!

I think GCC could do better here, and if it did, it would eliminate a lot of
atomic instructions in the critical path for things like `std::error_code{}`
and `std::pmr::new_delete_resource()`.

[Bug target/84406] [8 Regression][MSP430] ICE on valid code in find_widening_optab_handler_and_mode, at optabs-query.c:476

[rsandifo at gcc dot gnu.org]

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

--- Comment #5 from rsandifo at gcc dot gnu.org  
---
(In reply to Jakub Jelinek from comment #4)
> I think Richard needs to explain why he changed the function from using
> GET_MODE_WIDER_MODE to the assert + simple iteration on modes, it isn't
> clear from his patch why it was changed.  Does that not really work with the
> variable sized modes on SVE?

FOR_EACH_MODE does use GET_MODE_WIDER_MODE.  I think problem is just
with the assertion.

[Bug bootstrap/82939] genmatch fills up terminal with endless printing of periods

[egallager at gcc dot gnu.org]

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

--- Comment #16 from Eric Gallager  ---
(In reply to Jakub Jelinek from comment #15)
> Full testcase suitable for configure:
> extern "C" void abort ();
> struct S { ~S () { if (x) abort (); }; int x, y, z; };
> void foo (S *p) { *p = S (); }
> int main () { S s; s.x = 1; s.y = 2; s.z = 3; foo (); if (s.x != 0 || s.y
> != 0 || s.z != 0) abort (); }
> Given how many places r249234 changed, adding workarounds for the PR33916
> GCC 4.2.[0-3] bug might be too pervasive.  All 4.2.* compilers from 20061017
> to 20080212 are likely broken, unless patched.

I can confirm that this aborts for me when compiled with g++ 4.2.1 with -O2.

[Bug debug/83758] ICE building gccgo on powerpc64le --with-cpu=power8

[acsawdey at gcc dot gnu.org]

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

acsawdey at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #38 from acsawdey at gcc dot gnu.org ---
Backports complete, so this can be closed.

[Bug testsuite/84381] replace non-std 'call abort' by 'stop 1' in gfortran testsuite

[tkoenig at gcc dot gnu.org]

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

--- Comment #2 from Thomas Koenig  ---
Author: tkoenig
Date: Thu Feb 15 18:46:22 2018
New Revision: 257703

URL: https://gcc.gnu.org/viewcvs?rev=257703=gcc=rev
Log:
2018-02-15  Thomas Koenig  

PR fortran/84381
* gfortran.dg/stop_shouldfail.f90: New test.


Modified:
trunk/gcc/testsuite/ChangeLog

[Bug target/84406] [8 Regression][MSP430] ICE on valid code in find_widening_optab_handler_and_mode, at optabs-query.c:476

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
I think Richard needs to explain why he changed the function from using
GET_MODE_WIDER_MODE to the assert + simple iteration on modes, it isn't clear
from his patch why it was changed.  Does that not really work with the variable
sized modes on SVE?

[Bug target/84406] [8 Regression][MSP430] ICE on valid code in find_widening_optab_handler_and_mode, at optabs-query.c:476

[jozefl.gcc at gmail dot com]

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

--- Comment #3 from Jozef Lawrynowicz  ---
Created attachment 43433
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43433=edit
define {u,}mulhipsi3 insns

I applied the patch but trunk still ICEs.

After defining some insns for "umulhipsi3" and "mulhipsi3" in msp430.md, the
build gets a little further, but then a case is encountered where a widen from
QI to PSI is attempted. QI != PARTIAL_INT_MODE, so we ICE again.

The insns in attached patch are mostly just copied from the mulhisi*, so are
almost definitely not correct, but they are at least there for GCC to use in
the build.

[Bug bootstrap/84402] [meta] GCC build system: parallelism bottleneck

[marxin at gcc dot gnu.org]

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

--- Comment #11 from Martin Liška  ---
(In reply to Martin Liška from comment #10)
> Created attachment 43432 [details]
> Parallel build of make all-host on 8 core Haswell machine

This was generated with a slightly modified make (being able to run fully in
parallel):
https://github.com/marxin/make/tree/timestamp-v2

And output is then parsed and 'stacked' graph is generated:
https://github.com/marxin/script-misc/blob/master/parse-make-log-parallel.py

[Bug libffi/84410] libffi doesn't support riscv now, but not disabled in configure.ac

[sch...@linux-m68k.org]

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

--- Comment #1 from Andreas Schwab  ---
Neither does libgo support RISC-V yet.

[Bug translation/84303] Styled quotes in error message may be inappropriate

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Sebor  ---
I'll confirm this.

I would suggest to consider adopting the convention used by other back ends
(e.g, mips or i386) for spelling attribute target: "attribute %"
(i.e., the word attribute is not quoted but the keyword target is), and/or for
attributes in general used by the middle-end ("% attribute").

This convention is helpful because there are at least two ways of spelling an
attribute in user code, depending on the language:

__attribute__ ((target)) in both C and C++
[[gnu::target]] in C++

C hasn't adopted the C++ syntax but a proposal for including it in C2X has been
submitted and favorably received.  At the same time, some people on the C
committee have been arguing for alternate syntax along the lines of

_Attribute (target)

If this were to adopted (either in favor of the C++ notation or in addition to
it), there would be three different ways to spell the same thing.

Unless GCC can determine and use what appears in the source code using a
generic spelling is less confusing or misleading.

[Bug debug/83758] ICE building gccgo on powerpc64le --with-cpu=power8

[acsawdey at gcc dot gnu.org]

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

--- Comment #37 from acsawdey at gcc dot gnu.org ---
Author: acsawdey
Date: Thu Feb 15 18:36:20 2018
New Revision: 257701

URL: https://gcc.gnu.org/viewcvs?rev=257701=gcc=rev
Log:
2018-02-15  Aaron Sawdey  

Back port from mainline
2018-01-30  Aaron Sawdey  

PR target/83758
* config/rs6000/rs6000.c (rs6000_internal_arg_pointer): Only return
a reg rtx.




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

[Bug c++/84376] [7/8 Regression] ICE with missing template parameter

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug bootstrap/84402] [meta] GCC build system: parallelism bottleneck

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

  Attachment #43428|0   |1
is obsolete||

--- Comment #10 from Martin Liška  ---
Created attachment 43432
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43432=edit
Parallel build of make all-host on 8 core Haswell machine

[Bug c++/84368] [8 Regression] return type of generic lambda in variadic lambda in template is not deduced

[jason at gcc dot gnu.org]

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

--- Comment #6 from Jason Merrill  ---
Author: jason
Date: Thu Feb 15 18:15:32 2018
New Revision: 257699

URL: https://gcc.gnu.org/viewcvs?rev=257699=gcc=rev
Log:
PR c++/84368 - wrong error with local variable in variadic lambda.

* pt.c (tsubst_pack_expansion): Fix handling of non-packs in
local_specializations.

Added:
trunk/gcc/testsuite/g++.dg/cpp1y/lambda-generic-variadic14.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c

[Bug c++/84368] [8 Regression] return type of generic lambda in variadic lambda in template is not deduced

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #5 from Jason Merrill  ---
Fixed.

[Bug c++/70401] [c++1z on mingw]compile variadic template failed

[rai...@emrich-ebersheim.de]

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

--- Comment #5 from Rainer Emrich  ---
For a recent trunk version 8.0.1 20180207 (experimental) [trunk revision
257437] it's the same.

[Bug c++/84330] [6/7 Regression] [concepts] ICE with broken constraint

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

Summary|[6/7/8 Regression]  |[6/7 Regression] [concepts]
   |[concepts] ICE with broken  |ICE with broken constraint
   |constraint  |

--- Comment #5 from Paolo Carlini  ---
Fixed in trunk.

[Bug c++/84330] [6/7/8 Regression] [concepts] ICE with broken constraint

[paolo at gcc dot gnu.org]

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

--- Comment #4 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Thu Feb 15 18:05:40 2018
New Revision: 257698

URL: https://gcc.gnu.org/viewcvs?rev=257698=gcc=rev
Log:
/cp
2018-02-15  Paolo Carlini  

PR c++/84330
* constraint.cc (tsubst_constraint_info): Handle an error_mark_node
as first argument.

/testsuite
2018-02-15  Paolo Carlini  

PR c++/84330
* g++.dg/concepts/pr84330.C: New.

Added:
trunk/gcc/testsuite/g++.dg/concepts/pr84330.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/constraint.cc
trunk/gcc/testsuite/ChangeLog

[Bug c++/70401] [c++1z on mingw]compile variadic template failed

[rai...@emrich-ebersheim.de]

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

--- Comment #4 from Rainer Emrich  ---
gcc-7.3.0 on x86_64-w64-mingw32 doesn't compile this code:

$ g++ -std=c++1z aa.cpp -o aa.exe
aa.cpp: In instantiation of 'std::ostream& operator<<(std::ostream&, const
std::tuple<_Tps ...>&) [with T = {long long unsigned int, long long unsigned
int, const char*, long long unsigned int, const char*, const char*, long long
unsigned int, long long unsigned int, const char*, const char*, long long
unsigned int, const char*, long long unsigned int, long long unsigned int,
const char*, long long unsigned int, long long unsigned int, const char*, long
long unsigned int, const char*}; std::ostream = std::basic_ostream]':
aa.cpp:133:54:   required from here
aa.cpp:113:7: error: call of overloaded 'apply(const operator<<(std::ostream&,
const std::tuple<_Tps ...>&) [with T = {long long unsigned int, long long
unsigned int, const char*, long long unsigned int, const char*, const char*,
long long unsigned int, long long unsigned int, const char*, const char*, long
long unsigned int, const char*, long long unsigned int, long long unsigned int,
const char*, long long unsigned int, long long unsigned int, const char*, long
long unsigned int, const char*}; std::ostream =
std::basic_ostream]::&, const std::tuple&)' is ambiguous
  apply(printer,toprint);
  ~^
aa.cpp:105:6: note: candidate: auto apply(F&&, Tuple&&) [with F = const
operator<<(std::ostream&, const std::tuple<_Tps ...>&) [with T = {long long
unsigned int, long long unsigned int, const char*, long long unsigned int,
const char*, const char*, long long unsigned int, long long unsigned int, const
char*, const char*, long long unsigned int, const char*, long long unsigned
int, long long unsigned int, const char*, long long unsigned int, long long
unsigned int, const char*, long long unsigned int, const char*}; std::ostream =
std::basic_ostream]::&; Tuple = const
std::tuple&]
 auto apply(F&& f, Tuple&& t) {
  ^
In file included from aa.cpp:1:0:
d:\opt\devel\gnu\gcc\mingw_nt\x86_64-w64-mingw32\mingw-w64-runtime-trunk-svn\gcc-7.3.0\include\c++\7.3.0\tuple:1668:5:
note: candidate: constexpr decltype(auto) std::apply(_Fn&&, _Tuple&&) [with _Fn
= const operator<<(std::ostream&, const std::tuple<_Tps ...>&) [with T = {long
long unsigned int, long long unsigned int, const char*, long long unsigned int,
const char*, const char*, long long unsigned int, long long unsigned int, const
char*, const char*, long long unsigned int, const char*, long long unsigned
int, long long unsigned int, const char*, long long unsigned int, long long
unsigned int, const char*, long long unsigned int, const char*}; std::ostream =
std::basic_ostream]::&; _Tuple = const
std::tuple&]
 apply(_Fn&& __f, _Tuple&& __t)
 ^
aa.cpp: In instantiation of 'std::ostream& operator<<(std::ostream&, const
std::tuple<_Tps ...>&) [with T = {long long unsigned int, long long unsigned
int, const char*, long long unsigned int, const char*, const char*, long long
unsigned int, long long unsigned int, const char*, const char*, long long
unsigned int, const char*, long long unsigned int, long long unsigned int,
const char*, long long unsigned int, long long unsigned int, const char*, long
long unsigned int, const char*, const char*, long long unsigned int, long long
unsigned int, const char*, const char*, long long unsigned int, const char*,
long long unsigned int, long long unsigned int, const char*, long long unsigned
int, long long unsigned int, const char*, long long unsigned int, const char*,
const char*, long long unsigned int, long long unsigned int, const char*, const
char*, long long unsigned int, const char*, long long unsigned int, long long
unsigned int, const char*, long long unsigned int, long long unsigned int,
const char*, long long unsigned int, const char*, const char*, long long
unsigned int, long long unsigned int, const char*, const char*, long long
unsigned int, const char*, long long unsigned int, long long unsigned int,
const char*, long long unsigned int, long long unsigned int, const char*};
std::ostream = std::basic_ostream]':
aa.cpp:134:53:   required from here
aa.cpp:113:7: error: call of overloaded 'apply(const operator<<(std::ostream&,
const std::tuple<_Tps ...>&) [with T = {long long unsigned int, long long
unsigned int, const char*, long long unsigned int, const char*, const char*,
long long unsigned int, long long unsigned int, const char*, const char*, long
long unsigned int, const char*, long long unsigned int, long long unsigned int,
const char*, long long unsigned int, long long unsigned int, const char*, long
long unsigned int, const char*, const char*, long long unsigned int, long long
unsigned int, const char*, const char*, long long unsigned int, const char*,
long long unsigned int, long long unsigned int, const char*, long long unsigned
int, long long 

[Bug bootstrap/84405] [8 Regression] Fails to bootstrap with GCC 4.1.2, GCC 4.2.4

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-02-15
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #4 from Jakub Jelinek  ---
The first revision that can't be bootstrapped with GCC 3.4.6 is again r249234.
While rejecting GCC 4.2.[0-3] with PR33916 unfixed might be an option, I'm
afraid rejecting everything older than that is not.
I'll try to see what's going on in say 4.1.*.

[Bug target/84154] [7 Regression] PowerPC GCC 7 and 8 have regression in converting fp to short/char and returning it

[meissner at gcc dot gnu.org]

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

--- Comment #9 from Michael Meissner  ---
Author: meissner
Date: Thu Feb 15 17:54:41 2018
New Revision: 257697

URL: https://gcc.gnu.org/viewcvs?rev=257697=gcc=rev
Log:
[gcc]
2018-02-15  Michael Meissner  

Back port from trunk
2018-02-07  Michael Meissner  

PR target/84154
* config/rs6000/rs6000.md (fix_trunc2):
Convert from define_expand to be define_insn_and_split.  Rework
float/double/_Float128 conversions to QI/HI/SImode to work with
both ISA 2.07 (power8) or ISA 3.0 (power9).  Fix regression where
conversions to QI/HImode types did a store and then a load to
truncate the value.  For conversions to VSX registers, don't split
the insn, instead emit the code directly.  Use the code iterator
any_fix to combine signed and unsigned conversions.
(fix_truncsi2_p8): Likewise.
(fixuns_trunc2): Likewise.
(fix_trunc2): Likewise.
(fix_trunc2): Likewise.
(fix_di2_hw): Likewise.
(fixuns_di2_hw): Likewise.
(fix_si2_hw): Likewise.
(fixuns_si2_hw): Likewise.
(fix_2_hw): Likewise.
(fix_trunc2): Likewise.
(fctiwz__smallint): Rename fctiwz__smallint to
fix_truncsi2_p8.
(fix_trunc2_internal): Delete, no longer
used.
(fixuns_trunc2_internal): Likewise.
(fix__mem): Likewise.
(fctiwz__mem): Likewise.
(fix__mem): Likewise.
(fix_trunc2_mem): On ISA 3.0, prevent
the register allocator from doing a direct move to the GPRs to do
a store, and instead use the ISA 3.0 store byte/half-word from
vector register instruction.  For IEEE 128-bit floating point,
also optimize stores of 32-bit ints.
(fix_trunc2_mem): Likewise.

[gcc/testsuite]
2018-02-15  Michael Meissner  

Back port from trunk
2018-02-07  Michael Meissner  

PR target/84154
* gcc.target/powerpc/pr84154-1.c: New tests.
* gcc.target/powerpc/pr84154-2.c: Likewise.
* gcc.target/powerpc/pr84154-3.c: Likewise.


Added:
branches/gcc-7-branch/gcc/testsuite/gcc.target/powerpc/pr84154-1.c
branches/gcc-7-branch/gcc/testsuite/gcc.target/powerpc/pr84154-2.c
branches/gcc-7-branch/gcc/testsuite/gcc.target/powerpc/pr84154-3.c
Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/config/rs6000/rs6000.md
branches/gcc-7-branch/gcc/testsuite/ChangeLog

[Bug jit/84288] Support jit on Solaris

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-02-15
 Depends on||84379
 Ever confirmed|0   |1

--- Comment #3 from Rainer Orth  ---
I've now developed a patch for PR target/84379 that cures the GC-related
failures
described before.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84379
[Bug 84379] Problems with sol2.c GTY handling

[Bug other/84379] Problems with sol2.c GTY handling

[ro at gcc dot gnu.org]

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

--- Comment #1 from Rainer Orth  ---
Created attachment 43431
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43431=edit
proposed patch

By closely following what darwin.c does for machopic_indirections, I arrived at
the attached patch which both bootstrapped and fixed the GC related failures
in the jit testsuite.

[Bug c++/84368] [8 Regression] return type of generic lambda in variadic lambda in template is not deduced

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-02-15
   Assignee|unassigned at gcc dot gnu.org  |jason at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug preprocessor/83063] [8 Regression] ICE on an invalid preprocessor snippet

[jason at gcc dot gnu.org]

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

--- Comment #6 from Jason Merrill  ---
Author: jason
Date: Thu Feb 15 17:43:01 2018
New Revision: 257696

URL: https://gcc.gnu.org/viewcvs?rev=257696=gcc=rev
Log:
PR preprocessor/83063 - __VA_OPT__ and ##

PR preprocessor/83708
* macro.c (vaopt_state): Reorder m_last_was_paste before m_state.
(vaopt_state::vaopt_state): Adjust.
(vaopt_state::update_flags): Add BEGIN and END.
(vaopt_state::update): Return them.
(copy_paste_flag): Factor out of replace_args.
(last_token_is): New.
(replace_args): Handle BEGIN and END.  Avoid padding there.
(tokens_buff_last_token_ptr): Return NULL if no tokens.

Added:
trunk/gcc/testsuite/c-c++-common/cpp/va-opt-2.c
trunk/gcc/testsuite/c-c++-common/cpp/va-opt-3.c
Modified:
trunk/libcpp/ChangeLog
trunk/libcpp/macro.c

[Bug preprocessor/83063] [8 Regression] ICE on an invalid preprocessor snippet

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #7 from Jason Merrill  ---
Fixed.

[Bug preprocessor/83708] Token-based policy broken by __VA_OPT__

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||jason at gcc dot gnu.org
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |jason at gcc dot gnu.org
   Target Milestone|--- |8.0

--- Comment #2 from Jason Merrill  ---
Fixed.

[Bug preprocessor/83708] Token-based policy broken by __VA_OPT__

[jason at gcc dot gnu.org]

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

--- Comment #1 from Jason Merrill  ---
Author: jason
Date: Thu Feb 15 17:43:01 2018
New Revision: 257696

URL: https://gcc.gnu.org/viewcvs?rev=257696=gcc=rev
Log:
PR preprocessor/83063 - __VA_OPT__ and ##

PR preprocessor/83708
* macro.c (vaopt_state): Reorder m_last_was_paste before m_state.
(vaopt_state::vaopt_state): Adjust.
(vaopt_state::update_flags): Add BEGIN and END.
(vaopt_state::update): Return them.
(copy_paste_flag): Factor out of replace_args.
(last_token_is): New.
(replace_args): Handle BEGIN and END.  Avoid padding there.
(tokens_buff_last_token_ptr): Return NULL if no tokens.

Added:
trunk/gcc/testsuite/c-c++-common/cpp/va-opt-2.c
trunk/gcc/testsuite/c-c++-common/cpp/va-opt-3.c
Modified:
trunk/libcpp/ChangeLog
trunk/libcpp/macro.c

[Bug target/82989] [7/8 regression ] Inexplicable use of NEON for 64-bit math

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  ---
In both adddi3_neon and lshrdi3_neon the GPR alternatives use exactly the same
number of ?s as the NEON ones with avoid_neon_for_64bits, just the
neon_for_64bits alternatives don't have any.  So I don't see how it is a
preference of not using NEON, when TARGET_PREFER_NEON_64BITS is true, neon is
clearly preferred, otherwise there is no preferencing at all.  And indeed, for
DImode shifts by 32 the GPR regs should be prefered.  Anyway, leaving this to
ARM maintainers, don't know about the arch enough to do something.