[Bug target/54429] [SH] SImode values get ferried through FPUL and FP regs for -O0

[egallager at gcc dot gnu.org]

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

--- Comment #9 from Eric Gallager  ---
(In reply to Oleg Endo from comment #8)
> BTW, the problem is also there when using LRA.

Is this still the case?

[Bug jit/64201] JIT tutorial does not describe accessing symbols from other DSOs

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-10-06
 Ever confirmed|0   |1

--- Comment #1 from Eric Gallager  ---
I'll take your word for it and confirm and assign

[Bug rtl-optimization/63156] web can't handle AUTOINC correctly

[egallager at gcc dot gnu.org]

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

--- Comment #11 from Eric Gallager  ---
(In reply to Steven Bosscher from comment #7)
> (In reply to Carrot from comment #6)
> > Since it is intentionally to remove flag DF_REF_READ_WRITE on use,
> 
> Ah, but I don't think that was the correct fix. The DEF and USE refs should
> both have the flag set.

Are you still working on this?

[Bug preprocessor/44317] ,##__VA_ARGS__ comma not eaten with -std=c++0x

[egallager at gcc dot gnu.org]

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

--- Comment #8 from Eric Gallager  ---
(In reply to Eric Gallager from comment #7)
> (In reply to emsr from comment #6)
> > Created attachment 33119 [details]
> > Patch to pedwarn.
> > 
> > This doesn't have the right column pointed out.
> > Also, the message (and that given by clang) is, in my opinion, obscure.
> > At least this starts the ball rolling.
> 
> Please submit the patch to the gcc-patches mailing list for review

...if you're still working on this, that is.
(unassigning next time around if there's no reply)

[Bug c++/60917] sub-optimal diagnostic when instantiating template

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||dmalcolm at gcc dot gnu.org,
   ||dodji at gcc dot gnu.org

--- Comment #2 from Eric Gallager  ---
cc-ing diagnostics maintainers

[Bug rtl-optimization/86939] IRA incorrectly creates an interference between a pseudo register and a hard register

[bergner at gcc dot gnu.org]

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

Peter Bergner  changed:

   What|Removed |Added

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

--- Comment #4 from Peter Bergner  ---
Both patches have been committed, so fixed.

[Bug rtl-optimization/87479] [9 Regression] FAIL: gcc.target/i386/pr63527.c

[bergner at gcc dot gnu.org]

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

Peter Bergner  changed:

   What|Removed |Added

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

--- Comment #4 from Peter Bergner  ---
Fixed.

[Bug rtl-optimization/87479] [9 Regression] FAIL: gcc.target/i386/pr63527.c

[bergner at gcc dot gnu.org]

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

--- Comment #3 from Peter Bergner  ---
Author: bergner
Date: Sat Oct  6 02:12:30 2018
New Revision: 264897

URL: https://gcc.gnu.org/viewcvs?rev=264897=gcc=rev
Log:
gcc/
PR rtl-optimization/86939
PR rtl-optimization/87479
* ira.h (non_conflicting_reg_copy_p): New prototype.
* ira-lives.c (ignore_reg_for_conflicts): New static variable.
(make_hard_regno_dead): Don't add conflicts for register
ignore_reg_for_conflicts.
(make_object_dead): Likewise.
(non_conflicting_reg_copy_p): New function.
(process_bb_node_lives): Set ignore_reg_for_conflicts for copies.
Remove special conflict handling of REAL_PIC_OFFSET_TABLE_REGNUM.
* lra-lives.c (ignore_reg_for_conflicts): New static variable.
(make_hard_regno_dead): Don't add conflicts for register
ignore_reg_for_conflicts.  Remove special conflict handling of
REAL_PIC_OFFSET_TABLE_REGNUM.  Remove now unused argument
check_pic_pseudo_p and update callers.
(mark_pseudo_dead): Don't add conflicts for register
ignore_reg_for_conflicts.
(process_bb_lives): Set ignore_reg_for_conflicts for copies.

gcc/testsuite/
PR rtl-optimization/86939
PR rtl-optimization/87479
* gcc.target/powerpc/pr86939.c: New test.
* gcc/testsuite/gcc.target/i386/pr49095.c: Fix expected results.

Added:
trunk/gcc/testsuite/gcc.target/powerpc/pr86939.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/ira-lives.c
trunk/gcc/ira.h
trunk/gcc/lra-lives.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/i386/pr49095.c

[Bug rtl-optimization/86939] IRA incorrectly creates an interference between a pseudo register and a hard register

[bergner at gcc dot gnu.org]

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

--- Comment #3 from Peter Bergner  ---
Author: bergner
Date: Sat Oct  6 02:12:30 2018
New Revision: 264897

URL: https://gcc.gnu.org/viewcvs?rev=264897=gcc=rev
Log:
gcc/
PR rtl-optimization/86939
PR rtl-optimization/87479
* ira.h (non_conflicting_reg_copy_p): New prototype.
* ira-lives.c (ignore_reg_for_conflicts): New static variable.
(make_hard_regno_dead): Don't add conflicts for register
ignore_reg_for_conflicts.
(make_object_dead): Likewise.
(non_conflicting_reg_copy_p): New function.
(process_bb_node_lives): Set ignore_reg_for_conflicts for copies.
Remove special conflict handling of REAL_PIC_OFFSET_TABLE_REGNUM.
* lra-lives.c (ignore_reg_for_conflicts): New static variable.
(make_hard_regno_dead): Don't add conflicts for register
ignore_reg_for_conflicts.  Remove special conflict handling of
REAL_PIC_OFFSET_TABLE_REGNUM.  Remove now unused argument
check_pic_pseudo_p and update callers.
(mark_pseudo_dead): Don't add conflicts for register
ignore_reg_for_conflicts.
(process_bb_lives): Set ignore_reg_for_conflicts for copies.

gcc/testsuite/
PR rtl-optimization/86939
PR rtl-optimization/87479
* gcc.target/powerpc/pr86939.c: New test.
* gcc/testsuite/gcc.target/i386/pr49095.c: Fix expected results.

Added:
trunk/gcc/testsuite/gcc.target/powerpc/pr86939.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/ira-lives.c
trunk/gcc/ira.h
trunk/gcc/lra-lives.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/i386/pr49095.c

[Bug libstdc++/54005] Use __atomic_always_lock_free in libstdc++ is_lock_free instead of __atomic_is_lock_free

[hp at gcc dot gnu.org]

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

--- Comment #27 from Hans-Peter Nilsson  ---
(In reply to Jonathan Wakely from comment #24)
> (In reply to Hans-Peter Nilsson from comment #22)
> > Or do I misread that?  Are __alignof(x) and the result of alignas(x)
> > in the declaration guaranteed to always be the same here?
> 
> Yes.

For the combination of alignof and alignas in *this* code it's not
obvious to me.  I can imagine that (for example) the alignment of a
container can affect the __alignof(x) such that it's (for example)
higher than the specifically alignas declaration of x, likely by bug,
less likely by intent.  IOW, to me, this isn't the alignas(type) ===
alignas(alignof(type)) in
.

Either way, whether the guarantee is by C++ standard wording or by gcc
internals documentation carries not more value than the documentation
for __atomic_is_lock_free when it comes to maintainer reading, heh...

So, what I'd like to see is either:

- This change in atomic_base.h, avoiding use of the specific object in
is_lock_free and changing to __atomic_always_lock_free:

Index: atomic_base.h
===
--- atomic_base.h   (revision 264855)
+++ atomic_base.h   (working copy)
@@ -355,7 +355,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   {
// Use a fake, minimally aligned pointer.
return __atomic_is_lock_free(sizeof(_M_i),
-   reinterpret_cast(-__alignof(_M_i)));
+   reinterpret_cast(-_S_alignment));
   }

   bool
@@ -363,7 +363,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   {
// Use a fake, minimally aligned pointer.
return __atomic_always_lock_free(sizeof(_M_i),
-   reinterpret_cast(-__alignof(_M_i)));
+   reinterpret_cast(-_S_alignment));
   }

   _GLIBCXX_ALWAYS_INLINE void

(Note the change to __atomic_always_lock_free.  BTW, why use __alignof and not
alignof?  No underscores in the _S_alignment expression!)

-or-

- at least a test in the C++ test-suite with at least a construct of
the exact same form as the one in atomic_base.h but with an overaligned
container and an assert that the alignof the inner object equals the
alignas expression, as you asserted above.  I know that'd cover only
the first case of alignment-bleed that comes to mind, but it'd
indicate an intent to future hackers.

- optionally: wording in the gcc documentation to the effect of the
__alignof === alignas guarantee.  (Still, a test-case is more reliable
than gcc documentation.)  But, there's probably sufficient wording in the
standard.

Maybe some of that is already in place; if it isn't, I'll produce
patches (and CC you, hoping for speedier review).

Do we have common ground here?

[Bug libstdc++/54005] Use __atomic_always_lock_free in libstdc++ is_lock_free instead of __atomic_is_lock_free

[hp at gcc dot gnu.org]

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

--- Comment #26 from Hans-Peter Nilsson  ---
(In reply to Jonathan Wakely from comment #25)
> (In reply to Hans-Peter Nilsson from comment #23)
> > ...and also, a call might be generated as the result of using
> > __atomic_is_lock_free (instead of __atomic_always_lock_free), so the target
> > may change its mind.  Not good.
> 
> That should have been fixed by r227878 for Bug 65913 so that for these cases
> no call is generated.

I went by the documentation, which says at r264855 for __atomic_is_lock_free
that "If the built-in function is not known to be lock-free, a call is made to
a runtime routine named @code{__atomic_is_lock_free}."  It certainly seems to
be that way too (builtins.c):

static tree
fold_builtin_atomic_is_lock_free (tree arg0, tree arg1)
{
  if (!flag_inline_atomics)
return NULL_TREE;

  /* If it isn't always lock free, don't generate a result.  */
  if (fold_builtin_atomic_always_lock_free (arg0, arg1) == boolean_true_node)
return boolean_true_node;

  return NULL_TREE;
}

ISTM that this will not "inline" a return of "false".

[Bug debug/87472] Unknown macro opcode with -gsplit-dwarf -g3

[mark at gcc dot gnu.org]

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

--- Comment #3 from Mark Wielaard  ---
(In reply to Mark Wielaard from comment #2)
> (In reply to Richard Biener from comment #1)
> > Confirmed with GCC 8 and just -g3 -gsplit-dwarf.  readelf isn't very verbose
> > of which macro section it complains about though...
> > 
> > Mark?
> 
> With -gsplit-dwarf the .debug_macro section (actually the .debug_macro.dwo
> section) goes into the .dwo file. readelf is complaining about the second
> and third such section. But there really should only be one debug_macro
> section. Need to figure out why.

It is by design, see output_macinfo ():

  /* If any DW_MACRO_import were used, on those DW_MACRO_import entries 
 terminate the current chain and switch to a new comdat .debug_macinfo  
 section and emit the define/undef entries within it.  */   

Which makes sense for normal .o files because the linker will resolve the
references and comdat sections. But not for .dwo files.

It isn't clear to me how DW_MACRO_import would work for split-dwarf. It looks
like there is no clear mechanism for it that would work. Which seems to mean
that for split-dwarf we should not use it. Which would be somewhat painful
since then we cannot easily deduplicate macro definitions anymore. It would
have to be done by some post-processor (dwp or dwz?) that finds duplicates and
(re)creates the .debug_macro section.

[Bug middle-end/87535] multiple attribute assume_aligned interpreted inconsistently

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   See Also|https://gcc.gnu.org/bugzill |https://gcc.gnu.org/bugzill
   |a/show_bug.cgi?id=81871 |a/show_bug.cgi?id=87533

--- Comment #2 from Martin Sebor  ---
(In reply to Martin Sebor from comment #1)

That should have been pr87533.

[Bug middle-end/87535] multiple attribute assume_aligned interpreted inconsistently

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=81871

--- Comment #1 from Martin Sebor  ---
See also pr81871 for other problems with the handling of the assume_aligned
attribute.

[Bug middle-end/87533] bogus assume_aligned attribute silently accepted

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||patch

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

[Bug debug/87472] Unknown macro opcode with -gsplit-dwarf -g3

[mark at gcc dot gnu.org]

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

--- Comment #2 from Mark Wielaard  ---
(In reply to Richard Biener from comment #1)
> Confirmed with GCC 8 and just -g3 -gsplit-dwarf.  readelf isn't very verbose
> of which macro section it complains about though...
> 
> Mark?

With -gsplit-dwarf the .debug_macro section (actually the .debug_macro.dwo
section) goes into the .dwo file. readelf is complaining about the second and
third such section. But there really should only be one debug_macro section.
Need to figure out why.

[Bug c/81851] missing -Wduplicated-branches on if and return statements with no else

[msebor at gcc dot gnu.org]

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

--- Comment #6 from Martin Sebor  ---
(In reply to Jonathan Wakely from comment #5)

I would think warning in this case should be fine, just as it is on the below
when NDEBUG is defined:

int f (int i)
{
  if (i == 0)   // -Wduplicated-branches (good)
return 0;
  else {
#ifndef NDEBUG
  assert (i > 0);
#endif
return 0;
  }
}

[Bug libstdc++/87538] New: Incorrect noexcept specifier for not_fn

[barry.revzin at gmail dot com]

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

Bug ID: 87538
   Summary: Incorrect noexcept specifier for not_fn
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: barry.revzin at gmail dot com
  Target Milestone: ---

Found by Edgar Rokjān (https://stackoverflow.com/q/52673235/2069064). The
noexcept specifier for _Not_fn currently only checks the noexcept-ness of
applying the ! operator on the return type, not of the actual call:

noexcept(noexcept(_S_not<__inv_res_t<_Fn _QUALS, _Args...>>()))

As a result, this fails:

#include 

struct X { 
int operator()(int);
};

static_assert(!noexcept(
std::not_fn(X{})(2)));

While not_fn isn't actually specified to have any kind of noexcept-specifier,
this one seems actively wrong - either it should propagate through the type's
actual call function (so the above assert shouldn't trigger) or it should never
be noexcept (likewise).

[Bug c/81871] bogus attribute alloc_align accepted

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #3 from Martin Sebor  ---
Let me fix this.

[Bug c/81871] bogus attribute alloc_align accepted

[msebor at gcc dot gnu.org]

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

--- Comment #2 from Martin Sebor  ---
Clang prints:

  a.c:1:22: warning: 'alloc_align' attribute only applies to return values that
are pointers or references [-Wignored-attributes]

After changing the return type to void*, Clang then prints:

  a.c:1:30: error: 'alloc_align' attribute argument may only refer to a
function parameter of integer type

GCC accepts both without a warning.  In fact, GCC accepts alloc_align even on
function declarations where the argument is not an integer, such as in:

  struct S { };
  __attribute__ ((alloc_align (1))) void* f (struct S);

Clang detects this as well:

  a.c:2:30: error: 'alloc_align' attribute argument may only refer to a
function parameter of integer type

[Bug target/87532] bad results from vec_extract(unsigned char, foo) dependent upon function inline

[willschm at gcc dot gnu.org]

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

--- Comment #1 from Will Schmidt  ---
Created attachment 44797
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44797=edit
simpler testcase variation

Simplified the testcase a bit.
comment/uncomment the noinline attribute on the get_auto_n() function to toggle 
pass/fail.
Fails with -O2.
on Power8.  (probably also power9).

[Bug target/87537] New: Redundant vmovaps

[hjl.tools at gmail dot com]

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

Bug ID: 87537
   Summary: Redundant vmovaps
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
  Target Milestone: ---
Target: i386,x86-64

[hjl@gnu-skx-1 gcc]$ cat
/export/gnu/import/git/sources/gcc/gcc/testsuite/gcc.target/i386/avx2-vbroadcastss_ps256-1.c
/* { dg-do compile } */
/* { dg-options "-mavx2 -O2" } */
/* { dg-final { scan-assembler "vbroadcastss\[ \\t\]+\[^\n\]*%xmm\[0-9\]" } }
*/

#include 

__m128 x;
__m256 y;

void extern
avx2_test (void)
{
  y = _mm256_broadcastss_ps (x);
}
[hjl@gnu-skx-1 gcc]$ ./xgcc -B./ -S
/export/gnu/import/git/sources/gcc/gcc/testsuite/gcc.target/i386/avx2-vbroadcastss_ps256-1.c
-mavx2 -O2
cat[hjl@gnu-skx-1 gcc]$ cat avx2-vbroadcastss_ps256-1.s 
.file   "avx2-vbroadcastss_ps256-1.c"
.text
.p2align 4
.globl  avx2_test
.type   avx2_test, @function
avx2_test:
.LFB5178:
.cfi_startproc
vmovaps x(%rip), %xmm1
vbroadcastss%xmm1, %ymm0
vmovaps %ymm0, y(%rip)
vzeroupper
ret
.cfi_endproc
.LFE5178:
.size   avx2_test, .-avx2_test
.comm   y,32,32
.comm   x,16,16
.ident  "GCC: (GNU) 9.0.0 20180901 (experimental)"
.section.note.GNU-stack,"",@progbits
[hjl@gnu-skx-1 gcc]$ 

We should generate

[hjl@gnu-cfl-1 gcc]$ cat avx2-vbroadcastss_ps256-1.s
.file   "avx2-vbroadcastss_ps256-1.c"
.text
.p2align 4
.globl  avx2_test
.type   avx2_test, @function
avx2_test:
.LFB5178:
.cfi_startproc
vbroadcastssx(%rip), %ymm0
vmovaps %ymm0, y(%rip)
vzeroupper
ret
.cfi_endproc
.LFE5178:
.size   avx2_test, .-avx2_test
.comm   y,32,32
    .comm   x,16,16
.ident  "GCC: (GNU) 9.0.0 20181005 (experimental)"
.section.note.GNU-stack,"",@progbits
[hjl@gnu-cfl-1 gcc]$

[Bug c++/87536] New: Illegal recursive concept leads to compiler ICE

[blelbach at cct dot lsu.edu]

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

Bug ID: 87536
   Summary: Illegal recursive concept leads to compiler ICE
   Product: gcc
   Version: c++-concepts
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: blelbach at cct dot lsu.edu
  Target Milestone: ---

GCC concepts seem to allow the use of the name of a concept in the definition
of the concept itself. This appears to allow me to trick GCC into infinitely
recursing and blowing up with an ICE:

https://godbolt.org/z/p8Yuo0

A repro is as follows:

template 
bool concept X = X;

template  struct A{};
A a;

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

[dmalcolm at gcc dot gnu.org]

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

Bug 56856 Summary: -Wformat warnings don't show location *within* format string 
in C++ FE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56856

   What|Removed |Added

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

[Bug c++/56856] -Wformat warnings don't show location *within* format string in C++ FE

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #12 from David Malcolm  ---
Should be fixed for gcc 9 by r264887.

[Bug c++/56856] -Wformat warnings don't show location *within* format string in C++ FE

[dmalcolm at gcc dot gnu.org]

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

--- Comment #11 from David Malcolm  ---
Author: dmalcolm
Date: Fri Oct  5 19:02:17 2018
New Revision: 264887

URL: https://gcc.gnu.org/viewcvs?rev=264887=gcc=rev
Log:
Support string locations for C++ in -Wformat (PR c++/56856)

-Wformat in the C++ FE doesn't work as well as it could:
(a) it doesn't report precise locations within the string literal, and
(b) it doesn't underline arguments for those arguments !CAN_HAVE_LOCATION_P,
despite having location wrapper nodes.

For example:

  Wformat-ranges.C:32:10: warning: format '%s' expects argument of type
'char*', but argument 2 has type 'int' [-Wformat=]
  32 |   printf("hello %s", 42);
 |  ^~

(a) is due to not wiring up the langhook for extracting substring
locations.

This patch uses the one in c-family; it also fixes string literal
parsing so that it records string concatenations (needed for
extracting substring locations from concatenated strings).

(b) is due to the call to maybe_constant_value here:
   fargs[j] = maybe_constant_value (argarray[j]);
within build_over_call.

The patch fixes this by building a vec of location_t values when
calling check_function_arguments.
I attempted to eliminate the maybe_constant_value call here, but
it's needed by e.g. check_function_sentinel for detecting NULL,
and that code is in "c-family", so it can't simply call into
maybe_constant_value (which is in "cp").

With this patch, the output for the above example is improved to:

  Wformat-ranges.C:32:18: warning: format '%s' expects argument of type
'char*', but argument 2 has type 'int' [-Wformat=]
  32 |   printf("hello %s", 42);
 | ~^   ~~
 |  |   |
 |  |   int
 |  char*
 | %d

gcc/cp/ChangeLog:
PR c++/56856
* call.c (build_over_call): Build a vec of locations of the
arguments before the call to maybe_constant_value, and pass to
check_function_arguments.
* cp-lang.c (LANG_HOOKS_GET_SUBSTRING_LOCATION): Define as
c_get_substring_location.
* parser.c (cp_parser_string_literal): Capture string
concatenation locations.

gcc/ChangeLog:
PR c++/56856
* input.c (expand_location_to_spelling_point): Add param "aspect"
and use rather than hardcoding LOCATION_ASPECT_CARET.
(get_substring_ranges_for_loc): Handle the case of a single token
within a macro expansion.
* input.h (expand_location_to_spelling_point): Add "aspect" param,
defaulting to LOCATION_ASPECT_CARET.

gcc/testsuite/ChangeLog:
PR c++/56856
* g++.dg/ext/builtin4.C: Set expected location for warning to the
correct location within the format string.
* g++.dg/plugin/plugin.exp (plugin_test_list): Add the plugin and
files for testing locations within string literal locations from
the C frontend.
* g++.dg/warn/Wformat-method.C: New test.
* g++.dg/warn/Wformat-pr71863.C: New test.
* g++.dg/warn/Wformat-ranges-c++11.C: New test.
* g++.dg/warn/Wformat-ranges.C: New test, based on
gcc.dg/format/diagnostic-ranges.c.
* gcc.dg/plugin/diagnostic-test-string-literals-1.c
(test_multitoken_macro): Generalize expected output to work with
both C and C++.
* gcc.dg/plugin/diagnostic-test-string-literals-2.c
(test_stringified_token_1): Likewise.
(test_stringified_token_3): Likewise.


Added:
trunk/gcc/testsuite/g++.dg/warn/Wformat-method.C
trunk/gcc/testsuite/g++.dg/warn/Wformat-pr71863.C
trunk/gcc/testsuite/g++.dg/warn/Wformat-ranges-c++11.C
trunk/gcc/testsuite/g++.dg/warn/Wformat-ranges.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/call.c
trunk/gcc/cp/cp-lang.c
trunk/gcc/cp/parser.c
trunk/gcc/input.c
trunk/gcc/input.h
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/ext/builtin4.C
trunk/gcc/testsuite/g++.dg/plugin/plugin.exp
trunk/gcc/testsuite/gcc.dg/format/diagnostic-ranges.c
trunk/gcc/testsuite/gcc.dg/plugin/diagnostic-test-string-literals-1.c
trunk/gcc/testsuite/gcc.dg/plugin/diagnostic-test-string-literals-2.c

[Bug gcov-profile/77698] Unrolled loop not considered hot after profiling

[pthaugen at gcc dot gnu.org]

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

Pat Haugen  changed:

   What|Removed |Added

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

--- Comment #5 from Pat Haugen  ---
It's still not fixed in current trunk. After unrolling maybe_hot_bb_p() returns
false (via maybe_hot_count_p()), which prevents aligning the label in
final.c:compute_alignments(). Here's the tail section of debug session and
partial backtrace to show.

maybe_hot_count_p (fun=0x759f, count=...) at
/home/pthaugen/src/gcc/trunk_work/gcc/gcc/predict.c:185
185   return (count.to_gcov_type () >= get_hot_bb_threshold ());
(gdb) p count.to_gcov_type ()
$3 = 25
(gdb) p get_hot_bb_threshold ()
$4 = 100
(gdb) bt
#0  maybe_hot_count_p (fun=0x759f, count=...) at
/home/pthaugen/src/gcc/trunk_work/gcc/gcc/predict.c:185
#1  0x10d8fdb0 in maybe_hot_bb_p (fun=0x759f,
bb=0x759801a0)
at /home/pthaugen/src/gcc/trunk_work/gcc/gcc/predict.c:195
#2  0x10d9045c in optimize_bb_for_size_p (bb=0x759801a0)
at /home/pthaugen/src/gcc/trunk_work/gcc/gcc/predict.c:301
#3  0x108c7234 in compute_alignments () at
/home/pthaugen/src/gcc/trunk_work/gcc/gcc/final.c:674
#4  0x108c7d3c in (anonymous
namespace)::pass_compute_alignments::execute (this=0x12886200)
at /home/pthaugen/src/gcc/trunk_work/gcc/gcc/final.c:823

[Bug target/87534] Typo in sgxintrin.h

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #1 from H.J. Lu  ---
It turns out that the assembler support is missing.

[Bug libbacktrace/87529] libbacktrace API forces users to have memory leaks

[ian at airs dot com]

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

Ian Lance Taylor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from Ian Lance Taylor  ---
Thanks, closing this PR.

[Bug middle-end/87535] New: multiple attribute assume_aligned interpreted inconsistently

[msebor at gcc dot gnu.org]

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

Bug ID: 87535
   Summary: multiple attribute assume_aligned interpreted
inconsistently
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

The example below shows that attribute assume_aligned is interpreted
inconsistently between apparently equivalent declarations of the same function.
 When two such attributes are specified on the same declaration the one
specified last wins.  When the same pair are specified on distinct declarations
of the same function, the first one wins.

Clang treats both forms consistently, but honors the attribute that was
specified last.  I think it's debatable whether that's preferable to honoring
the most restrictive one as specified for _Alignas by C11.  I'm leaning toward
going with the C11 approach to minimize surprises due to an inconsistency.

$ cat c.c && gcc -O2 -S -Wall -fdump-tree-optimized=/dev/stdout c.c
__attribute ((assume_aligned (8), // ignored
  assume_aligned (32)))   // overrdides prior attribute
char* f (void);

void f1 (void)
{
  char *p = f ();
  if ((__INTPTR_TYPE__)p & 31)   // folded to false
__builtin_abort ();
}

__attribute ((assume_aligned (8)))   // overrides subsequent attribute
void* g (void);

__attribute ((assume_aligned (32)))   // attribute ignored
void* g (void);

void g1 (void)
{
  void *p = g ();
  if ((__INTPTR_TYPE__)p & 31)   // not folded
__builtin_abort ();
}


;; Function f1 (f1, funcdef_no=0, decl_uid=1908, cgraph_uid=1, symbol_order=0)

f1 ()
{
   [local count: 1073741824]:
  f (); [tail call]
  return;

}



;; Function g1 (g1, funcdef_no=1, decl_uid=1916, cgraph_uid=2, symbol_order=1)

g1 ()
{
  void * p;
  long int p.1_1;
  long int _2;

   [local count: 1073741824]:
  p_5 = g ();
  p.1_1 = (long int) p_5;
  _2 = p.1_1 & 31;
  if (_2 != 0)
goto ; [0.00%]
  else
goto ; [99.96%]

   [count: 0]:
  __builtin_abort ();

   [local count: 1073312328]:
  return;

}

[Bug fortran/82995] Segmentation fault passing optional argument to intrinsic sum function

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 Status|ASSIGNED|NEW

--- Comment #10 from Thomas Koenig  ---
Hm, seeems like the scalarizer has some things that I really, really do not
understand... unassigning, I'll come back to it, hopefully.

[Bug libbacktrace/87529] libbacktrace API forces users to have memory leaks

[antoshkka at gmail dot com]

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

--- Comment #3 from Antony Polukhin  ---
Comment is enough to make me happy. Thanks!

[Bug target/87534] New: Typo in sgxintrin.h

[hjl.tools at gmail dot com]

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

Bug ID: 87534
   Summary: Typo in sgxintrin.h
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: ubizjak at gmail dot com
  Target Milestone: ---
Target: i386,x86-64

#define __enclv_bc(leaf, b, c, retval)  \
  __asm__ __volatile__("enclv\n\t"  \
   : "=a" (retval)  \
   : "a" (leaf), "b" (b), "c" (c)   \
   : "cc")

#define __enclv_cd(leaf, c, d, retval)  \
  __asm__ __volatile__("enclv\n\t"  \
   : "=a" (retval)  \
   : "a" (leaf), "c" (c), "d" (d)   \
   : "cc")

#define __enclv_generic(leaf, b, c, d, retval)  \
  __asm__ __volatile__("enclv\n\t"  \
   : "=a" (retval), "=b" (b), "=c" (b), "=d" (d)\
   : "a" (leaf), "b" (b), "c" (c), "d" (d)  \
   : "cc")

But SGX spec has

ENCLS—Execute an Enclave System Function of Specified Leaf Number
ENCLU—Execute an Enclave User Function of Specified Leaf Number

There is no ENCLV instruction.

[Bug target/87391] [RISCV] -march=rv32i -mabi=ilp32e is erroneously accepted

[wilson at gcc dot gnu.org]

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

Jim Wilson  changed:

   What|Removed |Added

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

--- Comment #6 from Jim Wilson  ---
GCC patch applied, riscv-elf-psABI-doc updated, and riscv-c-api-doc updated.

[Bug middle-end/87528] Popcount changes caused 531.deepsjeng_r run-time regression on Skylake

[amonakov at gcc dot gnu.org]

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

Alexander Monakov  changed:

   What|Removed |Added

 CC||amonakov at gcc dot gnu.org

--- Comment #2 from Alexander Monakov  ---
x86 has native popcount only with -msse4.2, otherwise popcount(int) first
zero-extends to 64-bit, then calls __popcountdi2 (64-bit libgcc popcount).

If the original code computes popcount on narrow types, or has only a few
non-zero bits, it can be expected that libgcc replacement is slower.

Even if size-wise popcount detection is an optimization, speed-wise GCC
probably should avoid replacing a simple loop with a libgcc call (just like
final value replacement avoids replacing a loop with computations involving
modulus/division).

[Bug middle-end/87533] bogus assume_aligned attribute silently accepted

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Sebor  ---
Let me handle this.

[Bug middle-end/87533] New: bogus assume_aligned attribute silently accepted

[msebor at gcc dot gnu.org]

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

Bug ID: 87533
   Summary: bogus assume_aligned attribute silently accepted
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

The manual describes the assume_aligned attribute as follows:

  The assume_aligned attribute is used to tell the compiler that the function
return value points to memory, where the returned pointer minimum alignment is
given by the first argument. If the attribute has two arguments, the second
argument is misalignment offset. 

Clearly, the first argument must be a power of two, and second argument should
presumably be greater than (or perhaps equal to) zero and less than the value
of the first argument.  Finally, the attribute only makes sense on functions
that return a pointer.  Yet GCC silently accepts the following non-sensical
declaration:

$ cat c.c && gcc -S -Wall c.c

__attribute ((assume_aligned (-1, -2))) void f (void) { }

Clang, on the other hand, issues:

c.c:1:15: warning: 'assume_aligned' attribute only applies to return values
that are pointers or references [-Wignored-attributes]

__attribute ((assume_aligned (-1, -2))) void f (void) { }

  ^~~   

After the return type is changed to void*, Clang then issues the following:

c.c:1:15: error: requested alignment is not a power of 2

[Bug c/87532] New: bad results from vec_extract(unsigned char, foo) dependent upon function inline

[willschm at gcc dot gnu.org]

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

Bug ID: 87532
   Summary: bad results from vec_extract(unsigned char, foo)
dependent upon function inline
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: willschm at gcc dot gnu.org
  Target Milestone: ---

Created attachment 44796
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44796=edit
patch to add powerpc testcase vec-extract-v16qiu-v2a.c  and -v2b.c

Debugging an issue with an existing testcase that exercises
vec_extract(unsigned char, #); and have run into this.  Using gcc trunk built
Oct 1, but believe this is not a new issue.

Results from a call into get_auto_n(a,i) are correct/incorrect depending on
whether the function being called is marked as __noinline__ .  

Attaching a stripped down and slightly modified version of an existing
vec-extract-v16qiu testcase.   Per the output below, the 'get_auto_n return
values are not consistent.


> cat gcc/testsuite/gcc/gcc.log  | egrep "^get_|PASS"
PASS: gcc.target/powerpc/vec-extract-v16qiu-v2a.c (test for excess errors)
get_auto_n return: -202182160
PASS: gcc.target/powerpc/vec-extract-v16qiu-v2a.c execution test
PASS: gcc.target/powerpc/vec-extract-v16qiu-v2b.c (test for excess errors)
get_auto_n return:  4
PASS: gcc.target/powerpc/vec-extract-v16qiu-v2b.c execution test

[Bug tree-optimization/87490] [9 Regression] ICE in expand_builtin_strnlen at gcc/builtins.c:3164

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #6 from Martin Sebor  ---
Fixed in r264876.

[Bug tree-optimization/87490] [9 Regression] ICE in expand_builtin_strnlen at gcc/builtins.c:3164

[msebor at gcc dot gnu.org]

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

--- Comment #5 from Martin Sebor  ---
Author: msebor
Date: Fri Oct  5 16:43:11 2018
New Revision: 264876

URL: https://gcc.gnu.org/viewcvs?rev=264876=gcc=rev
Log:
PR tree-optimization/87490 - ICE in expand_builtin_strnlen with a constant
argument and non-constant bound

gcc/ChangeLog:

PR tree-optimization/87490
* builtins.c (expand_builtin_strnlen): Handle a null data.decl
consistently.

gcc/testsuite/ChangeLog:

PR tree-optimization/87490
* gcc.dg/pr87490.c: New test.
* gcc.dg/warn-strnlen-no-nul-2.c: Same.

Added:
trunk/gcc/testsuite/gcc.dg/pr87490.c
trunk/gcc/testsuite/gcc.dg/warn-strnlen-no-nul-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/builtins.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/38573] Missing markers for translation

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

 Status|ASSIGNED|NEW

[Bug fortran/52387] I/O output of write after nonadvancing read

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

 Status|ASSIGNED|NEW

[Bug fortran/61632] Improve error locus on large format strings

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

 Status|ASSIGNED|NEW

[Bug fortran/66499] Letters with accents change format behavior for X and T descriptors.

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

 Status|ASSIGNED|NEW

[Bug fortran/78351] comma not terminating READ of formatted input field - ok in 4.1.7, not 4.4.7- maybe related to 25419?

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

 Status|ASSIGNED|NEW

[Bug fortran/80009] Printing/writing a structure with a real edit descriptor.

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

 Status|ASSIGNED|NEW

[Bug fortran/81499] internal compiler error when compiling gfortran code with user-defined derived type i/o

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

 Status|ASSIGNED|NEW

[Bug fortran/82086] namelist read with repeat count fails when item is member of array of structures

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

 Status|ASSIGNED|NEW

[Bug fortran/83522] ICE on invalid allocatable string reference, string(:)(:)

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

 Status|ASSIGNED|NEW

[Bug fortran/83829] Implement runtime checks for DT format specifier and allignment with effective items

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

 Status|ASSIGNED|NEW

[Bug fortran/84143] Intrinsic output of PDT incorrectly includes type parameters

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

 Status|ASSIGNED|NEW
 CC||jvdelisle at gcc dot gnu.org

[Bug c++/87531] New: [8/9 Regression] assignment operator does nothing if performed as a call via operator=

[nok.raven at gmail dot com]

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

Bug ID: 87531
   Summary: [8/9 Regression] assignment operator does nothing if
performed as a call via operator=
   Product: gcc
   Version: 8.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nok.raven at gmail dot com
  Target Milestone: ---

The regression appeared after 7.3.0 and not later than 8.1.0. I do not have
8.0.0 to test it.

https://godbolt.org/z/jjoZ6t

// main.cpp
struct dummy {};

template 
struct foo : dummy
{
foo() : v() {}
foo(T v_) : v(v_) {}
void assign(foo const& rhs)
{
this->operator=(rhs); // the assignment does nothing
//(*this).operator=(rhs); // this one does nothing too
//*this = rhs;// this one works as expected
}

T v;
};

template 
struct bar : foo
{
typedef foo base;
bar() : base() {}
bar(T v) : base(v) {}
bar& operator=(bar const& rhs)
{
this->assign( static_cast(rhs) ) ;
return *this ;
}
};

int main()
{
bar a, b(123);
a.assign(b);
if (a.v != 123) throw "problem!";
}

[Bug tree-optimization/71625] missing strlen optimization on different array initialization style

[sje at gcc dot gnu.org]

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

--- Comment #24 from Steve Ellcey  ---
Author: sje
Date: Fri Oct  5 15:26:40 2018
New Revision: 264874

URL: https://gcc.gnu.org/viewcvs?rev=264874=gcc=rev
Log:
2018-10-05  Steve Ellcey  

PR tree-optimization/71625
* /gcc.target/aarch64/vclz.c (test_vclz_s8): Add noinline attribute.
(test_vclz_s16): Ditto.
(test_vclz_s32): Ditto.
(test_vclzq_s8): Ditto.
(test_vclzq_s16): Ditto.
(test_vclzq_s32): Ditto.
(test_vclz_u8): Ditto.
(test_vclz_u16): Ditto.
(test_vclz_u32): Ditto.
(test_vclzq_u8): Ditto.
(test_vclzq_u16): Ditto.
(test_vclzq_u32): Ditto.
* gcc.target/aarch64/vneg_s.c (test_vneg_s8): Ditto.
(test_vneg_s16): Ditto.
(test_vneg_s32): Ditto.
(test_vneg_s64): Ditto.
(test_vnegd_s64): Ditto.
(test_vnegq_s8): Ditto.
(test_vnegq_s16): Ditto.
(test_vnegq_s32): Ditto.
(test_vnegq_s64): Ditto.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/aarch64/vclz.c
trunk/gcc/testsuite/gcc.target/aarch64/vneg_s.c

[Bug middle-end/71296] missing warning on strcat appending to a non-string

[msebor at gcc dot gnu.org]

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

Bug 71625 Summary: missing strlen optimization on different array 
initialization style
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71625

   What|Removed |Added

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

[Bug tree-optimization/71625] missing strlen optimization on different array initialization style

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #23 from Martin Sebor  ---
The optimization was implemented in r263511 and the fallout has been resolved.

[Bug debug/84342] Location views breaks cross builds of arm including gnueabihf

[tnfchris at gcc dot gnu.org]

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

Tamar Christina  changed:

   What|Removed |Added

   Priority|P1  |P2
   Severity|critical|major

--- Comment #15 from Tamar Christina  ---
Bringing down the priority as it's not a release blocker anymore.

[Bug libbacktrace/87529] libbacktrace API forces users to have memory leaks

[ian at gcc dot gnu.org]

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

--- Comment #2 from ian at gcc dot gnu.org  ---
Author: ian
Date: Fri Oct  5 14:09:07 2018
New Revision: 264871

URL: https://gcc.gnu.org/viewcvs?rev=264871=gcc=rev
Log:
PR libbacktrace/87529
* backtrace.h: Document that backtrace_create_state should be
called only once.

Modified:
trunk/libbacktrace/ChangeLog
trunk/libbacktrace/backtrace.h

[Bug libbacktrace/87529] libbacktrace API forces users to have memory leaks

[ian at airs dot com]

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

Ian Lance Taylor  changed:

   What|Removed |Added

 CC||ian at airs dot com

--- Comment #1 from Ian Lance Taylor  ---
Programs are expected to call backtrace_create_state once.  There's no reason
to call it more than once.

Yes, I agree that it would be nice to have backtrace_free_state, but it's hard
to write correctly.  And it's hard to see why any program would want to call
it, as it would be less efficient.

[Bug c++/87530] New: copy elision in return statement doesn't check for rvalue reference to object type

[barry.revzin at gmail dot com]

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

Bug ID: 87530
   Summary: copy elision in return statement doesn't check for
rvalue reference to object type
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: barry.revzin at gmail dot com
  Target Milestone: ---

Example from StackOverflow (https://stackoverflow.com/q/52662407/2069064):

struct Base { };

template
struct A : Base
{
A();
A(Base&&);
};

A foo()
{
A v;
return v;
}

gcc accepts this code, invoking the A(Base&&) constructor in the return
statement. But the requirement in [class.copy.elision]/3 requires the first
type in the selected constructor to be an rvalue reference to the object's
type, which it is not.

[Bug middle-end/26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)

[jamborm at gcc dot gnu.org]

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

Martin Jambor  changed:

   What|Removed |Added

 Depends on||87528

--- Comment #3 from Martin Jambor  ---
(I hope this is also for regressions)


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87528
[Bug 87528] Popcount changes caused 531.deepsjeng_r run-time regression on
Skylake

[Bug libbacktrace/87529] New: libbacktrace API forces users to have memory leaks

[antoshkka at gmail dot com]

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

Bug ID: 87529
   Summary: libbacktrace API forces users to have memory leaks
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libbacktrace
  Assignee: unassigned at gcc dot gnu.org
  Reporter: antoshkka at gmail dot com
CC: ian at gcc dot gnu.org
  Target Milestone: ---

Function for creating state `backtrace_create_state` returns a pointer to
`struct backtrace_state`.

There's no function to free the state so the users assume that the pointer
returned from `backtrace_create_state` is a pointer to some static variable
that should not be freed... Which is not true. `struct backtrace_state` is
dynamically allocated.

Multiple usages of `backtrace_create_state` consume all the available memory
and lead to segfaults.

Please add `backtrace_free_state` function that frees the resources allocated
by `backtrace_create_state` and document that state returned by
`backtrace_create_state` should be freed.


Another way to solve the problem is to 
* always return the same state `backtrace_create_state` and override the
`threaded` argument with 1
* free that state on exit

[Bug middle-end/87528] Popcount changes caused 531.deepsjeng_r run-time regression on Skylake

[jamborm at gcc dot gnu.org]

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

Martin Jambor  changed:

   What|Removed |Added

 CC||kugan at gcc dot gnu.org

--- Comment #1 from Martin Jambor  ---
It seems that the machine does not like the newly generated calls into
libgcc for popcount.

The profile of r262486 (_slow variant) and the one immediately
preceding it (the _fast variant) is:

$ perf report -n --percent-limit=2 | cat

# Overhead   Samples  Command  Shared Object  Symbol
#     ...  .  .
#
 6.15%187930  deepsjeng_r_slow  deepsjeng_r   feval
 5.88%179434  deepsjeng_r_fast  deepsjeng_r   feval
 5.56%169734  deepsjeng_r_fast  deepsjeng_r   search
 5.42%165581  deepsjeng_r_slow  deepsjeng_r   search
 5.19%158575  deepsjeng_r_slow  deepsjeng_r   ProbeTT
 5.16%157546  deepsjeng_r_fast  deepsjeng_r   ProbeTT
 4.74%144696  deepsjeng_r_slow  deepsjeng_r   qsearch
 4.72%144193  deepsjeng_r_fast  deepsjeng_r   qsearch
 2.76% 84389  deepsjeng_r_slow  libgcc_s.so   __popcountdi2
 2.75% 83936  deepsjeng_r_fast  deepsjeng_r   see
 2.73% 83307  deepsjeng_r_slow  deepsjeng_r   see
 2.67% 81614  deepsjeng_r_slow  deepsjeng_r   order_moves
 2.62% 80077  deepsjeng_r_fast  deepsjeng_r   order_moves
 2.49% 76087  deepsjeng_r_slow  deepsjeng_r   FindFirstRemove
 2.47% 75346  deepsjeng_r_fast  deepsjeng_r   FindFirstRemove
 2.03% 61888  deepsjeng_r_fast  deepsjeng_r   make
 2.03% 61861  deepsjeng_r_slow  deepsjeng_r   make


The profile for r262864 (marked again as _slow below) and its
immediate predecessor (marked _fast) is:


# Overhead   Samples  Command  Shared Object  Symbol
#     ...  .  .
#
 5.87%192681  deepsjeng_r_slow  deepsjeng_r   feval
 5.74%188254  deepsjeng_r_fast  deepsjeng_r   feval
 5.48%179850  deepsjeng_r_slow  libgcc_s.so   __popcountdi2
 5.17%169671  deepsjeng_r_slow  deepsjeng_r   search
 5.04%165438  deepsjeng_r_fast  deepsjeng_r   search
 4.83%158368  deepsjeng_r_fast  deepsjeng_r   ProbeTT
 4.82%158096  deepsjeng_r_slow  deepsjeng_r   ProbeTT
 4.44%145659  deepsjeng_r_fast  deepsjeng_r   qsearch
 4.39%144117  deepsjeng_r_slow  deepsjeng_r   qsearch
 2.56% 84085  deepsjeng_r_fast  libgcc_s.so   __popcountdi2
 2.55% 83853  deepsjeng_r_slow  deepsjeng_r   see
 2.55% 83653  deepsjeng_r_fast  deepsjeng_r   see
 2.54% 83383  deepsjeng_r_fast  deepsjeng_r   order_moves
 2.44% 80246  deepsjeng_r_slow  deepsjeng_r   order_moves
 2.31% 75966  deepsjeng_r_fast  deepsjeng_r   FindFirstRemove
 2.30% 75575  deepsjeng_r_slow  deepsjeng_r   FindFirstRemove

Again, let me emphasize this is all about generic march/mtune, native
march/mtune is almost 3% faster than GCC 8.

[Bug middle-end/87528] New: Popcount changes caused 531.deepsjeng_r run-time regression on Skylake

[jamborm at gcc dot gnu.org]

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

Bug ID: 87528
   Summary: Popcount changes caused 531.deepsjeng_r run-time
regression on Skylake
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jamborm at gcc dot gnu.org
  Target Milestone: ---

According to my repeated measurements, r262486 and r262864 caused ~14%
regression (roughly 7% and 7% each) in run-time of SPEC 2017
531.deepsjeng_r, with generic tuning (only), both at -O2 and -Ofast,
on an Intel Skylake machine (Intel Xeon Platinum 8164 CPU).

Martin Liška could not reproduce this on his Kabylake machine, so I'd
be very grateful if someone else could attempt to reproduce this.
Having said that, I really can reproduce the regression very reliably.

[Bug target/87509] ICE in extract_insn, at recog.c:2305

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

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

--- Comment #3 from Segher Boessenkool  ---
Fixed.

[Bug middle-end/63155] [6/7/8 Regression] memory hog

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||rsandifo at gcc dot gnu.org

--- Comment #39 from Richard Biener  ---
Oh, and backprop is really intersect_uses () with

  FOR_EACH_IMM_USE_STMT (stmt, iter, var)
{

being quadratic due to its stupid implementation (we really have many uses
of vars).  If the pass can deal with duplicate stmt uses just fine using
FOR_EACH_IMM_USE_FAST is going to be faster.

[Bug middle-end/63155] [6/7/8 Regression] memory hog

[rguenth at gcc dot gnu.org]

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

--- Comment #38 from Richard Biener  ---
For the last testcase the compile-time on trunk is now 25s at -O1:

 tree PTA   :   3.37 ( 13%)   0.10 ( 30%)   3.46 ( 13%)
  12445 kB (  2%)
 tree CCP   :   4.61 ( 18%)   0.00 (  0%)   4.62 ( 18%)
646 kB (  0%)
 tree FRE   :   2.21 (  9%)   0.01 (  3%)   2.21 (  9%)
116 kB (  0%)
 tree backward propagate:   5.03 ( 20%)   0.00 (  0%)   5.04 ( 20%)
  0 kB (  0%)
 out of ssa :   3.05 ( 12%)   0.00 (  0%)   3.05 ( 12%)
  0 kB (  0%)
 TOTAL  :  25.39  0.33 25.72   
 573954 kB

and perf:

Samples: 9K of event 'instructions', Event count (approx.): 107285199390
Overhead   Samples  Command  Shared Object Symbol  
 ◆
  18.06%  1195  cc1  cc1   [.] (anonymous
namespace)::backprop::process_var  ▒
   5.58%   560  cc1  cc1   [.] visit_phi   
 ▒
   5.21%   476  cc1  cc1   [.] inchash::add_expr   
 ▒
   5.21%   671  cc1  cc1   [.] VN_INFO 
 ▒
   5.14%   493  cc1  cc1   [.] bitmap_set_bit  
 ▒
   3.13%   296  cc1  cc1   [.]
hash_table::find_with_hash▒
   2.99%   287  cc1  cc1   [.] vn_phi_lookup   
 ▒
   2.39%   229  cc1  cc1   [.] bitmap_ior_into 
 ▒
   1.77%   165  cc1  cc1   [.] do_rpo_vn

[Bug middle-end/63155] [6/7/8 Regression] memory hog

[rguenth at gcc dot gnu.org]

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

--- Comment #37 from Richard Biener  ---
Author: rguenth
Date: Fri Oct  5 12:54:51 2018
New Revision: 264869

URL: https://gcc.gnu.org/viewcvs?rev=264869=gcc=rev
Log:
2018-10-05  Richard Biener  

PR tree-optimization/63155
* tree-ssa-ccp.c (ccp_propagate::visit_phi): Avoid excess
vertical space in dumpfiles.
* tree-ssa-propagate.h
(ssa_propagation_engine::process_ssa_edge_worklist): Remove.
* tree-ssa-propagate.c (cfg_blocks_back): New global.
(ssa_edge_worklist_back): Likewise.
(curr_order): Likewise.
(cfg_blocks_get): Remove abstraction.
(cfg_blocks_add): Likewise.
(cfg_blocks_empty_p): Likewise.
(add_ssa_edge): Add to current or next worklist based on
RPO index.
(add_control_edge): Likewise.
(ssa_propagation_engine::process_ssa_edge_worklist): Fold
into ...
(ssa_propagation_engine::ssa_propagate): ... here.  Unify
iteration from CFG and SSA edge worklist so we process
everything in RPO order, prioritizing forward progress
over iteration.
(ssa_prop_init): Allocate new worklists, do not dump
immediate uses.
(ssa_prop_fini): Free new worklists.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-ssa-ccp.c
trunk/gcc/tree-ssa-propagate.c
trunk/gcc/tree-ssa-propagate.h

[Bug libstdc++/87502] Poor code generation for std::string("c-style string")

[terra at gnome dot org]

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

--- Comment #7 from M Welinder  ---
Actually, it's more like 50+ instructions for destructing the string that
never (or almost never) needs destructing.  16 of those appear to need
linker fixup.

Sample for the C++14 mode:




callZ3fooRKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE
.LEHE5:
movq(%rsp), %rbx
leaq16(%rsp), %rax
cmpq%rax, %rbx
je  .L72
movq16(%rsp), %rsi
addq$1, %rsi
je  .L72
testq   %rbx, %rbx
je  .L72
cmpq$128, %rsi
ja  .L73
movl_ZN9__gnu_cxx12__pool_allocIcE12_S_force_newE(%rip), %r9d
testl   %r9d, %r9d
jle .L74
.L73:
movq%rbx, %rdi
call_ZdlPv
.L72:
[done]
...
[out-of-band code]
.p2align 4,,10
.p2align 3
.L74:
movq%rsp, %rdi
movl$_ZL28__gthrw___pthread_key_createPjPFvPvE, %ebp
call_ZN9__gnu_cxx17__pool_alloc_base16_M_get_free_listEm
movq%rsp, %rdi
movq%rax, %r12
call_ZN9__gnu_cxx17__pool_alloc_base12_M_get_mutexEv
movq%rax, %r13
testq   %rbp, %rbp
je  .L75
movq%rax, %rdi
call_ZL26__gthrw_pthread_mutex_lockP15pthread_mutex_t
testl   %eax, %eax
je  .L75
movl$8, %edi
call__cxa_allocate_exception
movl$_ZN9__gnu_cxx24__concurrence_lock_errorD1Ev, %edx
movl$_ZTIN9__gnu_cxx24__concurrence_lock_errorE, %esi
movq$_ZTVN9__gnu_cxx24__concurrence_lock_errorE+16, (%rax)
movq%rax, %rdi
.LEHB20:
call__cxa_throw
.LEHE20:
.p2align 4,,10
.p2align 3
.L75:
movq(%r12), %rax
movq%rax, (%rbx)
movq%rbx, (%r12)
testq   %rbp, %rbp
je  .L72
movq%r13, %rdi
call_ZL28__gthrw_pthread_mutex_unlockP15pthread_mutex_t
testl   %eax, %eax
je  .L72
movl$8, %edi
call__cxa_allocate_exception
movl$_ZN9__gnu_cxx26__concurrence_unlock_errorD1Ev, %edx
movl$_ZTIN9__gnu_cxx26__concurrence_unlock_errorE, %esi
movq$_ZTVN9__gnu_cxx26__concurrence_unlock_errorE+16, (%rax)
movq%rax, %rdi
.LEHB21:
call__cxa_throw

[Bug libstdc++/87527] New: uniform_real_distribution can't generate the full range of finite floating point numbers

[fergus.henderson at gmail dot com]

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

Bug ID: 87527
   Summary: uniform_real_distribution can't generate the full
range of finite floating point numbers
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fergus.henderson at gmail dot com
  Target Milestone: ---

Created attachment 44795
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44795=edit
Example program demonstrating the problem.

std::uniform_real_distribution doesn't work if you try to use it to cover the
whole range of available finite floating point numbers:

...
double low = std::numeric_limits::lowest();
double high = std::numeric_limits::max();
std::uniform_real_distribution<> distribution(low, high);
... distribution(generator) ...

In that case, rather than returning a random finite float, it always returns
"inf".

The code in include/bits/random.h line 1862
 
https://github.com/gcc-mirror/gcc/blob/140696c847da5f27f6b8b6f321c426c932dd1592/libstdc%2B%2B-v3/include/bits/random.h#L1862
computes
  __p.b() - __p.a()
which in this case ends up being
   std::numeric_limits::max() - std::numeric_limits::lowest()
and that expression overflows to "inf", which then ends up propagating to the
return value from std::uniform_real_distribution<>::operator().

See the attached example program uniform_real.cc for a test case.

  g++ -Wall uniform_real.cc
  ./a.out

Expected behaviour: program runs successfully with no output.
Observed behaviour: 
a.out: uniform_real.cc:13: int main(): Assertion `x >= low && x < high' failed.

Observed with: gcc version 7.3.0 (Debian 7.3.0-5)
and libstdc++.so.6.0.25

GCC for AArch64 never emits CFI in debug_frame

[Alexander Fedotov]

Hello

I've noticed that for C++ translation unit GCC for aarch64 always
emits CFI into eh_frame but never debug_frame even if debug
information is enabled. Tried on GCC versions 6 to 8.
DWARF for the ARM 64-bit architecture (AArch64) states that it must be
debug_frame ((https://static.docs.arm.com/ihi0057/b/IHI0057B_aadwarf64.pdf)
GAS supports emitting CFI to both sections by directive: .cfi_sections
   .debug_frame,.eh_frame

At the same time gcc for arm emits CFI in both debug_frame and .ARM.exidx

I'm aware about CFI for Exception Handling. But what the reason to not
emit both ?
Is there any implicit reason for that or it's just a bug ?

Steps to reproduce:

cat > test.cpp < test.c <

[Bug libstdc++/87502] Poor code generation for std::string("c-style string")

[terra at gnome dot org]

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

--- Comment #6 from M Welinder  ---
> const_cast(s)="some longer string so it needs proper deletion";

Is that really valid?

This comes down to whether the temporary object creating with the function
call is constant [in which case the above is UB] or not [in which case the
above is perfectly fine].

If I am reading http://cpp14.centaur.ath.cx/dcl.init.ref.html right then
the object is created with the const/volatile specifiers of the argument
type, in this case const.  If so, such an object must not be changed.

Just in case I am reading it wrong, I still say the generated code is
excessive.  gcc creates 16 instructions that, among other things, check
the _S_force_new flag.  Most of those instructions will never be executed
in practice.  I think the generated code, at least for the
temporary-from-small-string case, should simply be

movq (%rsp), %rdi
leaq 16(%rsp), %rax
cmpq %rax, %rdi;; check if buffer is allocated
je .L42
call do_the_complicated_thing
.L42:

[Bug target/87522] LTO incorrectly merges target specific options

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #6 from H.J. Lu  ---
Fixed for GCC 9, GCC 8.3 and GCC 7.4.

[Bug target/87522] LTO incorrectly merges target specific options

[hjl at gcc dot gnu.org]

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

--- Comment #5 from hjl at gcc dot gnu.org  ---
Author: hjl
Date: Fri Oct  5 11:40:59 2018
New Revision: 264867

URL: https://gcc.gnu.org/viewcvs?rev=264867=gcc=rev
Log:
i386: Don't pass -msse2avx to assembler for -mavx

With

gcc -O2 -fPIC -flto -g -c -o a.o a.c
gcc -O2 -fPIC -flto -g -mavx   -c -o b.o b.c
gcc -shared -O2 -fPIC -flto -g -o lib1.so a.o b.o

LTO correctly generates AVX for b.o and SSE for a.o.  But the GCC driver
passes -msse2avx to assembler, which encodes SSE instructions as AVX
instructions.  We shouldn't pass -msse2avx to assembler for -mavx.

Backport from mainline
PR target/87522
* config/i386/gnu-user.h (ASM_SPEC): Don't pass -msse2avx to
assembler for -mavx.
* config/i386/gnu-user64.h (ASM_SPEC): Likewise.

Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/config/i386/gnu-user.h
branches/gcc-7-branch/gcc/config/i386/gnu-user64.h

[Bug target/87522] LTO incorrectly merges target specific options

[hjl at gcc dot gnu.org]

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

--- Comment #4 from hjl at gcc dot gnu.org  ---
Author: hjl
Date: Fri Oct  5 11:31:45 2018
New Revision: 264865

URL: https://gcc.gnu.org/viewcvs?rev=264865=gcc=rev
Log:
i386: Don't pass -msse2avx to assembler for -mavx

With

gcc -O2 -fPIC -flto -g -c -o a.o a.c
gcc -O2 -fPIC -flto -g -mavx   -c -o b.o b.c
gcc -shared -O2 -fPIC -flto -g -o lib1.so a.o b.o

LTO correctly generates AVX for b.o and SSE for a.o.  But the GCC driver
passes -msse2avx to assembler, which encodes SSE instructions as AVX
instructions.  We shouldn't pass -msse2avx to assembler for -mavx.

Backport from mainline
PR target/87522
* config/i386/gnu-user.h (ASM_SPEC): Don't pass -msse2avx to
assembler for -mavx.
* config/i386/gnu-user64.h (ASM_SPEC): Likewise.

Modified:
branches/gcc-8-branch/gcc/ChangeLog
branches/gcc-8-branch/gcc/config/i386/gnu-user.h
branches/gcc-8-branch/gcc/config/i386/gnu-user64.h

[Bug target/87522] LTO incorrectly merges target specific options

[hjl at gcc dot gnu.org]

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

--- Comment #3 from hjl at gcc dot gnu.org  ---
Author: hjl
Date: Fri Oct  5 11:29:44 2018
New Revision: 264864

URL: https://gcc.gnu.org/viewcvs?rev=264864=gcc=rev
Log:
i386: Don't pass -msse2avx to assembler for -mavx

With

gcc -O2 -fPIC -flto -g -c -o a.o a.c
gcc -O2 -fPIC -flto -g -mavx   -c -o b.o b.c
gcc -shared -O2 -fPIC -flto -g -o lib1.so a.o b.o

LTO correctly generates AVX for b.o and SSE for a.o.  But the GCC driver
passes -msse2avx to assembler, which encodes SSE instructions as AVX
instructions.  We shouldn't pass -msse2avx to assembler for -mavx.

PR target/87522
* config/i386/gnu-user.h (ASM_SPEC): Don't pass -msse2avx to
assembler for -mavx.
* config/i386/gnu-user64.h (ASM_SPEC): Likewise.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/gnu-user.h
trunk/gcc/config/i386/gnu-user64.h

[Bug target/87509] ICE in extract_insn, at recog.c:2305

[segher at gcc dot gnu.org]

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

--- Comment #2 from Segher Boessenkool  ---
Author: segher
Date: Fri Oct  5 10:52:33 2018
New Revision: 264863

URL: https://gcc.gnu.org/viewcvs?rev=264863=gcc=rev
Log:
rs6000: Various fixes for the new fpscr builtins (PR87509)

With these fixes all testcases test clean for me, both on
powerpc64-linux {-m32,-m64} and on powerpc64le-linux, with all
relevant -mcpu= settings.


PR target/87509
* config/rs6000/rs6000-builtin.def (RS6000_BUILTIN_SET_FPSCR_DRN): Use
RS6000_BTM_DFP.
* config/rs6000/rs6000.md (rs6000_set_fpscr_rn): Require the operand
to be DImode.  When using mffscrn, force the operand to a register.

gcc/testsuite/
PR target/87509
* gcc.target/powerpc/test_fpscr_drn_builtin.c: Use hard_dfp instead
of dfp_hw.  Don't include .
* gcc.target/powerpc/test_fpscr_drn_builtin_error.c: Ditto.  Require
lp64.
* gcc.target/powerpc/test_fpscr_rn_builtin.c: Don't include
.
* gcc.target/powerpc/test_fpscr_rn_builtin_error.c: Ditto.
* gcc.target/powerpc/test_mffsl.c: Ditto.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/rs6000-builtin.def
trunk/gcc/config/rs6000/rs6000.md
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/powerpc/test_fpscr_drn_builtin.c
trunk/gcc/testsuite/gcc.target/powerpc/test_fpscr_drn_builtin_error.c
trunk/gcc/testsuite/gcc.target/powerpc/test_fpscr_rn_builtin.c
trunk/gcc/testsuite/gcc.target/powerpc/test_fpscr_rn_builtin_error.c
trunk/gcc/testsuite/gcc.target/powerpc/test_mffsl.c

[Bug fortran/87449] -Wunused-variable and associate

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-10-05
 Ever confirmed|0   |1

--- Comment #4 from Dominique d'Humieres  ---
Confirmed from at least 4.8 up to trunk (9.0).

[Bug fortran/87477] [meta-bug] [F03] issues concerning the ASSOCIATE statement

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-10-05
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Marking as NEW.

[Bug fortran/58618] Wrong code with character substring and ASSOCIATE

[dominiq at lps dot ens.fr]

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

--- Comment #7 from Dominique d'Humieres  ---
> Still present in the current trunk as of r264725.

If the PR has not been marked as fixed, such post is just adding noise!-(

[Bug fortran/87127] External function not recognised from within an associate block

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Keywords||rejects-valid
   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-10-05
 Ever confirmed|0   |1

--- Comment #2 from Dominique d'Humieres  ---
> Present since at least version 5.4. It is still present in the very
> recent trunk (r264725).

Also present in 4.8 and 4.9.

[Bug fortran/87127] External function not recognised from within an associate block

[juergen.reuter at desy dot de]

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

--- Comment #1 from Jürgen Reuter  ---
Present since at least version 5.4. It is still present in the very recent
trunk (r264725).

[Bug fortran/58618] Wrong code with character substring and ASSOCIATE

[juergen.reuter at desy dot de]

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

Jürgen Reuter  changed:

   What|Removed |Added

 CC||juergen.reuter at desy dot de

--- Comment #6 from Jürgen Reuter  ---
Still present in the current trunk as of r264725.

[Bug libstdc++/54005] Use __atomic_always_lock_free in libstdc++ is_lock_free instead of __atomic_is_lock_free

[redi at gcc dot gnu.org]

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

--- Comment #25 from Jonathan Wakely  ---
(In reply to Hans-Peter Nilsson from comment #23)
> ...and also, a call might be generated as the result of using
> __atomic_is_lock_free (instead of __atomic_always_lock_free), so the target
> may change its mind.  Not good.

That should have been fixed by r227878 for Bug 65913 so that for these cases no
call is generated.

Without a testcase showing the wrong thing happening, I still think the right
thing happens here.

[Bug libstdc++/54005] Use __atomic_always_lock_free in libstdc++ is_lock_free instead of __atomic_is_lock_free

[redi at gcc dot gnu.org]

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

--- Comment #24 from Jonathan Wakely  ---
(In reply to Hans-Peter Nilsson from comment #22)
> Or do I misread that?  Are __alignof(x) and the result of alignas(x)
> in the declaration guaranteed to always be the same here?

Yes.

[Bug fortran/80524] [F03] Problematic behaviour with a finalization subroutine in gfortran

[juergen.reuter at desy dot de]

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

--- Comment #7 from Jürgen Reuter  ---
This is still present in the actual trunk.

[Bug c++/71128] [concepts] ICE on ill-formed explicit instantiation of a function concept

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--- Comment #1 from Paolo Carlini  ---
Mine.

[Bug middle-end/63155] [6/7/8 Regression] memory hog

[rguenther at suse dot de]

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

--- Comment #36 from rguenther at suse dot de  ---
On Thu, 4 Oct 2018, rogerio.souza at gmail dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63155
> 
> --- Comment #35 from Rogério de Souza Moraes  
> ---
> Created attachment 44791
>   --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44791=edit
> Small testcase more similar to original environment
> 
> Hi Richard,
> 
> this is a new testcase, based on another file in the original environment. 
> It’s
> quite small (7000 lines, 240 setjmp calls).
> 
> This code with a little complex but still simplified control structure
> represents state machine implementation, which is very widely used by our
> customers. Another new factor is the nested setjmp calls. Of course, original
> testcase is more complex and takes even more time with more difference.
> 
> You can run it using the following commands:
> 
> 
> time gcc -DGCC -DLINUX_C -D_GLIBCXX_USE_CXX11_ABI=0  -m32 -m32 -w -c -O0
> -pedantic -fwrapv -mstackrealign -mpreferred-stack-boundary=4
> gcc_2nd_synth_pure_c_item.c -o gcc_2nd_synth_pure_c_item.o
> 
> time gcc -DGCC -DLINUX_C -D_GLIBCXX_USE_CXX11_ABI=0  -m32 -m32 -w -c -O
> -pedantic -fwrapv -mstackrealign -mpreferred-stack-boundary=4
> gcc_2nd_synth_pure_c_item.c -o gcc_2nd_synth_pure_c_item.o
> 
> 
> Results :
> 
> GCC: 4.8.5 (From RHEL 7.5)
> 
> real0m0.349s
> user0m0.255s
> sys 0m0.083s
> 
> real0m0.193s
> user0m0.163s
> sys 0m0.023s
> 
> GCC: 6.3.0 (GCC 6.3.0 with Revision 264523 backported and applied to it)
> 
> real0m32.235s
> user0m30.486s
> sys 0m1.622s
> 
> real3m34.203s
> user3m33.726s
> sys 0m0.292s
> 
> The performance difference is relevant in this test.

Thanks for the more realistic testcase.  I can confirm the above
and I also see a slowdown in GCC 9 compared to GCC 8 at -O1:

> /usr//bin/time gcc-8 -S t.c -O -fwrapv -mstackrealign 
-mpreferred-stack-boundary=4 -m32
157.48user 0.24system 2:37.78elapsed 99%CPU (0avgtext+0avgdata 
888036maxresident)k
47704inputs+152outputs (8major+240936minor)pagefaults 0swaps

> /usr//bin/time gcc-9 -S t.c -O -fwrapv -mstackrealign 
-mpreferred-stack-boundary=4 -m32
197.61user 0.39system 3:18.08elapsed 99%CPU (0avgtext+0avgdata 
890628maxresident)k
0inputs+184outputs (0major+259016minor)pagefaults 0swaps

Somehow it's still CCP that makes things slow:

 tree CCP   : 178.52 ( 89%)   0.01 (  2%) 178.55 ( 
89%) 646 kB (  0%)

perf tells me it's

-   96.33%29.55% 14801  cc1  cc1   [.] 
ccp_propagate::visit_phi▒
 ccp_propagate::visit_phi   
▒
   - ssa_propagation_engine::simulate_stmt  
▒
  + 49.51% ssa_propagation_engine::simulate_block   
▒
  + 46.82% ssa_propagation_engine::ssa_propagate

-   37.06%28.98% 12421  cc1  cc1   [.] 
ccp_lattice_meet▒
   - ccp_lattice_meet   
▒
  + 37.02% ccp_propagate::visit_phi 
▒
  + 0.03% set_lattice_value  

-5.17% 5.17%  1949  cc1  cc1   [.] 
wi::bit_or >, generic_w▒
 wi::bit_or >, 
generic_wide_int > >   ▒
   - ccp_lattice_meet   
▒
  + 5.16% ccp_propagate::visit_phi  
▒
  + 0.01% set_lattice_value 

-4.02% 4.02%  1509  cc1  cc1   [.] 
canonicalize_value  ▒
   - canonicalize_value 
▒
  + 4.02% get_value_for_expr
▒
  + 0.00% ccp_folder::get_value  

-2.90% 2.89%  1083  cc1  cc1   [.] 
wi::eq_p >, int>   ▒
 wi::eq_p >, int>  
▒
   - ccp_lattice_meet   
▒
  + 2.89% ccp_propagate::visit_phi  
▒
  + 0.00% set_lattice_value   

As said, thanks for the testcase.

[Bug libstdc++/87520] [8/9 Regression] ODR violations in std::make_shared when mixing -fno-rtti and -frtti

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |8.3

[Bug libstdc++/87502] Poor code generation for std::string("c-style string")

[pinskia at gcc dot gnu.org]

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

--- Comment #5 from Andrew Pinski  ---
The C++17 calling a function part of this issue is record as PR 86590 already.

The rest is a different issue and should be looked into.

[Bug lto/87525] infinite loop generated for fread() if enabling -flto and -D_FORTIFY_SOURCE=2

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #5 from Martin Liška  ---
Can you please advise how to build the flac package and how to run a test that
spins in an infinite loop?

[Bug testsuite/87487] New test case gfortran.dg/deferred_character_24.f90 in r264721 fails on big endian

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

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

--- Comment #7 from Paul Thomas  ---
Thanks for flagging the problem up and confirming the fix so promptly.

Fixed.

Paul

[Bug libstdc++/87502] Poor code generation for std::string("c-style string")

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||redi at gcc dot gnu.org

--- Comment #4 from Martin Liška  ---
Ccing Jonathan, libstdc++ maintainer.

[Bug testsuite/87487] New test case gfortran.dg/deferred_character_24.f90 in r264721 fails on big endian

[pault at gcc dot gnu.org]

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

--- Comment #6 from Paul Thomas  ---
Author: pault
Date: Fri Oct  5 07:01:57 2018
New Revision: 264862

URL: https://gcc.gnu.org/viewcvs?rev=264862=gcc=rev
Log:
2018-10-05  Paul Thomas  

PR fortran/87487
* trans-decl.c (gfc_get_symbol_decl): Make sure that deferred
character length pointer initializer has the right type to fix
problem with deferred_character_24.f90 on big endian.


Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-decl.c