Re: [PATCH] Fix PR84003

[Richard Biener]

On Fri, 26 Jan 2018, Richard Biener wrote:

> On Fri, 26 Jan 2018, Richard Sandiford wrote:
> 
> > Richard Biener  writes:
> > > On Thu, 25 Jan 2018, Richard Sandiford wrote:
> > >
> > >> Richard Sandiford  writes:
> > >> > Richard Biener  writes:
> > >> >> The following patch fixes PR84003 where RTL DSE removes a redundant
> > >> >> store (a store storing the same value as an earlier store) but in
> > >> >> doing this changing program semantics because the later store changes
> > >> >> the effective type of the memory location.  This in turn allows
> > >> >> sched2 to do an originally invalid transform.
> > >> >>
> > >> >> The fix is to harden DSE so that while removing the later store
> > >> >> the earlier stores alias-sets are changed to reflect both dynamic
> > >> >> types - which means using alias-set zero.
> > >> >>
> > >> >> On GIMPLE we simply avoid removing such type-changing stores because
> > >> >> we cannot easily get hold on the earlier store.
> > >> >>
> > >> >> Bootstrap and regtest running on x86_64-unknown-linux-gnu.
> > >> >>
> > >> >> Disclaimer: this is a "local" fix, I didn't try to understand much
> > >> >> of the DSE data structures but only learned from +-10 lines around
> > >> >> the affected transform which I found by searching for the dumped
> > >> >> messages ...  Richard, you contributed the pass so please review.
> > >> >
> > >> > So the file says.  In reality I only wrote an early version, and what
> > >> > was committed contains very little of that.  So TBH this pass is almost
> > >> > a complete unknown to me.  That said...
> > >> >
> > >> > Might it be worth keeping the store instead?
> > >> 
> > >> ...that is, like gimple. :-)  Sorry, I spent so long thinking about this
> > >> that I forgot you'd said that gimple already does the same thing.
> > >
> > > Yeah, and it still runs into PR82224 ... which means it is not 
> > > conservative enough.
> > >
> > >> Richard
> > >> 
> > >> > Giving things alias set
> > >> > zero seems like a pretty big hammer and would turn the remaining store
> > >> > into something close to a scheduling barrier.
> > >> >
> > >> > IOW, how about checking alias_set_subset_of in:
> > >> >
> > >> >  /* Even if PTR won't be eliminated as unneeded, if both
> > >> > PTR and this insn store the same constant value, we might
> > >> > eliminate this insn instead.  */
> > >> >  if (s_info->const_rhs
> > >> >  && const_rhs
> > >> >  && known_subrange_p (offset, width,
> > >> >   s_info->offset, s_info->width)
> > >> >  && all_positions_needed_p (s_info, offset - 
> > >> > s_info->offset,
> > >> > width))
> > >> >
> > >> > instead?
> > >
> > > That's what GIMPLE does (use alias_set_subset_of), but it arguably
> > > doesn't work for unions (ok, there even the equality case doesn't 
> > > work...).
> > >
> > > I guess I thought it's worth trying sth new and adjust the earlier
> > > store ;)  Sth that I can't easily do on GIMPLE but everything seemed
> > > to be in place in RTL DSE.
> > >
> > > So, when looking at the above code it seems like there are exactly
> > > two insns we look at?  s_info and 'mem' I guess.  And s_info is
> > > the earlier one.
> > 
> > Yeah.
> > 
> > > So sth like
> > >
> > > Index: gcc/dse.c
> > > ===
> > > --- gcc/dse.c   (revision 257077)
> > > +++ gcc/dse.c   (working copy)
> > > @@ -1532,7 +1532,12 @@ record_store (rtx body, bb_info_t bb_inf
> > >   && known_subrange_p (offset, width,
> > >s_info->offset, s_info->width)
> > >   && all_positions_needed_p (s_info, offset - s_info->offset,
> > > -width))
> > > +width)
> > > + /* We can only remove the later store if the earlier aliases
> > > +at least all accesses the later one.  */
> > > + && (MEM_ALIAS_SET (mem) == MEM_ALIAS_SET (s_info->mem)
> > > + || alias_set_subset_of (MEM_ALIAS_SET (mem),
> > > + MEM_ALIAS_SET (s_info->mem
> > > {
> > >   if (GET_MODE (mem) == BLKmode)
> > > {
> > >
> > > ?  I can confirm that this patch works as well.  Is that what we prefer?
> > 
> > Not sure I can call that one, but it seems safer (especially for
> > backports).
> > 
> > > It would be consistent with what we do on GIMPLE currently (irrespective
> > > of still existing bugs in this area...).
> > >
> > > Note that with the above instead of dse1 removing the later store
> > > dse2 now decides to remove the earlier one...  (which is fine!).
> > >
> > > So I'm testing the above now, ok if it succeeds?
> > 
> > LGTM (but I can't approve it).
> 
> I 

[Bug middle-end/84034] [6/7/8 Regression] incomplete warning message with dos line endings

[edlinger at gcc dot gnu.org]

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

--- Comment #3 from Bernd Edlinger  ---
Author: edlinger
Date: Sat Jan 27 06:44:25 2018
New Revision: 257120

URL: https://gcc.gnu.org/viewcvs?rev=257120=gcc=rev
Log:
2018-01-27  Bernd Edlinger  

PR diagnostic/84034
* diagnostic-show-locus.c (get_line_width_without_trailing_whitespace):
Handle CR like TAB.
(layout::print_source_line): Likewise.
(test_get_line_width_without_trailing_whitespace): Add test cases.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/diagnostic-show-locus.c

[Bug middle-end/84040] [8 regression] compilation time of gcc.c-torture/compile/limits-blockid.c is 50x slower

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #6 from Jakub Jelinek  ---
Fixed.

[Bug middle-end/84040] [8 regression] compilation time of gcc.c-torture/compile/limits-blockid.c is 50x slower

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Sat Jan 27 06:28:15 2018
New Revision: 257119

URL: https://gcc.gnu.org/viewcvs?rev=257119=gcc=rev
Log:
PR middle-end/84040
* sched-deps.c (sched_macro_fuse_insns): Return immediately for
debug insns.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/sched-deps.c

Re: [PATCH] Avoid O(n^2) compile time issue in sched2 with debug insns (PR middle-end/84040)

[Vladimir Makarov]

On 01/26/2018 06:15 PM, Jakub Jelinek wrote:

Hi!

On a testcase which has 10 consecutive debug insns sched2 spends
a lot of time calling prev_nonnote_nondebug_insn on each of the debug
insns, even when it is completely useless, because no target wants
to fuse a non-debug insn with some debug insn after it, it makes sense
only for two non-debug insns.

By returning early for those, we'll just walk the long set of them once when
we process some non-debug instruction after a long block of debug insns.

Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?


OK.


2018-01-26  Jakub Jelinek  

PR middle-end/84040
* sched-deps.c (sched_macro_fuse_insns): Return immediately for
debug insns.

--- gcc/sched-deps.c.jj 2018-01-03 10:19:56.301534141 +0100
+++ gcc/sched-deps.c2018-01-26 16:21:01.922414579 +0100
@@ -2834,10 +2834,16 @@ static void
  sched_macro_fuse_insns (rtx_insn *insn)
  {
rtx_insn *prev;
+  /* No target hook would return true for debug insn as any of the
+ hook operand, and with very large sequences of only debug insns
+ where on each we call sched_macro_fuse_insns it has quadratic
+ compile time complexity.  */
+  if (DEBUG_INSN_P (insn))
+return;
prev = prev_nonnote_nondebug_insn (insn);
if (!prev)
  return;
-
+
if (any_condjump_p (insn))
  {
unsigned int condreg1, condreg2;

[Bug fortran/82994] ICE in gfc_match_deallocate, at fortran/match.c:4478

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4
 CC||kargl at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |kargl at gcc dot gnu.org

--- Comment #3 from kargl at gcc dot gnu.org ---
I have a patch.

[Bug fortran/68746] FAIL: gfortran.dg/read_dir.f90 -O0 execution test

[dave.anglin at bell dot net]

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

--- Comment #9 from dave.anglin at bell dot net ---
On 2018-01-26 8:29 PM, dominiq at lps dot ens.fr wrote:
> By the xfail? Can the PR be closed?
I'll have to investigate...

[Bug fortran/68746] FAIL: gfortran.dg/read_dir.f90 -O0 execution test

[dominiq at lps dot ens.fr]

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

--- Comment #8 from Dominique d'Humieres  ---
> I don't have a recent gcc-6 set of test results but the bug is fixed in 
> gcc-7 and gcc-8.

By the xfail? Can the PR be closed?

[Bug libstdc++/58931] condition_variable::wait_until overflowed by large time_point

[aaron at aarongraham dot com]

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

--- Comment #5 from Aaron Graham  ---
Created attachment 43261
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43261=edit
Patch to check for overflow

[Bug fortran/68746] FAIL: gfortran.dg/read_dir.f90 -O0 execution test

[dave.anglin at bell dot net]

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

--- Comment #7 from dave.anglin at bell dot net ---
I don't have a recent gcc-6 set of test results but the bug is fixed in 
gcc-7 and gcc-8.

[Bug c++/83342] extern marked variable template with later definition emits error

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-01-27
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1
  Known to fail||7.2.0, 8.0

--- Comment #1 from Martin Sebor  ---
Confirmed with the following simplified test case.  As noted, other compilers
including Clang, EDG eccp 4.13, ICC 18, and MSVC accept the code.

$ cat t.C && gcc -O2 -S -Wall t.C
template 
extern const int N;

template 
const int N = sizeof(T);

template const int N;
t.C: In instantiation of ‘const int N’:
t.C:7:20:   required from here
t.C:7:20: error: explicit instantiation of ‘N’ but no definition available
[-fpermissive]
 template const int N;
^~

[Bug fortran/68746] FAIL: gfortran.dg/read_dir.f90 -O0 execution test

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|NEW |WAITING

--- Comment #6 from Dominique d'Humieres  ---
What is the status of this PR?

[Bug fortran/66833] ICE on assumed-rank character actual argument to intrinsic functions

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Priority|P3  |P4
Summary|[4.9/5.1/6.0]: ICE on   |ICE on assumed-rank
   |assumed-rank character  |character actual argument
   |actual argument to  |to intrinsic functions
   |intrinsic functions |

--- Comment #2 from Dominique d'Humieres  ---
ICE seen with 4.8 up to trunk (8.0).

[Bug libstdc++/81122] [DR 2381] parsing f stopped after '0' when reading std::hexfloat >> f;

[redi at gcc dot gnu.org]

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

--- Comment #12 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #11)
> (In reply to Ben Woodard from comment #10)
> > Also note: 
> > https://connect.microsoft.com/VisualStudio/feedback/details/742775
> > 
> > My reading of:
> > https://wg21.link/lwg2381
> > 
> > is that if the first part of the number includes a '.' then the portion
> > after the 'p' or 'P' is not part of the number and is left in the string.
> > The example is 
> > 0x1a.bp+07p
> > 
> > So I believe that your assertion that 2381 applies in this situation is not
> > accurate. This example refers to the number: 26.6875 (16+10+11/16) and
> > because there is already a hexadecimal point '.' separating the integral
> > portion from the fractional portion the 'p' is not part of the number.
> 
> That just means it's a bad example in the proposed resolution, but the
> example is not normative anyway.

No, there's nothing wrong with the example. I don't know how you're
interpreting the spec but it seems wrong.

[Bug libstdc++/81122] [DR 2381] parsing f stopped after '0' when reading std::hexfloat >> f;

[redi at gcc dot gnu.org]

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

--- Comment #11 from Jonathan Wakely  ---
(In reply to Ben Woodard from comment #10)
> Also note: https://connect.microsoft.com/VisualStudio/feedback/details/742775
> 
> My reading of:
> https://wg21.link/lwg2381
> 
> is that if the first part of the number includes a '.' then the portion
> after the 'p' or 'P' is not part of the number and is left in the string.
> The example is 
> 0x1a.bp+07p
> 
> So I believe that your assertion that 2381 applies in this situation is not
> accurate. This example refers to the number: 26.6875 (16+10+11/16) and
> because there is already a hexadecimal point '.' separating the integral
> portion from the fractional portion the 'p' is not part of the number.

That just means it's a bad example in the proposed resolution, but the example
is not normative anyway.

> However, if the number was: "0x1abp+07p" (note the absence of the '.') then
> the number would be: in the normal hexfloat format and refer to 1752839.0
> leaving the trailing 'p' in the stream.

But in all versions of the C++ standard the first 'p' is not accumulated in
Stage 2 of the num_get::do_get call, and so the string passed to strtod is
"0x1ab" and nothing more. That's what LWG 2381 is about: the list of atoms
needs to be extended to include 'p' and 'P' so that the fractional portion can
be accumulated and passed to strtod.

[Bug fortran/56691] [OOP] Allocatable array: wrong offset when passing to CLASS dummy

[dominiq at lps dot ens.fr]

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

--- Comment #10 from Dominique d'Humieres  ---
The test in comment 3 has likely been fixed by revision r222361 (pr60322).

[Bug c++/83835] [7/8 Regression] constexpr constructor rejected in c++17 mode (regression WRT c++14)

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-01-27
 CC||jason at gcc dot gnu.org,
   ||msebor at gcc dot gnu.org
  Known to work||6.4.0
Summary|constexpr constructor   |[7/8 Regression] constexpr
   |rejected in c++17 mode  |constructor rejected in
   |(regression WRT c++14)  |c++17 mode (regression WRT
   ||c++14)
 Ever confirmed|0   |1
  Known to fail||7.2.0, 8.0

--- Comment #1 from Martin Sebor  ---
Confirmed with the slightly simplified test case below.  Other compilers accept
the code, as does GCC 6.4.0.

The regression was introduced in GCC 7.0 by r240889.

$ cat pr83835.C && gcc -S -Wall -std=c++17 pr83835.C
struct Y {
struct Z {
virtual ~Z ();

constexpr explicit Z (const Y*) { }
};

Z z;
constexpr Y (): z (this) { }
};
pr83835.C: In constructor ‘constexpr Y::Y()’:
pr83835.C:9:32: error: temporary of non-literal type ‘Y::Z’ in a constant
expression
 constexpr Y (): z (this) { }
^
pr83835.C:2:12: note: ‘Y::Z’ is not literal because:
 struct Z {
^
pr83835.C:2:12: note:   ‘Y::Z’ has a non-trivial destructor

[Bug fortran/56691] [OOP] Allocatable array: wrong offset when passing to CLASS dummy

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 CC||vladimir.fuka at gmail dot com

--- Comment #9 from Dominique d'Humieres  ---
*** Bug 84074 has been marked as a duplicate of this bug. ***

[Bug fortran/84074] Incorrect indexing of array when actual argument is an array expression and dummy is polymorphic

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #2 from Dominique d'Humieres  ---
> I am pretty sure there is at least one duplicate, but I cannot find it right 
> now.

I found it: pr56691.

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

[Bug target/84039] x86 retpolines and CFI

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2018-01-27
 Ever confirmed|0   |1

--- Comment #1 from H.J. Lu  ---
(In reply to Florian Weimer from comment #0)

Can you try hjl/pr84039/master branch at

https://github.com/hjl-tools/gcc

[Bug middle-end/84048] [8 Regression] FAIL: gcc.dg/torture/tls/run-ld.c -O0 -pie -fPIE execution test

[danglin at gcc dot gnu.org]

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

John David Anglin  changed:

   What|Removed |Added

 CC||doko at gcc dot gnu.org

--- Comment #4 from John David Anglin  ---
ii  binutils   2.29.90.2018 hppa GNU assembler, linker and binary

[Bug testsuite/83881] FAIL: c-c++-common/Wrestrict.c -std=gnu++98 (test for excess errors)

[danglin at gcc dot gnu.org]

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

John David Anglin  changed:

   What|Removed |Added

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

--- Comment #2 from John David Anglin  ---
Fixed.

[Bug fortran/60322] [OOP] Incorrect bounds on polymorphic dummy array

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 CC||frank.otto at pci dot 
uni-heidelbe
   ||rg.de

--- Comment #12 from Dominique d'Humieres  ---
*** Bug 58043 has been marked as a duplicate of this bug. ***

[Bug fortran/58043] [OOP] Incorrect behaviour of polymorphic array

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #7 from Dominique d'Humieres  ---
Likely fixed by revision r222361, i.e., a duplicate of pr60322.

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

[Bug target/56010] Powerpc, -mcpu=native and -mtune=native use the wrong name for target 7450

[segher at gcc dot gnu.org]

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

--- Comment #10 from Segher Boessenkool  ---
(In reply to Peter Bergner from comment #9)
> (In reply to Segher Boessenkool from comment #8)
> >> This kernel AT_PLATFORM name should strip the '+' off:
> >>   .platform = "power7+", -> "power7"
> >
> > We probably should have a -mcpu=power7+, we have power5+ as well etc.
> 
> Well, we have a -mcpu=power5+ because power5+ added a few new instructions
> over and above what power5 has.  That is not the case with power7+.  It
> implements the exact same instructions that power7 does, so power7+ doesn't
> really buy us anything.

It makes life simpler for users who do not know that -- like the compiler
itself with -mcpu=native :-)  (Compare with 740 vs. 750, although you could
call that historical accident).

power7 and power7+ have different cache sizes, if we ever bother to get that
right, too.

> >> These kernel AT_PLATFORM names should strip their prefix and suffix off:
> >>   .platform = "ppc440gp", -> "440"
> >>   .platform = "ppc-cell-be", -> "cell"
> >> 
> >> These kernel AT_PLATFORM names should strip the 'ppc' prefix off, as
> >> well as test the AT_HWCAP for PPC_FEATURE_HAS_FPU:
> >>   .platform = "ppc405", -> "405" | "405fp"
> >>   .platform = "ppc440", -> "440" | "440fp"
> >> 
> >> This kernel AT_PLATFORM name should strip the 'ppc' prefix off, change
> >> 470 to 476 as well as test the AT_HWCAP for PPC_FEATURE_HAS_FPU:
> >>   .platform = "ppc470", -> "476" | "476fp"
> > 
> > We could also decide not to support those for "native" (except cell?),
> > they all have problems and no one will try to build on those anyway.
> > I hope.
> 
> Well, it was easy enough to add support for them in case some did try in the
> future.  Up to you though if you want to leave them out.

The "fp" ones are not so easy.  I don't know if 440gp is the same core.

> > Could use 970 for pa6t, if we care.
> 
> Its up to you if you want me to map that to 970.  Let me know what you want
> me to do.

I don't think we care.

[Bug c++/83870] template parameter pack followed by another template parameter does not error when following parameter can not be deduced

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-01-27
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1
  Known to fail||7.2.0, 8.0

--- Comment #1 from Martin Sebor  ---
Confirmed.  The example is still in [temp.param], p15 of N4700.  Clang silently
accepts it but others warn.

[Bug fortran/84074] Incorrect indexing of array when actual argument is an array expression and dummy is polymorphic

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-01-27
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Confirmed from 6.4.0, 7.2.0 and trunk (8.0). For 4.8, 4.9, and 5 the values for
a%n and a(1:size(a))%n are also wrong.

using

do i=0,size(a)-1
print *,a(i)%n
enddo

displays the expected values.

I am pretty sure there is at least one duplicate, but I cannot find it right
now.

[PATCH] RISC-V: Allow register pairs for 64-bit target.

[Jim Wilson]

This was noticed while looking at some 64-bit libgcc code.  Some functions
like negti had a stack frame allocated, but did not use the stack.  The 32-bit
equivalent negdi did not have a stack frame allocated.  This is because a
128-bit local variable got allocated to the stack and then optimized away.
But we allow register pairs for the 32-bit target, we should allow them for
the 64-bit target too.  Fixed by adding a missing definition for
MAX_FIXED_MODE_SIZE.

This was tested by multiple 32-bit and 64-bit newlib and glibc builds and
make checks.  There were no regressions.  The libgcc code for negti no longer
has a stack frame allocated.  libstdc++.so is 3KB smaller with the patch.

Committed.

Jim

gcc/
* config/riscv/riscv.h (MAX_FIXED_MODE_SIZE): New.
---
 gcc/config/riscv/riscv.h | 4 
 1 file changed, 4 insertions(+)

diff --git a/gcc/config/riscv/riscv.h b/gcc/config/riscv/riscv.h
index a002bff4480..1c1c3431119 100644
--- a/gcc/config/riscv/riscv.h
+++ b/gcc/config/riscv/riscv.h
@@ -158,6 +158,10 @@ along with GCC; see the file COPYING3.  If not see
 
 #define PCC_BITFIELD_TYPE_MATTERS 1
 
+/* An integer expression for the size in bits of the largest integer machine
+   mode that should actually be used.  We allow pairs of registers.  */
+#define MAX_FIXED_MODE_SIZE GET_MODE_BITSIZE (TARGET_64BIT ? TImode : DImode)
+
 /* If defined, a C expression to compute the alignment for a static
variable.  TYPE is the data type, and ALIGN is the alignment that
the object would ordinarily have.  The value of this macro is used
-- 
2.14.1

Go patch committed: Show readable names in escape analysis messages

[Ian Lance Taylor]

This patch to the Go frontend shows readable names in the messages
printed for escape analysis.  This will print names like `x` instead
of `.p.x`.  Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu.
Committed to mainline.

Ian
Index: gcc/go/gofrontend/MERGE
===
--- gcc/go/gofrontend/MERGE (revision 257069)
+++ gcc/go/gofrontend/MERGE (working copy)
@@ -1,4 +1,4 @@
-897ce971b06a39c217d02dce9e1361bc7a240188
+13b25c25faa8afd625732d2630a4f9ece5cacb2e
 
 The first line of this file holds the git revision number of the last
 merge done from the gofrontend repository.
Index: gcc/go/gofrontend/escape.cc
===
--- gcc/go/gofrontend/escape.cc (revision 257033)
+++ gcc/go/gofrontend/escape.cc (working copy)
@@ -131,7 +131,7 @@ Node::ast_format(Gogo* gogo) const
   Named_object* no = this->object();
   if (no->is_function() && no->func_value()->enclosing() != NULL)
return "func literal";
-  ss << no->name();
+  ss << no->message_name();
 }
   else if (this->expr() != NULL)
 {
Index: gcc/go/gofrontend/expressions.cc
===
--- gcc/go/gofrontend/expressions.cc(revision 257033)
+++ gcc/go/gofrontend/expressions.cc(working copy)
@@ -783,7 +783,7 @@ Var_expression::do_get_backend(Translate
 void
 Var_expression::do_dump_expression(Ast_dump_context* ast_dump_context) const
 {
-  ast_dump_context->ostream() << this->variable_->name() ;
+  ast_dump_context->ostream() << this->variable_->message_name() ;
 }
 
 // Make a reference to a variable in an expression.
@@ -859,7 +859,7 @@ Enclosed_var_expression::do_address_take
 void
 Enclosed_var_expression::do_dump_expression(Ast_dump_context* adc) const
 {
-  adc->ostream() << this->variable_->name();
+  adc->ostream() << this->variable_->message_name();
 }
 
 // Make a reference to a variable within an enclosing function.
Index: gcc/go/gofrontend/wb.cc
===
--- gcc/go/gofrontend/wb.cc (revision 256820)
+++ gcc/go/gofrontend/wb.cc (working copy)
@@ -151,7 +151,7 @@ Check_escape::variable(Named_object* no)
   && no->result_var_value()->is_in_heap()))
 go_error_at(no->location(),
 "%s escapes to heap, not allowed in runtime",
-no->name().c_str());
+no->message_name().c_str());
   return TRAVERSE_CONTINUE;
 }
 

[Bug fortran/56765] [OOP] compilation errors/ICE with polymorphic array

[dominiq at lps dot ens.fr]

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

--- Comment #7 from Dominique d'Humieres  ---
> On my environment, all tests compile now without an ICE.

Confirmed.

[Bug c++/83873] adjacent digit separators are accepted in the exponent-part of floating-point literals

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-01-26
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1
  Known to fail||7.2.0, 8.0

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

Re: [PATCH] i386: Use const reference of struct ix86_frame to avoid copy

[H.J. Lu]

On Thu, Jan 18, 2018 at 12:23 AM, Uros Bizjak  wrote:
> On Wed, Jan 17, 2018 at 5:00 PM, H.J. Lu  wrote:
>> We can use const reference of struct ix86_frame to avoid making a local
>> copy of ix86_frame.  ix86_expand_epilogue makes a local copy of struct
>> ix86_frame and uses the reg_save_offset field as a local variable.  This
>> patch uses a separate local variable for reg_save_offset.
>>
>> Tested on x86-64 with ada.  OK for trunk?
>
> OK.
>

I'd like to backport it to gcc-7-branch.   Is that OK?

Thanks.


H.J.
>
>> H.J.
>> --
>> PR target/83905
>> * config/i386/i386.c (ix86_expand_prologue): Use cost reference
>> of struct ix86_frame.
>> (ix86_expand_epilogue): Likewise.  Add a local variable for
>> the reg_save_offset field in struct ix86_frame.
>> ---
>>  gcc/config/i386/i386.c | 24 
>>  1 file changed, 12 insertions(+), 12 deletions(-)
>>
>> diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
>> index a301e18ed70..340eca42449 100644
>> --- a/gcc/config/i386/i386.c
>> +++ b/gcc/config/i386/i386.c
>> @@ -13385,7 +13385,6 @@ ix86_expand_prologue (void)
>>  {
>>struct machine_function *m = cfun->machine;
>>rtx insn, t;
>> -  struct ix86_frame frame;
>>HOST_WIDE_INT allocate;
>>bool int_registers_saved;
>>bool sse_registers_saved;
>> @@ -13413,7 +13412,7 @@ ix86_expand_prologue (void)
>>m->fs.sp_valid = true;
>>m->fs.sp_realigned = false;
>>
>> -  frame = m->frame;
>> +  const struct ix86_frame  = cfun->machine->frame;
>>
>>if (!TARGET_64BIT && ix86_function_ms_hook_prologue 
>> (current_function_decl))
>>  {
>> @@ -14291,7 +14290,6 @@ ix86_expand_epilogue (int style)
>>  {
>>struct machine_function *m = cfun->machine;
>>struct machine_frame_state frame_state_save = m->fs;
>> -  struct ix86_frame frame;
>>bool restore_regs_via_mov;
>>bool using_drap;
>>bool restore_stub_is_tail = false;
>> @@ -14304,7 +14302,7 @@ ix86_expand_epilogue (int style)
>>  }
>>
>>ix86_finalize_stack_frame_flags ();
>> -  frame = m->frame;
>> +  const struct ix86_frame  = cfun->machine->frame;
>>
>>m->fs.sp_realigned = stack_realign_fp;
>>m->fs.sp_valid = stack_realign_fp
>> @@ -14348,11 +14346,13 @@ ix86_expand_epilogue (int style)
>>   + UNITS_PER_WORD);
>>  }
>>
>> +  HOST_WIDE_INT reg_save_offset = frame.reg_save_offset;
>> +
>>/* Special care must be taken for the normal return case of a function
>>   using eh_return: the eax and edx registers are marked as saved, but
>>   not restored along this path.  Adjust the save location to match.  */
>>if (crtl->calls_eh_return && style != 2)
>> -frame.reg_save_offset -= 2 * UNITS_PER_WORD;
>> +reg_save_offset -= 2 * UNITS_PER_WORD;
>>
>>/* EH_RETURN requires the use of moves to function properly.  */
>>if (crtl->calls_eh_return)
>> @@ -14368,11 +14368,11 @@ ix86_expand_epilogue (int style)
>>else if (TARGET_EPILOGUE_USING_MOVE
>>&& cfun->machine->use_fast_prologue_epilogue
>>&& (frame.nregs > 1
>> -  || m->fs.sp_offset != frame.reg_save_offset))
>> +  || m->fs.sp_offset != reg_save_offset))
>>  restore_regs_via_mov = true;
>>else if (frame_pointer_needed
>>&& !frame.nregs
>> -  && m->fs.sp_offset != frame.reg_save_offset)
>> +  && m->fs.sp_offset != reg_save_offset)
>>  restore_regs_via_mov = true;
>>else if (frame_pointer_needed
>>&& TARGET_USE_LEAVE
>> @@ -14440,7 +14440,7 @@ ix86_expand_epilogue (int style)
>>rtx t;
>>
>>if (frame.nregs)
>> -   ix86_emit_restore_regs_using_mov (frame.reg_save_offset, style == 2);
>> +   ix86_emit_restore_regs_using_mov (reg_save_offset, style == 2);
>>
>>/* eh_return epilogues need %ecx added to the stack pointer.  */
>>if (style == 2)
>> @@ -14535,19 +14535,19 @@ ix86_expand_epilogue (int style)
>>  in epilogues.  */
>>if (!m->fs.sp_valid || m->fs.sp_realigned
>>   || (TARGET_SEH
>> - && (m->fs.sp_offset - frame.reg_save_offset
>> + && (m->fs.sp_offset - reg_save_offset
>>   >= SEH_MAX_FRAME_SIZE)))
>> {
>>   pro_epilogue_adjust_stack (stack_pointer_rtx, 
>> hard_frame_pointer_rtx,
>>  GEN_INT (m->fs.fp_offset
>> - - frame.reg_save_offset),
>> + - reg_save_offset),
>>  style, false);
>> }
>> -  else if (m->fs.sp_offset != frame.reg_save_offset)
>> +  else if (m->fs.sp_offset != reg_save_offset)
>> {
>>   pro_epilogue_adjust_stack (stack_pointer_rtx, stack_pointer_rtx,
>>  GEN_INT (m->fs.sp_offset
>> - - 

[Bug fortran/83633] gfortran internal compiler error for explicit-shape array with non-constant bounds

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4
 CC||kargl at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |kargl at gcc dot gnu.org

--- Comment #5 from kargl at gcc dot gnu.org ---
Patched to mailing list.

Re: [PATCH] Extend lazy computation of expensive preprocessor macros to FLOATN*

[Joseph Myers]

On Sat, 27 Jan 2018, Jakub Jelinek wrote:

> Works for me, this tests fine on a couple of tests, ok for trunk if it
> passes bootstrap/regtest?
> 
> 2018-01-27  Jakub Jelinek  
> 
>   * c-cppbuiltin.c (c_cpp_builtins): Use ggc_strdup for the fp_suffix
>   argument.
>   (LAZY_HEX_FP_VALUES_CNT): Define.
>   (lazy_hex_fp_values): Allow up to LAZY_HEX_FP_VALUES_CNT lazy hex fp
>   values rather than just 12.
>   (builtin_define_with_hex_fp_value): Likewise.
> 
>   * include/cpplib.h (enum cpp_builtin_type): Change BT_LAST_USER from
>   BT_FIRST_USER + 31 to BT_FIRST_USER + 63.

OK.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [PATCH] Extend lazy computation of expensive preprocessor macros to FLOATN*

[Jakub Jelinek]

On Fri, Jan 26, 2018 at 11:22:04PM +, Joseph Myers wrote:
> On Sat, 27 Jan 2018, Jakub Jelinek wrote:
> > Honza reported today on IRC that we spent (again) significant time
> > of empty file compilation computing preprocessor *_MAX/*_MIN etc. macros.
> > In 2010 I've added lazy computation for these, only when they are first used
> > except for -dD, but reserved just 12 entries for those, as only
> > FLT/DBL/LDBL prefixed macros (4 times for each kind) were needed at that
> > point.  In 2016 for PR32187 Joseph has added a bunch of other kinds and
> > because there is no space in the array reserved for those, they are
> > evaluated right away, which is quite expensive.
> > 
> > The following patch makes them lazy again.
> > Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
> 
> Rather than hardcoding a number 36 I'd rather it used an explicit 
> computation (with explanatory comment) such as 4 * (3 + 
> NUM_FLOATN_NX_TYPES) (if that is indeed a safe value to use to guarantee 
> covering all these types).

Works for me, this tests fine on a couple of tests, ok for trunk if it
passes bootstrap/regtest?

2018-01-27  Jakub Jelinek  

* c-cppbuiltin.c (c_cpp_builtins): Use ggc_strdup for the fp_suffix
argument.
(LAZY_HEX_FP_VALUES_CNT): Define.
(lazy_hex_fp_values): Allow up to LAZY_HEX_FP_VALUES_CNT lazy hex fp
values rather than just 12.
(builtin_define_with_hex_fp_value): Likewise.

* include/cpplib.h (enum cpp_builtin_type): Change BT_LAST_USER from
BT_FIRST_USER + 31 to BT_FIRST_USER + 63.

--- gcc/c-family/c-cppbuiltin.c.jj  2018-01-03 10:20:21.369538150 +0100
+++ gcc/c-family/c-cppbuiltin.c 2018-01-26 11:01:15.266648197 +0100
@@ -1124,8 +1124,8 @@ c_cpp_builtins (cpp_reader *pfile)
   floatn_nx_types[i].extended ? "X" : "");
   sprintf (csuffix, "F%d%s", floatn_nx_types[i].n,
   floatn_nx_types[i].extended ? "x" : "");
-  builtin_define_float_constants (prefix, csuffix, "%s", csuffix,
- FLOATN_NX_TYPE_NODE (i));
+  builtin_define_float_constants (prefix, ggc_strdup (csuffix), "%s",
+ csuffix, FLOATN_NX_TYPE_NODE (i));
 }
 
   /* For decfloat.h.  */
@@ -1571,7 +1571,14 @@ struct GTY(()) lazy_hex_fp_value_struct
   int digits;
   const char *fp_suffix;
 };
-static GTY(()) struct lazy_hex_fp_value_struct lazy_hex_fp_values[12];
+/* Number of the expensive to compute macros we should evaluate lazily.
+   Each builtin_define_float_constants invocation calls
+   builtin_define_with_hex_fp_value 4 times and builtin_define_float_constants
+   is called for FLT, DBL, LDBL and up to NUM_FLOATN_NX_TYPES times for
+   FLTNN*.  */ 
+#define LAZY_HEX_FP_VALUES_CNT (4 * (3 + NUM_FLOATN_NX_TYPES))
+static GTY(()) struct lazy_hex_fp_value_struct
+  lazy_hex_fp_values[LAZY_HEX_FP_VALUES_CNT];
 static GTY(()) int lazy_hex_fp_value_count;
 
 static bool
@@ -1616,7 +1623,7 @@ builtin_define_with_hex_fp_value (const
   char dec_str[64], buf[256], buf1[128], buf2[64];
 
   /* This is very expensive, so if possible expand them lazily.  */
-  if (lazy_hex_fp_value_count < 12
+  if (lazy_hex_fp_value_count < LAZY_HEX_FP_VALUES_CNT
   && flag_dump_macros == 0
   && !cpp_get_options (parse_in)->traditional)
 {
--- libcpp/include/cpplib.h.jj  2018-01-18 21:11:59.890207215 +0100
+++ libcpp/include/cpplib.h 2018-01-26 10:58:10.249699482 +0100
@@ -719,7 +719,7 @@ enum cpp_builtin_type
   BT_COUNTER,  /* `__COUNTER__' */
   BT_HAS_ATTRIBUTE,/* `__has_attribute__(x)' */
   BT_FIRST_USER,   /* User defined builtin macros.  */
-  BT_LAST_USER = BT_FIRST_USER + 31
+  BT_LAST_USER = BT_FIRST_USER + 63
 };
 
 #define CPP_HASHNODE(HNODE)((cpp_hashnode *) (HNODE))


Jakub

[PATCH] PR fortran/83633 -- check for nonconstant explicit shape array

[Steve Kargl]

The attached patch implements a check for F2015:C830.
The wording of the F2008:C531 is nearly identical, but
the restriction on BLOCK is noted in the normative test.
The 3 lines in the new testcase show be sufficient to
see the issue.  In regression testing, I needed to 
adjust the regex pattern in a few existing test because
it seems my patch now catches the problem earlier.

Regression tested on x86_64-*-freebsd.  OK to commit?

2018-01-26  Steven G. Kargl  

PR fortran/83633
* decl.c (variable_decl): Check that an explicit-shape-array with
nonconstant bounds is allowed.
 
2018-01-26  Steven G. Kargl  

PR fortran/83633
* gfortran.dg/explicit_shape_1.f90: New test.
* gfortran.dg/automatic_module_variable.f90: Update regex.
* gfortran.dg/bad_automatic_objects_1.f90: Ditto.
* gfortran.dg/constant_shape.f90: Ditto.
* gfortran.dg/dec_structure_23.f90: Ditto.
* gfortran.dg/pr78240.f90: Ditto.

-- 
Steve
Index: gcc/fortran/decl.c
===
--- gcc/fortran/decl.c	(revision 257103)
+++ gcc/fortran/decl.c	(working copy)
@@ -2280,7 +2280,10 @@ variable_decl (int elem)
   /* At this point, we know for sure if the symbol is PARAMETER and can thus
  determine (and check) whether it can be implied-shape.  If it
  was parsed as assumed-size, change it because PARAMETERs can not
- be assumed-size.  */
+ be assumed-size.
+
+ An explicit-shape-array cannot appear under several conditions.
+ That check is done here as well.  */
   if (as)
 {
   if (as->type == AS_IMPLIED_SHAPE && current_attr.flavor != FL_PARAMETER)
@@ -2302,6 +2305,44 @@ variable_decl (int elem)
 	  m = MATCH_ERROR;
 	  goto cleanup;
 	}
+
+  /* F2015:C830 (R816) An explicit-shape-spec whose bounds are not
+	 constant expressions shall appear only in a subprogram, derived
+	 type definition, BLOCK construct, or interface body.  */
+  if (as->type == AS_EXPLICIT
+	  && gfc_current_state () != COMP_BLOCK
+	  && gfc_current_state () != COMP_DERIVED
+	  && gfc_current_state () != COMP_FUNCTION
+	  && gfc_current_state () != COMP_INTERFACE
+	  && gfc_current_state () != COMP_SUBROUTINE)
+	{
+	  gfc_expr *e;
+	  bool not_constant = false;
+
+	  for (int i = 0; i < as->rank + as->corank; i++)
+	{
+	  e = gfc_copy_expr (as->lower[i]);
+	  gfc_resolve_expr (e);
+	  gfc_simplify_expr (e, 0);
+	  if (e && (e->expr_type != EXPR_CONSTANT))
+		not_constant = true;
+	  gfc_free_expr (e);
+
+	  e = gfc_copy_expr (as->upper[i]);
+	  gfc_resolve_expr (e);
+	  gfc_simplify_expr (e, 0);
+	  if (e && (e->expr_type != EXPR_CONSTANT))
+		not_constant = true;
+	  gfc_free_expr (e);
+	}
+
+	  if (not_constant)
+	{ 
+	  gfc_error ("Explicit shaped array with nonconstant bounds at %C");
+	  m = MATCH_ERROR;
+	  goto cleanup;
+	}
+	}
 }
 
   char_len = NULL;
@@ -2421,6 +2462,7 @@ variable_decl (int elem)
   && gfc_current_block ()->result
   && strcmp ("ppr@", gfc_current_block ()->result->name) == 0)
 strcpy (name, "ppr@");
+
 
   /* OK, we've successfully matched the declaration.  Now put the
  symbol in the current namespace, because it might be used in the
Index: gcc/testsuite/gfortran.dg/explicit_shape_1.f90
===
--- gcc/testsuite/gfortran.dg/explicit_shape_1.f90	(nonexistent)
+++ gcc/testsuite/gfortran.dg/explicit_shape_1.f90	(working copy)
@@ -0,0 +1,7 @@
+! { dg-do compile }
+! PR fortran/83633
+! Original testcase by Nathan T. Weeks  
+!
+integer :: A(command_argument_count()) = 1 ! { dg-error "nonconstant bounds" }
+write (*,*) A
+end
Index: gcc/testsuite/gfortran.dg/automatic_module_variable.f90
===
--- gcc/testsuite/gfortran.dg/automatic_module_variable.f90	(revision 257103)
+++ gcc/testsuite/gfortran.dg/automatic_module_variable.f90	(working copy)
@@ -1,10 +1,12 @@
 ! { dg-do compile }
 ! Tests fix for PR15976
 !
+! Error message update with patch for PR fortran/83633
+!
 module sd
   integer, parameter :: n = 20
   integer :: i(n)
-  integer :: j(m) ! { dg-error "must have constant shape" }
+  integer :: j(m) ! { dg-error "array with nonconstant bounds" }
   integer, pointer :: p(:)
   integer, allocatable :: q(:)
 contains
Index: gcc/testsuite/gfortran.dg/bad_automatic_objects_1.f90
===
--- gcc/testsuite/gfortran.dg/bad_automatic_objects_1.f90	(revision 257103)
+++ gcc/testsuite/gfortran.dg/bad_automatic_objects_1.f90	(working copy)
@@ -5,16 +5,18 @@
 !
 ! Contributed by Joost VandeVondele  
 !
+! Error message update with patch for PR fortran/83633
+!
 module foo
   integer::  i
 end module foo
 module bar
   use foo
-  integer, dimension (i) :: j ! { dg-error 

Re: Bugzilla timing out

[Martin Sebor]

On 01/26/2018 04:08 PM, Frank Ch. Eigler wrote:

Hi -


Many copies of a 5 MB message have apparently been timing out in
sourceware's spam processing, resulting in sourceware repeatedly accepting
the message while the sender's mail server also times out (sooner) and
keeps resending it. [...]


Thanks for the pointer.  I tightened up some of the timeouts / parallelism
associated with spam filtering.


Thanks.  It's a lot snappier now.

Martin

[Bug fortran/84074] New: Incorrect indexing of array when actual argument is an array expression and dummy is polymorphic

[vladimir.fuka at gmail dot com]

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

Bug ID: 84074
   Summary: Incorrect indexing of array when actual argument is an
array expression and dummy is polymorphic
   Product: gcc
   Version: 7.2.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: ---

Base on
https://stackoverflow.com/questions/48468922/creating-a-subset-of-an-array-of-derived-type-in-fortran-doesnt-work-what-am-i/48470594#48470594

Problem appears not just for vector subscript expressions, but I also confirmed
for array(2:1:-1).

  type :: t
  integer :: n
  end type

  type(t) :: array(2) = [t(1),t(2)]

  call sub(array((/1,2/)))

contains

  subroutine sub(a)
class(t) :: a(:)
integer :: i

print *, "loop a(i) :"
do i=1,size(a)
print *,a(i)%n
enddo
print *, "a%n :",a%n
print *, "a(1:size(a))%n :",a(1:size(a))%n
  end subroutine
end program

Expected output is 1 and 2 for all three.
Actual output:

> gfortran-7 vecsubs2.f90 
> ./a.out 
 loop a(i) :
   2
   0
 a%n :   1   2
 a(1:size(a))%n :   1   2

[Bug c++/83936] [feature request] Allow constexpr char* as target argument

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #5 from Martin Sebor  ---
Confirmed based on comment #4.

As a side note, the limitation isn't specific to back-ends.  The C++ front-end
itself doesn't accept a constexpr string as an argument to an attribute that
expects a string.  (For the one attribute the C++ standard specifies that takes
a string argument it requires it to be a string literal.  But G++ could accept
constexpr strings in other attributes, target-specific or otherwise, and even
in the standard [[deprecated(msg)]] attribute G++ could accept it as an
extension.)

$ cat t.C && gcc -S -Wall -Wextra -Wpedantic -Wswitch-enum t.C
struct A
{
  static constexpr const char msg[] = "string doesn't work";
  static constexpr unsigned align = 4;
};

template 
struct B
{
  static void foo [[gnu::deprecated (T::msg)]] () { }
  typedef int I4 [[gnu::aligned (T::align)]];
};

static_assert (alignof (B::I4) == A::align, "number works");

void h()
{
  B::foo ();
}
t.C: In instantiation of ‘struct B’:
t.C:14:29:   required from here
t.C:10:15: error: deprecated message is not a string
   static void foo [[gnu::deprecated (T::msg)]] () { }
   ^~~
t.C: In function ‘void h()’:
t.C:18:9: warning: ‘static void B::foo() [with T = A]’ is deprecated
[-Wdeprecated-declarations]
   B::foo ();
 ^~~
t.C:10:15: note: declared here
   static void foo [[gnu::deprecated (T::msg)]] () { }
   ^~~
t.C:18:14: warning: ‘static void B::foo() [with T = A]’ is deprecated
[-Wdeprecated-declarations]
   B::foo ();
  ^
t.C:10:15: note: declared here
   static void foo [[gnu::deprecated (T::msg)]] () { }
   ^~~

Re: [PATCH] Extend lazy computation of expensive preprocessor macros to FLOATN*

[Joseph Myers]

On Sat, 27 Jan 2018, Jakub Jelinek wrote:

> Hi!
> 
> Honza reported today on IRC that we spent (again) significant time
> of empty file compilation computing preprocessor *_MAX/*_MIN etc. macros.
> In 2010 I've added lazy computation for these, only when they are first used
> except for -dD, but reserved just 12 entries for those, as only
> FLT/DBL/LDBL prefixed macros (4 times for each kind) were needed at that
> point.  In 2016 for PR32187 Joseph has added a bunch of other kinds and
> because there is no space in the array reserved for those, they are
> evaluated right away, which is quite expensive.
> 
> The following patch makes them lazy again.
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

Rather than hardcoding a number 36 I'd rather it used an explicit 
computation (with explanatory comment) such as 4 * (3 + 
NUM_FLOATN_NX_TYPES) (if that is indeed a safe value to use to guarantee 
covering all these types).

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: C++ PATCH to fix ICE with vector expr folding (PR c++/83659)

[Jakub Jelinek]

On Fri, Jan 26, 2018 at 02:11:19PM +0100, Richard Biener wrote:
> >> POINTER_PLUS_EXPR offets are to be interpreted as signed (ptrdiff_t)
> >> so using uhwi and then performing an unsigned division is wrong code.
> >> See mem_ref_offset how to deal with this (ugh - poly-ints...).  Basically
> >> you have to force the thing to signed.  Like just use
> >>
> >>   HOST_WIDE_INT offset = TREE_INT_CST_LOW (op01);
> >
> > Does it really matter here though?  Any negative offsets there are UB, we
> > should punt on them rather than try to optimize them.
> > As we known op01 is unsigned, if we check that it fits into shwi_p, it means
> > it will be 0 to shwi max and then we can handle it in uhwi too.
> 
> Ah, of course.  Didn't look up enough context to see what this code
> does in the end ;)
> 
> >   /* ((foo*))[1] => BIT_FIELD_REF */
> >   if (VECTOR_TYPE_P (op00type)
> >   && (same_type_ignoring_top_level_qualifiers_p
> > -(type, TREE_TYPE (op00type
> > +(type, TREE_TYPE (op00type)))
> > + && tree_fits_shwi_p (op01))
> 
> nevertheless this appearant "mismatch" deserves a comment (checking
> shwi and using uhwi).

So like this?

Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

2018-01-26  Marek Polacek  
Jakub Jelinek  

PR c++/83659
* constexpr.c (cxx_fold_indirect_ref): Use unsigned HOST_WIDE_INT
when computing offsets.  Verify first that tree_fits_shwi_p (op01).
Formatting fix.

* g++.dg/torture/pr83659.C: New test.

--- gcc/cp/constexpr.c.jj   2018-01-24 17:18:42.392392254 +0100
+++ gcc/cp/constexpr.c  2018-01-26 18:54:43.991828743 +0100
@@ -3070,7 +3070,8 @@ cxx_fold_indirect_ref (location_t loc, t
{
  tree part_width = TYPE_SIZE (type);
  tree index = bitsize_int (0);
- return fold_build3_loc (loc, BIT_FIELD_REF, type, op, part_width, 
index);
+ return fold_build3_loc (loc, BIT_FIELD_REF, type, op, part_width,
+ index);
}
   /* Also handle conversion to an empty base class, which
 is represented with a NOP_EXPR.  */
@@ -3109,12 +3110,22 @@ cxx_fold_indirect_ref (location_t loc, t
 
  /* ((foo*))[1] => BIT_FIELD_REF */
  if (VECTOR_TYPE_P (op00type)
- && (same_type_ignoring_top_level_qualifiers_p
- (type, TREE_TYPE (op00type
+ && same_type_ignoring_top_level_qualifiers_p
+   (type, TREE_TYPE (op00type))
+ /* POINTER_PLUS_EXPR second operand is sizetype, unsigned,
+but we want to treat offsets with MSB set as negative.
+For the code below negative offsets are invalid and
+TYPE_SIZE of the element is something unsigned, so
+check whether op01 fits into HOST_WIDE_INT, which implies
+it is from 0 to INTTYPE_MAXIMUM (HOST_WIDE_INT), and
+then just use tree_to_uhwi because we want to treat the
+value as unsigned.  */
+ && tree_fits_shwi_p (op01))
{
- HOST_WIDE_INT offset = tree_to_shwi (op01);
+ unsigned HOST_WIDE_INT offset = tree_to_uhwi (op01);
  tree part_width = TYPE_SIZE (type);
- unsigned HOST_WIDE_INT part_widthi = tree_to_shwi 
(part_width)/BITS_PER_UNIT;
+ unsigned HOST_WIDE_INT part_widthi
+   = tree_to_uhwi (part_width) / BITS_PER_UNIT;
  unsigned HOST_WIDE_INT indexi = offset * BITS_PER_UNIT;
  tree index = bitsize_int (indexi);
 
--- gcc/testsuite/g++.dg/torture/pr83659.C.jj   2018-01-26 18:46:40.077572013 
+0100
+++ gcc/testsuite/g++.dg/torture/pr83659.C  2018-01-26 18:56:36.822888606 
+0100
@@ -0,0 +1,18 @@
+// PR c++/83659
+// { dg-do compile }
+
+typedef int V __attribute__ ((__vector_size__ (16)));
+V a;
+V b[2];
+
+int
+foo ()
+{
+  return reinterpret_cast  ()[-1] += 1;
+}
+
+int
+bar ()
+{
+  return reinterpret_cast  ([1])[-1];
+}


Jakub

[PATCH] Avoid creating >= 8GB EXPR_CONSTANT initializers for ilp32 targets (PR fortran/84065)

[Jakub Jelinek]

Hi!

resolve_charlen is going to error on ilp32 target charlens above what
can fit into 32-bit signed int, but add_init_expr_to_sym is done before
resolve_charlen, allocating huge amounts of memory in those cases
when we'll error later is just waste of compile time if running on 64-bit
host with enough memory, or will unnecessarily ICE due to out of memory
otherwise.

Another option would be to emit the error resolve_charlen is going to
emit and arrange for it not to be emitted afterwards, this just seemed
to be easier.

Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

It would be nice if the FE had some way to express very large repetitive
EXPR_CONSTANT more efficiently, say by not allocating the memory for
the rest which is filled only by ' ', or by allowing to say this and this
is repeated after the initial portion this many times.

2018-01-26  Jakub Jelinek  

PR fortran/84065
* decl.c (add_init_expr_to_sym): Ignore initializers for too large
lengths.

--- gcc/fortran/decl.c.jj   2018-01-23 21:35:04.0 +0100
+++ gcc/fortran/decl.c  2018-01-26 18:24:22.064763299 +0100
@@ -1757,22 +1757,32 @@ add_init_expr_to_sym (const char *name,
  if (!gfc_specification_expr (sym->ts.u.cl->length))
return false;
 
- HOST_WIDE_INT len = gfc_mpz_get_hwi 
(sym->ts.u.cl->length->value.integer);
-
- if (init->expr_type == EXPR_CONSTANT)
-   gfc_set_constant_character_len (len, init, -1);
- else if (init->expr_type == EXPR_ARRAY)
+ int k = gfc_validate_kind (BT_INTEGER, gfc_charlen_int_kind,
+false);
+ /* resolve_charlen will complain later on if the length
+is too large.  Just skeep the initialization in that case.  */
+ if (mpz_cmp (sym->ts.u.cl->length->value.integer,
+  gfc_integer_kinds[k].huge) <= 0)
{
- gfc_constructor *c;
+ HOST_WIDE_INT len
+   = gfc_mpz_get_hwi (sym->ts.u.cl->length->value.integer);
+
+ if (init->expr_type == EXPR_CONSTANT)
+   gfc_set_constant_character_len (len, init, -1);
+ else if (init->expr_type == EXPR_ARRAY)
+   {
+ gfc_constructor *c;
 
- /* Build a new charlen to prevent simplification from
-deleting the length before it is resolved.  */
- init->ts.u.cl = gfc_new_charlen (gfc_current_ns, NULL);
- init->ts.u.cl->length = gfc_copy_expr (sym->ts.u.cl->length);
+ /* Build a new charlen to prevent simplification from
+deleting the length before it is resolved.  */
+ init->ts.u.cl = gfc_new_charlen (gfc_current_ns, NULL);
+ init->ts.u.cl->length
+   = gfc_copy_expr (sym->ts.u.cl->length);
 
- for (c = gfc_constructor_first (init->value.constructor);
-  c; c = gfc_constructor_next (c))
-   gfc_set_constant_character_len (len, c->expr, -1);
+ for (c = gfc_constructor_first (init->value.constructor);
+  c; c = gfc_constructor_next (c))
+   gfc_set_constant_character_len (len, c->expr, -1);
+   }
}
}
}

Jakub

[Bug c++/84055] warning: ignoring attributes on template argument ‘cl_uint {aka unsigned int}’ [-Wignored-attributes]

[kip at thevertigo dot com]

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

--- Comment #6 from Kip Warner  ---
Hey Martin. Yes, you are right. I see it now in cl_platform.h.

[PATCH] Avoid O(n^2) compile time issue in sched2 with debug insns (PR middle-end/84040)

[Jakub Jelinek]

Hi!

On a testcase which has 10 consecutive debug insns sched2 spends
a lot of time calling prev_nonnote_nondebug_insn on each of the debug
insns, even when it is completely useless, because no target wants
to fuse a non-debug insn with some debug insn after it, it makes sense
only for two non-debug insns.

By returning early for those, we'll just walk the long set of them once when
we process some non-debug instruction after a long block of debug insns.

Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

2018-01-26  Jakub Jelinek  

PR middle-end/84040
* sched-deps.c (sched_macro_fuse_insns): Return immediately for
debug insns.

--- gcc/sched-deps.c.jj 2018-01-03 10:19:56.301534141 +0100
+++ gcc/sched-deps.c2018-01-26 16:21:01.922414579 +0100
@@ -2834,10 +2834,16 @@ static void
 sched_macro_fuse_insns (rtx_insn *insn)
 {
   rtx_insn *prev;
+  /* No target hook would return true for debug insn as any of the
+ hook operand, and with very large sequences of only debug insns
+ where on each we call sched_macro_fuse_insns it has quadratic
+ compile time complexity.  */
+  if (DEBUG_INSN_P (insn))
+return;
   prev = prev_nonnote_nondebug_insn (insn);
   if (!prev)
 return;
- 
+
   if (any_condjump_p (insn))
 {
   unsigned int condreg1, condreg2;

Jakub

[Bug fortran/84073] In -fc-prototypes fixed (nonzero) length strings are mapped to plain char in prototype.

[dominiq at lps dot ens.fr]

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

--- Comment #2 from Dominique d'Humieres  ---
See also
https://gcc.gnu.org/onlinedocs/gfortran/Further-Interoperability-of-Fortran-with-C.html#Further-Interoperability-of-Fortran-with-C

> Using assumed-shape, assumed-rank and deferred-shape arrays in BIND(C)
> procedures is not fully supported. In particular, C interoperable strings
> of other length than one are not supported as this requires the new array
> descriptor.

[PATCH] Extend lazy computation of expensive preprocessor macros to FLOATN*

[Jakub Jelinek]

Hi!

Honza reported today on IRC that we spent (again) significant time
of empty file compilation computing preprocessor *_MAX/*_MIN etc. macros.
In 2010 I've added lazy computation for these, only when they are first used
except for -dD, but reserved just 12 entries for those, as only
FLT/DBL/LDBL prefixed macros (4 times for each kind) were needed at that
point.  In 2016 for PR32187 Joseph has added a bunch of other kinds and
because there is no space in the array reserved for those, they are
evaluated right away, which is quite expensive.

The following patch makes them lazy again.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

2018-01-26  Jakub Jelinek  

* c-cppbuiltin.c (c_cpp_builtins): Use ggc_strdup for the fp_suffix
argument.
(lazy_hex_fp_values): Allow up to 36 lazy hex fp values rather than
just 12.
(builtin_define_with_hex_fp_value): Likewise.

* include/cpplib.h (enum cpp_builtin_type): Change BT_LAST_USER from
BT_FIRST_USER + 31 to BT_FIRST_USER + 63.

--- gcc/c-family/c-cppbuiltin.c.jj  2018-01-03 10:20:21.369538150 +0100
+++ gcc/c-family/c-cppbuiltin.c 2018-01-26 11:01:15.266648197 +0100
@@ -1124,8 +1124,8 @@ c_cpp_builtins (cpp_reader *pfile)
   floatn_nx_types[i].extended ? "X" : "");
   sprintf (csuffix, "F%d%s", floatn_nx_types[i].n,
   floatn_nx_types[i].extended ? "x" : "");
-  builtin_define_float_constants (prefix, csuffix, "%s", csuffix,
- FLOATN_NX_TYPE_NODE (i));
+  builtin_define_float_constants (prefix, ggc_strdup (csuffix), "%s",
+ csuffix, FLOATN_NX_TYPE_NODE (i));
 }
 
   /* For decfloat.h.  */
@@ -1571,7 +1571,7 @@ struct GTY(()) lazy_hex_fp_value_struct
   int digits;
   const char *fp_suffix;
 };
-static GTY(()) struct lazy_hex_fp_value_struct lazy_hex_fp_values[12];
+static GTY(()) struct lazy_hex_fp_value_struct lazy_hex_fp_values[36];
 static GTY(()) int lazy_hex_fp_value_count;
 
 static bool
@@ -1616,7 +1616,7 @@ builtin_define_with_hex_fp_value (const
   char dec_str[64], buf[256], buf1[128], buf2[64];
 
   /* This is very expensive, so if possible expand them lazily.  */
-  if (lazy_hex_fp_value_count < 12
+  if (lazy_hex_fp_value_count < 36
   && flag_dump_macros == 0
   && !cpp_get_options (parse_in)->traditional)
 {
--- libcpp/include/cpplib.h.jj  2018-01-18 21:11:59.890207215 +0100
+++ libcpp/include/cpplib.h 2018-01-26 10:58:10.249699482 +0100
@@ -719,7 +719,7 @@ enum cpp_builtin_type
   BT_COUNTER,  /* `__COUNTER__' */
   BT_HAS_ATTRIBUTE,/* `__has_attribute__(x)' */
   BT_FIRST_USER,   /* User defined builtin macros.  */
-  BT_LAST_USER = BT_FIRST_USER + 31
+  BT_LAST_USER = BT_FIRST_USER + 63
 };
 
 #define CPP_HASHNODE(HNODE)((cpp_hashnode *) (HNODE))

Jakub

Re: Bugzilla timing out

[Frank Ch. Eigler]

Hi -

> Many copies of a 5 MB message have apparently been timing out in 
> sourceware's spam processing, resulting in sourceware repeatedly accepting 
> the message while the sender's mail server also times out (sooner) and 
> keeps resending it. [...]

Thanks for the pointer.  I tightened up some of the timeouts / parallelism
associated with spam filtering.

- FChE

[Bug middle-end/84071] [7/8 regression] nonzero_bits1 of subreg incorrect

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
I think this is related to PR 81443.  Can you see if the 7.3 release has it
fixed?

[Bug fortran/84073] In -fc-prototypes fixed (nonzero) length strings are mapped to plain char in prototype.

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2018-01-26
 CC||tkoenig at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Withe the following change

--- pr84073.f90 2018-01-26 22:48:32.0 +0100
+++ pr84073_db.f90  2018-01-27 00:03:06.0 +0100
@@ -13,10 +13,10 @@ module utderror
 integer(c_int):: nerrorloc
 real(c_double):: errorstartloc(3)
 real(c_double):: errorendloc(3)
-character(kind=c_char, len=41) :: errorsubsystem
-character(kind=c_char, len=9) :: errorseverity
+character(kind=c_char) :: errorsubsystem(41)
+character(kind=c_char) :: errorseverity(9)
 integer(c_int):: errorid
-character(kind=c_char, len=1001) :: errormessage
+character(kind=c_char) :: errormessage(1001)
   end type

   type(utderror_t), bind(c), save :: utderror_v

I get

...
char errorsubsystem[41];
char errorseverity[9];
int errorid;
char errormessage[1001];
} utderror_t;
void add_utd_error (int *ierror);
extern utderror_t utderror_v;

Possibly related to PR38506.

[Bug middle-end/84071] [7/8 regression] nonzero_bits1 of subreg incorrect

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||wrong-code
 Target||arm
   Target Milestone|--- |7.4

[Bug target/83712] [6/7/8 Regression] "Unable to find a register to spill" when compiling for thumb1

[vmakarov at gcc dot gnu.org]

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

Vladimir Makarov  changed:

   What|Removed |Added

 CC||vmakarov at gcc dot gnu.org

--- Comment #5 from Vladimir Makarov  ---
(In reply to sudi from comment #4)
> What I have observed so far is that the failure occurs based on how the
> scheduler (sched1) chooses to schedule the movmem12b instructions (insn 16
> in all the cases below). If that
> instruction is scheduled a bit later (even by one instruction), its all good!
> 
> Even though the movmem12b instruction has a very heavy demand on the
> registers, shouldn't the allocator and/or the scheduler be able to detect
> that? Is this a scheduler problem or an allocator problem or neither?
> 

It is hard to say which pass (scheduler or RA) is responsible for the bug. 
Such bug was frequent for older reload pass.  Therefore for i386 the 1st insn
scheduling was switched off long ago.

The newer LRA has a new feature to spill hard reg live range in some cases.
Unfortunately, it does not always work.  In this case the scheduler extends
live ranges of hard registers used for parameter passing.

To improve communication of the scheduler and RA. a few years ago a
register-pressure sensitive scheduling was introduced.  It should prevent
occurrence of 'unable to find a register to spill' situation and decrease
number of spills in RA.

We have two different algorithms for register-pressure sensitive scheduling. 
ARM by default uses the 2nd one (MODEL) probably because it results in a better
generated code.  The 1st algorithm (WEIGHTED) is less aggressive but more safe
IMHO.  So if you add --param sched-pressure-algorithm=1, the problem goes away. 

So I see 3 possible ways to solve the problem:
  1. Fix it in RA which would be very hard.
  2. Fix it in the 2nd pressure-sensitive insn scheduling.  I think Richard
Sandiford would do this as an author of the code or at least to say how hard to
fix the problem there.
  3. Use more conservative but safe 1st algorithm.  This is the simplest
solution.

I'd like to see other people opinions on what approach to use because I have no
particular preference except avoiding the 1st approach.

[Bug c/83955] false positive implicit-fallthrough warning on switch enum

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #2 from Martin Sebor  ---
Without -Wswitch-default GCC doesn't warn for case statements that have labels
for all values of the enumerated controlling expression.  I.e., the assumption
is that the controlling expression's value matches one of the enumerators. 
Having -Wimplicit-fallthrough warn for such a case statement would run counter
to that philosophy.  I think -Wimplicit-fallthrough should do what GCC does
without -Wswitch-default and assume that a case statement that transfers
control out of all labels for all of its controlling expression's enumerators
does not fall through.

With that I will confirm this report as a bug.

Re: [PATCH] fix for diagnostic/84034

[David Malcolm]

On Thu, 2018-01-25 at 18:53 +, Bernd Edlinger wrote:
> Hi,
> 
> as PR diagnostic/84034 shows, source files with
> dos style line endings can cause a glitch in the
> terminal emulation that erases the source line that
> is supposed to be shown.
> 
> That happens when the colorizing escape sequences are
> printed between the CR and the LF.  Apparently the LF is
> being ignored and thus the following line overwrites
> everything from the last source line.
> 
> 
> The following patch fixes the visual glitch by handling
> a CR '\r' like a TAB '\t' character.
> 
> 
> Bootstrapped and reg-rested in x86_64-pc-linux-gnu.
> OK for trunk?

Thanks for working on this.

[BEGIN BRAIN-DUMP:

Before gcc 6, we handled this case by printing (e.g. gcc 5):
/tmp/t.c: In function ‘test’:
/tmp/t.c:5:20: warning: suggest parentheses around ‘&&’ within ‘||’ [-
Wparentheses]
   (d && b > e) &&
^
where all lines would end with LF, apart from the quoted source line,
which would end with CR+LF.

>From gcc 6 onwards, the lines all end with LF, apart from quoted source
lines, which end with:
  CR + (end-colorization) + LF.

What's happening is that layout::print_source_line etc treat the CR as
non-whitespace, and prints it.  Then layout::print_newline () prints
the end-colorization and LF.

Presumably we *don't* want to preserve that mixed-ending behavior in
our output from gcc 5 and earlier descibed above; that seems like an
accident of the old implementation, and doesn't seem useful.

Your patch effectively turns the CR before the LF into trailing
whitespace, stopping the CR from being printed, turning it into just:
  (end-colorization) + LF
and thus fixing the glitch.

END BRAIN-DUMP]

The patch is OK.

Thanks
Dave

[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 #26 from acsawdey at gcc dot gnu.org ---
A little bit more info:

It appears the parameter asmhdr in this function is at the center of this:

func (tools gccgoToolchain) gc(b *Builder, a *Action, archive string, importcfg
[]byte, asmhdr bool, gofiles []string) (ofile string, output []byte, err error)
{

vt_add_function_parameter first sees this as (reg/v:DI 194 [ asmhdrD_4038 ])

but then near the top of the function is uses replace_equiv_address_nv to
rewrite it as:

(mem/c:QI (plus:DI (plus:DI (reg/f:DI 187)
(const_int 32 [0x20]))
(const_int 72 [0x48])) [8 asmhdrD_4038+0 S1 A64])

Then this piece of code in the same function gets ahold of it:

  lowpart = var_lowpart (mode, incoming);
  if (!lowpart)
return;

  val = cselib_lookup_from_insn (lowpart, mode, true,
 VOIDmode, get_insns ());

  /* ??? Float-typed values in memory are not handled by
 cselib.  */
  if (val)
{
  preserve_value (val);
  set_variable_part (out, val->val_rtx, dv, const_offset,
 VAR_INIT_STATUS_INITIALIZED, NULL, INSERT);
  dv = dv_from_value (val->val_rtx);
}

  if (MEM_P (incoming))
{
  val = cselib_lookup_from_insn (XEXP (incoming, 0), mode, true,
 VOIDmode, get_insns ());
  if (val)
{
  preserve_value (val);
  incoming = replace_equiv_address_nv (incoming, val->val_rtx);
}
}

This preserves the whole thing at the first preserve call:

(mem/c:QI (plus:DI (plus:DI (reg/f:DI 187)
(const_int 32 [0x20]))
(const_int 72 [0x48])) [8 asmhdrD_4038+0 S1 A64])

and this piece at the second call inside the MEM_P condition:

(plus:DI (plus:DI (reg/f:DI 187)
(const_int 32 [0x20]))
(const_int 72 [0x48]))

The expression that later causes the problem is the (reg/f:DI 187) in the
center of that which is not preserved.

Later when cselib_expand_value expands asmhdr, vt_expand_var_loc_chain gets
called on all 3 pieces of this and throws the assert on the innermost one
(reg/f:DI 187) when it sees it is not marked preserve.

[Bug c++/84027] new-expression does not accept an attribute-specifier-seq

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-01-26
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1
  Known to fail||7.1.0, 8.0

--- Comment #1 from Martin Sebor  ---
Confirmed.  AFAICS, both the form in comment #0 and the one below should be
accepted but neither is.

void f() { char* p = new char[sizeof(int)] [[gnu::aligned (alignof (int))]]; }

Re: Bugzilla timing out

[Joseph Myers]

On Fri, 26 Jan 2018, Frank Ch. Eigler wrote:

> Hi -
> 
> > Thanks for looking into it.  I'm still (or again) seeing very
> > poor responsiveness.  Right now, bringing up an existing bug
> > takes an entire minute.
> 
> There has been quite a burst in activity on sourceware.org over the
> last few hours.  Will look further into why, but quite a bit of it may
> be anti-spam processing.

Many copies of a 5 MB message have apparently been timing out in 
sourceware's spam processing, resulting in sourceware repeatedly accepting 
the message while the sender's mail server also times out (sooner) and 
keeps resending it.

https://sourceware.org/ml/libc-alpha/2018-01/msg00901.html

(the list archives uniquify based on message-id, but many separate copies 
have been delivered to libc-alpha so far each with its own ezmlm sequence 
number).

-- 
Joseph S. Myers
jos...@codesourcery.com

[Bug c++/84030] Name lookup in presence of namespace

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Sebor  ---
Confirmed.  All versions of GCC all the way to 4.1 accept the code so it's not
a recent regression.

EDG eccp 4.13 prints the following warning:

"pr84030.C", line 20: warning: ambiguous class member reference -- type
  "N_::A_::A_" (declared at line 5) used in preference to class "A_"
  (declared at line 3)
int b = a.operator A_().g();
   ^

I don't know if the standard requires an error for the ambiguity but if not, it
would seem appropriate to at least issue a warning.

Re: Bugzilla timing out

[Frank Ch. Eigler]

Hi -

> Thanks for looking into it.  I'm still (or again) seeing very
> poor responsiveness.  Right now, bringing up an existing bug
> takes an entire minute.

There has been quite a burst in activity on sourceware.org over the
last few hours.  Will look further into why, but quite a bit of it may
be anti-spam processing.

https://sourceware.org/grafana/index.html#/dashboard/file/default.json

- FChE

[Bug c++/84055] warning: ignoring attributes on template argument ‘cl_uint {aka unsigned int}’ [-Wignored-attributes]

[msebor at gcc dot gnu.org]

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

--- Comment #5 from Martin Sebor  ---
Here's what I see in attachment #43249:

$ cat -n minimal.ii | grep -E -e 'typedef *[^ ]+ *cl_uint' -e uint32_t | grep
typedef
66  typedef unsigned int __uint32_t;
   186  typedef __uint32_t uint32_t;
   239  typedef uint32_t cl_uint __attribute__((aligned(4)));
  5667  typedef cl_uint4 cl_uint3;

Re: Bugzilla timing out

[H.J. Lu]

On Fri, Jan 26, 2018 at 1:52 PM, Martin Sebor  wrote:
> On 01/22/2018 11:08 AM, Frank Ch. Eigler wrote:
>>
>> Hi -
>>
>>> Problems are still occurring for me; Bugzilla gives me 504 Gateway
>>> Time-outs when I try to access it tonight...
>>
>>
>> OK, we reworked some of the database routine maintenance workload,
>> e.g., a nightly cleanup pass that was quite likely excessive, and
>> will keep monitoring.
>
>
> Thanks for looking into it.  I'm still (or again) seeing very
> poor responsiveness.  Right now, bringing up an existing bug
> takes an entire minute.
>

Same here.  When I opened a new bug today, it timed out.  I had to look up
the database to see if I opened it or not.


-- 
H.J.

Re: Bugzilla timing out

[Martin Sebor]

On 01/22/2018 11:08 AM, Frank Ch. Eigler wrote:

Hi -


Problems are still occurring for me; Bugzilla gives me 504 Gateway
Time-outs when I try to access it tonight...


OK, we reworked some of the database routine maintenance workload,
e.g., a nightly cleanup pass that was quite likely excessive, and
will keep monitoring.


Thanks for looking into it.  I'm still (or again) seeing very
poor responsiveness.  Right now, bringing up an existing bug
takes an entire minute.

Martin

[Bug target/83946] [7/8 Regression] Safe Indirect Jumps broken on AIX

[segher at gcc dot gnu.org]

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

--- Comment #11 from Segher Boessenkool  ---
Author: segher
Date: Fri Jan 26 21:31:37 2018
New Revision: 257110

URL: https://gcc.gnu.org/viewcvs?rev=257110=gcc=rev
Log:
rs6000: Fix safe-indirect-jump-[18].c

Thist patch merges the safe-indirect-jump-1.c and -8.c testcases,
since they do the same thing.  On the 64-bit and AIX ABIs the indirect
call is not a sibcall, since there is code generated after the call
(the restore of r2).  On the 32-bit non-AIX ABIs it is a sibcall.


Backport from trunk
2018-01-26  Segher Boessenkool  

* gcc.target/powerpc/safe-indirect-jump-1.c: Build on all targets.
Make expected output depend on whether we expect sibcalls or not.
* gcc.target/powerpc/safe-indirect-jump-8.c: Delete (merged into
safe-indirect-jump-1.c).

Backport from trunk
2018-01-21  Bill Schmidt  

PR target/83946
* gcc.target/powerpc/safe-indirect-jump-8.c: Skip for AIX.

Removed:
   
branches/gcc-7-branch/gcc/testsuite/gcc.target/powerpc/safe-indirect-jump-8.c
Modified:
branches/gcc-7-branch/gcc/testsuite/ChangeLog
   
branches/gcc-7-branch/gcc/testsuite/gcc.target/powerpc/safe-indirect-jump-1.c

[PATCH] RISC-V: Add --specs=nosys.specs support.

[Jim Wilson]

This makes --specs=nosys.specs work correctly.  Without this patch, libnosys
is ignored because libgloss gets pulled in first.  We may have to revisit this
in the future when we have some proper BSPs defined for various RISC-V
hardware.  Meanwhile, adding libgloss by default makes things easier for
inexperienced users and I don't want to break that.

This was tested with a testsuite run for a newlib target, there were no
regressions.  Also tested by hand to verify that --specs=nosys.specs works
correctly.

Committed.

Jim

gcc/
* config/riscv/elf.h (LIB_SPEC): Don't include -lgloss when nosys.specs
specified.
---
 gcc/config/riscv/elf.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/config/riscv/elf.h b/gcc/config/riscv/elf.h
index 43ad68bbdf2..f39e83234d2 100644
--- a/gcc/config/riscv/elf.h
+++ b/gcc/config/riscv/elf.h
@@ -24,7 +24,7 @@ along with GCC; see the file COPYING3.  If not see
 /* Link against Newlib libraries, because the ELF backend assumes Newlib.
Handle the circular dependence between libc and libgloss. */
 #undef  LIB_SPEC
-#define LIB_SPEC "--start-group -lc -lgloss --end-group"
+#define LIB_SPEC "--start-group -lc %{!specs=nosys.specs:-lgloss} --end-group"
 
 #undef  STARTFILE_SPEC
 #define STARTFILE_SPEC "crt0%O%s crtbegin%O%s"
-- 
2.14.1

[Bug middle-end/84034] [6/7/8 Regression] incomplete warning message with dos line endings

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-01-26
 CC||dmalcolm at gcc dot gnu.org
Summary|incomplete warning message  |[6/7/8 Regression]
   |with dos line endings   |incomplete warning message
   ||with dos line endings
 Ever confirmed|0   |1

--- Comment #2 from David Malcolm  ---
Confirmed.  gcc 6, 7 and 8 are affected; gcc 5 is not affected.

Re: gcc generated memcpy calls symbol version

[H.J. Lu]

On Fri, Jan 26, 2018 at 1:17 PM, Tom Mason  wrote:
> I'm not entirely sure I understand that issue. From what I understand, calls
> to a function in a shared library should always use the PLT?
> Also, I don't understand the purpose of applying hidden visibility to an
> extern symbol,

There is no need for PLT since hidden symbol is defined locally.  But
GCC ignores hidden visibility for libcalls, like memcpy.  If GCC treats
them like normal calls, your scheme and my testcase should work.


> But anyway, doesn't matter terribly much if I understand :p
>
> On Fri, Jan 26, 2018 at 8:37 PM, H.J. Lu  wrote:
>>
>> On Fri, Jan 26, 2018 at 12:29 PM, Tom Mason  wrote:
>> > Hi,
>> > I've got a project here:
>> > https://github.com/wheybags/glibc_version_header
>> > which uses .symver directives to link to a specified version of glibc,
>> > so
>> > long as it's older than the version on your system.
>> > This works, but a problem I'm having is that gcc itself will sometimes
>> > insert calls to memcpy (or memmove, memset and memcmp), as documented
>> > here:
>> > https://gcc.gnu.org/onlinedocs/gcc/Standards.html
>> > When it does so, it doesn't respect the .symver directives, and uses the
>> > default version.
>> > Is there any way for me to force the version for these symbols aswell?
>> > I'm aware that I can disable the whole mechanism with -freestanding, but
>> > I
>> > don't want to cripple the optimiser.
>>
>> I think this is related to:
>>
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67220
>>
>> --
>> H.J.
>
>



-- 
H.J.

Re: gcc generated memcpy calls symbol version

[Tom Mason]

I'm not entirely sure I understand that issue. From what I understand,
calls to a function in a shared library should always use the PLT?
Also, I don't understand the purpose of applying hidden visibility to an
extern symbol,
But anyway, doesn't matter terribly much if I understand :p

On Fri, Jan 26, 2018 at 8:37 PM, H.J. Lu  wrote:

> On Fri, Jan 26, 2018 at 12:29 PM, Tom Mason  wrote:
> > Hi,
> > I've got a project here: https://github.com/wheybags/
> glibc_version_header
> > which uses .symver directives to link to a specified version of glibc, so
> > long as it's older than the version on your system.
> > This works, but a problem I'm having is that gcc itself will sometimes
> > insert calls to memcpy (or memmove, memset and memcmp), as documented
> here:
> > https://gcc.gnu.org/onlinedocs/gcc/Standards.html
> > When it does so, it doesn't respect the .symver directives, and uses the
> > default version.
> > Is there any way for me to force the version for these symbols aswell?
> > I'm aware that I can disable the whole mechanism with -freestanding, but
> I
> > don't want to cripple the optimiser.
>
> I think this is related to:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67220
>
> --
> H.J.
>

[Bug c++/60336] empty struct value is passed differently in C and C++

[hjl.tools at gmail dot com]

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

--- Comment #52 from H.J. Lu  ---
*** Bug 69846 has been marked as a duplicate of this bug. ***

[Bug target/69846] empty struct value fails to pass properly

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE
   Target Milestone|--- |8.0

--- Comment #4 from H.J. Lu  ---
g++.dg/abi/pr60336-2.C is very similar to this one.

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

[Bug target/69846] empty struct value fails to pass properly

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-01-26
 Ever confirmed|0   |1

--- Comment #3 from H.J. Lu  ---
This is a dup of PR 60336.  I will submit a testcase and close it.

[Bug c++/84036] [8 Regression] ICE on valid code in C++14, variadic lambda capture in a template function

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

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

[Bug c++/83956] [8 regression] error: use of deleted function ‘{anonymous}::a::~a()’

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

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

C++ PATCH for c++/83956, wrong error with anon union and deleted dtor

[Jason Merrill]

Here, when we walk the subobjects to determine the exception
specification of a defaulted destructor in order to apply it to a
user-provided destructor, we shouldn't look at variant members dtors,
which aren't called.

We really shouldn't be looking at variant members here at all except
to determine deletedness, but decided to go with a more limited change
since we're in stage 4.

Tested x86_64-pc-linux-gnu, applying to trunk.
commit df8979f62c2977bd18a2e085e90dbdd4c2f8f98e
Author: Jason Merrill 
Date:   Fri Jan 26 11:38:19 2018 -0500

PR c++/83956 - wrong dtor error with anonymous union

* method.c (walk_field_subobs): Variant members only affect
deletedness.
(maybe_explain_implicit_delete): Pass _p for diagnostic.

diff --git a/gcc/cp/method.c b/gcc/cp/method.c
index 5bc830cd820..33029d7967e 100644
--- a/gcc/cp/method.c
+++ b/gcc/cp/method.c
@@ -1305,6 +1305,15 @@ walk_field_subobs (tree fields, tree fnname, 
special_function_kind sfk,
  || DECL_ARTIFICIAL (field))
continue;
 
+  /* Variant members only affect deletedness.  In particular, they don't
+affect the exception-specification of a user-provided destructor,
+which we're figuring out via get_defaulted_eh_spec.  So if we aren't
+asking if this is deleted, don't even look up the function; we don't
+want an error about a deleted function we aren't actually calling.  */
+  if (sfk == sfk_destructor && deleted_p == NULL
+ && TREE_CODE (DECL_CONTEXT (field)) == UNION_TYPE)
+   break;
+
   mem_type = strip_array_types (TREE_TYPE (field));
   if (assign_p)
{
@@ -1850,7 +1859,7 @@ maybe_explain_implicit_delete (tree decl)
  "%q#D is implicitly deleted because the default "
  "definition would be ill-formed:", decl);
  synthesized_method_walk (ctype, sfk, const_p,
-  NULL, NULL, NULL, NULL, true,
+  NULL, NULL, _p, NULL, true,
   , parms);
}
  else if (!comp_except_specs
diff --git a/gcc/testsuite/g++.dg/cpp0x/anon-union2.C 
b/gcc/testsuite/g++.dg/cpp0x/anon-union2.C
new file mode 100644
index 000..38c91f41a5c
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/anon-union2.C
@@ -0,0 +1,12 @@
+// PR c++/83956
+// { dg-do compile { target c++11 } }
+
+struct a {
+  ~a() = delete;
+};
+struct b {
+  ~b() {}
+  union {
+a c;
+  };
+};

[Bug c++/83956] [8 regression] error: use of deleted function ‘{anonymous}::a::~a()’

[jason at gcc dot gnu.org]

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

--- Comment #4 from Jason Merrill  ---
Author: jason
Date: Fri Jan 26 20:47:32 2018
New Revision: 257107

URL: https://gcc.gnu.org/viewcvs?rev=257107=gcc=rev
Log:
PR c++/83956 - wrong dtor error with anonymous union

* method.c (walk_field_subobs): Variant members only affect
deletedness.
(maybe_explain_implicit_delete): Pass _p for diagnostic.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/anon-union2.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/method.c

[Bug target/55258] SSE register isn't used for 16byte copy

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |7.0

--- Comment #2 from H.J. Lu  ---
GCC 7 O2 generates:

_dl_profile_fixup:
.LFB0:
.cfi_startproc
subl$24, %esp
.cfi_def_cfa_offset 32
movl92(%edi), %eax
movl24(%edi), %edx
movl%esp, %edi
movl(%eax), %eax
movl(%eax,%esi,4), %eax
shrl$8, %eax
sall$4, %eax
addl(%edx), %eax
movdqu  (%eax), %xmm0
movaps  %xmm0, (%rsp)
callsymbind32
addl$24, %esp
.cfi_def_cfa_offset 8
ret
.cfi_endproc

[Bug rtl-optimization/83530] [8 Regression] ICE in reset_sched_cycles_in_current_ebb, at sel-sched.c:7150

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2018-01-26
 CC||aldyh at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Aldy Hernandez  ---
I cannot reproduce on mainline with a cross of:

--target=powerpc-e300c3-linux-gnu

or

--target=powerpc-linux-gnu

Is this still an issue on mainline?  FWIW, I couldn't reproduce with a cross
for r255766 as reported.

Re: [PATCH] rs6000: Fix safe-indirect-jump-[18].c

[David Edelsohn]

On Fri, Jan 26, 2018 at 2:27 PM, Segher Boessenkool
 wrote:
> Thist patch merges the safe-indirect-jump-1.c and -8.c testcases,
> since they do the same thing.  On the 64-bit and AIX ABIs the indirect
> call is not a sibcall, since there is code generated after the call
> (the restore of r2).  On the 32-bit non-AIX ABIs it is a sibcall.
>
> Tested on powerpc64-linux {-m32,-m64}, and on powerpc-ibm-aix7.1.3.0 .
> Is this okay for trunk and 7 branch?
>
>
> Segher
>
>
> 2018-01-26  Segher Boessenkool  
>
> gcc/testsuite/
> * gcc.target/powerpc/safe-indirect-jump-1.c: Build on all targets.
> Make expected output depend on whether we expect sibcalls or not.
> * gcc.target/powerpc/safe-indirect-jump-8.c: Delete (merged into
> safe-indirect-jump-1.c).

Okay.

Thanks, David

Re: gcc generated memcpy calls symbol version

[H.J. Lu]

On Fri, Jan 26, 2018 at 12:29 PM, Tom Mason  wrote:
> Hi,
> I've got a project here: https://github.com/wheybags/glibc_version_header
> which uses .symver directives to link to a specified version of glibc, so
> long as it's older than the version on your system.
> This works, but a problem I'm having is that gcc itself will sometimes
> insert calls to memcpy (or memmove, memset and memcmp), as documented here:
> https://gcc.gnu.org/onlinedocs/gcc/Standards.html
> When it does so, it doesn't respect the .symver directives, and uses the
> default version.
> Is there any way for me to force the version for these symbols aswell?
> I'm aware that I can disable the whole mechanism with -freestanding, but I
> don't want to cripple the optimiser.

I think this is related to:

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

-- 
H.J.

[Bug fortran/84073] New: In -fc-prototypes fixed (nonzero) length strings are mapped to plain char in prototype.

[emsr at gcc dot gnu.org]

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

Bug ID: 84073
   Summary: In -fc-prototypes fixed (nonzero) length strings are
mapped to plain char in prototype.
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: emsr at gcc dot gnu.org
  Target Milestone: ---

Created attachment 43260
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43260=edit
Module with fixed length strings.

Given this:
===
! ../../bin/bin/gfortran -c -fc-prototypes fixlen_character.f95 

module utderror

  use iso_c_binding

  type, bind(c) :: utderror_t
integer(c_int):: projectid
integer(c_int):: txantennaid
integer(c_int):: rxantennaid
integer(c_int):: pathid
integer(c_int):: frequencysetid
integer(c_int):: frequencyid
integer(c_int):: errornumber
integer(c_int):: nerrorloc
real(c_double):: errorstartloc(3)
real(c_double):: errorendloc(3)
character(kind=c_char, len=41) :: errorsubsystem
character(kind=c_char, len=9) :: errorseverity
integer(c_int):: errorid
character(kind=c_char, len=1001) :: errormessage
  end type

  type(utderror_t), bind(c), save :: utderror_v

  interface

subroutine add_utd_error(ierror) bind(c)
  use iso_c_binding
  implicit none
  integer(c_int), intent(out) :: ierror
end subroutine

  end interface

end module
===

I get:
===
typedef struct utderror_t {
int projectid;
int txantennaid;
int rxantennaid;
int pathid;
int frequencysetid;
int frequencyid;
int errornumber;
int nerrorloc;
double errorstartloc[3];
double errorendloc[3];
char errorsubsystem;
char errorseverity;
int errorid;
char errormessage;
} utderror_t;
void add_utd_error (int *ierror);
typedef struct utderror_t {
int projectid;
int txantennaid;
int rxantennaid;
int pathid;
int frequencysetid;
int frequencyid;
int errornumber;
int nerrorloc;
double errorstartloc[3];
double errorendloc[3];
char errorsubsystem;
char errorseverity;
int errorid;
char errormessage;
} utderror_t;
void add_utd_error (int *ierror);
extern utderror_t utderror_v;
extern utderror_t utderror_v;
===

I think the strings should be
char errorsubsystem[41];
char errorseverity[9];
int errorid;
char errormessage[1001];

If I do this by hand things work out.

Ed

gcc generated memcpy calls symbol version

[Tom Mason]

Hi,
I've got a project here: https://github.com/wheybags/glibc_version_header
which uses .symver directives to link to a specified version of glibc, so
long as it's older than the version on your system.
This works, but a problem I'm having is that gcc itself will sometimes
insert calls to memcpy (or memmove, memset and memcmp), as documented here:
https://gcc.gnu.org/onlinedocs/gcc/Standards.html
When it does so, it doesn't respect the .symver directives, and uses the
default version.
Is there any way for me to force the version for these symbols aswell?
I'm aware that I can disable the whole mechanism with -freestanding, but I
don't want to cripple the optimiser.
Regards,
Tom Mason

Re: [PATCH, fortran] Support Fortran 2018 teams

[Alessandro Fanfarillo]

Committed revision 257105.

Thanks.

On Wed, Jan 24, 2018 at 3:17 PM, Jakub Jelinek  wrote:
> On Wed, Jan 24, 2018 at 08:19:58PM +, Paul Richard Thomas wrote:
>> (Jakub, This is all hidden behind the -fcoarray option. To my mind
>> this is safe for release.)
>
> Ok from RM POV.
>
> Jakub



-- 

Alessandro Fanfarillo, Ph.D.
Postdoctoral Researcher
National Center for Atmospheric Research
Mesa Lab, Boulder, CO, USA
303-497-1229

[Bug c++/84055] warning: ignoring attributes on template argument ‘cl_uint {aka unsigned int}’ [-Wignored-attributes]

[kip at thevertigo dot com]

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

--- Comment #4 from Kip Warner  ---
Thanks Martin. I'm curious where the __int32 type was even coming from.
cl_platform.h has the following typedef, among others that use it...

typedef unsigned __int32cl_uint;

...but no where can I find __int32 declared anywhere. As far as I know, this is
an M$ V!C++ built in type and gcc doesn't have it built in. The reason why I'm
curious is because I wanted to find where the alignment attribute was being
specified which was causing this hiccup?

[Bug target/81763] Issues with BMI on 32bit x86 apps on GCC 7.1+

[ubizjak at gmail dot com]

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

--- Comment #48 from Uroš Bizjak  ---
(In reply to Mike Lothian from comment #47)
> With the patch you've committed to gcc master, applied on top of GCC 7.3 I'm
> now seeing the following error building Clang:

I don't think this is related to the original bugreport involving BMI
instructions.  Could be Clang's source incompatibility with 32bit target.

In any case, please open a new PR.

[Bug target/84072] New: [meta-bug] -mindirect-branch=thunk issues

[hjl.tools at gmail dot com]

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

Bug ID: 84072
   Summary: [meta-bug] -mindirect-branch=thunk issues
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
Depends on: 83970, 84039
  Target Milestone: ---
Target: x86

This meta bug tracks all -mindirect-branch=thunk related issues


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83970
[Bug 83970] -mindirect-branch=thunk -fno-plt generates CET-incompatible thunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84039
[Bug 84039] x86 retpolines and CFI

[Bug c++/84055] warning: ignoring attributes on template argument ‘cl_uint {aka unsigned int}’ [-Wignored-attributes]

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-01-26
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1
  Known to fail||7.2.0, 8.0

--- Comment #3 from Martin Sebor  ---
I think it's just a matter of G++ warning that a type attribute is being
dropped when instantiating a template on the type.  This is not entirely
intuitive and there have been other bug reports in the past as a result. 
Here's a small test case:

$ cat t.C && gcc -S -Wall t.C
typedef unsigned cl_uint __attribute__((aligned(4)));

template 
struct vector { };

vector v;
t.C:6:15: warning: ignoring attributes on template argument ‘cl_uint’ {aka
‘unsigned int’} [-Wignored-attributes]
 vector v;
   ^

I'll go ahead and confirm this report because the attribute here is superfluous
when an int is 4-byte aligned and so GCC might as well just silently drop it
when it's explicitly specified and avoid issuing a pointless warning.

I also confirm it because I'm bothered by the warning being issued
inconsistently.  For example, in the test case below, instantiating the class
template A on I4 triggers the (pointless in this case) -Wignored-attributes
warning but instantiating the function template g on f does not even though the
-Wreturn-type warning implies that the noreturn attribute was dropped.  I think
GCC should be consistent, if not in applying/dropping attributes then in
issuing the -Wignored-attributes warning.

$ cat t.C && gcc -S -Wall t.C
typedef int I4 __attribute__ ((aligned (4)));

template 
struct A { };
template struct A;

int __attribute__ ((noreturn)) f ();

template 
int g (T t) { t (); }

void h ()
{
  g (f);
}
t.C:5:21: warning: ignoring attributes on template argument ‘I4’ {aka ‘int’}
[-Wignored-attributes]
 template struct A;
 ^
t.C: In function ‘int g(T)’:
t.C:10:21: warning: no return statement in function returning non-void
[-Wreturn-type]
 int g (T t) { t (); }
 ^

[Bug fortran/83998] [8 Regression] ICE in gfc_conv_intrinsic_dot_product, at fortran/trans-intrinsic.c:4403

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #3 from kargl at gcc dot gnu.org ---
Fixed on trunk.  Thanks for the byg report.

[Bug fortran/83998] [8 Regression] ICE in gfc_conv_intrinsic_dot_product, at fortran/trans-intrinsic.c:4403

[kargl at gcc dot gnu.org]

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

--- Comment #2 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Fri Jan 26 19:33:16 2018
New Revision: 257104

URL: https://gcc.gnu.org/viewcvs?rev=257104=gcc=rev
Log:
2018-01-26  Steven G. Kargl  

PR fortran/83998
* simplify.c (compute_dot_product):  Initialize result to INTEGER(1) 0
or .false.  The summation does the correct type conversion.
(gfc_simplify_dot_product): Special case zero-sized arrays.


2018-01-26  Steven G. Kargl  

PR fortran/83998
* gfortran.dg/dot_product_4.f90

Added:
trunk/gcc/testsuite/gfortran.dg/dot_product_4.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/simplify.c
trunk/gcc/testsuite/ChangeLog

[PATCH] rs6000: Fix safe-indirect-jump-[18].c

[Segher Boessenkool]

Thist patch merges the safe-indirect-jump-1.c and -8.c testcases,
since they do the same thing.  On the 64-bit and AIX ABIs the indirect
call is not a sibcall, since there is code generated after the call
(the restore of r2).  On the 32-bit non-AIX ABIs it is a sibcall.

Tested on powerpc64-linux {-m32,-m64}, and on powerpc-ibm-aix7.1.3.0 .
Is this okay for trunk and 7 branch?


Segher


2018-01-26  Segher Boessenkool  

gcc/testsuite/
* gcc.target/powerpc/safe-indirect-jump-1.c: Build on all targets.
Make expected output depend on whether we expect sibcalls or not.
* gcc.target/powerpc/safe-indirect-jump-8.c: Delete (merged into
safe-indirect-jump-1.c).

---
 gcc/testsuite/gcc.target/powerpc/safe-indirect-jump-1.c | 10 --
 gcc/testsuite/gcc.target/powerpc/safe-indirect-jump-8.c | 16 
 2 files changed, 8 insertions(+), 18 deletions(-)
 delete mode 100644 gcc/testsuite/gcc.target/powerpc/safe-indirect-jump-8.c

diff --git a/gcc/testsuite/gcc.target/powerpc/safe-indirect-jump-1.c 
b/gcc/testsuite/gcc.target/powerpc/safe-indirect-jump-1.c
index 99cfab2..d1ab83a 100644
--- a/gcc/testsuite/gcc.target/powerpc/safe-indirect-jump-1.c
+++ b/gcc/testsuite/gcc.target/powerpc/safe-indirect-jump-1.c
@@ -1,4 +1,4 @@
-/* { dg-do compile { target { lp64 } } } */
+/* { dg-do compile } */
 /* { dg-additional-options "-mno-speculate-indirect-jumps" } */
 
 /* Test for deliberate misprediction of indirect calls.  */
@@ -11,4 +11,10 @@ int bar ()
 }
 
 /* { dg-final { scan-assembler "crset 2" } } */
-/* { dg-final { scan-assembler "beqctrl-" } } */
+
+/* The AIX and ELFv2 ABIs don't allow a sibcall here.  */
+/* { dg-final { scan-assembler "beqctrl-" { target { lp64 || { powerpc*-*-aix* 
} } } } } */
+
+/* The other ABIs do allow a sibcall.  */
+/* { dg-final { scan-assembler "beqctr-" { target { ilp32 && !powerpc*-*-aix* 
} } } } */
+/* { dg-final { scan-assembler {b \$} { target { ilp32 && !powerpc*-*-aix* } } 
} } */
diff --git a/gcc/testsuite/gcc.target/powerpc/safe-indirect-jump-8.c 
b/gcc/testsuite/gcc.target/powerpc/safe-indirect-jump-8.c
deleted file mode 100644
index 0a6f231..000
--- a/gcc/testsuite/gcc.target/powerpc/safe-indirect-jump-8.c
+++ /dev/null
@@ -1,16 +0,0 @@
-/* { dg-do compile { target { ilp32 } } } */
-/* { dg-skip-if "" { powerpc*-*-aix* } } */
-/* { dg-additional-options "-O2 -mno-speculate-indirect-jumps" } */
-
-/* Test for deliberate misprediction of -m32 sibcalls.  */
-
-extern int (*f)();
-
-int bar ()
-{
-  return (*f) ();
-}
-
-/* { dg-final { scan-assembler "crset 2" } } */
-/* { dg-final { scan-assembler "beqctr-" } } */
-/* { dg-final { scan-assembler {b \$} } } */
-- 
1.8.3.1

[Bug c/84046] [6/7/8 Regression] global zero-sized objects may have same address

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
If you want aggregate with size 1 and isn't used to store information, use
typedef struct { char : 1; } zero;
instead.

[Bug lto/83967] LTO removes C functions declared as weak in assembler(depending on files order in linking)

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |MOVED

--- Comment #13 from H.J. Lu  ---
(In reply to H.J. Lu from comment #12)
> 
> Yes, I can reproduce it with binutils 2.29.1.  But it was fixed in
> 2.30.

This is:

https://sourceware.org/bugzilla/show_bug.cgi?id=22502

[Bug c/84046] [6/7/8 Regression] global zero-sized objects may have same address

[uecker at eecs dot berkeley.edu]

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

--- Comment #3 from Martin Uecker  ---


(In reply to Richard Biener from comment #1)
> Confirmed.  I think the C language doesn't specify this since zero-sized
> arrays are a GNU extension and thus in C no zero-sized types/decls exist?
> 
> So not sure if there's anything to fix - Joseph?
> 
> Note that for global unique addresses you can use global objects of size 1,
> like a char object.  Not sure why you think using a GNU extension is
> superior?

It makes it clear in a nice way that these variables are not used to store
information.


(In reply to Jakub Jelinek from comment #2)
> Zero sized objects of course can have the same address and always had.
> Just in your testcase the comparison used to be optimized away before
> r218462.
> If you hide it from the optimizers, like with:
>   int *p = a;
>   int *q = b;
>   asm ("" : "+r" (p), "+r" (q));
> if(p == q) __builtin_abort ();
> you'll get aborts all the way to r104500 (oldest revision I have around).

Oh well, so this was simply an incorrect optimization.

[Bug c++/83503] [8 Regression] bogus -Wattributes for const and pure on function template specialization

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-01-26
 CC||aldyh at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Aldy Hernandez  ---
Confirmed.

[Bug c++/83502] [6/7/8 Regression] bogus -Wattributes for always_inline and noinline on function template specialization

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-01-26
 CC||aldyh at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #3 from Aldy Hernandez  ---
Confirmed.

[Bug tree-optimization/84053] [6/7/8 Regression] missing -Warray-bounds accessing a struct array member

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-01-26
 CC||aldyh at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Aldy Hernandez  ---
Confirmed.

[Bug middle-end/84071] New: [7/8 regression] nonzero_bits1 of subreg incorrect

[wilco at gcc dot gnu.org]

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

Bug ID: 84071
   Summary: [7/8 regression] nonzero_bits1 of subreg incorrect
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wilco at gcc dot gnu.org
  Target Milestone: ---

PR59461 changed nonzero_bits1 incorrectly for subregs:

  /* On many CISC machines, accessing an object in a wider mode
 causes the high-order bits to become undefined.  So they are
 not known to be zero.  */
  rtx_code extend_op;
  if ((!WORD_REGISTER_OPERATIONS
   /* If this is a typical RISC machine, we only have to worry
  about the way loads are extended.  */
   || ((extend_op = load_extend_op (inner_mode)) == SIGN_EXTEND
   ? val_signbit_known_set_p (inner_mode, nonzero)
   : extend_op != ZERO_EXTEND)
   || (!MEM_P (SUBREG_REG (x)) && !REG_P (SUBREG_REG (x
  && xmode_width > inner_width)
nonzero
  |= (GET_MODE_MASK (GET_MODE (x)) & ~GET_MODE_MASK (inner_mode));

If WORD_REGISTER_OPERATIONS is set and load_extend_op is ZERO_EXTEND, rtl like

(subreg:SI (reg:HI 125) 0)

is assumed to be always zero-extended. This is incorrect since modes that are
smaller than WORD_MODE may contain random top bits. This is equally true for
RISC and CISC ISAs and independent of WORD_REGISTER_OPERATIONS, so it's unclear
why the !REG_P check was added.

On ARM this causes the following bug:

arm-none-eabi-gcc -march=armv7-a -marm -O2 -S -o- -mbig-endian

typedef union 
{
  signed short ss;
  unsigned short us;
  int x;
} U;

int f(int x, int y, int z, int a, U u)
{
  return (u.ss <= 0) + u.us;
}

ldrsh   r3, [sp]
sxthr0, r3
cmp r0, #0  // correctly uses sign-extended value
movgt   r0, r3  // wrong - must be zero-extended!!!
addle   r0, r3, #1
bx  lr

[Bug tree-optimization/84051] [6/7/8 Regression] missing -Warray-bounds on an out-of-bounds access via an array pointer

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-01-26
 CC||aldyh at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Aldy Hernandez  ---
Confirmed.

Re: GCC 8.0.0 Status Report (2018-01-15), Trunk in Regression and Documentation fixes only mode

[Andrew Roberts]

It might be worth checking what MPFR is linking with in the test suite. 
I seemed to see it
linking with the system libs when built in tree, rather than the in tree 
ones.

This seems a regression in the MPFR test suite compared with 3.1.6

Andrew

On 26/01/18 14:22, Rainer Orth wrote:


I've given it a try with that combo on sparc-sun-solaris2.10 (a primary
target) and i386-pc-solaris2.10 (32 and 64-bit each), with mixed results:

* The gmp reuse test enters an infinite loop on 32-bit sparc.

* The mpfr trint test FAILs on sparcv9.  The failure vanishes with
   --disable-thread-safe.

* Many mpfr tests FAIL on amd64.  Again, they vanish with
   --disable-thread-safe.

I have not yet tried building gcc with those versions yet.

Beside, IMO we need to make sure that trunk and all open branches can be
built with that version set; having to maintain two different sets isn't
an option.

Rainer

[Bug lto/83967] LTO removes C functions declared as weak in assembler(depending on files order in linking)

[hjl.tools at gmail dot com]

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

--- Comment #12 from H.J. Lu  ---
(In reply to Richard Biener from comment #8)

> and then I get
> 
> > gcc-7 t2.s t1.c -flto
> /tmp/ccGhH7Cp.o:(.data+0x0): undefined reference to `Handler'
> collect2: error: ld returned 1 exit status
> > gcc-7 t1.c t2.s -flto
> 
> in the working case:
> 
> 1
> t1.o 4
> 190 16b2980a71930688 PREEMPTED_REG Handler
> 198 16b2980a71930688 PREVAILING_DEF_IRONLY i
> 194 16b2980a71930688 PREVAILING_DEF main
> 202 16b2980a71930688 RESOLVED_EXEC Dispatch
> 
> in the failing case (GNU ld):
> 
> 1
> t1.o 4
> 190 801577c96f9ccef3 PREVAILING_DEF_IRONLY Handler
> 198 801577c96f9ccef3 PREVAILING_DEF_IRONLY i
> 194 801577c96f9ccef3 PREVAILING_DEF main
> 202 801577c96f9ccef3 RESOLVED_EXEC Dispatch
> 
> which works with gold:
> 
> 1
> t1.o 4
> 190 680bbd652c7cfe04 PREVAILING_DEF Handler
> 198 680bbd652c7cfe04 PREVAILING_DEF_IRONLY i
> 194 680bbd652c7cfe04 PREVAILING_DEF main
> 202 680bbd652c7cfe04 RESOLVED_EXEC Dispatch
> 
> HJ?  This is with binutils 2.29.1, thus confirmed but as a GNU ld issue.

Yes, I can reproduce it with binutils 2.29.1.  But it was fixed in
2.30.

[Bug tree-optimization/83776] [6/7/8 Regression] missing -Warray-bounds indexing past the end of a string literal

[msebor at gcc dot gnu.org]

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

--- Comment #5 from Martin Sebor  ---
(In reply to Aldy Hernandez from comment #4)
> Isn't this a duplicate of pr84047?  My patch on that seems to fix this bug
> as well.
> 
> I think we should merge these PRs somehow.

This bug was introduced by r164688 while pr84047 by r161655.  It may be
possible to fix both by a single patch.  The patch I submitted for this bug
also happens to fix the test case in bug 84047 comment #0 (I had missed that
when I opened the bug) but not the one in bug 84047 comment #2.  It might be
just an oversight on my part.

I think I would prefer to keep the bugs separate since they have different root
causes, even if we end up fixing them in the same patch.

[Bug tree-optimization/84050] [6/7/8 Regression] missing -Warray-bounds accessing a struct array member

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-01-26
 CC||aldyh at gcc dot gnu.org,
   ||hubicka at gcc dot gnu.org,
   ||jakub at gcc dot gnu.org
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=84047
 Ever confirmed|0   |1

--- Comment #2 from Aldy Hernandez  ---
Confirmed.

FWIW, my patch for 84047 does not fix this PR, as VRP never sees the
problematic instruction and is not able to warn.  This is because ccp2 has
removed the instruction.

Before ccp2 we had:

fstatic_array ()
{
  static struct A a = {.a={1, 2, 3}};
  int _2;

   [local count: 1073741825]:
  _2 = a.a[7];
  return _2;
}

After ccp2 we have:

fstatic_array ()
{
  static struct A a = {.a={1, 2, 3}};

   [local count: 1073741825]:
  return 0;
}

I'm not a language lawyer, so I don't know what the semantics of undefined
behavior is.  Is returning 0 even the correct thing to do?

Though perhaps, as Jakub mentions in pr84047, maybe we should move this GCC 9?

[Bug target/81763] Issues with BMI on 32bit x86 apps on GCC 7.1+

[mike at fireburn dot co.uk]

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

--- Comment #47 from Mike Lothian  ---
With the patch you've committed to gcc master, applied on top of GCC 7.3 I'm
now seeing the following error building Clang:

[294/954] /usr/bin/x86_64-pc-linux-gnu-g++ -m32 -D_FILE_OFFSET_BITS=64
-D_GNU_SOURCE -D_LARGEFILE_SOURCE -D__STDC_CONSTANT_MACROS
-D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -Ilib/Serialization
-I/var/tmp/portage/sys-devel/clang-/work/x/y/clang-/lib/Serialization
-I/var/tmp/portage/sys-devel/clang-/work/x/y/clang-/include -Iinclude
-I/usr/lib/llvm/7/include  -DNDEBUG -O2 -march=native -pipe
-mindirect-branch=thunk -mfunction-return=thunk -mindirect-branch-register
-fpermissive -fPIC -fvisibility-inlines-hidden -Werror=date-time -std=c++11
-Wall -W -Wno-unused-parameter -Wwrite-strings -Wcast-qual
-Wno-missing-field-initializers -Wdelete-non-virtual-dtor -Wno-comment
-ffunction-sections -fdata-sections -fno-common -Woverloaded-virtual
-fno-strict-aliasing -pedantic -Wno-long-long -fPIC -MD -MT
lib/Serialization/CMakeFiles/clangSerialization.dir/ASTReader.cpp.o -MF
lib/Serialization/CMakeFiles/clangSerialization.dir/ASTReader.cpp.o.d -o
lib/Serialization/CMakeFiles/clangSerialization.dir/ASTReader.cpp.o -c
/var/tmp/portage/sys-devel/clang-/work/x/y/clang-/lib/Serialization/ASTReader.cpp
FAILED: lib/Serialization/CMakeFiles/clangSerialization.dir/ASTReader.cpp.o
/usr/bin/x86_64-pc-linux-gnu-g++ -m32 -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE
-D_LARGEFILE_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS
-D__STDC_LIMIT_MACROS -Ilib/Serialization
-I/var/tmp/portage/sys-devel/clang-/work/x/y/clang-/lib/Serialization
-I/var/tmp/portage/sys-devel/clang-/work/x/y/clang-/include -Iinclude
-I/usr/lib/llvm/7/include  -DNDEBUG -O2 -march=native -pipe
-mindirect-branch=thunk -mfunction-return=thunk -mindirect-branch-register
-fpermissive -fPIC -fvisibility-inlines-hidden -Werror=date-time -std=c++11
-Wall -W -Wno-unused-parameter -Wwrite-strings -Wcast-qual
-Wno-missing-field-initializers -Wdelete-non-virtual-dtor -Wno-comment
-ffunction-sections -fdata-sections -fno-common -Woverloaded-virtual
-fno-strict-aliasing -pedantic -Wno-long-long -fPIC -MD -MT
lib/Serialization/CMakeFiles/clangSerialization.dir/ASTReader.cpp.o -MF
lib/Serialization/CMakeFiles/clangSerialization.dir/ASTReader.cpp.o.d -o
lib/Serialization/CMakeFiles/clangSerialization.dir/ASTReader.cpp.o -c
/var/tmp/portage/sys-devel/clang-/work/x/y/clang-/lib/Serialization/ASTReader.cpp
In file included from
/var/tmp/portage/sys-devel/clang-/work/x/y/clang-/include/clang/AST/APValue.h:20:0,
 from
/var/tmp/portage/sys-devel/clang-/work/x/y/clang-/include/clang/AST/Decl.h:17,
 from
/var/tmp/portage/sys-devel/clang-/work/x/y/clang-/include/clang/AST/DeclObjC.h:17,
 from
/var/tmp/portage/sys-devel/clang-/work/x/y/clang-/include/clang/Serialization/ASTReader.h:17,
 from
/var/tmp/portage/sys-devel/clang-/work/x/y/clang-/lib/Serialization/ASTReader.cpp:14:
/usr/lib/llvm/7/include/llvm/ADT/PointerIntPair.h: In instantiation of ‘struct
llvm::PointerIntPairInfo*>, 2,
llvm::PointerLikeTypeTraits*> > >’:
/usr/lib/llvm/7/include/llvm/ADT/PointerIntPair.h:56:57:   required from
‘PointerTy llvm::PointerIntPair::getPointer() const [with PointerTy =
llvm::PointerUnion*>; unsigned int IntBits = 2; IntType = unsigned int; PtrTraits
= llvm::PointerLikeTypeTraits*> >; Info =
llvm::PointerIntPairInfo*>, 2,
llvm::PointerLikeTypeTraits*> > >]’
/var/tmp/portage/sys-devel/clang-/work/x/y/clang-/include/clang/AST/Decl.h:2859:39:
  required from here
/usr/lib/llvm/7/include/llvm/ADT/PointerIntPair.h:132:3: error: static
assertion failed: PointerIntPair with integer size too large for pointer
   static_assert(IntBits <= PtrTraits::NumLowBitsAvailable,
   ^
/usr/lib/llvm/7/include/llvm/ADT/PointerIntPair.h:147:42: warning: left shift
count >= width of type [-Wshift-count-overflow]
 ShiftedIntMask = (uintptr_t)(IntMask << IntShift)
 ~^~~~
/usr/lib/llvm/7/include/llvm/ADT/PointerIntPair.h:147:42: warning: right
operand of shift expression ‘(3 << 4294967295)’ is >= than the precision of the
left operand [-fpermissive]
/usr/lib/llvm/7/include/llvm/ADT/PointerIntPair.h: In