[Bug ada/90325] New: GCC Error in gnat_to_gnu_entity using Unchecked_Conversion to a discriminated type in a Lock_Free protected type body

[matsilvabustos at abc dot gob.ar]

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

Bug ID: 90325
   Summary: GCC Error in gnat_to_gnu_entity using
Unchecked_Conversion to a discriminated type in a
Lock_Free protected type body
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: matsilvabustos at abc dot gob.ar
  Target Milestone: ---

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

A bugbox shows up with this particular scenario.
It also happens in version 7.3
Full example in attachment.

  type T
-- Any discriminant yields a gcc error in protected body PT
-- No discriminant: everything ok.
(i : Integer := 1)
  is ...;

  type R is record
a : T;
  end record;

  function To_Access_R is
new Ada.Unchecked_Conversion(...);

  -- GCC Error would happen if Lock_Free => True. 
  -- Otherwise it compiles successfully.

  protected type PT
 with Lock_Free => True
   is
 ...
   end PT;

   protected body PT is
 function h return T is
   begin

 -- Maybe this operation is incompatible with a Lock_Free
 -- protected type. Anyway, GCC should show a message instead of
 -- bugboxing.

 return To_Access_R (x) . a;
   end h;
 end PT;

+===GNAT BUG DETECTED==+
| 9.0.1 20190501 (prerelease) (x86_64-pc-linux-gnu) GCC error: |
| in gnat_to_gnu_entity, at ada/gcc-interface/decl.c:438   |
| Error detected at main.adb:30:36 |


+===GNAT BUG DETECTED==+
| 7.3.1 20180712 (Red Hat 7.3.1-6) (x86_64-redhat-linux) GCC error:|
| en gnat_to_gnu_entity, en ada/gcc-interface/decl.c:422   |
| Error detected at main.adb:30:36 |

[Bug c++/90324] New: Accessibility: nested enum defined outside of class

[alex at webprise dot net]

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

Bug ID: 90324
   Summary: Accessibility: nested enum defined outside of class
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: alex at webprise dot net
  Target Milestone: ---

Test case:

class C {
   enum E: int;
   typedef int T;
};

enum C::E: C::T {
   X, Y, Z = X,
};

Error messages:

:6:15: error: 'typedef int C::T' is private within this context

 enum C::E: C::T {

   ^

:3:16: note: declared private here

typedef int T;

^

:7:14: error: 'C::E X' is private within this context

X, Y, Z = X,

  ^

:7:4: note: declared private here

X, Y, Z = X,

^

Compiler options:
-pedantic -std=c++11
(but probably not relevant at all)

clang++ and icpc compile this just fine.

Version(s):
I can reproduce it with almost any version, starting from 4.9 up to trunk.

Relevant Standard wording (ISO/IEC 14882:2011, 11p6):
All access controls in Clause 11 affect the ability to access a class member
name from the declaration of a particular entity, including parts of the
declaration preceding the name of the entity being declared and, if the
entity is a class, the definitions of members of the class appearing outside
the class’s member-specification.

I believe that both issues (accessibility in the underlying type
specification and enumerator specifications) are related. Hence, I am
submitting this as a single issue.

Doubts: Is my test-case standard-compliant? Is this rather an obscure
part of ISO/IEC 14882:2011 (and subsequent specs)?

[Bug target/90323] New: ppc should convert equivalent sequences to vec_sel()

[slandden at gmail dot com]

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

Bug ID: 90323
   Summary: ppc should convert equivalent sequences to vec_sel()
   Product: gcc
   Version: 8.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: slandden at gmail dot com
  Target Milestone: ---

Something like this:

xi = xi & ~is_subnormal;
xi |= subnormal & is_subnormal;

should be converted to:

xi = sel_vec(xi, subnormal, is_subnormal);

[Bug libstdc++/90299] std::filesystem::absolute("") and std::filesystem::absolute("", ec) behave differently

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
Although that suggests I should report the error as errc::invalid_argument not
errc::no_such_file_or_directory.

[Bug libstdc++/90299] std::filesystem::absolute("") and std::filesystem::absolute("", ec) behave differently

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
And for the avoidance of doubt, the problem is not that !exists(p) (although
that is true) but that an empty path doesn't refer to any file system location.
absolute("does not exist") is not an error, but absolute("") is.

There is no absolute representation of the empty path, it's a category error.

[Bug libstdc++/90299] std::filesystem::absolute("") and std::filesystem::absolute("", ec) behave differently

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
I changed absolute("", ec) to return an error intentionally, and I think
absolute("") should also return an error.

The effects of the function are to "compose an absolute path referencing the
same file system location as p". When p is the empty path it does not reference
any file system location, and so the function cannot meet its postcondition,
and must report an error.

The bug is that r260441 only fixed the overload taking an error_code&
parameter.

[Bug c++/90322] Cannot deduce size of

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Resolution|FIXED   |INVALID

[Bug c++/88829] Failure to deduce size of array of 2^31 chars

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-05-02
 Ever confirmed|0   |1

[Bug libstdc++/90314] [10 Regression] clang gives error about exception specification in declaration not matching definition after change in move.h

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #5 from Jonathan Wakely  ---
Fixed.

[Bug c++/90322] New: Cannot deduce size of

[i.hamsa at gmail dot com]

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

Bug ID: 90322
   Summary: Cannot deduce size of
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: i.hamsa at gmail dot com
  Target Milestone: ---

[Bug c++/88829] Failure to deduce size of array of 2^31 chars

[i.hamsa at gmail dot com]

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

i.hamsa at gmail dot com changed:

   What|Removed |Added

 CC||i.hamsa at gmail dot com

--- Comment #1 from i.hamsa at gmail dot com ---
An easier reproduction is:

int a[1ULL << 31];
template T* foo(T()[N]) {return t;}
auto x = foo(a);

I've tried several versions of the compiler and the bug is in all of them.
Error messages are slightly different between versions.

6.4.0 and 7.3.0: error: overflow in constant expression
8.2.0 and 8.3.0: error: size of array is negative

[Bug c++/90322] Cannot deduce size of

[i.hamsa at gmail dot com]

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

i.hamsa at gmail dot com changed:

   What|Removed |Added

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

--- Comment #1 from i.hamsa at gmail dot com ---
Submitted by mistake, please ignore

[Bug target/87833] [9/10 Regression] -fPIC isn't used to create offload shared library

[hjl.tools at gmail dot com]

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

--- Comment #6 from H.J. Lu  ---
A patch is posted at

https://gcc.gnu.org/ml/gcc-patches/2019-05/msg00084.html

[Bug libstdc++/90314] [10 Regression] clang gives error about exception specification in declaration not matching definition after change in move.h

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
Author: redi
Date: Thu May  2 21:23:38 2019
New Revision: 270827

URL: https://gcc.gnu.org/viewcvs?rev=270827=gcc=rev
Log:
PR libstdc++/90314 fix non-equivalent declarations of std::swap

In order to use the _GLIBCXX_NOEXCEPT_IF macro for an expression
containing commas I enclosed it in parentheses, so the preprocessor
wouldn't treat it as two arguments to the function-like macro. Clang
gives an error because now the noexcept-specifier noexcept((C)) is not
equivalent to the noexcept(C) one on the declaration of swap in
.

Instead of requiring extra parentheses around the expression, redefine
_GLIBCXX_NOEXCEPT_IF as a variadic macro (even though supporting that in
C++98 is a GNU extension).

PR libstdc++/90314
* include/bits/c++config (_GLIBCXX_NOEXCEPT_IF): Use variadic macro.
* include/bits/move.h (swap): Remove extra parentheses.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/c++config
trunk/libstdc++-v3/include/bits/move.h

[Bug c++/90321] [C++17] GCC allows structured binding (decomposition) of an object of type derived from a closure type

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||accepts-invalid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-05-02
 Ever confirmed|0   |1

[Bug other/89863] [meta-bug] Issues that cppcheck finds that gcc misses

[pinskia at gcc dot gnu.org]

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

Bug 90298 Summary: libquadmath/math/catanhq.c:113: possibly redundant code ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90298

   What|Removed |Added

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

[Bug libquadmath/90298] libquadmath/math/catanhq.c:113: possibly redundant code ?

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #4 from Andrew Pinski  ---
den is a floating point type, so when comparing equal against 0, it will match
both 0 and -0.  So it is not redundant.

[Bug libstdc++/90314] [10 Regression] clang gives error about exception specification in declaration not matching definition after change in move.h

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
Specifically, a new warning with -Wpedantic -Wsystem-headers and one of
-std=gnu++98 or -std=c++98 or -ansi, but not with any later dialects.

The alternatives are to leave the macro as it is now (which is valid C++98) and
either

- require the double parentheses whenever it's used with an expression
containing commas and add the double parens to any other declarations (like the
one in ), or

- only use the macro for expressions without commas and revert to using #if for
swap in 


No other uses of it in the library today require the double parens, and very
few declarations of function templates appear in more than one place.

[Bug libstdc++/90314] [10 Regression] clang gives error about exception specification in declaration not matching definition after change in move.h

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

  Known to work||8.3.0, 9.0
   Target Milestone|--- |10.0
Summary|clang gives error about |[10 Regression] clang gives
   |exception specification in  |error about exception
   |declaration not matching|specification in
   |definition after change in  |declaration not matching
   |move.h  |definition after change in
   ||move.h
  Known to fail||10.0

--- Comment #2 from Jonathan Wakely  ---
This would fix it:

diff --git a/libstdc++-v3/include/bits/c++config
b/libstdc++-v3/include/bits/c++config
index 5016f4853de..ca1557af564 100644
--- a/libstdc++-v3/include/bits/c++config
+++ b/libstdc++-v3/include/bits/c++config
@@ -157,12 +157,12 @@
 #ifndef _GLIBCXX_NOEXCEPT
 # if __cplusplus >= 201103L
 #  define _GLIBCXX_NOEXCEPT noexcept
-#  define _GLIBCXX_NOEXCEPT_IF(_COND) noexcept(_COND)
+#  define _GLIBCXX_NOEXCEPT_IF(...) noexcept(__VA_ARGS__)
 #  define _GLIBCXX_USE_NOEXCEPT noexcept
 #  define _GLIBCXX_THROW(_EXC)
 # else
 #  define _GLIBCXX_NOEXCEPT
-#  define _GLIBCXX_NOEXCEPT_IF(_COND)
+#  define _GLIBCXX_NOEXCEPT_IF(...)
 #  define _GLIBCXX_USE_NOEXCEPT throw()
 #  define _GLIBCXX_THROW(_EXC) throw(_EXC)
 # endif
diff --git a/libstdc++-v3/include/bits/move.h
b/libstdc++-v3/include/bits/move.h
index 996078cfbce..7271e273e8e 100644
--- a/libstdc++-v3/include/bits/move.h
+++ b/libstdc++-v3/include/bits/move.h
@@ -183,8 +183,8 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 void
 #endif
 swap(_Tp& __a, _Tp& __b)
-_GLIBCXX_NOEXCEPT_IF((__and_,
-is_nothrow_move_assignable<_Tp>>::value))
+_GLIBCXX_NOEXCEPT_IF(__and_,
+   is_nothrow_move_assignable<_Tp>>::value)
 {
   // concept requirements
   __glibcxx_function_requires(_SGIAssignableConcept<_Tp>)


The downside is a new warning with -Wsystem-headers -Wpedantic:

/home/jwakely/gcc/10/include/c++/10.0.0/x86_64-pc-linux-gnu/bits/c++config.h:167:32:
warning: anonymous variadic macros were introduced in C++11 [-Wvariadic-macros]
  167 | #  define _GLIBCXX_NOEXCEPT_IF(...)
  |^~~

But we already have such a warning elsewhere anyway:

/home/jwakely/gcc/10/include/c++/10.0.0/bits/concept_check.h:48:37: warning:
anonymous variadic macros were introduced in C++11 [-Wvariadic-macros]
   48 | #define __glibcxx_function_requires(...)
  | ^~~

So I think we can live with the warning.

[Bug libquadmath/90298] libquadmath/math/catanhq.c:113: possibly redundant code ?

[joseph at codesourcery dot com]

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

--- Comment #3 from joseph at codesourcery dot com  ---
This is not redundant; the point is to convert -0 to +0.

Most of the libquadmath code is generated automatically from glibc sources 
by substitutions done by update-quadmath.py (and most of the rest *should* 
be generated by such substitutions, but isn't yet), so it isn't 
particularly useful to report coding style issues for it to GCC Bugzilla.

[Bug c++/90321] New: [C++17] GCC allows structured binding (decomposition) of an object of type derived from a closure type

[language.lawyer at gmail dot com]

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

Bug ID: 90321
   Summary: [C++17] GCC allows structured binding (decomposition)
of an object of type derived from a closure type
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: language.lawyer at gmail dot com
  Target Milestone: ---

The bug 78896 was fixed in r244909, so it is no longer possible to decompose a
closure itself, but deriving from a closure type makes it possible to access
closure members through an object of the derived type:


template struct hack : F { };
template hack(F) -> hack;

int main()
{
auto f = [x = 1, y = 2]() { };
// auto [a, b] = f; // error: cannot decompose lambda closure type
'main()::'
auto [a, b] = hack { f };

return b; // returns 2
}


https://wandbox.org/permlink/1ucU0A9vFyAI9yYh

[Bug c++/90320] New: Explicit constructor called implicitly

[mitza at ociweb dot com]

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

Bug ID: 90320
   Summary: Explicit constructor called implicitly
   Product: gcc
   Version: 8.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mitza at ociweb dot com
  Target Milestone: ---

May be related to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87605 but this
doesn't involve the ternary operator.

The following example instantiates and calls M::M(M&) on GCC 8.3 and trunk
(godbolt.org), clang and other compilers don't.

struct M {
  explicit M(int);
  template  explicit M(T&&);
  M& a();
};

struct V {
  V(M m);
};

void addV(const V&);

int main() {
  addV(M(1).a());
}

[Bug rtl-optimization/90319] [C++17] aggregate initialization of base: ICE in assign_temp

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #1 from Marek Polacek  ---
Started with r241187.

[Bug rtl-optimization/90319] [C++17] aggregate initialization of base: ICE in assign_temp

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-05-02
 Ever confirmed|0   |1
  Known to fail||10.0, 9.0

[Bug lto/87833] [9/10 Regression] -fPIC -fno-PIE don't work with LTO

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|WAITING |NEW
 CC||marxin at gcc dot gnu.org
  Component|target  |lto
Summary|[9/10 Regression] Intel MIC |[9/10 Regression] -fPIC
   |(emulated) offloading:  |-fno-PIE don't work with
   |"relocation [...] can not   |LTO
   |be used when making a   |
   |shared object; recompile|
   |with -fPIC" |

--- Comment #5 from H.J. Lu  ---
[hjl@gnu-cfl-1 pr87833]$ cat x.i
void open_fd(char *);

void init_ioctl_ctl() { open_fd(""); }
void get_ioctl_ops() {}
[hjl@gnu-cfl-1 pr87833]$ cat y.i
void get_ioctl_ops();
void a() {
get_ioctl_ops();
}
[hjl@gnu-cfl-1 pr87833]$ make
/export/build/gnu/tools-build/gcc-debug/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/tools-build/gcc-debug/build-x86_64-linux/gcc/ -O2 -fPIC -c
y.i
/export/build/gnu/tools-build/gcc-debug/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/tools-build/gcc-debug/build-x86_64-linux/gcc/ -O2 -fPIC -c
x.i
/export/build/gnu/tools-build/gcc-debug/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/tools-build/gcc-debug/build-x86_64-linux/gcc/ -o x.so y.o
x.o -shared -fPIC -fno-pie
[hjl@gnu-cfl-1 pr87833]$ make clean
rm -f *.o *.s foo bar *.[cCi].* x *.ii.* *.a
[hjl@gnu-cfl-1 pr87833]$ make LTO=1
/export/build/gnu/tools-build/gcc-debug/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/tools-build/gcc-debug/build-x86_64-linux/gcc/ -O2 -flto
-fPIC -c y.i
/export/build/gnu/tools-build/gcc-debug/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/tools-build/gcc-debug/build-x86_64-linux/gcc/ -O2 -flto
-fPIC -c x.i
/export/build/gnu/tools-build/gcc-debug/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/tools-build/gcc-debug/build-x86_64-linux/gcc/ -o x.so y.o
x.o -shared -fPIC -fno-pie
/usr/local/bin/ld: /tmp/x.so.LWF6nG.ltrans0.ltrans.o: relocation R_X86_64_32
against `.rodata.str1.1' can not be used when making a shared object; recompile
with -fPIC
/usr/local/bin/ld: final link failed: nonrepresentable section on output
collect2: error: ld returned 1 exit status
make: *** [Makefile:21: x.so] Error 1
[hjl@gnu-cfl-1 pr87833]$ 

-fPIC -fno-pie should turn off PIE/pie, not PIC/pic.

[Bug rtl-optimization/90319] New: [C++17] aggregate initialization of base: ICE in assign_temp

[language.lawyer at gmail dot com]

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

Bug ID: 90319
   Summary: [C++17] aggregate initialization of base: ICE in
assign_temp
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: language.lawyer at gmail dot com
  Target Milestone: ---

This bug is similar to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90254, but
here the base is movable.

The following code:

struct B
{
B() = default;
B(B&&) { /* user-provided */ };
};
struct D : B {};

B f() { return {}; }

D a { f() };

triggers ICE in GCC HEAD 10.0.0 2019.04.30 (also reproducible in 8.x.y, 7.z.w):

$ g++ prog.cc -Wall -Wextra -std=c++17 prog.cc

during RTL pass: expand
prog.cc: In function 'void __static_initialization_and_destruction_0(int,
int)':
prog.cc:10:11: internal compiler error: in assign_temp, at function.c:982
   10 | D a { f() };
  |   ^
0x596de0 assign_temp(tree_node*, int, int)
../../source/gcc/function.c:982
0x7b185f expand_call(tree_node*, rtx_def*, int)
../../source/gcc/calls.c:3459
0x8b0236 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../source/gcc/expr.c:11033
0x8bdc73 expand_normal
../../source/gcc/expr.h:285
0x8bdc73 store_field
../../source/gcc/expr.c:7022
0x8bb2d3 expand_assignment(tree_node*, tree_node*, bool)
../../source/gcc/expr.c:5296
0x7bd3d0 expand_call_stmt
../../source/gcc/cfgexpand.c:2722
0x7bd3d0 expand_gimple_stmt_1
../../source/gcc/cfgexpand.c:3691
0x7bd3d0 expand_gimple_stmt
../../source/gcc/cfgexpand.c:3850
0x7c20f7 expand_gimple_basic_block
../../source/gcc/cfgexpand.c:5886
0x7c448e execute
../../source/gcc/cfgexpand.c:6509
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

(https://wandbox.org/permlink/f8QAVgCtSajxfG3L)


! There is no ICE if a positive optimization level (-O1/2/3) is specified !

[Bug rtl-optimization/90310] [7/8/9/10 Regression] wrong code with -Os -fno-forward-propagate

[marxin at gcc dot gnu.org]

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

--- Comment #10 from Martin Liška  ---
(In reply to Jakub Jelinek from comment #9)
> Why?  Those actually proved to be very efficient way to test the backends by
> exposing details late and discovered many bugs in the backends where the RTL
> in the instructions actually didn't match what the HW is doing.  Without
> that e.g. the PR90311 bug, which is very different from this, wouldn't be
> discovered.

I definitely agree with Jakub. Zdenek has been providing very useful bug
reports for quite a long time, especially the wrong-code issues which are the
most beneficial for us. I do prefer having 5 duplicates than missing a
test-case that looks similar, but was ignored by reporter.

[Bug testsuite/90318] New: Non-constant test names in libphobos.shared

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

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

Bug ID: 90318
   Summary: Non-constant test names in libphobos.shared
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sch...@linux-m68k.org
CC: ibuclaw at gdcproject dot org
  Target Milestone: ---

Some tests in libphobos.shared include $srcdir in the test name (via the second
argument of dg-runtest), causing unnecessary variations during testresult
comparisons:

# Main loop.
dg-runtest "$srcdir/$subdir/link.d" "-I$srcdir/$subdir lib.so
-shared-libphobos" \
"$DEFAULT_DFLAGS"

dg-runtest "$srcdir/$subdir/link_linkdep.d" \
"-I$srcdir/$subdir liblinkdep.so lib.so -shared-libphobos" \
"$DEFAULT_DFLAGS"

dg-runtest "$srcdir/$subdir/link_loaddep.d" \
"-I$srcdir/$subdir libloaddep.so -shared-libphobos" "$DEFAULT_DFLAGS"

[Bug libstdc++/90314] clang gives error about exception specification in declaration not matching definition after change in move.h

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-05-02
Version|unknown |10.0
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
Also reported at https://gcc.gnu.org/ml/libstdc++/2019-05/msg8.html

I'm pretty sure clang is wrong, but I'll change our code anyway, for the reason
you give.

[Bug other/90315] [10 regression] help text (or test for help text) problem after r270788

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-05-02
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Lemme take a look.

[Bug fortran/90133] [7/8/9/10 Regression] Linker error from accessing event_type via use association outside associate/block scope

[zbeekman at gmail dot com]

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

--- Comment #6 from Zaak  ---
Oh, I see, so the *bug* has been backported... sigh. Well thanks for localizing
it to the range r243909-r244868.

I may try to do a bisection search to find the culprit and work up a
fix/patch... I haven't contributed to GCC before though, if I need to sign a
CLA, etc. please point me in the right direction.

[Bug target/90317] New: [7/8/9/10] ICE for arm sha1h and wrong optimisations on sha1h/c/m/p

[syl.nktaylor at gmail dot com]

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

Bug ID: 90317
   Summary: [7/8/9/10] ICE for arm sha1h and wrong optimisations
on sha1h/c/m/p
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: syl.nktaylor at gmail dot com
  Target Milestone: ---

Target: arm-none-linux-gnueabihf | Neon intrinsics for sha1

Bug 1 (affects gcc versions 8 and above)

Description: calling vsha1h_u32 will throw an ICE; incompatible mode used for
zero_extend in the sha1h RTL pattern

testcase.c:

#include "arm_neon.h"

uint32_t foo (uint32_t val) 
{
   return vsha1h_u32 (val);
}

Error:

arm-none-linux-gnueabihf-gcc -mfpu=crypto-neon-fp-armv8 -O2 testcase.c
during RTL pass: combine
testcase.c: In function ‘foo’:
testcase.c:6:1: internal compiler error: in as_a, at machmode.h:353
6 | }
  | ^
0x5ce064 as_a
/src/gcc/gcc/machmode.h:353
0x13d043b as_a
/src/gcc/gcc/combine.c:7403
0x13d043b expand_compound_operation
/src/gcc/gcc/combine.c:7360
0x13d7623 combine_simplify_rtx
/src/gcc/gcc/combine.c:6453
0x13d9d6a subst
/src/gcc/gcc/combine.c:5727
0x13d99e8 subst
/src/gcc/gcc/combine.c:5668
0x13dbe23 try_combine
/src/gcc/gcc/combine.c:3423
0x13e2048 combine_instructions
/src/gcc/gcc/combine.c:1306
0x13e2048 rest_of_handle_combine
/src/gcc/gcc/combine.c:15076
0x13e2048 execute
/src/gcc/gcc/combine.c:15121

---

Bug 2 (likely affects all gcc versions where sha1h/c/m/p was added, includes 7,
8, 9 and 10)

Testcase:

uint32_t foo (uint32x4_t val)
{
   return vsha1h_u32 (vgetq_lane_u32 (val, 3));
}

incorrectly generates

sha1h.32 q0, q0
vmov.32 r0, d0[0]

without doing a vec select first for the specified lane (with something like
vmov.32 r3, d1[1] & vdup.32 q0, r3).

The bug happens on sha1h, sha1c, sha1m and sha1p. Their current RTL patterns
trigger incorrect combine pass optimisations.

---

I have a patch which I'll publish upstream soon.

[Bug fortran/90133] [7/8/9/10 Regression] Linker error from accessing event_type via use association outside associate/block scope

[dominiq at lps dot ens.fr]

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

--- Comment #5 from Dominique d'Humieres  ---
> Sure, I understand regresion, but perhaps I don't understand what you mean
> by "has been backported to GCC6".

The patch which caused the GCC7 regression has then been applied to GCC6: 6.0.0
works, but not 6.5.0.

[Bug fortran/90133] [7/8/9/10 Regression] Linker error from accessing event_type via use association outside associate/block scope

[zbeekman at gmail dot com]

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

--- Comment #4 from Zaak  ---
Sure, I understand regresion, but perhaps I don't understand what you mean by
"has been backported to GCC6".

[Bug tree-optimization/90316] New: large compile time increase in opt / alias stmt walking for Go example

[thanm at google dot com]

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

Bug ID: 90316
   Summary: large compile time increase in opt / alias stmt
walking for Go example
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: thanm at google dot com
  Target Milestone: ---

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

The attached Go file when built with gccgo tip takes a very long time to
compile; I think the test case may be exposing some sort of non-linear behavior
in tree-pre.  Original problem was discovered with an application internal to
Google (in auto-generated code); the testcase I am submitting is hand-generated
but has the same control flow characteristics. 

The function of interest has no loops, but there is if-then-else control flow,
and there are about 9000 bbs. Compiling with GCC 7 takes about 11 seconds;
compiling with tip takes about 7 minutes (original Google testcase is larger
and takes about 45 minutes to compile).

Compile with: gccgo -c -O2 -g generated.go -o /tmp/gen.o

Profile from "pprof":

(pprof) top15
Showing nodes accounting for 381.91s, 96.34% of 396.42s total
Dropped 1064 nodes (cum <= 1.98s)
Showing top 15 nodes out of 50
  flat  flat%   sum%cum   cum%
84.13s 21.22% 21.22%202.04s 50.97%  et_splay
75.82s 19.13% 40.35% 80.73s 20.36%  dominated_by_p
52.73s 13.30% 53.65% 52.73s 13.30%  et_recomp_min (inline)
42.98s 10.84% 64.49%384.60s 97.02%  get_continuation_for_phi
41.95s 10.58% 75.07% 41.95s 10.58%  set_depth_add (inline)
29.52s  7.45% 82.52% 29.52s  7.45%  tree_check (inline)
19.98s  5.04% 87.56%223.37s 56.35%  et_below
10.32s  2.60% 90.16% 10.32s  2.60%  set_depth (inline)
 7.54s  1.90% 92.07%  7.54s  1.90%  set_prev (inline)
 6.73s  1.70% 93.76%  6.73s  1.70%  set_next (inline)
 4.93s  1.24% 95.01%  4.93s  1.24%  dom_convert_dir_to_idx (inline)
 3.06s  0.77% 95.78%  3.06s  0.77%  bitmap_list_find_element (inline)
 1.65s  0.42% 96.20%  3.20s  0.81%  gimple_vuse (inline)
 0.41s   0.1% 96.30%  4.32s  1.09%  insert_updated_phi_nodes_for
 0.16s  0.04% 96.34%384.15s 96.90%  maybe_skip_until (inline)

Top offenders include "maybe_skip_until" and "get_continuation_for_phi".

Time report:

Time variable   usr   sys  wall
  GGC
 phase parsing  :   0.15 (  0%)   0.01 (  3%)   0.15 (  0%)
   7482 kB ( 12%)
 phase opt and generate : 191.73 (100%)   0.37 ( 97%) 192.11 (100%)
  52645 kB ( 87%)
 phase last asm :   0.01 (  0%)   0.00 (  0%)   0.01 (  0%)
116 kB (  0%)
 garbage collection :   0.08 (  0%)   0.00 (  0%)   0.08 (  0%)
  0 kB (  0%)
 callgraph construction :   0.01 (  0%)   0.01 (  3%)   0.01 (  0%)
   6204 kB ( 10%)
 callgraph optimization :   0.00 (  0%)   0.00 (  0%)   0.03 (  0%)
  0 kB (  0%)
 ipa function summary   :   0.01 (  0%)   0.00 (  0%)   0.00 (  0%)
  1 kB (  0%)
 ipa dead code removal  :   0.01 (  0%)   0.01 (  3%)   0.02 (  0%)
  0 kB (  0%)
 ipa profile:   0.00 (  0%)   0.00 (  0%)   0.01 (  0%)
  0 kB (  0%)
 cfg construction   :   0.00 (  0%)   0.00 (  0%)   0.01 (  0%)
412 kB (  1%)
 cfg cleanup:   0.01 (  0%)   0.01 (  3%)   0.02 (  0%)
 56 kB (  0%)
 CFG verifier   :   0.22 (  0%)   0.01 (  3%)   0.26 (  0%)
  0 kB (  0%)
 trivially dead code:   0.02 (  0%)   0.00 (  0%)   0.03 (  0%)
  0 kB (  0%)
 df scan insns  :   0.02 (  0%)   0.01 (  3%)   0.02 (  0%)
  0 kB (  0%)
 df multiple defs   :   0.25 (  0%)   0.00 (  0%)   0.25 (  0%)
  0 kB (  0%)
 df reaching defs   :   0.09 (  0%)   0.01 (  3%)   0.08 (  0%)
  0 kB (  0%)
 df live regs   :   0.12 (  0%)   0.00 (  0%)   0.13 (  0%)
  0 kB (  0%)
 df live regs   :   0.06 (  0%)   0.00 (  0%)   0.07 (  0%)
  0 kB (  0%)
 df must-initialized regs   :   0.03 (  0%)   0.01 (  3%)   0.03 (  0%)
  0 kB (  0%)
 df use-def / def-use chains:   0.19 (  0%)   0.04 ( 11%)   0.25 (  0%)
  0 kB (  0%)
 df reg dead/unused notes   :   0.07 (  0%)   0.00 (  0%)   0.09 (  0%)
530 kB (  1%)
 register information   :   0.01 (  0%)   0.00 (  0%)   0.01 (  0%)
  0 kB (  0%)
 alias analysis :   0.01 (  0%)   0.00 (  0%)   0.02 (  0%)
   1408 kB (  2%)
 alias stmt walking : 184.44 ( 96%)   0.07 ( 18%) 184.51 ( 96%)
 37 kB (  0%)
 rebuild jump 

[Bug other/90315] New: [10 regression] help text (or test for help text) problem after r270788

[seurer at gcc dot gnu.org]

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

Bug ID: 90315
   Summary: [10 regression] help text (or test for help text)
problem after r270788
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

spawn -ignore SIGHUP /home/seurer/gcc/build/gcc-trunk/gcc/xgcc
-B/home/seurer/gcc/build/gcc-trunk/gcc/ test-105206.c
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never --help=params --help=optimizers -lm -o test-105206.x
The following options control optimizations:
  -O  Set optimization level to .
  -Ofast  Optimize for speed disregarding exact standards
compliance.
  -Og Optimize for debugging experience rather than
speed or size.
  -Os Optimize for space rather than speed.
  -faggressive-loop-optimizations Aggressively optimize loops using language
constraints.
  -falign-functions   Align the start of functions.
  -falign-functions=  This option lacks documentation.
  -falign-jumps   Align labels which are only reached by jumping.
  -falign-jumps=  This option lacks documentation.
  -falign-labels  Align all labels.
  -falign-labels= This option lacks documentation.
  -falign-loops   Align the start of loops.
  -falign-loops=  This option lacks documentation.
  -fassociative-math  Allow optimization for floating-point arithmetic
which may change the result of the operation due to rounding.
  -fassume-phsa   Assume we are finalizing for phsa and its
libhsail-rt.  Enables additional phsa-specific optimizations (default).
  -fasynchronous-unwind-tables Generate unwind tables that are exact at each
instruction boundary.
  -fauto-inc-dec  Generate auto-inc/dec instructions.
  -fbranch-count-reg  Replace add, compare, branch with branch on count
register.
  -fbranch-probabilities  Use profiling information for branch
probabilities.
  -fbranch-target-load-optimize Perform branch target load optimization before
prologue / epilogue threading.
  -fbranch-target-load-optimize2 Perform branch target load optimization after
prologue / epilogue threading.
  -fbtr-bb-exclusive  Restrict target load migration not to re-use
registers in any basic block.
  -fcaller-saves  Save registers around function calls.
  -fcode-hoisting Enable code hoisting.
  -fcombine-stack-adjustments Looks for opportunities to reduce stack
adjustments and stack references.
  -fcompare-elim  Perform comparison elimination after register
allocation has finished.
  -fconserve-stackDo not perform optimizations increasing
noticeably stack usage.
  -fcprop-registers   Perform a register copy-propagation optimization
pass.
  -fcrossjumping  Perform cross-jumping optimization.
  -fcse-follow-jumps  When running CSE, follow jumps to their targets.
  -fcx-fortran-rules  Complex multiplication and division follow
Fortran rules.
  -fcx-limited-range  Omit range reduction step when performing complex
division.
  -fdce   Use the RTL dead code elimination pass.
  -fdefer-pop Defer popping functions args from stack until
later.
  -fdelayed-branchAttempt to fill delay slots of branch
instructions.
  -fdelete-dead-exceptionsDelete dead instructions that may throw
exceptions.
  -fdelete-null-pointer-checks Delete useless null pointer checks.
  -fdevirtualize  Try to convert virtual calls to direct ones.
  -fdevirtualize-speculatively Perform speculative devirtualization.
  -fdse   Use the RTL dead store elimination pass.
  -fearly-inliningPerform early inlining.
  -fexceptionsEnable exception handling.
  -fexpensive-optimizations   Perform a number of minor, expensive
optimizations.
  -ffast-math This option lacks documentation.
  -ffinite-math-only  Assume no NaNs or infinities are generated.
  -ffloat-store   Don't allocate floats and doubles in
extended-precision registers.
  -fforward-propagate Perform a forward propagation pass on RTL.
  -ffp-contract=[off|on|fast] Perform floating-point expression contraction.
  -ffp-int-builtin-inexactAllow built-in functions ceil, floor, round,
trunc to raise "inexact" exceptions.
  -ffunction-cse  Allow function addresses to be held in registers.
  -fgcse  Perform global common subexpression elimination.
  -fgcse-after-reload Perform global common subexpression elimination
after register allocation has finished.
  

[Bug pch/90306] ICE when using precompiled headers with -MD and -fpch-deps

[psmith at gnu dot org]

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

--- Comment #2 from Paul Smith  ---
Yes that seems like it would definitely solve the ICE.

But then this bug report changes to say that the output of -fpch-deps is wrong
(it's empty when it shouldn't be) :p :).

That would potentially cause build failures as make will not be properly
rebuilding targets due to incorrect dependency lists.

The real question/bug is that the deps section of the PCH file is empty, or at
least not parsed during the PCH read.  Obviously, there ARE dependencies from
the PCH file so that should not be empty.

[Bug c++/90265] [9/10 Regression] ICE in build_call_a at gcc/cp/call.c:396 since r268377

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed|2019-04-26 00:00:00 |2019-05-02
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug rtl-optimization/90311] [9/10 Regression] wrong code with -O and __builtin_add_overflow() and compare

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
At least from other PRs, I think it is important to differentiate in what is
emitted/matched for the multi-word addition (generally that has been using CC_V
mode I think on ARM) vs. what is emitted/matched for multi-word subtraction
(which has been using CC_C mode I think).  In this PR, it seems to be a mix of
both.

[Bug c++/6945] A static constant that is initialize inline is not create if only a temperary is used

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
Author: redi
Date: Thu May  2 15:45:04 2019
New Revision: 270807

URL: https://gcc.gnu.org/viewcvs?rev=270807=gcc=rev
Log:
Improve API docs for  and 

* config/allocator/new_allocator_base.h (__allocator_base): Add
workaround for Doxygen bug #6945.
* include/std/memory: Improve docs. Define group for pointer safety.
* include/std/scoped_allocator: Improve docs. Use "undocumented"
conditional to suppress documentation for implementation details.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/config/allocator/new_allocator_base.h
trunk/libstdc++-v3/include/std/memory
trunk/libstdc++-v3/include/std/scoped_allocator

[Bug rtl-optimization/90310] [7/8/9/10 Regression] wrong code with -Os -fno-forward-propagate

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #9 from Jakub Jelinek  ---
Why?  Those actually proved to be very efficient way to test the backends by
exposing details late and discovered many bugs in the backends where the RTL in
the instructions actually didn't match what the HW is doing.  Without that e.g.
the PR90311 bug, which is very different from this, wouldn't be discovered.

[Bug libstdc++/90314] New: clang gives error about exception specification in declaration not matching definition after change in move.h

[peter.smith at linaro dot org]

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

Bug ID: 90314
   Summary: clang gives error about exception specification in
declaration not matching definition after change in
move.h
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: peter.smith at linaro dot org
  Target Milestone: ---

The following error message was found by a CI job that builds spec2k6 with
master clang, using a master gcc sysroot for the libraries. It can be
reproduced with the following source file:

#include 

void func(void) {
int a = 5, b = 3;
std::swap(a, b);
}

With a libcstd++ built including the change:
> commit 744a3010791fbd97718a3f51e9c9b2512f6d3f3e
> Author: redi 
> Date:   Mon Apr 29 13:25:38 2019 +
> 
>Use _GLIBCXX_NOEXCEPT_IF for std::swap
> 
>* include/bits/move.h (swap(T&, T&), swap(T (&)[N], T (&)[N])): Use
>_GLIBCXX_NOEXCEPT_IF to simplify declarations.
> 
>git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@270650 
> 138bc75d-0d04-0410-961f-82ee72b054a4

The error message I get is:
/work/gnu/gcc/install_gcc/include/c++/10.0.0/bits/move.h:185:5: error: 
  exception specification in declaration does not match previous
declaration
swap(_Tp& __a, _Tp& __b)
^
/work/gnu/gcc/install_gcc/include/c++/10.0.0/type_traits:2531:5: note: previous
  declaration is here
swap(_Tp&, _Tp&)
^

The error message unfortunately truncates the exception specification which is
what clang is complaining about. The preprocessed source of each is:

swap(_Tp& __a, _Tp& __b)
noexcept((__and_,
is_nothrow_move_assignable<_Tp>>::value))

and:

swap(_Tp&, _Tp&)
noexcept(__and_,
 is_nothrow_move_assignable<_Tp>>::value);

The difference is the extra parentheses in
noexcept((__and_,
is_nothrow_move_assignable<_Tp>>::value))

The error can be reproduced in clang with a much simpler example.

I'm not 100% sure on whether extra parentheses are considered as non-matching
in the standard, so I don't know whether this is a problem in clang or
libstdc++. I've raised https://bugs.llvm.org/show_bug.cgi?id=41705 on clang to
see if the error message can be tuned. I'm raising it here to see if a matching
change can be made to the exception specification in type_traits as even if
clang is fixed there will be plenty of older versions in use.

[Bug target/89400] [7/8/9/10 Regression] ICE: output_operand: invalid %-code with -march=armv6kz -mthumb -munaligned-access

[rearnsha at gcc dot gnu.org]

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

Richard Earnshaw  changed:

   What|Removed |Added

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

--- Comment #5 from Richard Earnshaw  ---
testing patch

[Bug rtl-optimization/90311] [9/10 Regression] wrong code with -O and __builtin_add_overflow() and compare

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P2
 Status|ASSIGNED|NEW
 CC||ktkachov at gcc dot gnu.org,
   ||ramana at gcc dot gnu.org,
   ||rearnsha at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
I'm afraid I need to punt on this, my limited understanding of the ARM
cary-related handling is insufficient here.
The code does x - ((x + a) 

[Bug rtl-optimization/90310] [7/8/9/10 Regression] wrong code with -Os -fno-forward-propagate

[ebotcazou at gcc dot gnu.org]

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

--- Comment #8 from Eric Botcazou  ---
> What is obvious to you, is not obvious to me. Most of the bug reports I
> create look quite similar (both testcases and compiler flags; eg.
> -fno-forward-propagate, -fno-dce, -fno-tree-dce and some other flags are
> very common in the bugreports). I already filter out about 1/2 of wrong-code
> testcases because they look too similiar to me.

Good, then I'd strengthen the filtering quite a bit.  Having N reports
containing the improbable combination of __builtin_bswap32,
__builtin_mul_overflow and __builtin_sub_overflow_p in a handful of lines
really should raise the red flag.

[Bug gcov-profile/47618] Collecting multiple profiles and using all for PGO

[marxin at gcc dot gnu.org]

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

--- Comment #28 from Martin Liška  ---
(In reply to Martin Liška from comment #26)
> (In reply to qinzhao from comment #25)
> > (In reply to Martin Liška from comment #24)
> > > 
> > > > How about the patch for the above 2? has it been committed?
> > > 
> > > It has been there for a while, please take a look at:
> > > 
> > > $ gcov-tool merge --help
> > > merge: unrecognized option '--help'
> > > Merge subcomand usage:  merge [options]   Merge 
> > > coverage
> > > file contents
> > > -o, --output   Output directory
> > > -v, --verbose   Verbose mode
> > > -w, --weight Set weights (float point values)
> > 
> > two more questions on this merge tool:
> > 1. it can only merge two directories at one time. So, for multiple
> > directories, for example "n", we have to invoke gcov-tool merge n-1 times in
> > order to merge all of them?
> 
> Yep. I guess one can write a simple bash script that does that.
> 
> > 2. Intel compiler (icc)'s profmerge is able to merge all the .dyn files
> > under one directory, does gcc have such functionality currently?
> 
> We have folder-base merging where we search for all .gcda files and we merge
> them to a destination folder.

$ echo "int main() {return 0;}" >> main.c && gcc --coverage main.c && ./a.out
$ mkdir a && mkdir b && cp main.gcda c && cp main.gcda b
$ gcov-tool merge a b -o a+b -v
reading file: ./main.gcda
tag one function id=108032747
reading file: ./main.gcda
tag one function id=108032747

$ ls a+b
main.gcda

$ gcov-dump a+b/main.gcda 
a+b/main.gcda:data:magic `gcda':version `A83*'
a+b/main.gcda:stamp 2031787297
a+b/main.gcda:  a300:  22:PROGRAM_SUMMARY checksum=0x33c369a8
a+b/main.gcda:counts=1, runs=1, sum_all=2, run_max=2, sum_max=2
a+b/main.gcda:counter histogram:
a+b/main.gcda: 2: num counts=1, min counter=2, cum_counter=2
a+b/main.gcda:  0100:   3:FUNCTION ident=108032747,
lineno_checksum=0x3b5ee2be, cfg_checksum=0xdb5de9e8
a+b/main.gcda:01a1:   2:COUNTERS arcs 1 counts

[Bug sanitizer/90312] Address sanitizer cannot be used with -mabi=ms since r266073

[marxin at gcc dot gnu.org]

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

--- Comment #4 from Martin Liška  ---
(In reply to Bence Szabó from comment #3)
> Thank you for the patch!
> 
> The main blocker is some msvc specific code in sanitizer_win_defs.h.
> WIN_FORCE_LINK, WIN_WEAK_ALIAS, WIN_EXPORT
> 
> AFAIK the sanitizer is from LLVM (or google?)

Yes, libsanitizer is part of LLVM and we copy the run-time library.

> and the official llvm build
> for windows is using msvc. So probably no-one has ever tried to compile this
> for windows with gcc. 

Hard to guess, but I would expect usage of llvm.

That said, I would create a PR here:
https://github.com/google/sanitizers/issues

and ask about LLVM + sanitizers being used for mingw.

> 
> The build dies early in libsanitizer with:
> 
> libtool: compile:  /c/GIT/gcc/trunk_build/./gcc/xgcc -shared-libgcc
> -B/c/GIT/gcc/trunk_build/./gcc -nostdinc++
> -L/c/GIT/gcc/trunk_build/x86_64-w64-mingw32/libstdc++-v3/src
> -L/c/GIT/gcc/trunk_build/x86_64-w64-mingw32/libstdc++-v3/src/.libs
> -L/c/GIT/gcc/trunk_build/x86_64-w64-mingw32/libstdc++-v3/libsupc++/.libs
> -L/c/mingw_83_build/x86_64-w64-mingw32/lib -L/c/mingw_83_build/mingw/lib
> -isystem /c/mingw_83_build/x86_64-w64-mingw32/include -isystem
> /c/mingw_83_build/mingw/include -B/c/mingw_83_build/x86_64-w64-mingw32/bin/
> -B/c/mingw_83_build/x86_64-w64-mingw32/lib/ -isystem
> /c/mingw_83_build/x86_64-w64-mingw32/include -isystem
> /c/mingw_83_build/x86_64-w64-mingw32/sys-include -D_GNU_SOURCE -D_DEBUG
> -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS
> -DHAVE_RPC_XDR_H=0 -DHAVE_TIRPC_RPC_XDR_H=0 -I.
> -I../../../../trunk_src/libsanitizer/sanitizer_common -I.. -I
> ../../../../trunk_src/libsanitizer/include -isystem
> ../../../../trunk_src/libsanitizer/include/system -Wall -W
> -Wno-unused-parameter -Wwrite-strings -pedantic -Wno-long-long -fPIC
> -fno-builtin -fno-exceptions -fno-rtti -fomit-frame-pointer -funwind-tables
> -fvisibility=hidden -Wno-variadic-macros -I../../libstdc++-v3/include
> -I../../libstdc++-v3/include/x86_64-w64-mingw32
> -I../../../../trunk_src/libsanitizer/../libstdc++-v3/libsupc++ -std=gnu++11
> -g -O2 -pipe -fno-ident
> -I/c/GIT/gcc/prerequisites/x86_64-w64-mingw32-static/include -MT
> sanitizer_common.lo -MD -MP -MF .deps/sanitizer_common.Tpo -c
> ../../../../trunk_src/libsanitizer/sanitizer_common/sanitizer_common.cc 
> -DDLL_EXPORT -DPIC -o .libs/sanitizer_common.o
> In file included from
> c:\git\gcc\trunk_src\libsanitizer\sanitizer_common\sanitizer_internal_defs.h:
> 58,
>  from
> c:\git\gcc\trunk_src\libsanitizer\sanitizer_common\sanitizer_flags.h:15,
>  from
> c:\git\gcc\trunk_src\libsanitizer\sanitizer_common\sanitizer_common.h:17,
>  from
> ../../../../trunk_src/libsanitizer/sanitizer_common/sanitizer_common.cc:12:
> c:\git\gcc\trunk_src\libsanitizer\sanitizer_common\sanitizer_win_defs.h:66:
> 11: error: expected constructor, destructor, or type conversion before '('
> token
>66 |   __pragma(comment(linker, "/alternatename:" WIN_SYM_PREFIX
> STRINGIFY(Name) "="\
>   |   ^
> c:\git\gcc\trunk_src\libsanitizer\sanitizer_common\sanitizer_win_defs.h:94:3:
> note: in expansion of macro 'WIN_WEAK_ALIAS'
>94 |   WIN_WEAK_ALIAS(Name, WEAK_DEFAULT_NAME(Name)) 
> \
>   |   ^~
> c:\git\gcc\trunk_src\libsanitizer\sanitizer_common\sanitizer_internal_defs.h:
> 60:3: note: in expansion of macro 'WIN_WEAK_EXPORT_DEF'
>60 |   WIN_WEAK_EXPORT_DEF(ReturnType, Name, __VA_ARGS__)
>   |   ^~~
> ../../../../trunk_src/libsanitizer/sanitizer_common/sanitizer_common.cc:328:
> 1: note: in expansion of macro 'SANITIZER_INTERFACE_WEAK_DEF'
>   328 | SANITIZER_INTERFACE_WEAK_DEF(void, __sanitizer_report_error_summary,
>   | ^~~~
> make[4]: *** [Makefile:663: sanitizer_common.lo] Error 1
> 
> Same goes for WIN_FORCE_LINK

[Bug rtl-optimization/90310] [7/8/9/10 Regression] wrong code with -Os -fno-forward-propagate

[zsojka at seznam dot cz]

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

--- Comment #7 from Zdenek Sojka  ---
(In reply to Eric Botcazou from comment #6)
> > Sure; how do I detect if it is a duplicate?
> 
> Look at the different PRs, both the code, the options and the target.  Isn't
> there  an obviously redundant trend?

What is obvious to you, is not obvious to me. Most of the bug reports I create
look quite similar (both testcases and compiler flags; eg.
-fno-forward-propagate, -fno-dce, -fno-tree-dce and some other flags are very
common in the bugreports). I already filter out about 1/2 of wrong-code
testcases because they look too similiar to me. If I am unsure, I link the
other bug report as in #c0 "Might be related to PR89795." Sometimes it is a
dup, sometimes not. I have stopped testing this target, until PR89795 is fixed.
I can also generally stop testing this target (as I did for sparc) if you think
the bugreports are meaningless, as they generally contain several -fno-*
compiler switches.

[Bug c++/90313] New: Is an assignment elided with gcc7.3 -O2?

[nina.korshunova at tum dot de]

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

Bug ID: 90313
   Summary: Is an assignment elided with gcc7.3 -O2?
   Product: gcc
   Version: 7.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nina.korshunova at tum dot de
  Target Milestone: ---

#include 
#include 

using Coordinates = std::array;

Coordinates map( const Coordinates& c, size_t level )
{
Coordinates result{ c[1], c[2], c[0] };

if( level != 0 )
{
  result =  map( result, level - 1 );
}

return result;
}

int main( )
{
Coordinates vecOfCoordinates = { 1.0, 2.0, 3.0 };
size_t level = 1;

auto result = map( vecOfCoordinates, level );

std::cout << "result = (" << result[0] << ", " << result[1] << ", " <<
result[2] << "), should be (3, 1, 2)" << std::endl;

return 0;

}

This minimal example delivers the following results with different
optimizations:
g++-6 -O2 : result = (3, 1, 2), should be (3, 1, 2)

g++-7: result = (3, 1, 2), should be (3, 1, 2)

g++-7 -O2: result = (3, 1, 3), should be (3, 1, 2)

g++-7 -O2 -fno-elide-constructors: result = (3, 1, 2), should be (3, 1, 2)

g++-8 -O2: result = (3, 1, 2), should be (3, 1, 2)

Gcc7.3.0 and -O2 deliver the wrong result. -fno-elide-constructors fixes the
result. -Wall -Wextra -fno-strict-aliasing -fwrap did not make a difference. Is
this a possible bug, or is there a problem in the code?

Everything is run on Ubuntu 18.04.

[Bug rtl-optimization/90310] [7/8/9/10 Regression] wrong code with -Os -fno-forward-propagate

[ebotcazou at gcc dot gnu.org]

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

--- Comment #6 from Eric Botcazou  ---
> Sure; how do I detect if it is a duplicate?

Look at the different PRs, both the code, the options and the target.  Isn't
there  an obviously redundant trend?

[Bug rtl-optimization/90310] [7/8/9/10 Regression] wrong code with -Os -fno-forward-propagate

[zsojka at seznam dot cz]

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

--- Comment #5 from Zdenek Sojka  ---
(In reply to Eric Botcazou from comment #3)
> Can you stop opening duplicate PRs, please?  It's the 4th instance.
> 
> *** This bug has been marked as a duplicate of bug 89795 ***

Sure; how do I detect if it is a duplicate?

[Bug gcov-profile/47618] Collecting multiple profiles and using all for PGO

[qing.zhao at oracle dot com]

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

--- Comment #27 from Qing Zhao  ---
> --- Comment #26 from Martin Liška  ---
> 
>> 2. Intel compiler (icc)'s profmerge is able to merge all the .dyn files
>> under one directory, does gcc have such functionality currently?
> 
> We have folder-base merging where we search for all .gcda files and we merge
> them to a destination folder.

could you please point me which command does this? thanks.

[Bug rtl-optimization/90310] [7/8/9/10 Regression] wrong code with -Os -fno-forward-propagate

[zsojka at seznam dot cz]

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

--- Comment #4 from Zdenek Sojka  ---
(In reply to Martin Liška from comment #2)
> To be honest, I can't see what you see with GCC 6. I've got:
> 
>   bl  __popcountsi2
>   ldr r3, .L6+16
>   str r0, [r3]
>   lsl r0, r4, #16
>   lsr r0, r0, #16
>   pop {r4, pc}
> .L7:
> 

my gcc-6:
$ armv7a-hardfloat-linux-gnueabi-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-6-branch/binary-latest-armv7a-hardfloat/bin/armv7a-hardfloat-linux-gnueabi-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-6-branch/binary-6-branch-265890-checking-yes-rtl-df-armv7a-hardfloat/bin/../libexec/gcc/armv7a-hardfloat-linux-gnueabi/6.5.0/lto-wrapper
Target: armv7a-hardfloat-linux-gnueabi
Configured with: /repo/gcc-6-branch//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df
--with-cloog --with-ppl --with-isl --with-float=hard --with-fpu=vfpv4
--with-arch=armv7-a --with-sysroot=/usr/armv7a-hardfloat-linux-gnueabi
--build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu
--target=armv7a-hardfloat-linux-gnueabi
--with-ld=/usr/bin/armv7a-hardfloat-linux-gnueabi-ld
--with-as=/usr/bin/armv7a-hardfloat-linux-gnueabi-as --disable-libstdcxx-pch
--prefix=/repo/gcc-6-branch//binary-6-branch-265890-checking-yes-rtl-df-armv7a-hardfloat
Thread model: posix
gcc version 6.5.0 (GCC) 


uxth is available on ARMv6 and above only.

[Bug target/89795] [7/8/9/10 Regression] wrong code with -O2 -fno-dce -fno-forward-propagate -fno-sched-pressure

[ebotcazou at gcc dot gnu.org]

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

--- Comment #8 from Eric Botcazou  ---
*** Bug 90310 has been marked as a duplicate of this bug. ***

[Bug rtl-optimization/90310] [7/8/9/10 Regression] wrong code with -Os -fno-forward-propagate

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #3 from Eric Botcazou  ---
Can you stop opening duplicate PRs, please?  It's the 4th instance.

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

[Bug target/87833] [9/10 Regression] Intel MIC (emulated) offloading: "relocation [...] can not be used when making a shared object; recompile with -fPIC"

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
See https://gcc.gnu.org/wiki/Offloading

[Bug rtl-optimization/90310] [7/8/9/10 Regression] wrong code with -Os -fno-forward-propagate

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Keywords|needs-bisection |
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-05-02
 CC||ebotcazou at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Martin Liška  ---
To be honest, I can't see what you see with GCC 6. I've got:

bl  __popcountsi2
ldr r3, .L6+16
str r0, [r3]
lsl r0, r4, #16
lsr r0, r0, #16
pop {r4, pc}
.L7:

while GCC 10 does:

bl  __popcountsi2
ldr r3, .L6+16
str r0, [r3]
mov r0, r4  @ movhi
pop {r4, pc}
.L7:

Which is a change that started with r242326:

commit 1998c023a3ed6c59d8f1eea3a34528a9d6a93fe1 (refs/bisect/bad)
Author: ebotcazou 
Date:   Fri Nov 11 22:38:33 2016 +

PR rtl-optimization/59461
* doc/rtl.texi (paradoxical subregs): Add missing word.
* combine.c (reg_nonzero_bits_for_combine): Do not discard results
in modes with precision larger than that of last_set_mode.
* rtlanal.c (nonzero_bits1) : If WORD_REGISTER_OPERATIONS
is
set and LOAD_EXTEND_OP is appropriate, propagate results from inner
REGs to paradoxical SUBREGs.
(num_sign_bit_copies1) : Likewise.  Check that the mode is
not
larger than a word before invoking LOAD_EXTEND_OP on it.


git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@242326
138bc75d-0d04-0410-961f-82ee72b054a4

[Bug target/87833] [9/10 Regression] Intel MIC (emulated) offloading: "relocation [...] can not be used when making a shared object; recompile with -fPIC"

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|NEW |WAITING

--- Comment #3 from H.J. Lu  ---
(In reply to Thomas Schwinge from comment #2)
> (In reply to H.J. Lu from comment #1)
> > Do you have a testcase?
> 
> Thought that would be obvious from the report.  Configure GCC for Intel MIC
> (emulated) offloading, then run the libgomp testsuite.

Please provide your GCC configure options.

[Bug sanitizer/90312] Address sanitizer cannot be used with -mabi=ms since r266073

[sbence92 at gmail dot com]

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

--- Comment #3 from Bence Szabó  ---
Thank you for the patch!

The main blocker is some msvc specific code in sanitizer_win_defs.h.
WIN_FORCE_LINK, WIN_WEAK_ALIAS, WIN_EXPORT

AFAIK the sanitizer is from LLVM (or google?) and the official llvm build for
windows is using msvc. So probably no-one has ever tried to compile this for
windows with gcc. 

The build dies early in libsanitizer with:

libtool: compile:  /c/GIT/gcc/trunk_build/./gcc/xgcc -shared-libgcc
-B/c/GIT/gcc/trunk_build/./gcc -nostdinc++
-L/c/GIT/gcc/trunk_build/x86_64-w64-mingw32/libstdc++-v3/src
-L/c/GIT/gcc/trunk_build/x86_64-w64-mingw32/libstdc++-v3/src/.libs
-L/c/GIT/gcc/trunk_build/x86_64-w64-mingw32/libstdc++-v3/libsupc++/.libs
-L/c/mingw_83_build/x86_64-w64-mingw32/lib -L/c/mingw_83_build/mingw/lib
-isystem /c/mingw_83_build/x86_64-w64-mingw32/include -isystem
/c/mingw_83_build/mingw/include -B/c/mingw_83_build/x86_64-w64-mingw32/bin/
-B/c/mingw_83_build/x86_64-w64-mingw32/lib/ -isystem
/c/mingw_83_build/x86_64-w64-mingw32/include -isystem
/c/mingw_83_build/x86_64-w64-mingw32/sys-include -D_GNU_SOURCE -D_DEBUG
-D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS
-DHAVE_RPC_XDR_H=0 -DHAVE_TIRPC_RPC_XDR_H=0 -I.
-I../../../../trunk_src/libsanitizer/sanitizer_common -I.. -I
../../../../trunk_src/libsanitizer/include -isystem
../../../../trunk_src/libsanitizer/include/system -Wall -W
-Wno-unused-parameter -Wwrite-strings -pedantic -Wno-long-long -fPIC
-fno-builtin -fno-exceptions -fno-rtti -fomit-frame-pointer -funwind-tables
-fvisibility=hidden -Wno-variadic-macros -I../../libstdc++-v3/include
-I../../libstdc++-v3/include/x86_64-w64-mingw32
-I../../../../trunk_src/libsanitizer/../libstdc++-v3/libsupc++ -std=gnu++11 -g
-O2 -pipe -fno-ident
-I/c/GIT/gcc/prerequisites/x86_64-w64-mingw32-static/include -MT
sanitizer_common.lo -MD -MP -MF .deps/sanitizer_common.Tpo -c
../../../../trunk_src/libsanitizer/sanitizer_common/sanitizer_common.cc 
-DDLL_EXPORT -DPIC -o .libs/sanitizer_common.o
In file included from
c:\git\gcc\trunk_src\libsanitizer\sanitizer_common\sanitizer_internal_defs.h:58,
 from
c:\git\gcc\trunk_src\libsanitizer\sanitizer_common\sanitizer_flags.h:15,
 from
c:\git\gcc\trunk_src\libsanitizer\sanitizer_common\sanitizer_common.h:17,
 from
../../../../trunk_src/libsanitizer/sanitizer_common/sanitizer_common.cc:12:
c:\git\gcc\trunk_src\libsanitizer\sanitizer_common\sanitizer_win_defs.h:66:11:
error: expected constructor, destructor, or type conversion before '(' token
   66 |   __pragma(comment(linker, "/alternatename:" WIN_SYM_PREFIX
STRINGIFY(Name) "="\
  |   ^
c:\git\gcc\trunk_src\libsanitizer\sanitizer_common\sanitizer_win_defs.h:94:3:
note: in expansion of macro 'WIN_WEAK_ALIAS'
   94 |   WIN_WEAK_ALIAS(Name, WEAK_DEFAULT_NAME(Name))
   \
  |   ^~
c:\git\gcc\trunk_src\libsanitizer\sanitizer_common\sanitizer_internal_defs.h:60:3:
note: in expansion of macro 'WIN_WEAK_EXPORT_DEF'
   60 |   WIN_WEAK_EXPORT_DEF(ReturnType, Name, __VA_ARGS__)
  |   ^~~
../../../../trunk_src/libsanitizer/sanitizer_common/sanitizer_common.cc:328:1:
note: in expansion of macro 'SANITIZER_INTERFACE_WEAK_DEF'
  328 | SANITIZER_INTERFACE_WEAK_DEF(void, __sanitizer_report_error_summary,
  | ^~~~
make[4]: *** [Makefile:663: sanitizer_common.lo] Error 1

Same goes for WIN_FORCE_LINK

[Bug c++/57378] gnu multiversioning gives assembler error: foo.resolver is already defined

[nheart at gmail dot com]

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

Nikolay Bogoychev  changed:

   What|Removed |Added

 CC||nheart at gmail dot com

--- Comment #4 from Nikolay Bogoychev  ---
Still an issue in 8.3.0

Works in clang

Cheers,

Nick

[Bug tree-optimization/89653] Missing vectorization of loop containing std::min/std::max and temporary

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work||10.0
 Resolution|--- |FIXED

--- Comment #10 from Richard Biener  ---
Fixed on trunk.

[Bug middle-end/49774] [meta-bug] restrict qualification aliasing issues

[rguenth at gcc dot gnu.org]

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

Bug 89509 Summary: restrict doesnt work with subfield accesses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89509

   What|Removed |Added

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

[Bug tree-optimization/89509] restrict doesnt work with subfield accesses

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work||10.0
 Resolution|--- |FIXED

--- Comment #4 from Richard Biener  ---
Fixed.

[Bug tree-optimization/89653] Missing vectorization of loop containing std::min/std::max and temporary

[rguenth at gcc dot gnu.org]

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

--- Comment #9 from Richard Biener  ---
Author: rguenth
Date: Thu May  2 14:08:08 2019
New Revision: 270800

URL: https://gcc.gnu.org/viewcvs?rev=270800=gcc=rev
Log:
2019-05-02  Richard Biener  

PR tree-optimization/89653
* tree-ssa-loop.c (pass_data_tree_loop_init): Execute
update-address-taken before the pass.
* passes.def (pass_tree_loop_init): Put comment before it.

* g++.dg/vect/pr89653.cc: New testcase.

Added:
trunk/gcc/testsuite/g++.dg/vect/pr89653.cc
Modified:
trunk/gcc/ChangeLog
trunk/gcc/passes.def
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-loop.c

[Bug tree-optimization/89509] restrict doesnt work with subfield accesses

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
Author: rguenth
Date: Thu May  2 14:05:27 2019
New Revision: 270799

URL: https://gcc.gnu.org/viewcvs?rev=270799=gcc=rev
Log:
2019-05-02  Richard Biener  

PR tree-optimization/89509
* tree-ssa-structalias.c (compute_dependence_clique): Look
at the first subvar when determining whether it is restrict.

* gcc.dg/torture/restrict-8.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/torture/restrict-8.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-structalias.c

[Bug lto/85574] [8/9 Regression] LTO bootstapped binaries differ

[rguenth at gcc dot gnu.org]

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

--- Comment #32 from Richard Biener  ---
Author: rguenth
Date: Thu May  2 13:58:47 2019
New Revision: 270798

URL: https://gcc.gnu.org/viewcvs?rev=270798=gcc=rev
Log:
2019-05-02  Richard Biener  

PR bootstrap/85574
* Makefile.tpl (compare target): Also compare extra-compare
files.
* Makefile.in: Regenerate.

config/
* bootstrap-lto.mk (extra-compare): Set to gcc/lto1$(exeext).

Modified:
trunk/ChangeLog
trunk/Makefile.in
trunk/Makefile.tpl
trunk/config/ChangeLog
trunk/config/bootstrap-lto.mk

[Bug rtl-optimization/90311] [9/10 Regression] wrong code with -O and __builtin_add_overflow() and compare

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Keywords|needs-bisection |
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-05-02
 CC||jakub at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Jakub Jelinek  ---
Started with my r269186, I'll have a look.

[Bug tree-optimization/90285] Poor optimised codegen for memmove() back on top of oneself

[s_gccbugzilla at nedprod dot com]

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

--- Comment #4 from Niall Douglas  ---
> "non-aliasing reinterpret cast"?  Whatever that means.
> 
> // Reinterpret bytes by copying (not UB for TC types)
> memmove(temp, , sizeof(T));
> 
> // Put reinterpreted bytes back. This avoids the UB
> // of reinterpret casting without creating new objects.
> memmove(ret, temp, sizeof(T));
> 
> not sure I understand this.  Note that mem{cpy,move} transfer the
> effective type, this is a no-op.
> 
> But well, C++ folks go wild these days...

WG21 hasn't formally seen this proposal yet. I report only WG14 feedback, which
is that a unidirectional reinterpreting cast where input object lifetime ends
within the abstract machine would be valuable. Then the compiler can know for a
fact that pointers to the input object are invalidated, and thus cannot alias
pointers derived from the returned value.

Under the C2x object model, the effective type of non-allocated storage
propagates to the destination. As we memmove() from non-allocated storage (the
stack allocated type), the effective type written to `ret` is that of `temp`.
The object lifetime for input object v ends, if input object v is not stored in
allocated storage.

So basically these operations are greenlit for the C2x object model, which is
why I presented them here, and the C committee says they are fine under the
existing C abstract machine. (Yes, as reported here they are written in C++,
but just as easily could be implemented as a C macro)

We will find out what WG21 SG12 thinks of this proposal come July.

Niall

[Bug tree-optimization/90285] Poor optimised codegen for memmove() back on top of oneself

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
(In reply to Niall Douglas from comment #2)
> To put this into a wider context, the detach and attach cast proposal passed
> muster earlier this week at the WG14 meeting that I am currently sitting in.
> The current C2x draft allows this implementation of "unidirectional
> reinterpret casting with no aliasing of input with output" under its
> "effective type" object model.
>
> (I will be taking this proposal to WG21 in July. Its paper number will be
> P1631 "Object detachment and attachment")
> 
> The ability to specify a non-aliasing reinterpret cast is valuable. If you
> shrink the size of the Foo object e.g. https://godbolt.org/z/a1Fajj, GCC
> generates ideal codegen. So I suspect the cause of this issue is probably
> quite easy to fix.

Not so, with small constant object size the memmoves are simply open-coded.

"non-aliasing reinterpret cast"?  Whatever that means.

// Reinterpret bytes by copying (not UB for TC types)
memmove(temp, , sizeof(T));

// Put reinterpreted bytes back. This avoids the UB
// of reinterpret casting without creating new objects.
memmove(ret, temp, sizeof(T));

not sure I understand this.  Note that mem{cpy,move} transfer the
effective type, this is a no-op.

But well, C++ folks go wild these days...

> Niall

[Bug tree-optimization/90285] Poor optimised codegen for memmove() back on top of oneself

[s_gccbugzilla at nedprod dot com]

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

--- Comment #2 from Niall Douglas  ---
To put this into a wider context, the detach and attach cast proposal passed
muster earlier this week at the WG14 meeting that I am currently sitting in.
The current C2x draft allows this implementation of "unidirectional reinterpret
casting with no aliasing of input with output" under its "effective type"
object model.

(I will be taking this proposal to WG21 in July. Its paper number will be P1631
"Object detachment and attachment")

The ability to specify a non-aliasing reinterpret cast is valuable. If you
shrink the size of the Foo object e.g. https://godbolt.org/z/a1Fajj, GCC
generates ideal codegen. So I suspect the cause of this issue is probably quite
easy to fix.

Niall

[Bug rtl-optimization/90311] [9/10 Regression] wrong code with -O and __builtin_add_overflow() and compare

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |9.0

[Bug rtl-optimization/90310] [7/8/9/10 Regression] wrong code with -Os -fno-forward-propagate

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |7.5

[Bug c++/90309] Spurious warning shift-negative-value

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||diagnostic
 Target||mips
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-05-02
  Component|target  |c++
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed.

[Bug tree-optimization/90307] -Wuninitialized only at -O1, not at -O2

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-05-02
  Component|c++ |tree-optimization
 Ever confirmed|0   |1

--- Comment #2 from Richard Biener  ---
I think SRA split this according to external_type layout even though accesses
are using internal_type layout.  For the full remat of the aggregate,
that is, the scalarization itself is triggered by the filed accesses later.
Doesn't look very clever overall.

@@ -24,7 +38,13 @@
   s.u.internal.size = 5;
   MEM[(struct  &)] ={v} {CLOBBER};
   x.u.internal = MEM[(const struct sstring &)].u.internal;
+  x$u$external$str_24 = MEM[(union contents *)];
+  x$u$external$size_64 = MEM[(union contents *) + 8B];
+  x$u$internal$size_65 = MEM[(union contents *) + 15B];
   MEM[(struct  &)] ={v} {CLOBBER};
+  MEM[(union contents *)] = x$u$external$str_24;
+  MEM[(union contents *) + 8B] = x$u$external$size_64;
+  MEM[(union contents *) + 15B] = x$u$internal$size_65;
   D.2505.u.internal = MEM[(const struct sstring &)].u.internal;
   use ();

[Bug pch/90306] ICE when using precompiled headers with -MD and -fpch-deps

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org

--- Comment #1 from Richard Biener  ---
Just a wild guess, maybe the following helps - but I have no idea how this was
supposed to work.

Index: libcpp/pch.c
===
--- libcpp/pch.c(revision 270791)
+++ libcpp/pch.c(working copy)
@@ -856,6 +856,9 @@ cpp_read_state (cpp_reader *r, const cha

   free (data);

+  if (!r->deps)
+r->deps = deps_init ();
+
   if (deps_restore (r->deps, f, CPP_OPTION (r, restore_pch_deps) ? name :
NULL)
   != 0)
 goto error;

[Bug c++/90304] -O3 vectorization gets worse when code is moved into main()

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-05-02
 Blocks||49774
 Ever confirmed|0   |1

--- Comment #2 from Richard Biener  ---
Yes, it is related to us not handling restrict qualification of automatic
variables.  The whole loop is still vectorized we just have to emit a runtime
check for possible aliasing.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49774
[Bug 49774] [meta-bug] restrict qualification aliasing issues

[Bug rtl-optimization/90311] [9/10 Regression] wrong code with -O and __builtin_add_overflow() and compare

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Keywords||needs-bisection

--- Comment #1 from Martin Liška  ---
I'll bisect that..

[Bug rtl-optimization/90310] [7/8/9/10 Regression] wrong code with -Os -fno-forward-propagate

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Keywords||needs-bisection

--- Comment #1 from Martin Liška  ---
I'll bisect that..

[Bug sanitizer/90312] Address sanitizer cannot be used with -mabi=ms since r266073

[marxin at gcc dot gnu.org]

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

--- Comment #2 from Martin Liška  ---
Created attachment 46275
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46275=edit
Untested patch

[Bug tree-optimization/90303] [9/10 Regression] ICE in hash_odr_name with fastcall attribute starting with r267359

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug sanitizer/90312] Address sanitizer cannot be used with -mabi=ms since r266073

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC|mliska at suse dot cz  |
   Target Milestone|--- |9.2

[Bug middle-end/90302] Implement __builtin_warning

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
I'm not sure a function call is the proper way to handle this.  It would maybe
be better to use a DEBUG-stmt like thing (maybe even actually a debug stmt!).

In theory it would be possible to emit those into DWARF and trigger the
warnings at runtime (under inspection of an appropriate tool like valgrind).

[Bug sanitizer/90312] Address sanitizer cannot be used with -mabi=ms since r266073

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-05-02
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org
 Ever confirmed|0   |1
  Known to fail||9.0

--- Comment #1 from Martin Liška  ---
(In reply to Bence Szabó from comment #0)
> The fix or PR sanitizer/87930 (r266073) makes it impossible to use
> -fsanitize=address on windows which uses -mabi=ms as default.

Hello.

> 
> Currently the mingw releases do not contain libasan (or libusan) and so far
> my attempts to include them failed.

I can help you with that if you want. What are the main blockers of that?

> However there's a mingw based llvm
> toolchain (https://github.com/mstorsjo/llvm-mingw) which contains libasan
> and libusan as static lib. These can be linked to a dll by the said
> toolchain and they work with mingw as drop-in until gcc 8.3.

I see. I'm attaching a patch candidate that will error only when default ABI is
different from MS.

> 
> I guess PR sanitizer/87930 could be fixed instead of forbidden.
> 
> It would be awesome to use the asan (and usan) with mingw but that's
> currently impossible after r266073 even if we produce the libasan for mingw
> somehow.

[Bug c++/90301] RangeV3 usage, ICE internal compiler error: canonical types differ for identical types

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||ice-checking,
   ||ice-on-valid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-05-02
Version|unknown |9.0
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
ICEs the same on the GCC 8 branch with -fchecking, so the issue is likely
older.

[Bug tree-optimization/90285] Poor optimised codegen for memmove() back on top of oneself

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-05-02
  Component|c++ |tree-optimization
 Ever confirmed|0   |1
   Severity|normal  |enhancement

--- Comment #1 from Richard Biener  ---
Your example boils down to the C testcase

struct S { char arr[1024]; };

struct S *foo (struct S *s)
{
  struct S temp;
  __builtin_memcpy (, s, sizeof (struct S));
  __builtin_memcpy (s, , sizeof (struct S));
  return s;
}

which shows that indeed GCC doesn't have a pass doing "copy propagation"
of aggregates.

One might argue that if you write stupid source it might be possible you
get back stupid assembly ;)

But yes, this is a long-standing issue usually popping up when we do not
copy back to s but return temp by value.

[Bug lto/51765] [9/10 Regression] Testsuite ICEs with -flto

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #11 from Richard Biener  ---
So let's close it.

[Bug lto/51765] [9/10 Regression] Testsuite ICEs with -flto

[rguenther at suse dot de]

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

--- Comment #12 from rguenther at suse dot de  ---
On Wed, 1 May 2019, asolokha at gmx dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51765
> 
> --- Comment #10 from Arseny Solokha  ---
> (In reply to Jan Hubicka from comment #8)
> > FAIL: gcc.dg/nested-func-12.c (internal compiler error)
> > FAIL: gcc.dg/nested-func-9.c (internal compiler error)
> 
> I cannot reproduce these as for now. I believe it makes sense to finally close
> this PR and maybe mark PR83997 as a regression in turn.

I believe the Ada ones are real as well (but have a separate bug IIRC).

[Bug debug/90273] [10 Regression] GCC runs out of memory building Firefox

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #30 from Richard Biener  ---
Fixed.

[Bug lto/45375] [meta-bug] Issues with building Mozilla (i.e. Firefox) with LTO

[rguenth at gcc dot gnu.org]

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

Bug 90273 Summary: [10 Regression] GCC runs out of memory building Firefox
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90273

   What|Removed |Added

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

[Bug debug/90273] [10 Regression] GCC runs out of memory building Firefox

[rguenth at gcc dot gnu.org]

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

--- Comment #31 from Richard Biener  ---
Author: rguenth
Date: Thu May  2 11:17:00 2019
New Revision: 270791

URL: https://gcc.gnu.org/viewcvs?rev=270791=gcc=rev
Log:
2019-05-02  Richard Biener  

PR tree-optimization/90273
* tree-ssa-dce.c (eliminate_unnecessary_stmts): Eliminate
useless debug stmts.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-ssa-dce.c

[Bug debug/86964] [7/8 Regression] Too many debug symbols included, especially for extern globals

[rguenther at suse dot de]

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

--- Comment #12 from rguenther at suse dot de  ---
On Tue, 30 Apr 2019, patrickdepinguin at gmail dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86964
> 
> --- Comment #11 from Thomas De Schampheleire  com> ---
> It seems the necessary patch is applied now, are these the only changes
> 
> The target milestone is set 7.5. Do you have any rough idea when that would be
> released?

Somewhen in summer.

[Bug sanitizer/90312] New: Address sanitizer cannot be used with -mabi=ms since r266073

[sbence92 at gmail dot com]

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

Bug ID: 90312
   Summary: Address sanitizer cannot be used with -mabi=ms since
r266073
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sbence92 at gmail dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org,
marxin at gcc dot gnu.org, mliska at suse dot cz
  Target Milestone: ---
Target: x86_64-w64-mingw32
 Build: x86_64-w64-mingw32

The fix or PR sanitizer/87930 (r266073) makes it impossible to use
-fsanitize=address on windows which uses -mabi=ms as default.

Currently the mingw releases do not contain libasan (or libusan) and so far my
attempts to include them failed. However there's a mingw based llvm toolchain
(https://github.com/mstorsjo/llvm-mingw) which contains libasan and libusan as
static lib. These can be linked to a dll by the said toolchain and they work
with mingw as drop-in until gcc 8.3.

I guess PR sanitizer/87930 could be fixed instead of forbidden.

It would be awesome to use the asan (and usan) with mingw but that's currently
impossible after r266073 even if we produce the libasan for mingw somehow.

[Bug rtl-optimization/90311] New: [9/10 Regression] wrong code with -O and __builtin_add_overflow() and compare

[zsojka at seznam dot cz]

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

Bug ID: 90311
   Summary: [9/10 Regression] wrong code with -O and
__builtin_add_overflow() and compare
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: armv7a-hardfloat-linux-gnueabi

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

Output:
$ armv7a-hardfloat-linux-gnueabi-gcc -O testcase.c -static
$ ./a.out 
qemu: uncaught target signal 6 (Aborted) - core dumped
Aborted

Correct value is 0, wrong value is 0x

Difference between gcc-8 (OK) and gcc-9 (BAD) is:

--- testcase.s.OK   2019-05-02 12:44:11.856127737 +0200
+++ testcase.s.BAD  2019-05-02 12:44:17.306127716 +0200
@@ -27,9 +27,8 @@
movwr1, #:lower16:a
movtr1, #:upper16:a
ldrbr1, [r1]@ zero_extendqisi2
-   add r1, r3, r1
-   cmp r1, r3
-   subcc   r3, r3, #1
+   cmn r3, r1
+   sbc r3, r3, #0
str r3, [r2]
cmp r3, #0
bne .L6

$ armv7a-hardfloat-linux-gnueabi-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-armv7a-hardfloat/bin/armv7a-hardfloat-linux-gnueabi-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-270639-checking-yes-rtl-df-extra-armv7a-hardfloat/bin/../libexec/gcc/armv7a-hardfloat-linux-gnueabi/10.0.0/lto-wrapper
Target: armv7a-hardfloat-linux-gnueabi
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--with-cloog --with-ppl --with-isl --with-float=hard --with-fpu=vfpv4
--with-arch=armv7-a --with-sysroot=/usr/armv7a-hardfloat-linux-gnueabi
--build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu
--target=armv7a-hardfloat-linux-gnueabi
--with-ld=/usr/bin/armv7a-hardfloat-linux-gnueabi-ld
--with-as=/usr/bin/armv7a-hardfloat-linux-gnueabi-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-270639-checking-yes-rtl-df-extra-armv7a-hardfloat
Thread model: posix
gcc version 10.0.0 20190429 (experimental) (GCC)

[Bug rtl-optimization/90310] New: [7/8/9/10 Regression] wrong code with -Os -fno-forward-propagate

[zsojka at seznam dot cz]

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

Bug ID: 90310
   Summary: [7/8/9/10 Regression] wrong code with -Os
-fno-forward-propagate
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: armv7a-hardfloat-linux-gnueabi

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

Might be related to PR89795.

Output:
$ armv7a-hardfloat-linux-gnueabi-gcc -Os -fno-forward-propagate testcase.c
-static
$ ./a.out 
qemu: uncaught target signal 6 (Aborted) - core dumped
Aborted

Correct value is 0x, wrong value is 0x.

Diff between gcc-6 (OK) and gcc-10 (BAD) is:

--- testcase.s.ok   2019-05-02 12:32:34.546130397 +0200
+++ testcase.s  2019-05-02 12:32:43.996130361 +0200
@@ -39,7 +40,7 @@
bl  __popcountsi2
ldr r3, .L6+16
str r0, [r3]
-   uxthr0, r4
+   mov r0, r4  @ movhi
pop {r4, pc}
 .L7:
.align  2


$ armv7a-hardfloat-linux-gnueabi-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-armv7a-hardfloat/bin/armv7a-hardfloat-linux-gnueabi-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-270639-checking-yes-rtl-df-extra-armv7a-hardfloat/bin/../libexec/gcc/armv7a-hardfloat-linux-gnueabi/10.0.0/lto-wrapper
Target: armv7a-hardfloat-linux-gnueabi
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--with-cloog --with-ppl --with-isl --with-float=hard --with-fpu=vfpv4
--with-arch=armv7-a --with-sysroot=/usr/armv7a-hardfloat-linux-gnueabi
--build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu
--target=armv7a-hardfloat-linux-gnueabi
--with-ld=/usr/bin/armv7a-hardfloat-linux-gnueabi-ld
--with-as=/usr/bin/armv7a-hardfloat-linux-gnueabi-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-270639-checking-yes-rtl-df-extra-armv7a-hardfloat
Thread model: posix
gcc version 10.0.0 20190429 (experimental) (GCC)

[Bug tree-optimization/90303] [9/10 Regression] ICE in hash_odr_name with fastcall attribute starting with r267359

[hubicka at ucw dot cz]

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

--- Comment #5 from Jan Hubicka  ---
I see, i suppose we may lose some optimizations in early opts because of
this but your patch is safe and I don't think the missed optimizations
are very important (if they are we should avoid having structural
equality on such types)

Honza

[Bug target/90309] New: Spurious warning shift-negative-value

[philipp.lucas at siemens dot com]

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

Bug ID: 90309
   Summary: Spurious warning shift-negative-value
   Product: gcc
   Version: 8.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: philipp.lucas at siemens dot com
  Target Milestone: ---

Created attachment 46272
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46272=edit
Test case

Consider the following code:

  struct O { 
char c;
  };

  typedef void (O::*MP)(void);

  struct Uv : O {
virtual void v();
void f();  
  };

  MP mfv=static_cast(::f);

When compiled for MIPS, this triggers the following warning:

  > mips-sde-elf-gcc -c -Wshift-negative-value shift.cpp

  warning: left shift of negative value [-Wshift-negative-value]
 MP mfv=static_cast(::f);

The reason for this seems to be the left shift in 

  build_ptrmemfunc (tree type, tree pfn, int force, bool c_cast_p,
  tsubst_flags_t complain)
  ...
  if (!integer_zerop (n))
{
  if (TARGET_PTRMEMFUNC_VBIT_LOCATION == ptrmemfunc_vbit_in_delta)
  n = cp_build_binary_op (input_location,
LSHIFT_EXPR, n, integer_one_node,
complain);
  delta = cp_build_binary_op (input_location,
  PLUS_EXPR, delta, n, complain);
}

where n->int_cst.val == -4 , which is to be expected.

I do not think such an internally generated shift should give rise to a user
visible warning, which will make the user search in vain for a shift in the
original code.

[Bug c/90293] New function attribute: expect_return

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #3 from Martin Liška  ---
I quite like the suggested functionality..

[Bug target/87833] [9/10 Regression] Intel MIC (emulated) offloading: "relocation [...] can not be used when making a shared object; recompile with -fPIC"

[tschwinge at gcc dot gnu.org]

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

Thomas Schwinge  changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #2 from Thomas Schwinge  ---
(In reply to H.J. Lu from comment #1)
> Do you have a testcase?

Thought that would be obvious from the report.  Configure GCC for Intel MIC
(emulated) offloading, then run the libgomp testsuite.

[Bug tree-optimization/90303] [9/10 Regression] ICE in hash_odr_name with fastcall attribute starting with r267359

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
No, TYPE_CANONICAL (TYPE_MAIN_VARIANT (type)) is also NULL, for the same
reasons.
It is a template instantiation with a template parameter that needs structural
equality.

[Bug gcov-profile/47618] Collecting multiple profiles and using all for PGO

[marxin at gcc dot gnu.org]

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

--- Comment #26 from Martin Liška  ---
(In reply to qinzhao from comment #25)
> (In reply to Martin Liška from comment #24)
> > 
> > > How about the patch for the above 2? has it been committed?
> > 
> > It has been there for a while, please take a look at:
> > 
> > $ gcov-tool merge --help
> > merge: unrecognized option '--help'
> > Merge subcomand usage:  merge [options]   Merge coverage
> > file contents
> > -o, --output   Output directory
> > -v, --verbose   Verbose mode
> > -w, --weight Set weights (float point values)
> 
> two more questions on this merge tool:
> 1. it can only merge two directories at one time. So, for multiple
> directories, for example "n", we have to invoke gcov-tool merge n-1 times in
> order to merge all of them?

Yep. I guess one can write a simple bash script that does that.

> 2. Intel compiler (icc)'s profmerge is able to merge all the .dyn files
> under one directory, does gcc have such functionality currently?

We have folder-base merging where we search for all .gcda files and we merge
them to a destination folder.