[Bug tree-optimization/59859] [meta-bug] GRAPHITE issues

[rguenth at gcc dot gnu.org]

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

Bug 93134 Summary: [graphite] ICE: Segmentation fault in ISL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93134

   What|Removed |Added

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

[Bug tree-optimization/93134] [graphite] ICE: Segmentation fault in ISL

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #8 from Richard Biener  ---
So this one is confirmed an ISL issue.

[Bug c/93132] bogus `attribute((access))' warning when size-index is specified

[p...@gcc-bugzilla.mail.kapsi.fi]

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

--- Comment #2 from Pekka S  ---
As the patch is pretty trivial, I think it's easiest if you simply make the
appropriate changes, including incrementing the atoi() values.  I did mention
in the last paragraph that not incrementing the 1-based indexes is a bit
misleading, so I guess this confirms that :-)

By the way, at least with AArch64 on C++ front-end the test case contributed by
you causes an ICE.  I did already notice this earlier on my tests -- complex,
i.e. normal, files with prototyped access attributes are fine, but on simple
cases with very little code they ICE.  This sounds a bit fishy to me (perhaps
the cause is found somewhere else).  Are you able to reproduce this?  Shall I
make a separate PR?

$ g++ -S -Wall -xc++ pr93132.c
pr93132.c:12:29: internal compiler error: canonical types differ for identical
types 'void(void*, int, int, int, int)' and 'void(void*, int, int, int, int)'
   12 | f (void*, int, int, int, int);   // { dg-warning "attribute
'access\\\(read_only, 1, 3\\\)' mismatch positional argument values 3 and 5" }

I do not have the backtrace available to be included here, but if I recall
correctly it wasn't anywhere near `c-attribs.c' code.

[Bug libstdc++/81806] Split in pbds works in O(n) instead of O(log n)

[raihatneloy1992 at gmail dot com]

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

Raihat Zaman Neloy  changed:

   What|Removed |Added

 CC||raihatneloy1992 at gmail dot 
com

--- Comment #10 from Raihat Zaman Neloy  ---
Hello all,
I am also a user of pb_ds and recently dig into the split function's o(n)
behaviour. A lot of contestants from my country (Bangladesh) uses these DS. If
the split function behaves correctly (logn complexity), this DS's will have
been vastly used for query processing. Please consider this before deprecating
the pb_ds. It helps contestants a lot to code and solve quicker.

[Bug middle-end/93195] New: -fpatchable-function-entries : __patchable_function_entries should consider comdat groups

[i at maskray dot me]

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

Bug ID: 93195
   Summary: -fpatchable-function-entries :
__patchable_function_entries should consider comdat
groups
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: i at maskray dot me
  Target Milestone: ---

% cat a.cc
inline void foo() {}
void bar() { foo(); }
% cat b.cc
inline void foo() {}
void bar1() { foo(); }
% g++ -fpatchable-function-entry=1 -c a.cc b.cc

Linkers don't allow a relocation to a discarded symbol (foo).

% ld.bfd a.o b.o
...
`.text._Z3foov' referenced in section `__patchable_function_entries' of b.o:
defined in discarded section `.text._Z3foov[_Z3foov]' of b.o

% gold a.o b.o
b.o(__patchable_function_entries+0x0): error: relocation refers to local symbol
"" [5], which is defined in a discarded section
  section group signature: "_Z3foov"
  prevailing definition is from a.o

% ld.lld a.o b.o
ld.lld: error: relocation refers to a discarded section: .text._Z3foov
>>> defined in b.o
>>> referenced by b.cc
>>>   b.o:(__patchable_function_entries+0x0)

[Bug middle-end/93194] -fpatchable-function-entries : __patchable_function_entries has wrong sh_flags and sh_addralign

[i at maskray dot me]

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

--- Comment #1 from Fangrui Song  ---
The SHF_WRITE issue has been fixed.

https://gcc.gnu.org/ml/gcc-patches/2020-01/msg00271.html will fix sh_addralign

[Bug target/93177] PPC: Missing many useful platform intrinsics

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
ppu_intrinsics.h is installed for all powerpc* configs.  Though to use it you
need to compile with -mcpu=cell :)

[Bug tree-optimization/93084] [10 regression] Infinite loop in ipa-cp when building clang with LTO+PGO

[fxue at gcc dot gnu.org]

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

--- Comment #13 from fxue at gcc dot gnu.org ---
Author: fxue
Date: Wed Jan  8 02:55:00 2020
New Revision: 279987

URL: https://gcc.gnu.org/viewcvs?rev=279987=gcc=rev
Log:
Find matched aggregate lattice for self-recursive CP (PR ipa/93084)

2020-01-08  Feng Xue  

PR ipa/93084
* ipa-cp.c (self_recursively_generated_p): Find matched aggregate
lattice for a value to check.
(propagate_vals_across_arith_jfunc): Add an assertion to ensure
finite propagation in self-recursive scc.

2020-01-08  Feng Xue  

PR ipa/93084
* gcc.dg/ipa/ipa-clone-3.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/ipa/ipa-clone-3.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/ipa-cp.c
trunk/gcc/testsuite/ChangeLog

[Bug c/93194] New: -fpatchable-function-entries : __patchable_function_entries has wrong sh_flags and sh_addralign

[i at maskray dot me]

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

Bug ID: 93194
   Summary: -fpatchable-function-entries :
__patchable_function_entries has wrong sh_flags and
sh_addralign
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: i at maskray dot me
  Target Milestone: ---

% cat a.c
void f(){}
% gcc -fpatchable-function-entry=3 -c a.c
% readelf -S a.o
...
  [Nr] Name  TypeAddress  OffSize   ES Flg
Lk Inf Al
  [ 0]   NULL 00 00 00 
0   0  0
  [ 1] .text PROGBITS 40 0a 00  AX 
0   0  1
  [ 2] .data PROGBITS 4a 00 00  WA 
0   0  1
  [ 3] .bss  NOBITS   4a 00 00  WA 
0   0  1
  [ 4] __patchable_function_entries PROGBITS 4a
08 00   A  0   0  1
  [ 5] .rela__patchable_function_entries RELA
0001a0 18 18   I 10   4  8


sh_addralign of __patchable_function_entries should be 8 on ELF64 platforms, 4
on ELF32 platforms, instead of 1.

__patchable_function_entries should have the SHF_WRITE flag. A
__patchable_function_entries entry is relocated by a symbolic relocation (e.g.
R_X86_64_64, R_AARCH64_ABS64, R_PPC64_ADDR64).
In -shared or -pie mode, the linker will create a dynamic relocation,

* non-preemptible (STB_LOCAL / non-STV_DEFAULT / -Bsymbolic / not-shared /
--dynamic-list excluded / etc): relative relocation (e.g. R_X86_64_RELATIVE)
* preemptible: symbolic relocation (e.g. R_X86_64_64)


(We can't emit an offset relative to the image base (.quad .Lfoo - .Lbase),
because differences across sections are generally not representable. A symbolic
relocation gives the runtime code information about the symbol names, which may
be desirable.)

[Bug middle-end/93189] [10 regression] Many test case failures starting with r279942

[luoxhu at gcc dot gnu.org]

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

--- Comment #3 from luoxhu at gcc dot gnu.org ---
Author: luoxhu
Revision: 279986
Modified property: svn:log

Modified: svn:log at Wed Jan  8 01:32:45 2020
--
--- svn:log (original)
+++ svn:log Wed Jan  8 01:32:45 2020
@@ -7,5 +7,6 @@

2020-01-08  Luo Xiong Hu  

+   PR middle-end/93189
* ipa-inline.c (caller_growth_limits): Restore the AND.

[Bug web/93185] Support git commits as a link in bugzilla entries

[LpSolit at gmail dot com]

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

Frédéric Buclin  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-01-07
 Ever confirmed|0   |1

--- Comment #2 from Frédéric Buclin  ---
(In reply to Martin Liška from comment #0)
> Once we'll switch to git, it would be handy to refer in bugzilla to git
> commits with their corresponding hashes. Similarly to currently existing
> r123456.

When will the move to git take place?

[Bug middle-end/87256] hppa spends huge amount of time in synth_mult()

[slyfox at inbox dot ru]

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

--- Comment #12 from Sergei Trofimovich  ---
I started looking at implementing full local cache in complement to global
evicting 'struct alg_hash_entry x_alg_hash[NUM_ALG_HASH_ENTRIES];' cache.

Noob question: which gcc's data structure should I use to implement a simple
append-only hash set of POD-like 'struct alg_hash_entry' keyed by
'alg_hash_entry::t' as a hash?

'gcc/hash-set.h', 'gcc/hash-map.h'? Or they are both wrong? Looks like for
hash-*  ones I need to define a bunch of traits that define things like
'is_deleted'/'is_empty'. I'm not very clear what it actually means. Do I need
to embed/wrap 'is_deleted' flag into alg_hash_entry to accomodate the
requirement?

[Bug fortran/93193] C preprocessor works across commented lines

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
C Preprocessor happens and then Lexing for fortran.  This is by design.  Also
use of the c preprocessor is a gnu extension. In that it is not specified by
the fortran standard.

[Bug c++/40752] -Wconversion generates false warnings for operands not larger than target type

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug libstdc++/92124] std::vector copy-assigning when it should move-assign.

[fdumont at gcc dot gnu.org]

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

--- Comment #4 from François Dumont  ---
Author: fdumont
Date: Tue Jan  7 21:01:37 2020
New Revision: 279967

URL: https://gcc.gnu.org/viewcvs?rev=279967=gcc=rev
Log:
PR libstdc++/92124 fix incorrect container move assignment

* include/bits/stl_tree.h
(_Rb_tree<>::_M_move_assign(_Rb_tree&, false_type)): Replace
std::move_if_noexcept by std::move.
* testsuite/23_containers/map/92124.cc: New.
* testsuite/23_containers/set/92124.cc: New.

Added:
trunk/libstdc++-v3/testsuite/23_containers/map/92124.cc
trunk/libstdc++-v3/testsuite/23_containers/set/92124.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/stl_tree.h

[Bug c/93180] const function pointers placed in a custom section are causing that custom section to become writable

[pskocik at gmail dot com]

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

--- Comment #5 from pskocik at gmail dot com ---
Jakub Jelinek, I later asked how this worked on Stack Overflow
(https://stackoverflow.com/questions/59629946/why-do-gcc-and-clang-place-custom-sectioned-const-funcptr-symbols-into-writable).
Got no answer there (yet), but your comment explains it nicely! Thanks!

[Bug fortran/93193] New: C preprocessor works across commented lines

[i.s.ger at yandex dot ru]

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

Bug ID: 93193
   Summary: C preprocessor works across commented lines
   Product: gcc
   Version: 9.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: i.s.ger at yandex dot ru
  Target Milestone: ---

C preprocessor works across commented lines, so than if C-like multiline
comments are in .F files, the output file in incorrect.


I have tried to compile the following file (gfortran 9.2.1):

program main
! /*
print *, "Hello, World!"
! */
end program main

If -cpp flag is set, the output of `gfortran example.F90 -cpp -E` (compiled
program is incorrect):

# 1 "example.F90"
# 1 ""
# 1 ""
# 1 "example.F90"
program main
! 


end program main

If -nocpp flag is set, the output of `gfortran example.F90 -nocpp -E` (compiled
program is correct):
 MAIN__ main
Analyzing compilation unit
Performing interprocedural optimizations
 <*free_lang_data>   
  Streaming LTO
 
Assembling functions:
   MAIN__ main
Time variable   usr   sys  wall
  GGC
 phase parsing  :   0.00 (  0%)   0.00 (  0%)   0.01 ( 50%)
   1684 kB ( 85%)
 phase opt and generate :   0.01 (100%)   0.00 (  0%)   0.01 ( 50%)
111 kB (  6%)
 parser (global):   0.00 (  0%)   0.00 (  0%)   0.00 (  0%)
   1684 kB ( 85%)
 varconst   :   0.00 (  0%)   0.00 (  0%)   0.01 ( 50%)
  0 kB (  0%)
 initialize rtl :   0.01 (100%)   0.00 (  0%)   0.00 (  0%)
 12 kB (  1%)
 rest of compilation:   0.00 (  0%)   0.00 (  0%)   0.01 ( 50%)
  4 kB (  0%)
 TOTAL  :   0.01  0.00  0.02   
   1978 kB

I do not know what the compiler wants to say to me in the second case, but I
would have expected to see preprocessored code.

[Bug c/93180] const function pointers placed in a custom section are causing that custom section to become writable

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
For variables that should be read-only after relocation processing, but should
be relocated, gcc normally uses .data.rel.ro and similar sections, those are
writable, but placed in PT_GNU_RELRO part of the binary/shared library, so it
is mprotected after relocation processing.
You should probably arrange through linker script to put your section in that
segment too.

[Bug target/93187] [10 Regression] ICE in extract_insn, at recog.c:2294

[jakub at gcc dot gnu.org]

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

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

Untested fix.

[Bug middle-end/93189] [10 regression] Many test case failures starting with r279942

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||build
  Component|testsuite   |middle-end
   Target Milestone|--- |10.0

[Bug rtl-optimization/93187] [10 Regression] ICE in extract_insn, at recog.c:2294

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2020-01-07
 CC||jakub at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
   Target Milestone|--- |10.0
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Cleaned up testcase:

// PR target/93187
// { dg-do compile }
// { dg-options "-O2" }
// { dg-additional-options "-fstack-protector-strong" { target fstack_protector
} }
// { dg-additional-options "-fpie" { target fpie } }

struct A;
struct B;
struct C { int operator () (B, const B &); };
struct D { typedef int *d; };
struct E { C g; };
struct F { F (D::d); friend bool operator==(F &, const int &); };
template  struct H {
  typedef D *I;
  E l;
  I foo ();
  T t;
  F bar (I, const T &);
  F baz (const T &);
};
template 
F
H::bar (I n, const T )
{
  while (n)
if (l.g (t, o))
  n = 0;
  return 0;
}
template 
F
H::baz (const T )
{
  D *r = foo ();
  F p = bar (r, n);
  return p == 0 ? 0 : p;
}
template  struct J {
  H h;
  B 
  void baz () { h.baz (q); }
};
enum K { L };
template  struct M;
template  struct G {
  using N = J;
  N *operator->();
};
template  struct M : public G {
  using N = J;
  N *foo () { return n; }
  N *n;
  int o;
};
template 
inline typename G::N *
G::operator-> ()
{
  N *n = static_cast> *>(this)->foo ();
  return n;
}
struct B { bool qux (); };
struct O {
  struct P { M p; };
  static thread_local P o;
  int baz () const;
};
thread_local O::P O::o;
B be;
int
O::baz () const
{
  do
o.p->baz ();
  while (be.qux ());
  __builtin_unreachable ();
}

[Bug target/93192] [m68k] incorrect conversion of inf and nan in __truncxfdf2

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
Patches should be sent to gcc-patches@ after reading
https://gcc.gnu.org/contribute.html .

[Bug inline-asm/47071] Using -ffunction-sections produces bad assembler on my testcase

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||ian.s.mcinerney at ieee dot org

--- Comment #4 from Andrew Pinski  ---
*** Bug 93190 has been marked as a duplicate of this bug. ***

[Bug inline-asm/93190] Failure to link with .note.GNU-stack in inline assembly

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|INVALID |DUPLICATE

--- Comment #7 from Andrew Pinski  ---


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

[Bug libgcc/93192] New: [m68k] incorrect conversion of inf and nan in __truncxfdf2

[ad...@tho-otto.de]

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

Bug ID: 93192
   Summary: [m68k] incorrect conversion of inf and nan in
__truncxfdf2
   Product: gcc
   Version: 9.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgcc
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ad...@tho-otto.de
  Target Milestone: ---

Created attachment 47606
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47606=edit
Suggested patch

The implementation of _truncxfdf2 (long double to double) incorrectly converts
INFs and NaNs to very large numbers (8.98847e307).

Attached is a suggested patch. It also fixes the test case for a zero exponent,
which in the current version also tests the empty 16 bits of the long double
format for being zero, but should ignore them.

[Bug fortran/67202] Fortran FE should load scalar pass-by-reference intent-in arguments at the beginning of a function

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

   Host|67202   |

--- Comment #4 from Thomas Koenig  ---
(In reply to Martin Liška from comment #3)
> @Thomas: Setting host to 67202 is probably a typo.

Definitely :-) Removing.

[Bug inline-asm/93190] Failure to link with .note.GNU-stack in inline assembly

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #6 from Andrew Pinski  ---
You change the section behind gcc's back. You need to change back to the
section that it was before you started the top level inline asm.  This is a dup
of other bugs but I am lazy to find them.

[Bug inline-asm/93190] Failure to link with .note.GNU-stack in inline assembly

[ian.s.mcinerney at ieee dot org]

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

--- Comment #5 from Ian McInerney  ---
Created attachment 47605
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47605=edit
Verbose output from successful linking

[Bug inline-asm/93190] Failure to link with .note.GNU-stack in inline assembly

[ian.s.mcinerney at ieee dot org]

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

--- Comment #4 from Ian McInerney  ---
Created attachment 47604
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47604=edit
GCC verbose output from failed linking

[Bug c++/93191] New: Conversions to arrays of unknown bound P0388 Fails for variadic args

[wjwray at gmail dot com]

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

Bug ID: 93191
   Summary: Conversions to arrays of unknown bound P0388 Fails for
variadic args
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wjwray at gmail dot com
  Target Milestone: ---

The P0388 permitted conversion from array of known bound to
array-reference of unknown bound fails for variadic arguments
https://godbolt.org/z/Rp3GdN

#include 

void cat(auto const(&...cstr)[]) { (((void)cstr,puts("G'bye")),...); }
//void cat(auto const(&...cstr)[6]) { (puts(cstr),...); }

using punk = char(*)[]; // Pointer to UNKnown-bound char array

int main() {
cat("Hello","world");  // error: no matching function
cat(*punk{},*punk{});  // Matches 1st overload
}

Same with explicit template syntax

template  void cat(C const(&...cstr)[]);

[Bug inline-asm/93190] Failure to link with .note.GNU-stack in inline assembly

[ian.s.mcinerney at ieee dot org]

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

--- Comment #3 from Ian McInerney  ---
Note that I am compiling this with 

g++ -fno-lto -v -Wl,-v main.cpp

[Bug inline-asm/93190] Failure to link with .note.GNU-stack in inline assembly

[ian.s.mcinerney at ieee dot org]

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

--- Comment #2 from Ian McInerney  ---
Created attachment 47603
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47603=edit
Object file from successful linking

[Bug inline-asm/93190] Failure to link with .note.GNU-stack in inline assembly

[ian.s.mcinerney at ieee dot org]

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

--- Comment #1 from Ian McInerney  ---
Created attachment 47602
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47602=edit
Object file from failed linking

[Bug inline-asm/93190] New: Failure to link with .note.GNU-stack in inline assembly

[ian.s.mcinerney at ieee dot org]

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

Bug ID: 93190
   Summary: Failure to link with .note.GNU-stack in inline
assembly
   Product: gcc
   Version: 9.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: inline-asm
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ian.s.mcinerney at ieee dot org
  Target Milestone: ---

Created attachment 47601
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47601=edit
Example program

When compiling inline assembly that contains the line ".section
.note.GNU-stack,"",%progbits", sometimes the linker fails with the error:
"`.note.GNU-stack' referenced in section `.text' of /tmp/ccKoiXRb.o: defined in
discarded section `.note.GNU-stack' of /tmp/ccKoiXRb.o"

I have narrowed this down to the example in the attached main.cpp. When the
iostream header is included the linking fails, but when it is commented out the
linking works.

It appears that there are some cases when the .note.GNU-stack section is being
referenced inside the .text section of the created object file (taken from the
compiled main.o of the failed linking) even though it is a discarded section in
the linker:

Relocation section '.rela.text' at offset 0x470 contains 9 entries:
  Offset  Info   Type   Sym. ValueSym. Name +
Addend
0036  000e0004 R_X86_64_PLT32 Add2 - 4
0043  0008000a R_X86_64_32    .note.GNU-stack +
0
004d  0014 R_X86_64_PLT32 printf - 4
0076  0004000a R_X86_64_32    .bss + 0
007b  00110004 R_X86_64_PLT32
_ZNSt8ios_base4InitC1E - 4
0080  0012000a R_X86_64_32    __dso_handle + 0
0085  0004000a R_X86_64_32    .bss + 0
008a  0013000a R_X86_64_32   
_ZNSt8ios_base4InitD1E + 0
008f  00140004 R_X86_64_PLT32 __cxa_atexit - 4



The successful compilation produces a .text section that doesn't reference it:

Relocation section '.rela.text' at offset 0x250 contains 3 entries:
  Offset  Info   Type   Sym. ValueSym. Name +
Addend
0036  00090004 R_X86_64_PLT32 Add2 - 4
0043  0006000a R_X86_64_32    .rodata + 0
004d  000b0004 R_X86_64_PLT32 printf - 4



This inconsistent behavior is very problematic. Ideally it should always
compile/link fine with this included in the inline assembly.

I have tested this using 9.2.1 from Fedora 31, and also 7.4.0 from Ubuntu 18.04
and it is present in both versions.

[Bug c/93132] bogus `attribute((access))' warning when size-index is specified

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-01-07
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
I was able to reproduce a problem with the test case below, so confirmed. 
Thanks for pointing it out!  Your fix makes sense to me with one caveat:
Positional arguments are 1-based so I think the diagnostic needs to add 1 to
the atoi() result.  If you have a test case of your own please also add it the
patch (in addition to the one below if it they have different symptoms) and
post it to gcc-patches for review.  Alternatively, let me know if you would
prefer me to fix it.

$ cat pr93132.c && gcc -S -Wall  pr93132.c
/* PR c/93132 - bogus `attribute((access))' warning when size-index
   is specified
   { dg-do compile }
   { dg-options "-Wall" } */

void __attribute__ ((access (read_only, 1, 5)))
f (void*, int, int, int, int);

void __attribute__ ((access (read_only, 1, 3)))
f (void*, int, int, int, int);   // { dg-warning "attribute
'access\\\(read_only, 1, 3\\\)' mismatch positional argument values 3 and 5" }
pr93132.c:10:1: warning: attribute ‘access(read_only, 1, 3)’ mismatch
positional argument values 3 and 5 [-Wattributes]
   10 | f (void*, int, int, int, int);   // { dg-warning "attribute
'access\\\(read_only, 1, 3\\\)' mismatch positional argument values 3 and 5" }
  | ^
pr93132.c:7:1: note: previous declaration here
7 | f (void*, int, int, int, int);
  | ^

[Bug testsuite/93189] [10 regression] Many test case failures starting with r279942

[seurer at gcc dot gnu.org]

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

--- Comment #2 from seurer at gcc dot gnu.org ---
And prevents 176.gcc in spec2000 from building

c-lex.o: In function `init_lex':
c-lex.c:(.text+0xb30): undefined reference to `is_reserved_word'
c-lex.c:(.text+0xc68): undefined reference to `is_reserved_word'
c-lex.c:(.text+0xe50): undefined reference to `is_reserved_word'
c-lex.c:(.text+0xe74): undefined reference to `is_reserved_word'
collect2: error: ld returned 1 exit status
specmake: *** [cc1] Error 1
specmake -j 16 options 2> options.err | tee options.out
COMP: /home/seurer/gcc/install/gcc-test/bin/gcc -c -o options.o  -m64
-fno-strict-aliasing -DHOST_WORDS_BIG_ENDIAN -DSPEC_CPU2000_LP64-O2
-m64 -mcpu=power7  
LINK: /home/seurer/gcc/install/gcc-test/bin/gcc -m64 -Wl,-q
-Wl,-rpath=/home/seurer/gcc/install/gcc-test/lib64  -O2 -m64 -mcpu=power7 
-lm  -o options
  Some files did not appear to be built: cc1
*** Error building 176.gcc

[Bug c++/91364] Implement P0388R4: Permit conversions to arrays of unknown bound

[mpolacek at gcc dot gnu.org]

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

--- Comment #10 from Marek Polacek  ---
(In reply to Will Wray from comment #7)
> Fails to match for variadic arguments. Reopen or file a new bug?

Definitely a new bug, please.

[Bug testsuite/93189] [10 regression] Many test case failures starting with r279942

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
The same change also breaks bootstrap on x86_64-linux.

[Bug target/93174] [10 Regression] ICE building glibc __sha512_process_block for i686

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Created attachment 47600
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47600=edit
gcc10-pr93174.patch

Untested fix.

[Bug c++/91364] Implement P0388R4: Permit conversions to arrays of unknown bound

[wjwray at gmail dot com]

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

--- Comment #9 from Will Wray  ---
The variadic unknown-bound 1st overload matches exact T(&)[] only
https://godbolt.org/z/9qZpWX

#include 
void cat(auto const(&...cstr)[]) { (((void)cstr,puts("G'bye")),...); }
void cat(auto const(&...cstr)[6]) { (puts(cstr),...); }

using punk = char(*)[]; // Pointer to UNKnown-bound char array

int main() {
cat("Hello");  // Outputs "Hello" via 2nd overload
cat(*punk{});  // Outputs "G'bye" via 1st overload
}

[Bug testsuite/93189] New: [10 regression] Many test case failures starting with r279942

[seurer at gcc dot gnu.org]

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

Bug ID: 93189
   Summary: [10 regression] Many test case failures starting with
r279942
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

FAIL: gcc.dg/pr71969-3.c scan-tree-dump-times einline "will not early inline" 8
FAIL: gcc.dg/ipa/remref-2b.c scan-tree-dump-not optimized "hooray"
FAIL: gcc.dg/Wnonnull.c  (test for warnings, line 22)
FAIL: gcc.dg/Wnonnull.c  (test for warnings, line 24)
FAIL: gcc.dg/Wnonnull.c  (test for warnings, line 27)
FAIL: gcc.dg/Wnonnull.c  (test for warnings, line )
FAIL: gcc.dg/Wnonnull.c (test for excess errors)
FAIL: g++.dg/pr83239.C  -std=gnu++14  scan-tree-dump-not optimized
"_ZNSt6vectorIiSaIiEE17_M_default_appendEm"
FAIL: g++.dg/pr83239.C  -std=gnu++17  scan-tree-dump-not optimized
"_ZNSt6vectorIiSaIiEE17_M_default_appendEm"
FAIL: g++.dg/pr83239.C  -std=gnu++2a  scan-tree-dump-not optimized
"_ZNSt6vectorIiSaIiEE17_M_default_appendEm"
FAIL: g++.dg/warn/string1.C(test for warnings, line 17)
FAIL: g++.dg/tree-ssa/pr53844.C  -std=gnu++98  scan-tree-dump-times optimized
"VDEF" 1
FAIL: g++.dg/tree-ssa/pr53844.C  -std=gnu++14  scan-tree-dump-times optimized
"VDEF" 1
FAIL: g++.dg/tree-ssa/pr53844.C  -std=gnu++17  scan-tree-dump-times optimized
"VDEF" 1
FAIL: g++.dg/tree-ssa/pr53844.C  -std=gnu++2a  scan-tree-dump-times optimized
"VDEF" 1
FAIL: g++.dg/tree-ssa/pr61034.C  -std=gnu++98  scan-tree-dump-times fre3 ";;
Function" 1
FAIL: g++.dg/tree-ssa/pr61034.C  -std=gnu++98  scan-tree-dump-times fre3
"unreachable" 11
FAIL: g++.dg/tree-ssa/pr61034.C  -std=gnu++98  scan-tree-dump-times fre3 "free"
14
FAIL: g++.dg/tree-ssa/pr61034.C  -std=gnu++98  scan-tree-dump-times optimized
"free" 0
FAIL: g++.dg/tree-ssa/pr61034.C  -std=gnu++14  scan-tree-dump-times fre3 ";;
Function" 1
FAIL: g++.dg/tree-ssa/pr61034.C  -std=gnu++14  scan-tree-dump-times fre3
"unreachable" 11
FAIL: g++.dg/tree-ssa/pr61034.C  -std=gnu++14  scan-tree-dump-times fre3 "free"
14
FAIL: g++.dg/tree-ssa/pr61034.C  -std=gnu++14  scan-tree-dump-times optimized
"free" 0
FAIL: g++.dg/tree-ssa/pr61034.C  -std=gnu++17  scan-tree-dump-times fre3 ";;
Function" 1
FAIL: g++.dg/tree-ssa/pr61034.C  -std=gnu++17  scan-tree-dump-times fre3
"unreachable" 11
FAIL: g++.dg/tree-ssa/pr61034.C  -std=gnu++17  scan-tree-dump-times fre3 "free"
14
FAIL: g++.dg/tree-ssa/pr61034.C  -std=gnu++17  scan-tree-dump-times optimized
"free" 0
FAIL: g++.dg/tree-ssa/pr61034.C  -std=gnu++2a  scan-tree-dump-times fre3 ";;
Function" 1
FAIL: g++.dg/tree-ssa/pr61034.C  -std=gnu++2a  scan-tree-dump-times fre3
"unreachable" 11
FAIL: g++.dg/tree-ssa/pr61034.C  -std=gnu++2a  scan-tree-dump-times fre3 "free"
14
FAIL: g++.dg/tree-ssa/pr61034.C  -std=gnu++2a  scan-tree-dump-times optimized
"free" 0

[Bug c++/91364] Implement P0388R4: Permit conversions to arrays of unknown bound

[wjwray at gmail dot com]

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

--- Comment #8 from Will Wray  ---
Reduced example (but still with puts output) https://godbolt.org/z/Ttc2Za

#include 
void cat(auto const(&...cstr)[]) { (puts(cstr),...); }
// Comment out this next line[6]
void cat(auto const(&...cstr)[6]) { (puts(cstr),...); }

int main() { cat("Hello","world"); }

Fails to match the 1st overload when the 2nd overload is removed

Answering my own question "is this well formed?"

void cat(auto const()[]...);

Yes; it matches T(&)[] type argument exactly https://godbolt.org/z/NHjPrK

[Bug target/93174] [10 Regression] ICE building glibc __sha512_process_block for i686

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P1
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2020-01-07
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Jakub Jelinek  ---
Reduced testcase:
unsigned long long a[2];
void bar (void);

void
foo (int c)
{
  int e = c >> 2;
  a[0] += c;
  a[1] = a[0] < c;
  while (e--)
bar ();
}

[Bug target/89096] [8/9/10 regression] AIX 7 linker rejects _.ro_ sections by default

[douglas_north at hotmail dot com]

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

james north  changed:

   What|Removed |Added

 CC||douglas_north at hotmail dot 
com

--- Comment #23 from james north  ---
we are seeing a similar error building our software stack.

ld: 0711-308 SEVERE ERROR: Object
/home/jnorth/builds/11-5.dev.4/obj/cosmos_9.engine.cli/engine/main.o, csect
<_main.ro_>
The csect is part of the .text section.
collect2: error: ld returned 12 exit status


any idea if this will make it into 8.4?

[Bug c++/91364] Implement P0388R4: Permit conversions to arrays of unknown bound

[wjwray at gmail dot com]

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

Will Wray  changed:

   What|Removed |Added

 CC||wjwray at gmail dot com

--- Comment #7 from Will Wray  ---
Fails to match for variadic arguments. Reopen or file a new bug?

https://godbolt.org/z/zuJagw

#include 

void cat(auto const(&...a)[]);
//void cat(auto const(&...)[]); // REJECT error: variable or field
//  'cat' declared void
void cat(auto const(&)[]...);   // ACCEPT: is this well formed? (IDK)
void cat(auto const()[]...);  // ACCEPT: is this well formed? (IDK)
//can't provide a definition

// If the char[6] overload below is removed then this [] overload fails:
//   error: no matching function for call to 'cat(const char [6]...)'
void cat(auto const(&...cstr)[]) { (puts(cstr),...); }

void cat(auto const(&...cstr)[6]) { (puts(cstr),...); }

int main() {
cat("Hello","world");
}

[Bug rtl-optimization/93184] Incorrect result of right shift bit operation if compile-time constant shift amount exceeds type width

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

 CC||rsandifo at gcc dot gnu.org

--- Comment #6 from rsandifo at gcc dot gnu.org  
---
(In reply to ktkachov from comment #4)
> (In reply to Wojciech Migda from comment #2)
> > Should there be at least a warning in case when the shift amount is a
> > compile-time known constant?
> 
> In an ideal world yes. Howevever, most such warnings are done before any
> optimisations are done. To detect this case the compiler would need to
> inline mask into pub and do the constant propagation to figure out the bogus
> shift count.
> 
> The compiler does warn about a more direct use of a negative shift count
> e.g.:
> static
> unsigned long long mask(const unsigned long long sz)
> {
> auto const rv = (unsigned long long)-1 >> (8 - 9) * 8;
> return rv;
> }

FWIW, it's also a hard error for:

static constexpr
unsigned long long mask(const unsigned long long sz)
{
auto const rv = (unsigned long long)-1 >> (8 - sz) * 8;
return rv;
}

void pub(unsigned long long & out1, unsigned long long & out2, unsigned long
long const sz)
{
auto constexpr first = mask(9);
out1 = first;

auto const second = mask(sz); // sz equals 9 at runtime
out2 = second;
}

[Bug target/93183] SVE does not use neg as conditional

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-01-07
 CC||rsandifo at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from rsandifo at gcc dot gnu.org  
---
(In reply to Andrew Pinski from comment #1)
> We get:
> .L3:
> ld1bz0.b, p0/z, [x1, x3]
> movprfx z2, z0
> and z2.b, z2.b, #0xc0
> neg z1.b, p1/m, z0.b  ;;;  THIS
> cmpeq   p2.b, p1/z, z2.b, #0
> sel z0.b, p2, z0.b, z1.b   AND THIS
> st1bz0.b, p0, [x0, x3]
> incbx3
> whilelo p0.b, w3, w2
> b.any   .L3
> 
> The two instructions marked should be combined.

The problem is that it isn't a straight combination of the
NEG and SEL, because the condition is the inverse of the one
that we want for predication.

This is one of the things that the IFN_COND_* functions were
designed to fix.  We should probably add unary versions of those.

[Bug target/93188] [9/10-regression] a-profile multilib mismatch for rmprofile toolchain when architecture includes +mp or +sec

[rearnsha at gcc dot gnu.org]

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

Richard Earnshaw  changed:

   What|Removed |Added

 Target||arm
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-01-07
  Component|driver  |target
Summary|a-profile multilib mismatch |[9/10-regression] a-profile
   |for rmprofile toolchain |multilib mismatch for
   |when architecture includes  |rmprofile toolchain when
   |+mp or +sec |architecture includes +mp
   ||or +sec
 Ever confirmed|0   |1

--- Comment #1 from Richard Earnshaw  ---
confirmed, patch in testing

[Bug driver/93188] New: a-profile multilib mismatch for rmprofile toolchain when architecture includes +mp or +sec

[przemyslaw.wirkus at arm dot com]

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

Bug ID: 93188
   Summary: a-profile multilib mismatch for rmprofile toolchain
when architecture includes +mp or +sec
   Product: gcc
   Version: 9.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: driver
  Assignee: unassigned at gcc dot gnu.org
  Reporter: przemyslaw.wirkus at arm dot com
  Target Milestone: ---

Hi,

There are missing multilibs for rmprofile when architecture includes +mp or
+sec:

# Exact version of GCC and options given when GCC was configured/built:

$ ./arm-none-eabi-gcc -v
Using built-in specs.
COLLECT_GCC=./gcc-arm-none-eabi-9-2019-q4-major/bin/arm-none-eabi-gcc
COLLECT_LTO_WRAPPER=/media/przwir01/bulk/toolchains/gcc-arm-none-eabi-9-2019-q4-major/bin/../lib/gcc/arm-none-eabi/9.2.1/lto-wrapper
Target: arm-none-eabi
Configured with:
/mnt/workspace/workspace/GCC-9-pipeline/jenkins-GCC-9-pipeline-100_20191030_1572397542/src/gcc/configure
--target=arm-none-eabi
--prefix=/mnt/workspace/workspace/GCC-9-pipeline/jenkins-GCC-9-pipeline-100_20191030_1572397542/install-native
--libexecdir=/mnt/workspace/workspace/GCC-9-pipeline/jenkins-GCC-9-pipeline-100_20191030_1572397542/install-native/lib
--infodir=/mnt/workspace/workspace/GCC-9-pipeline/jenkins-GCC-9-pipeline-100_20191030_1572397542/install-native/share/doc/gcc-arm-none-eabi/info
--mandir=/mnt/workspace/workspace/GCC-9-pipeline/jenkins-GCC-9-pipeline-100_20191030_1572397542/install-native/share/doc/gcc-arm-none-eabi/man
--htmldir=/mnt/workspace/workspace/GCC-9-pipeline/jenkins-GCC-9-pipeline-100_20191030_1572397542/install-native/share/doc/gcc-arm-none-eabi/html
--pdfdir=/mnt/workspace/workspace/GCC-9-pipeline/jenkins-GCC-9-pipeline-100_20191030_1572397542/install-native/share/doc/gcc-arm-none-eabi/pdf
--enable-languages=c,c++ --enable-plugins --disable-decimal-float
--disable-libffi --disable-libgomp --disable-libmudflap --disable-libquadmath
--disable-libssp --disable-libstdcxx-pch --disable-nls --disable-shared
--disable-threads --disable-tls --with-gnu-as --with-gnu-ld --with-newlib
--with-headers=yes --with-python-dir=share/gcc-arm-none-eabi
--with-sysroot=/mnt/workspace/workspace/GCC-9-pipeline/jenkins-GCC-9-pipeline-100_20191030_1572397542/install-native/arm-none-eabi
--build=x86_64-linux-gnu --host=x86_64-linux-gnu
--with-gmp=/mnt/workspace/workspace/GCC-9-pipeline/jenkins-GCC-9-pipeline-100_20191030_1572397542/build-native/host-libs/usr
--with-mpfr=/mnt/workspace/workspace/GCC-9-pipeline/jenkins-GCC-9-pipeline-100_20191030_1572397542/build-native/host-libs/usr
--with-mpc=/mnt/workspace/workspace/GCC-9-pipeline/jenkins-GCC-9-pipeline-100_20191030_1572397542/build-native/host-libs/usr
--with-isl=/mnt/workspace/workspace/GCC-9-pipeline/jenkins-GCC-9-pipeline-100_20191030_1572397542/build-native/host-libs/usr
--with-libelf=/mnt/workspace/workspace/GCC-9-pipeline/jenkins-GCC-9-pipeline-100_20191030_1572397542/build-native/host-libs/usr
--with-host-libstdcxx='-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic -lm'
--with-pkgversion='GNU Tools for Arm Embedded Processors 9-2019-q4-major'
--with-multilib-list=rmprofile
Thread model: single
gcc version 9.2.1 20191025 (release) [ARM/arm-9-branch revision 277599] (GNU
Tools for Arm Embedded Processors 9-2019-q4-major) 

# Host system type:

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:Ubuntu 18.04.3 LTS
Release:18.04
Codename:   bionic

$ uname -a
Linux e109982-lin 4.15.0-72-generic #81-Ubuntu SMP Tue Nov 26 12:20:02 UTC 2019
x86_64 x86_64 x86_64 GNU/Linux

# Command line that triggers the bug:

$ cat test.c 
int x,y,z;
void main() {x=y/z;}

$ ./arm-none-eabi-gcc -mcpu=cortex-a9 -mfloat-abi=hard -specs=rdimon.specs
test.c

/home/przwir01/validation/2019-10/gcc-arm-none-eabi-9-2019-q4-major/bin/../lib/gcc/arm-none-eabi/9.2.1/../../../../arm-none-eabi/bin/ld:
error: /tmp/cc6G2Yt6.o uses VFP register arguments, a.out does not

/home/przwir01/validation/2019-10/gcc-arm-none-eabi-9-2019-q4-major/bin/../lib/gcc/arm-none-eabi/9.2.1/../../../../arm-none-eabi/bin/ld:
failed to merge target specific data of file /tmp/cc6G2Yt6.o
 collect2: error: ld returned 1 exit status

# It is a regression started in GCC 8.3:

$ ./arm-none-eabi-gcc --version | grep release
arm-none-eabi-gcc (GNU Tools for Arm Embedded Processors 8-2018-q4-major) 8.2.1
20181213 (release) [gcc-8-branch revision 267074]
$ ./arm-none-eabi-gcc -mcpu=cortex-a9 -mfloat-abi=hard -S --print-multi-dir
thumb/v7+fp/hard

$ ./arm-none-eabi-gcc --version | grep release
arm-none-eabi-gcc (GNU Tools for Arm Embedded Processors 8-2019-q3-update)
8.3.1 20190703 (release) [gcc-8-branch revision 273027]
$ ./arm-none-eabi-gcc -mcpu=cortex-a9 -mfloat-abi=hard -S --print-multi-dir
.

$ ./arm-none-eabi-gcc --version | grep release
arm-none-eabi-gcc (GNU Tools for Arm Embedded Processors 9-2019-q4-major) 9.2.1
20191025 (release) 

[Bug rtl-optimization/93187] New: [10 Regression] ICE in extract_insn, at recog.c:2294

[doko at debian dot org]

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

Bug ID: 93187
   Summary: [10 Regression] ICE in extract_insn, at recog.c:2294
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: doko at debian dot org
  Target Milestone: ---

seen on x86_64-linux-gnu building pdns-recursor with r279880, and hardening
options.

$ cat syncres.ii
# 1 "" 3
class a;
class b;
struct c {
  operator()(b, const b &);
};
struct d {
  typedef *aa;
};
struct e {
  c g;
};
struct h {
  typedef h ab;
  h(d::aa);
  friend operator==(ab &, const &);
};
template  class j {
  typedef d *k;
  e l;
  k ac();
  i ad;

public:
  typedef h ae;
  ae m(k, const i &);
  ae ag(const i &);
};
template  h j::m(k n, const i ) {
  while (n)
if (l.g(ad, o))
  n = 0;
  return 0;
}
template  h j::ag(const i ) {
  d *r = ac();
  ae p = m(r, n);
  return p == 0 ? 0 : p;
}
template  class s {
  j al;

public:
  b 
  void ag() { al.ag(q); }
};
enum am { an };
template  class ao;
template  class G {
public:
  using ar = s;
  ar *operator->() {
ar *as = static_cast> *>(this)->at();
return as;
  }
};
template  class ao : public G {
public:
  using ar = s;
  ar *at() { return av; }
  ar *av;
  int aw;
};
class b {
public:
  ax();
};
class t {
  struct ba {
ao bb;
  } static thread_local bc;
  bd() const;
};
thread_local t::ba t::bc;
b be;
t::bd() const {
  do
bc.bb->ag();
  while (be.ax());
}

$ g++ -c -O2 -Wall syncres.ii 
: In member function 'int t::bd() const':
:79:1: error: unrecognizable insn:
(insn 125 3 99 2 (parallel [
(set (mem/v/f/c:DI (plus:DI (reg/f:DI 7 sp)
(const_int 24 [0x18])) [13 D.2787+0 S8 A64])
(unspec:DI [
(mem/v/f:DI (const_int 40 [0x28]) [14
MEM[( long unsigned int *)40B]+0 S8 A64 AS1])
] UNSPEC_SP_SET))
(set (reg:DI 0 ax [105])
(const:DI (unspec:DI [
(symbol_ref:DI ("_ZN1t2bcE") [flags 0x2a] )
] UNSPEC_NTPOFF)))
(clobber (reg:CC 17 flags))
]) -1
 (expr_list:REG_UNUSED (reg:CC 17 flags)
(nil)))
during RTL pass: cprop_hardreg
:79:1: internal compiler error: in extract_insn, at recog.c:2294
0x5c6f01 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
../../src/gcc/rtl-error.c:108
0x5c6f23 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
../../src/gcc/rtl-error.c:116
0x5c605c extract_insn(rtx_insn*)
../../src/gcc/recog.c:2294
0xb7a0ef extract_constrain_insn(rtx_insn*)
../../src/gcc/recog.c:2193
0xb82f9c copyprop_hardreg_forward_1
../../src/gcc/regcprop.c:802
0xb83e26 execute
../../src/gcc/regcprop.c:1367
Please submit a full bug report,
with preprocessed source if appropriate.

[Bug target/93174] [10 Regression] ICE building glibc __sha512_process_block for i686

[jsm28 at gcc dot gnu.org]

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

Joseph S. Myers  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org
   Target Milestone|--- |10.0

--- Comment #1 from Joseph S. Myers  ---
Introduced by r279887.

[Bug c++/93186] New: C++ compile time hog

[jakub at gcc dot gnu.org]

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

Bug ID: 93186
   Summary: C++ compile time hog
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

I've tried to create a testcase for quadratic behavior in sink_clobbers, but on
the one I've created it seems we trigger quadratic behavior in the C++ FE
instead:
struct S {
  S ();
  S (int i);
  int s;
  operator bool () { return s != 0; }
};

void
foo (bool x)
{
  S a;
  x
#define A(n) ? (a = S (0))
#define B(n) A(n##0) A(n##1) A(n##2) A(n##3) A(n##4) \
 A(n##5) A(n##6) A(n##7) A(n##8) A(n##9)
#define C(n) B(n##0) B(n##1) B(n##2) B(n##3) B(n##4) \
 B(n##5) B(n##6) B(n##7) B(n##8) B(n##9)
#define D(n) C(n##0) C(n##1) C(n##2) C(n##3) C(n##4) \
 C(n##5) C(n##6) C(n##7) C(n##8) C(n##9)
#define E(n) D(n##0) D(n##1) D(n##2) D(n##3) D(n##4) \
 D(n##5) D(n##6) D(n##7) D(n##8) D(n##9)
#define F(n) E(n##0) E(n##1) E(n##2) E(n##3) E(n##4) \
 E(n##5) E(n##6) E(n##7) E(n##8) E(n##9)
E(1)
? 0
#undef A
#define A(n) : 0
E(1)
: 0;
}
[

[Bug c/55791] gcc fails to detect wrong type in sizeof in malloc

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org

--- Comment #5 from Martin Sebor  ---
The detection does have to happen in the parser; after that, argument
expressions like 10 * sizeof (char*) may be folded into constants with no trace
of the original subexpressions.

Besides malloc (and realloc) the warning should also work for the two-argument
calloc as well as for user-defined allocation functions declared with attribute
alloc_size.  The design will also need to consider how to handle conditional
and binary expressions involving multiple sizeof expressions such as malloc(x ?
sizeof (A) : sizeof (B)) and malloc(sizeof (A) + sizeof (B)).  Both explicit
conversions (i.e., casts) and implicit conversions (e.g., when passing the
allocation result as an argument to a function) should be considered as well.

[Bug c++/47877] -fvisibility-inlines-hidden does not hide member template functions

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #7 from Jason Merrill  ---
Fixed for GCC 10.

[Bug c++/47877] -fvisibility-inlines-hidden does not hide member template functions

[jason at gcc dot gnu.org]

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

--- Comment #6 from Jason Merrill  ---
Author: jason
Date: Tue Jan  7 15:05:25 2020
New Revision: 279960

URL: https://gcc.gnu.org/viewcvs?rev=279960=gcc=rev
Log:
PR c++/47877 - -fvisibility-inlines-hidden and member templates.

DECL_VISIBILITY_SPECIFIED is also true if an enclosing scope has explicit
visibility, and we don't want that to override -fvisibility-inlines-hidden.
So check for the attribute specifically on the function, like we already do
for template argument visibility restriction.

* decl2.c (determine_visibility): -fvisibility-inlines-hidden beats
explicit class visibility for a template.

Added:
trunk/gcc/testsuite/g++.dg/ext/visibility/fvisibility-inlines-hidden-5.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl2.c
trunk/gcc/tree.h

[Bug c++/91525] ICE (Segmentation Fault) on a bool conversion operator with concepts

[gcc-bugs at marehr dot dialup.fu-berlin.de]

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

--- Comment #3 from gcc-bugs at marehr dot dialup.fu-berlin.de ---
On gcc-10 I get now the following stacktrace:

```
g++-git -std=c++17 -fconcepts -c ice.cpp
main.cpp: In function ‘std::string e()’:
main.cpp:46:16: internal compiler error: Segmentation fault
   46 |   std::cout << o;
  |^
0xc5b15f crash_signal
/home/marehr/Packages/gcc-git/src/gcc/gcc/toplev.c:328
0x645182 compare_ics
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/call.c:10538
0x648c84 joust
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/call.c:11191
0x649cbc tourney
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/call.c:11630
0x649fd1 build_user_type_conversion_1
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/call.c:4165
0x64b435 implicit_conversion
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/call.c:2053
0x64baf0 good_conversion(tree_node*, tree_node*, tree_node*, int, int)
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/call.c:2093
0x77183e check_non_deducible_conversion
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/pt.c:21173
0x77183e check_non_deducible_conversions
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/pt.c:20645
0x77183e fn_type_unification(tree_node*, tree_node*, tree_node*, tree_node*
const*, unsigned int, tree_node*, unification_kind_t, int, conversion**, bool,
bool)
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/pt.c:20947
0x64e879 add_template_candidate_real
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/call.c:3394
0x64f046 add_template_candidate
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/call.c:3479
0x64f046 add_candidates
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/call.c:5805
0x64f612 add_candidates
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/call.c:5720
0x64f612 add_operator_candidates
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/call.c:5909
0x6545eb build_new_op_1
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/call.c:6132
0x6551ed build_new_op(op_location_t const&, tree_code, int, tree_node*,
tree_node*, tree_node*, tree_node**, int)
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/call.c:6520
0x7a563a build_x_binary_op(op_location_t const&, tree_code, tree_node*,
tree_code, tree_node*, tree_code, tree_node**, int)
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/typeck.c:4245
0x70c7ad cp_parser_binary_expression
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/parser.c:9650
0x70d575 cp_parser_assignment_expression
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/parser.c:9785
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions
```

[Bug fortran/93158] Coarray ICE when module and submodule are in separate files

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu.org,
   ||pault at gcc dot gnu.org

--- Comment #1 from Tobias Burnus  ---
The ICE occurs when invoking gfc_get_derived_type with codimen==1 and

(gdb) p derived->name
$11 = 0x778f76e0 "__vtype_surfaces_interface_Package"

(gdb) p c->name
$14 = 0x778e1710 "_extends"

as token == NULL for:
  snprintf (caf_name, GFC_MAX_SYMBOL_LEN, "_caf_%s", c->name);
  token = gfc_find_component (derived, caf_name, true, true, NULL);
  gcc_assert (token);

However, if one puts everything into a single file: while gfc_get_derived_type
gets invoked for __vtype_surfaces_interface_Package more than once, it never
gets invoked (for those) with 'codimen=1'. (It does so only for surfaces and
__class_surfaces_interface_Package_a).


In the ICE case, one has in the same function (gfc_get_derived_type) the code:

  if ((!c->attr.pointer && !c->attr.proc_pointer
  && !same_alloc_type)
  || c->ts.u.derived->backend_decl == NULL)
{
  int local_codim = c->attr.codimension ? c->as->corank: codimen;
  c->ts.u.derived->backend_decl = gfc_get_derived_type
(c->ts.u.derived,
local_codim);
}

where derived->name == __class_surfaces_interface_Package_a and c->name ==
'_vptr' – local_codim is 1 as the argument 'codim' is 1.


 * * *

The following patch – which more looks like a band aid – fixes the compilation:

diff --git a/gcc/fortran/trans-types.c b/gcc/fortran/trans-types.c
index 0a749d6e0a0..062fdf3608e 100644
--- a/gcc/fortran/trans-types.c
+++ b/gcc/fortran/trans-types.c
@@ -2667,6 +2667,8 @@ gfc_get_derived_type (gfc_symbol * derived, int codimen)
  || c->ts.u.derived->backend_decl == NULL)
{
  int local_codim = c->attr.codimension ? c->as->corank: codimen;
+ if (derived->attr.is_class && strcmp (c->name, "_vptr") == 0)
+   local_codim = 0;
  c->ts.u.derived->backend_decl = gfc_get_derived_type
(c->ts.u.derived,
local_codim);
}

 * * *

The code was added at this location with commit r256065 on 2018-01-01 for PR
83076. I think before it did not ICE, but I don't think it was right, either.

[Bug c++/93143] [10 Regression] Multiple calls to static constexpr member function gives wrong code

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org
 Blocks||55004

--- Comment #3 from Martin Sebor  ---
Bisection points to r272126:

Reduce unsharing in constexpr call evaluation.

* constexpr.c (unshare_constructor): Only unshare if T is itself a
CONSTRUCTOR.
(cxx_eval_call_expression): Don't call it on the result here.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55004
[Bug 55004] [meta-bug] constexpr issues

[Bug c++/93143] [10 Regression] Multiple calls to static constexpr member function gives wrong code

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-01-07
 CC||msebor at gcc dot gnu.org
  Known to work||9.2.0
 Ever confirmed|0   |1
  Known to fail||10.0

--- Comment #2 from Martin Sebor  ---
Confirmed with today's top of trunk.  A smaller test case is below.  The
original dump looks correct but the Gimple dump is not.  The store to a.a[0] is
missing from foobar(). 

$ cat pr93143.C && gcc -O2 -S -Wall -fdump-tree-gimple=/dev/stdout pr93143.C
struct A { char a[2]; };

static constexpr A foo () { return A{1}; }

void bar ()
{
  A a = foo ();
  if (a.a[0] != 1)
__builtin_abort(); 
}

void foobar ()
{
  A a = foo ();
  if (a.a[0] != 1)
__builtin_abort(); 
}
bar ()
{
  struct A a;

  try
{
  a = {};
  a.a[0] = 1;
  _1 = a.a[0];
  if (_1 != 1) goto ; else goto ;
  :
  __builtin_abort ();
  :
}
  finally
{
  a = {CLOBBER};
}
}


foobar ()
{
  struct A a;

  try
{
  a = {};
  _1 = a.a[0];
  if (_1 != 1) goto ; else goto ;
  :
  __builtin_abort ();
  :
}
  finally
{
  a = {CLOBBER};
}
}

[Bug libfortran/90374] Fortran 2018: Support d0.d, e0.d, es0.d, en0.d, g0.d and ew.d e0 edit descriptors for output

[thenlich+gccbug at gmail dot com]

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

--- Comment #26 from Thomas Henlich  ---
I must admit that the following F2018 clause invalidates my previous comment,
because it applies to G editing specifically (but not to E editing)


13.7.5.2.2 Generalized real and complex editing
...
3 When used to specify the output of real or complex data ..., the G0 and G0.d
edit descriptors follow the rules for the Gw.dEe edit descriptor, except that
any leading or trailing blanks are removed. Reasonable processor-dependent
values of w, d (if not specified), and e are used with each output value.

[Bug web/93185] Support git commits as a link in bugzilla entries

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||rearnsha at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
Plus we need to decide what exactly will go into gcc-cvs mails and into
bugzilla (I think right now the body is the same for both).
For the monotonically increasing trunk and release branch commits, we could use
special tags (tag the trunk whenever we branch off a release branch with some
uniquely named tags that would include the upcoming gcc major version and then
git describe --all --match 'r[0-9]*' ... | sed ...
to convert a git commit into say a rNN- syntax that we could handle in
http://gcc.gnu.org/rNN- redirects too and mention in the git-cvs/bugzilla.
E.g. r10-1234 would be 1234th trunk commit in gcc 10 (i.e. since gcc 9 branched
off), r11-2 2nd trunk commit after gcc 10 branched off.
My primary reason for this is bisect seed, with monotonically increasing such
numbers it will still allow by hand bisection which is impossible with git
hashes, but e.g. for gcc -v it could be shorter too, and we could have git
aliases to convert in both directions (if it is possible to write it, my git-fu
is very limited).

[Bug web/93185] New: Support git commits as a link in bugzilla entries

[marxin at gcc dot gnu.org]

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

Bug ID: 93185
   Summary: Support git commits as a link in bugzilla entries
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: web
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: LpSolit at gmail dot com
  Target Milestone: ---

Once we'll switch to git, it would be handy to refer in bugzilla to git commits
with their corresponding hashes. Similarly to currently existing r123456.

[Bug libfortran/90374] Fortran 2018: Support d0.d, e0.d, es0.d, en0.d, g0.d and ew.d e0 edit descriptors for output

[thenlich+gccbug at gmail dot com]

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

--- Comment #25 from Thomas Henlich  ---
On second thoughts, I change my mind to:

c) the same output as G0.10 editing ("0.10E+1235") because there is no
need to do it differently for E editing.

[Bug rtl-optimization/93184] Incorrect result of right shift bit operation if compile-time constant shift amount exceeds type width

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
(In reply to Wojciech Migda from comment #2)
> Should there be at least a warning in case when the shift amount is a
> compile-time known constant?

There is a warning, but only when it is a constant in the FEs, in your testcase
it needs to be inlined first to turn it into a compile time constant.
For that case, the only thing the compiler offers is the runtime
instrumentation (compile/link with -fsanitize=undefined (etc.), you'll get
runtime errors about it.

[Bug rtl-optimization/93184] Incorrect result of right shift bit operation if compile-time constant shift amount exceeds type width

[ktkachov at gcc dot gnu.org]

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

--- Comment #4 from ktkachov at gcc dot gnu.org ---
(In reply to Wojciech Migda from comment #2)
> Should there be at least a warning in case when the shift amount is a
> compile-time known constant?

In an ideal world yes. Howevever, most such warnings are done before any
optimisations are done. To detect this case the compiler would need to inline
mask into pub and do the constant propagation to figure out the bogus shift
count.

The compiler does warn about a more direct use of a negative shift count e.g.:
static
unsigned long long mask(const unsigned long long sz)
{
auto const rv = (unsigned long long)-1 >> (8 - 9) * 8;
return rv;
}

[Bug rtl-optimization/93184] Incorrect result of right shift bit operation if compile-time constant shift amount exceeds type width

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Shifts by negative values or larger or equal to the bitsize are undefined
behavior.  Once you invoke undefined behavior in a program, there is no
discussion about what is correct and what is incorrect, the only incorrect
thing is the program that lead to the undefined behavior, any behavior at that
point is fine.

[Bug rtl-optimization/93184] Incorrect result of right shift bit operation if compile-time constant shift amount exceeds type width

[wojtek.golf at interia dot pl]

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

--- Comment #2 from Wojciech Migda  ---
Should there be at least a warning in case when the shift amount is a
compile-time known constant?

[Bug rtl-optimization/93184] Incorrect result of right shift bit operation if compile-time constant shift amount exceeds type width

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #1 from ktkachov at gcc dot gnu.org ---
Shift by a negative amount or larger than the type width is undefined behaviour
in C (I think C++ as well). There are no guarantees on the results of that
program.

[Bug rtl-optimization/93184] New: Incorrect result of right shift bit operation if compile-time constant shift amount exceeds type width

[wojtek.golf at interia dot pl]

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

Bug ID: 93184
   Summary: Incorrect result of right shift bit operation if
compile-time constant shift amount exceeds type width
   Product: gcc
   Version: 7.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wojtek.golf at interia dot pl
  Target Milestone: ---

GCC version: 7.4.0 (but seen in other versions as well, including trunk on
godbolt)
System: Ubuntu 18.04 LTS, godbolt online compiler, coliru online compiler
GCC build: stock version supplied with Ubuntu or either of the online compilers
mentioned
Command line: g++ -std=c++1z -O2 -Wall -Wextra main.cpp && ./a.out
Compiler output: nothing wrong with it

static
unsigned long long mask(const unsigned long long sz)
{
auto const rv = (unsigned long long)-1 >> (8 - sz) * 8;
return rv;
}

void pub(unsigned long long & out1, unsigned long long & out2, unsigned long
long const sz)
{
auto const first = mask(9);
out1 = first;

auto const second = mask(sz); // sz equals 9 at runtime
out2 = second;
}

Problem description:
There is a difference in the result of bit right shift operation applied to an
all-1s 64-bit unsigned integer when the code is generated based on the shift
amount that is derived from either a compile-time constant expression or a
runtime value.

The problem appears only when optimization leval is > 0;

Example on godbolt: https://godbolt.org/z/nENczm
Example on coliru: http://coliru.stacked-crooked.com/a/857711a4a7cf8416

When the shift amount is derived from a compile time constant the result of the
shift generated by the compiler is 0, which is different from the one that the
machine code generated for the runtime shift amount calculates.

For the code above executed program (see coliru example) for -O0 gives correct
output:

255
255

When optimization is enabled the output (incorrect) is

0
255

[Bug libfortran/90374] Fortran 2018: Support d0.d, e0.d, es0.d, en0.d, g0.d and ew.d e0 edit descriptors for output

[thenlich+gccbug at gmail dot com]

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

--- Comment #24 from Thomas Henlich  ---
There is another issue with E0.d editing, concerning the case |exp| ≥ 1000 with
extended and quad precision.

In addition to tables 13.1 ... 13.3, the standard says:


13.7.2 Numeric editing
13.7.2.1 General rules
...
(5) On output, if an exponent exceeds its specified or implied width using the
E, EN, ES, EX, D, or G edit descriptor, or the number of characters produced
exceeds the field width, the processor shall fill the entire field of width w
with asterisks. However, the processor shall not produce asterisks if the field
width is not exceeded when optional characters are omitted.

(6) On output, with I, B, O, Z, D, E, EN, ES, EX, F, and G editing, the
specified value of the field width w may be zero. In such cases, the processor
selects the smallest positive actual field width that does not result in a
field filled with asterisks. The specified value of w shall not be zero on
input.


Example:

Should the following code
write(*, "(e0.10)")  1e1234_10
result in 

a) a field filled with asterisks because 13.7.2.1(5) applies, and if so, how
many?

b) the same output as E0.10E4 editing ("0.10E+1234") because
13.7.2.1(6) applies

In my opinion, it should be a), with a field width corresponding to the width
of the field corresponding to the smallest width required for the mantissa plus
4 for the implied exponent width.

[Bug c++/93143] [10 Regression] Multiple calls to static constexpr member function gives wrong code

[larsbj at gullik dot net]

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

--- Comment #1 from Lars Gullik Bjønnes  ---
Forgot to mention that it works nicely with GCC 9.

[Bug target/93183] SVE does not use neg as conditional

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Blocks||26163, 53947
Summary|SVE only makes the last |SVE does not use neg as
   |thing conditional with  |conditional
   |ifconversion|

--- Comment #1 from Andrew Pinski  ---
Actually it looks more like conditional neg does not work.
Take:
typedef unsigned char uint8_t;

static inline uint8_t x264_clip_uint8( uint8_t x )
{
  uint8_t t = -x;
  uint8_t t1 = x&(~63);
  return t1 ? t : x;
}


void mc_weight( uint8_t *__restrict dst, uint8_t *__restrict src, int n)
{
for( int x = 0; x < n*16; x++ )
dst[x] = x264_clip_uint8(src[x]);
}
--- CUT ---
We get:
.L3:
ld1bz0.b, p0/z, [x1, x3]
movprfx z2, z0
and z2.b, z2.b, #0xc0
neg z1.b, p1/m, z0.b  ;;;  THIS
cmpeq   p2.b, p1/z, z2.b, #0
sel z0.b, p2, z0.b, z1.b   AND THIS
st1bz0.b, p0, [x0, x3]
incbx3
whilelo p0.b, w3, w2
b.any   .L3

The two instructions marked should be combined.

NOTE this does show up in real code in SPEC CPU, see PR 92492.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
[Bug 26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
[Bug 53947] [meta-bug] vectorizer missed-optimizations

[Bug debug/92983] [8/9/10 Regression] Debug info regression since PR87428 changes

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
Isn't the issue that we say the split function parts are actually the original
function?  If the tail were artificial there shouldn't be two breakpoints
but still a correct inlined subroutine (of an artificial function)?  Similar
issues exist for clones where the signature doesn't really match reality
and which we should represent as artificial functions with an inlined
(with constant / optimized away params) copy of the original function.

That is, tree_function_versioning sets DECL_ABSTRACT_ORIGIN

#0  tree_function_versioning (
old_decl=, 
new_decl=, 
tree_map=0x0, param_adjustments=0x346e090, update_clones=false, 
blocks_to_copy=0x340a748, new_entry=)
at /tmp/trunk2/gcc/tree-inline.c:6130
#1  0x00b48a03 in cgraph_node::create_version_clone_with_body (
this=, 
redirect_callers=..., tree_map=0x0, param_adjustments=0x346e090, 
bbs_to_copy=0x340a748, new_entry_block=, 
suffix=0x2ba39b5 "part", target_attributes=)
at /tmp/trunk2/gcc/cgraphclones.c:1037
#2  0x021540a7 in split_function (
return_bb=, 
split_point=0x335da40 , add_tsan_func_exit=false)

now, when changing DECL_ABSTRACT_ORIGIN to NULL we later ICE when cloning
this node for ISRA because tree_function_versioning does

6122  /* Output the inlining info for this abstract function, since it has
been
6123 inlined.  If we don't do this now, we can lose the information
about the
6124 variables in the function when the blocks get blown away as soon
as we
6125 remove the cgraph node.  */
6126  (*debug_hooks->outlining_inline_function) (old_decl);

but the old_decl is DECL_ARTIFICIAL and it didn't have early dwarf generated
(but what for anyways?).  I guess we want the actual outlined BLOCKs to
have an abstract origin to the original functions copy?  But clearly not
the decl itself.  I'm hesitant to set DECL_IGNORED_P on it but that avoids
the ICEing.  The debug info then looks sane though - can you verify?

Index: gcc/ipa-split.c
===
--- gcc/ipa-split.c (revision 279944)
+++ gcc/ipa-split.c (working copy)
@@ -1358,6 +1358,9 @@ split_function (basic_block return_bb, c
  split_point->split_bbs, split_point->entry_bb, "part");
   delete adjustments;
   node->split_part = true;
+  /* Do not pretend the tail is a representation of the actual function.  */
+  DECL_ABSTRACT_ORIGIN (node->decl) = NULL_TREE;
+  DECL_IGNORED_P (node->decl) = 1;

   if (cur_node->same_comdat_group)
 {

[Bug target/93183] New: SVE only makes the last thing conditional with ifconversion

[pinskia at gcc dot gnu.org]

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

Bug ID: 93183
   Summary: SVE only makes the last thing conditional with
ifconversion
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: enhancement
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---
Target: aarch64-linux-gnu

Take:
typedef unsigned char uint8_t;

static inline uint8_t x264_clip_uint8( uint8_t x )
{
  uint8_t t = -x;
  t = t>>7;
  uint8_t t1 = x&(~63);
  return t1 ? t : x;
}


void mc_weight( uint8_t *__restrict dst, uint8_t *__restrict src, int n)
{
for( int x = 0; x < n*16; x++ )
dst[x] = x264_clip_uint8(src[x]);
}

 CUT 
Currently (with -O3 -mcpu=generic+sve), we get for the inner loop:
.L3:
ld1bz0.b, p0/z, [x1, x3]
movprfx z2, z0
and z2.b, z2.b, #0xc0
neg z1.b, p1/m, z0.b
cmpne   p2.b, p1/z, z2.b, #0
movprfx z0.b, p2/m, z1.b
lsr z0.b, p2/m, z0.b, #7
st1bz0.b, p0, [x0, x3]
incbx3
whilelo p0.b, w3, w2
b.any   .L3

--- CUT ---
But we should be able to do:
.L3:
ld1bz0.b, p0/z, [x1, x3]
and z2.b, z0.b, #0xc0
cmpne   p2.b, p1/z, z2.b, #0 ;;; << I think p1/z here really should be
p0/z also
neg z0.b, p2/m, z0.b ;;; <<< This one should be conditional
lsr z0.b, p2/m, z0.b, #7
st1bz0.b, p0, [x0, x3]
incbx3
whilelo p0.b, w3, w2
b.any   .L3

[Bug middle-end/92492] Missed optimization in detecting unneeded widening conversions.

[pinskia at gcc dot gnu.org]

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

--- Comment #4 from Andrew Pinski  ---
If we change x264_clip_uint8 slightly to:

static inline uint8_t x264_clip_uint8( uint8_t x )
{
  uint8_t t = -x;
  t = t>>7;
  uint8_t t1 = x&(~63);
  return t1 ? t : x;
}


GCC does the "right" thing.

This is all type demontion going on.

[Bug tree-optimization/93156] abused nonnull attribute evokes new segfault in gcc 10 since Nov 4 commit, 0fb958ab8aa

[jakub at gcc dot gnu.org]

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

--- Comment #11 from Jakub Jelinek  ---
Author: jakub
Date: Tue Jan  7 10:05:14 2020
New Revision: 279951

URL: https://gcc.gnu.org/viewcvs?rev=279951=gcc=rev
Log:
PR tree-optimization/93156
* tree-ssa-ccp.c (bit_value_binop): For x * x note that the second
least significant bit is always clear.

* gcc.dg/tree-ssa/pr93156.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr93156.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-ccp.c

[Bug middle-end/92492] Missed optimization in detecting unneeded widening conversions.

[tnfchris at gcc dot gnu.org]

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

Tamar Christina  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  
|anton.youdkevitch@bell-sw.c
   ||om

[Bug tree-optimization/93118] >>32<<32 is not always converted into &~0ffffffffull at the tree level

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Tue Jan  7 10:03:07 2020
New Revision: 279950

URL: https://gcc.gnu.org/viewcvs?rev=279950=gcc=rev
Log:
PR tree-optimization/93118
* match.pd ((x >> c) << c -> x & (-1<

[Bug target/93005] Redundant NEON loads/stores from stack are not eliminated

[rearnsha at gcc dot gnu.org]

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

--- Comment #8 from Richard Earnshaw  ---
(In reply to Joel Holdsworth from comment #7)
> > Did you test it with big-endian?
> 
> Good question. It seems to do the right thing in both cases:
> https://godbolt.org/z/7rDzAm

foo2(long*, __simd128_int32_t):
vst1.64 {d0-d1}, [r0:64]
bx  lr

Well for big-endian that is wrong.  You've got a vector of 32-bit elements but
you're storing it as 64-bit elements, so when you look in memory you'll find
the elements permuted.

[Bug tree-optimization/93134] [graphite] ICE: Segmentation fault in ISL

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Biener  ---
Looking at ISL 0.2[01] they did

__isl_give isl_basic_set *isl_basic_map_underlying_set(
__isl_take isl_basic_map *bmap)
{
if (!bmap)
goto error;
if (bmap->dim->nparam == 0 && bmap->dim->n_in == 0 &&
bmap->n_div == 0 &&
!isl_space_is_named_or_nested(bmap->dim, isl_dim_in) &&
!isl_space_is_named_or_nested(bmap->dim, isl_dim_out))
return bset_from_bmap(bmap);
bmap = isl_basic_map_cow(bmap);
if (!bmap)
goto error;

[Bug ipa/83411] function multiversioning should clone the entire sub-callgraph

[marxin at gcc dot gnu.org]

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

--- Comment #7 from Martin Liška  ---
Author: marxin
Date: Tue Jan  7 09:18:46 2020
New Revision: 279948

URL: https://gcc.gnu.org/viewcvs?rev=279948=gcc=rev
Log:
Document cloning for the target_clone attribute.

2020-01-07  Martin Liska  

PR ipa/83411
* doc/extend.texi: Explain cloning for target_clone
attribute.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/doc/extend.texi

[Bug tree-optimization/92860] [8/9/10 regression] Global flags affected by -O settings are clobbered by optimize attribute

[marxin at gcc dot gnu.org]

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

--- Comment #12 from Martin Liška  ---
Author: marxin
Date: Tue Jan  7 09:15:38 2020
New Revision: 279947

URL: https://gcc.gnu.org/viewcvs?rev=279947=gcc=rev
Log:
Make warn_inline Optimization option.

2020-01-07  Martin Liska  

PR tree-optimization/92860
* common.opt: Make in Optimization option
as it is affected by -O0, which is an Optimization
option.
* tree-inline.c (tree_inlinable_function_p):
Use opt_for_fn for warn_inline.
(expand_call_inline): Likewise.
2020-01-07  Martin Liska  

PR tree-optimization/92860
* gcc.dg/pr92860-2.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr92860-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/common.opt
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-inline.c

[Bug tree-optimization/92860] [8/9/10 regression] Global flags affected by -O settings are clobbered by optimize attribute

[marxin at gcc dot gnu.org]

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

--- Comment #11 from Martin Liška  ---
Author: marxin
Date: Tue Jan  7 09:10:37 2020
New Revision: 279945

URL: https://gcc.gnu.org/viewcvs?rev=279945=gcc=rev
Log:
Mark param_min_crossjump_insns with Optimization keyword.

2020-01-07  Martin Liska  

PR optimization/92860
* params.opt: Mark param_min_crossjump_insns with Optimization
keyword.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/params.opt

[Bug tree-optimization/93134] [graphite] ICE: Segmentation fault in ISL

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener  ---
I've tried to notify ISL folks via the isl-development google group,
bugzilla doesn't like the URL though,
https://groups.google.com/forum/#!topic/isl-development/kgt5RxawS_Q

[Bug tree-optimization/93134] [graphite] ICE: Segmentation fault in ISL

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
But, confirmed.  With in-tree ISL:

rogram received signal SIGSEGV, Segmentation fault.
0x02447d44 in isl_basic_map_underlying_set (bmap=0x0)
at /tmp/trunk/isl/isl_map.c:5515
5515space = isl_space_underlying(space, bmap->n_div);
(gdb) bt
#0  0x02447d44 in isl_basic_map_underlying_set (bmap=0x0)
at /tmp/trunk/isl/isl_map.c:5515
#1  0x023f0fc0 in equalities_in_underlying_set (bmap=0x3779510)
at /tmp/trunk/isl/isl_affine_hull.c:860
#2  0x023f11ba in isl_basic_map_detect_equalities (bmap=0x3779510)
at /tmp/trunk/isl/isl_affine_hull.c:919
#3  0x023f1374 in isl_basic_set_detect_equalities (bset=0x3779510)
at /tmp/trunk/isl/isl_affine_hull.c:952
#4  0x02465c0a in uset_gist (bset=0x0, context=0x3779510)
at /tmp/trunk/isl/isl_map_simplify.c:2702
#5  0x02466a13 in isl_basic_map_gist (bmap=0x3836370, 
context=0x38242f0) at /tmp/trunk/isl/isl_map_simplify.c:3176
#6  0x02466cd9 in isl_map_gist_basic_map (map=0x37f56e0, 
context=0x3929240) at /tmp/trunk/isl/isl_map_simplify.c:3234
#7  0x024677d5 in map_gist (map=0x38118f0, context=0x38dc310)
at /tmp/trunk/isl/isl_map_simplify.c:3601
#8  0x0243d9b7 in isl_map_align_params_map_map_and (map1=0x38118f0, 
map2=0x38dc310, fn=0x24675f3 ) at /tmp/trunk/isl/isl_map.c:1531
#9  0x0246782b in isl_map_gist (map=0x38118f0, context=0x38dc310)
at /tmp/trunk/isl/isl_map_simplify.c:3611
#10 0x02467a09 in isl_map_gist_domain (map=0x38118f0, 
context=0x377ec30) at /tmp/trunk/isl/isl_map_simplify.c:3661
#11 0x024f256b in bin_add_pair (res=0x37b2cc0, map1=0x38118f0, 
#12 0x024f27f7 in gen_bin_entry (entry=0x377f478, user=0x7fffd5c0)
at /tmp/trunk/isl/isl_union_map.c:957
#13 0x0242a86a in isl_hash_table_foreach (ctx=0x37597e0, 
table=0x3780a90, fn=0x24f2742 , user=0x7fffd5c0)
at /tmp/trunk/isl/isl_hash.c:207
#14 0x024f28f1 in gen_bin_op (umap1=0x3780a80, umap2=0x378cc60, 
control=0x7fffd610) at /tmp/trunk/isl/isl_union_map.c:982
#15 0x024f34d5 in union_map_gist_domain (umap=0x3780a80, 
uset=0x378cc60) at /tmp/trunk/isl/isl_union_map.c:1390
#16 0x024f351f in isl_union_map_gist_domain (umap=0x3780a80, 
uset=0x378cc60) at /tmp/trunk/isl/isl_union_map.c:1403
#17 0x02142e2b in optimize_isl (scop=0x36458d0)
at /tmp/trunk/gcc/graphite-optimize-isl.c:128
#18 0x02143307 in apply_poly_transforms (scop=0x36458d0)
at /tmp/trunk/gcc/graphite-optimize-isl.c:211

looks like isl_basic_map_cow can return NULL but the code doesn't check that:

Breakpoint 5, isl_basic_map_underlying_set (bmap=0x376f1b0)
at /tmp/trunk/isl/isl_map.c:5513
5513bmap = isl_basic_map_cow(bmap);
(gdb) l
5508if (bmap->dim->nparam == 0 && bmap->dim->n_in == 0 &&
5509bmap->n_div == 0 &&
5510!isl_space_is_named_or_nested(bmap->dim, isl_dim_in) &&
5511!isl_space_is_named_or_nested(bmap->dim, isl_dim_out))
5512return bset_from_bmap(bmap);
5513bmap = isl_basic_map_cow(bmap);
5514space = isl_basic_map_take_space(bmap);
5515space = isl_space_underlying(space, bmap->n_div);
5516bmap = isl_basic_map_restore_space(bmap, space);
5517if (!bmap)

it can return NULL via isl_basic_map_dup ending up with a NULL
dup from isl_basic_map_alloc_space.  We do

isl_basic_map_alloc_space (space=0x3a29240, extra=0, n_eq=0, n_ineq=22)

and isl_calloc_type fails via

101 if (isl_ctx_next_operation(ctx) < 0)
102 return NULL;

because ctx->max_operations && ctx->operations >= ctx->max_operations

so the segfault is clearly an ISL bug.

[Bug tree-optimization/93179] [10 Regression] ICE (segfault) in loop_depth on x86_64-linux-gnu

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2020-01-07
 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
With the mentioned revision I see a dup of PR93173:

$ g++ pr93179.cc -c -std=c++11 -Wall -Wextra -Wpedantic -O1
pr93179.cc: In member function ‘void DateFormatTest::TestNonGregoFmtParse()’:
pr93179.cc:38:6: error: incorrect sharing of tree nodes
   38 | void DateFormatTest::TestNonGregoFmtParse() {
  |  ^~
*D.2212
D.2212->caftItems = _zh_chinese_custU;
during GIMPLE pass: cfg
pr93179.cc:38:6: internal compiler error: verify_gimple failed
0x108b831 verify_gimple_in_cfg(function*, bool)
/home/marxin/Programming/gcc/gcc/tree-cfg.c:5445
0xf66c1f execute_function_todo
/home/marxin/Programming/gcc/gcc/passes.c:1983
0xf679ce execute_todo
/home/marxin/Programming/gcc/gcc/passes.c:2037
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug c++/93173] [10 Regression] "error: incorrect sharing of tree nodes" and "internal compiler error: verify_gimple failed"

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-01-07
 CC||jason at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
  Known to work||9.2.0
   Target Milestone|--- |10.0
Summary|"error: incorrect sharing   |[10 Regression] "error:
   |of tree nodes" and  |incorrect sharing of tree
   |"internal compiler error:   |nodes" and "internal
   |verify_gimple failed"   |compiler error:
   ||verify_gimple failed"
 Ever confirmed|0   |1
  Known to fail||10.0

--- Comment #1 from Martin Liška  ---
Confirmed, also started with r279576.

[Bug fortran/67202] Fortran FE should load scalar pass-by-reference intent-in arguments at the beginning of a function

[marxin at gcc dot gnu.org]

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

--- Comment #3 from Martin Liška  ---
@Thomas: Setting host to 67202 is probably a typo.

[Bug tree-optimization/93134] [graphite] ICE: Segmentation fault in ISL

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||grosser at gcc dot gnu.org

--- Comment #4 from Richard Biener  ---
Crashes in ISL are not easy to track down for me - we might present it with
garbage of course.

[Bug tree-optimization/92860] [8/9/10 regression] Global flags affected by -O settings are clobbered by optimize attribute

[rguenth at gcc dot gnu.org]

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

--- Comment #10 from Richard Biener  ---
(In reply to Jan Hubicka from comment #8)
> > @Richi:
> > 
> > About the param_max_fields_for_field_sensitive:
> > Do I understand it correctly that the param is used in IPA PTA for global
> > variables? If so, we can't easily use Optimization keyword as the param 
> > value
> > will not make sense to be different for different functions.
> There is global var use_field_sensitive which IMO needs to go but
> otherwise I think PTA should always analyze an assignment that is
> withing some function. So it can always query the OPTIMIZATION node of
> the function the statement lives in.

But it also affects global variables in IPA mode, and no, the effect doesn't
only materialize at stmts.  So for IPA the only thing we could do is
always use subfields for globals (but what max-fields-for-field-sensitive?)
and when analyzing stmts "pun" the fields.  And get rid of the
global use_field_sensitive flag and it's "optimization".  Ah, there's a FIXME
for globals with IPA PTA there.

That said, --param max-fields-for-field-sensitive is far from obvious to
make it per function (for IPA).  But mostly because of the effect for
'use_field_sensitive' which cannot be simply changed on/off if we actually
did end up with subfields for a variable.

I'd fear we introduce hard to track down correctness issues with "just"
flipping it to per-function.  Maybe splitting the param to a IPA and
non-IPA param works?  How do we handle other "true" IPA params considering
different TUs might be built with different settings of those as well?

> Honza

[Bug c++/92552] [10 Regression] internal compiler error: in lazily_declare_fn, at cp/method.c:3045 with -fconcepts

[gcc-bugs at marehr dot dialup.fu-berlin.de]

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

--- Comment #7 from gcc-bugs at marehr dot dialup.fu-berlin.de ---
Thank you!

[Bug tree-optimization/61502] == comparison on "one-past" pointer gives wrong result

[rguenth at gcc dot gnu.org]

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

--- Comment #38 from Richard Biener  ---
(In reply to Alexander Cherepanov from comment #37)
> On 30/12/2019 10.51, rguenther at suse dot de wrote:
> >> Obviously, it could be used to fold `a + i == b` to `0` if `a` and `b`
> >> are two different known arrays and `i` is unknown
> > 
> > That's indeed the main thing. Basically it allows points-to analysis work at
> > all in the presence of non-constant offsets.
> 
> But what is PTA used for? Examples that I've seen all deal with
> dereferenceable pointers. And current gcc behaviour is just fine in that
> case. The problem is with non-dereferenceable pointers. So is PTA important
> for cases where dereferenceability is unknown (or known to be false) or it's
> just too complicated to take dereferenceability into account?

points-to analysis doesn't care about whether a pointer is dereferenced or not
when computing its points-to set.  You can very well add a dereference to your
testcase and that shouldn't affect its outcome, no?

And yes, GCC uses points-to analysis results to optimize pointer equality
compares like p == q to false if the points-to sets do not intersect (for
a set of cases, but that's current implementation detail).  That helps
surprisingly often for abstraction coming from the C++ standard library
container iterators.

I do agree that we have bugs in GCC but AFAICS those come from conditional
equivalences being propagated and from the very old RTL alias analysis issue
involving base_alias_check.  Once we dealt with the latter I'm happily
exploring
fixes for the former - but the latter will happily nullify fixes of the former.

[Bug libfortran/90374] Fortran 2018: Support d0.d, e0.d, es0.d, en0.d, g0.d and ew.d e0 edit descriptors for output

[thenlich+gccbug at gmail dot com]

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

--- Comment #23 from Thomas Henlich  ---
(In reply to Jerry DeLisle from comment #21)
> Author: jvdelisle
> Date: Thu Jan  2 00:57:31 2020
> New Revision: 279828
> 
> URL: https://gcc.gnu.org/viewcvs?rev=279828=gcc=rev

Jerry, please note that the standard requires that the minimum exponent width
is only selected in case of Ew.dE0 editing (including E0.dE0), but not for E0.d
editing in general.

Your latest patch changes this behaviour.

See Table 13.1: E and D exponent forms

Edit  Absolute Value   Form of
Descriptorof Exponent  Exponent (1)

Ew.d  |exp| ≤ 99   E±z1z2 or ±0z1z2
  99 < |exp| ≤ 999 ±z1z2z3

Ew.d Ee with e > 0|exp| ≤ 10^e − 1 E±z1z2 . . . ze

Ew.d E0   any  E±z1z2 . . . zs

Dw.d  |exp| ≤ 99   D±z1z2 or E±z1z2
   or ±0z1z2
  99 < |exp| ≤ 999 ±z1z2z3

(1) where each z is a digit, and s is the minimum number of digits
required to represent the exponent.

[Bug rtl-optimization/49330] Integer arithmetic on addresses optimised with pointer arithmetic rules

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Blocks||93105

--- Comment #31 from Richard Biener  ---
*** Bug 93105 has been marked as a duplicate of this bug. ***


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93105
[Bug 93105] [8/9/10 Regression] Wrong optimization for pointers: provenance of
`p + (q1 - q2)` is treated as `q` when the provenance of `p` is unknown

[Bug rtl-optimization/93105] [8/9/10 Regression] Wrong optimization for pointers: provenance of `p + (q1 - q2)` is treated as `q` when the provenance of `p` is unknown

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Depends on||49330
 Resolution|--- |DUPLICATE

--- Comment #1 from Richard Biener  ---
It's actually the same as PR49330.  One of the reasons I've not even tried to
do major surgery on GIMPLE is that we can't seem to agree on a course of action
on the RTL blunder called find_base_term and base_alias_check which makes any
"fixing" on the GIMPLE side pointless.

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


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49330
[Bug 49330] Integer arithmetic on addresses optimised with pointer arithmetic
rules