[Bug demangler/88629] Heap-buffer-overflow problem in function d_expression_1 in cp-demangle.c, as demonstrated by c++filt

[wcventure at 126 dot com]

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

--- Comment #5 from Cheng Wen  ---
This bug got assigned CVE-2018-20712

[Bug lto/89147] flto removes functions implemented in asm

[Hi-Angel at yandex dot ru]

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

--- Comment #2 from Konstantin Kharlamov  ---
(In reply to Andrew Pinski from comment #1)
> >Possible workarounds are welcome.
> 
> Use -ffat-lto-objects or use a .s file.

Thank you for reply!

Adding a `-ffat-lto-objects` to the command above didn't help, still "no
symbols".

Unless no other way around, I'd like to refrain from reworking the generation
code to produce a .S file as that likely would result in a lot of work and may
introduce bugs, whereas the code works well ATM. I wonder though if it's
possible to rewrite it to use "builtin"s (I didn't look at that more closely
yet).

[Bug target/89148] [AVR] Merge plugin to place C++ vtables in flash memory

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|c++ |target

--- Comment #1 from Andrew Pinski  ---
.

[Bug fortran/88669] Contiguous attribute wrongly rejected

[mscfd at gmx dot net]

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

--- Comment #6 from martin  ---
Thanks for fixing.

[Bug rtl-optimization/88596] [9 Regression] ICE: Maximum number of LRA assignment passes is achieved (30)

[asolokha at gmx dot com]

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

--- Comment #5 from Arseny Solokha  ---
Created attachment 45579
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45579=edit
Testcase #2

At least, this one fails on godbolt.

% x86_64-pc-linux-gnu-gcc-9.0.0-alpha20190127 -O1 -fschedule-insns
-fsel-sched-pipelining -fselective-scheduling -funroll-loops -funswitch-loops
-fno-split-wide-types -fno-ssa-phiopt -fno-tree-ch -fno-tree-copy-prop
-fno-tree-dce -fno-tree-dominator-opts --param logical-op-non-short-circuit=0
-c hn3vahj0.c
during RTL pass: reload
hn3vahj0.c: In function 'w0':
hn3vahj0.c:97:1: internal compiler error: Maximum number of LRA assignment
passes is achieved (30)

   97 | }
  | ^
0xbe9ccd lra_assign(bool&)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190127/work/gcc-9-20190127/gcc/lra-assigns.c:1695
0xbe46b4 lra(_IO_FILE*)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190127/work/gcc-9-20190127/gcc/lra.c:2518
0xb9bc79 do_reload
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190127/work/gcc-9-20190127/gcc/ira.c:5516
0xb9bc79 execute
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190127/work/gcc-9-20190127/gcc/ira.c:5700

[Bug rtl-optimization/88596] [9 Regression] ICE: Maximum number of LRA assignment passes is achieved (30)

[asolokha at gmx dot com]

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

--- Comment #4 from Arseny Solokha  ---
I still can w/ r268327, on Ivy Bridge and Haswell. It ICEs only w/ this
particular argument to --param selsched-max-lookahead, though. Playing w/
-f{,no-}stack-protector{,-strong,explicit} gave me nothing this time. Anyway, I
have more testcases of this kind to try.

% x86_64-pc-linux-gnu-gcc-9.0.0-alpha20190127 -mtune=haswell -O1
-fschedule-insns -fselective-scheduling --param selsched-max-lookahead=78 -c
a76zvftd.c -v
Using built-in specs.
COLLECT_GCC=x86_64-pc-linux-gnu-gcc-9.0.0-alpha20190127
Target: x86_64-pc-linux-gnu
Configured with:
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190127/work/gcc-9-20190127/configure
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr
--bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/9.0.0-alpha20190127
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/9.0.0-alpha20190127/include
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/9.0.0-alpha20190127
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/9.0.0-alpha20190127/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/9.0.0-alpha20190127/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/9.0.0-alpha20190127/include/g++-v9
--with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/9.0.0-alpha20190127/python
--enable-languages=c,c++ --enable-obsolete --enable-secureplt --disable-werror
--with-system-zlib --disable-nls --enable-checking=yes --disable-esp
--enable-libstdcxx-time --disable-libstdcxx-pch --enable-shared
--enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu
--disable-multilib --with-multilib-list=m64 --disable-altivec
--disable-fixed-point --enable-targets=all --enable-libgomp
--disable-libmudflap --disable-libssp --disable-libmpx --disable-systemtap
--disable-vtable-verify --disable-libvtv --disable-libquadmath --enable-lto
--with-isl --disable-isl-version-check --disable-libsanitizer
--enable-default-pie --enable-default-ssp
Thread model: posix
gcc version 9.0.0-alpha20190127 20190127 (experimental) (GCC) 
COLLECT_GCC_OPTIONS='-mtune=haswell' '-O1' '-fschedule-insns'
'-fselective-scheduling' '--param' 'selsched-max-lookahead=78' '-c' '-v'
'-march=x86-64'
 /usr/libexec/gcc/x86_64-pc-linux-gnu/9.0.0-alpha20190127/cc1 -quiet -v
a76zvftd.c -quiet -dumpbase a76zvftd.c -mtune=haswell -march=x86-64 -auxbase
a76zvftd -O1 -version -fschedule-insns -fselective-scheduling --param
selsched-max-lookahead=78 -o /tmp/ccTRhQ2O.s
GNU C17 (GCC) version 9.0.0-alpha20190127 20190127 (experimental)
(x86_64-pc-linux-gnu)
compiled by GNU C version 9.0.0-alpha20190127 20190127 (experimental),
GMP version 6.1.2, MPFR version 4.0.1, MPC version 1.1.0, isl version
isl-0.20-GMP

GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
ignoring nonexistent directory "/usr/local/include"
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-pc-linux-gnu/9.0.0-alpha20190127/../../../../x86_64-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc/x86_64-pc-linux-gnu/9.0.0-alpha20190127/include
 /usr/lib/gcc/x86_64-pc-linux-gnu/9.0.0-alpha20190127/include-fixed
 /usr/include
End of search list.
GNU C17 (GCC) version 9.0.0-alpha20190127 20190127 (experimental)
(x86_64-pc-linux-gnu)
compiled by GNU C version 9.0.0-alpha20190127 20190127 (experimental),
GMP version 6.1.2, MPFR version 4.0.1, MPC version 1.1.0, isl version
isl-0.20-GMP

GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: 6125d5c9aba55c0e4ecd3178c2c99564
during RTL pass: reload
a76zvftd.c: In function 'px':
a76zvftd.c:26:1: internal compiler error: Maximum number of LRA assignment
passes is achieved (30)

   26 | }
  | ^
0xbe9ccd lra_assign(bool&)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190127/work/gcc-9-20190127/gcc/lra-assigns.c:1695
0xbe46fd lra(_IO_FILE*)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190127/work/gcc-9-20190127/gcc/lra.c:2521
0xb9bc79 do_reload
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190127/work/gcc-9-20190127/gcc/ira.c:5516
0xb9bc79 execute
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190127/work/gcc-9-20190127/gcc/ira.c:5700

[Bug tree-optimization/89134] A missing optimization opportunity for a simple branch in loop

[jiangning.liu at amperecomputing dot com]

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

--- Comment #10 from Jiangning Liu  
---
(In reply to Martin Sebor from comment #9)
> But since GCC emits infinite loops regardless of whether or not
> they have any side-effects, whether inc() is pure or not may not matter. 

I think "for (; it != m.end (); ++it);  /* get an empty loop */" is a finite
loop.

[Bug tree-optimization/89134] A missing optimization opportunity for a simple branch in loop

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|NEW |UNCONFIRMED
 Ever confirmed|1   |0

--- Comment #9 from Martin Sebor  ---
Let me actually retract the confirmation.  I acknowledged this for the pure
attribute apparently not being taken into consideration when determining
whether the loop terminates, on the basis of the minimum the standard requires.
 But since GCC emits infinite loops regardless of whether or not they have any
side-effects, whether inc() is pure or not may not matter.  Richard is the
expert on loops so I should defer to him, especially since this request seems
to be about more than just finite loops.

[Bug c/89126] missing -Wtype-limits for int variables

[msebor at gcc dot gnu.org]

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

--- Comment #3 from Martin Sebor  ---
The problem is in shorten_compare() in c-common.c which deals with these cases.
 The comment above the block that handles this has this to say just above the
conditional that guards the code.  The conditional fails in the fint case
because both operands of the inequality have the same precision:

  /* If comparing an integer against a constant more bits wide,
 maybe we can deduce a value of 1 or 0 independent of the data.
 Or else truncate the constant now
 rather than extend the variable at run time.

 This is only interesting if the constant is the wider arg.
 Also, it is not safe if the constant is unsigned and the
 variable arg is signed, since in this case the variable
 would be sign-extended and then regarded as unsigned.
 Our technique fails in this case because the lowest/highest
 possible unsigned results don't follow naturally from the
 lowest/highest possible values of the variable operand.
 For just EQ_EXPR and NE_EXPR there is another technique that
 could be used: see if the constant can be faithfully represented
 in the other operand's type, by truncating it and reextending it
 and see if that preserves the constant's value.  */

  if (!real1 && !real2
  && TREE_CODE (TREE_TYPE (primop0)) != FIXED_POINT_TYPE
  && TREE_CODE (primop1) == INTEGER_CST
  && TYPE_PRECISION (TREE_TYPE (primop0)) < TYPE_PRECISION (*restype_ptr))
{

Eventually, after the function returns the inequality expression without a
warning, c_parser_condition() calls c_fully_fold() on it which folds it into a
constant, without a warning.

[Bug tree-optimization/43565] Missed address comparison folding of DECL_COMMONs

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-02-01
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1
  Known to fail||4.5.3, 4.8.5, 4.9.4, 5.4.0,
   ||6.4.0, 7.3.0, 8.2.0, 9.0

--- Comment #1 from Martin Sebor  ---
I came across this by accident but since it's still not implemented I might as
well confirm it.  Neither Clang nor ICC optimizes it, but Visual C 19.0 does
(though most likely by accident, because 19.10 doesn't again).

[Bug tree-optimization/87022] [8 Regression] miscompilation with -ftree-loop-distribution

[amker at gcc dot gnu.org]

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

--- Comment #7 from bin cheng  ---
Given this is an regression, now I backported the fix to GCC-8 at r268441.

[Bug tree-optimization/87022] [8 Regression] miscompilation with -ftree-loop-distribution

[amker at gcc dot gnu.org]

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

--- Comment #6 from bin cheng  ---
Author: amker
Date: Fri Feb  1 03:11:08 2019
New Revision: 268441

URL: https://gcc.gnu.org/viewcvs?rev=268441=gcc=rev
Log:
Backport from mainline
2018-10-15  Bin Cheng  

PR tree-optimization/87022
* tree-loop-distribution.c (pg_add_dependence_edges): Check all
bits in dist vector rather than the first one.

gcc/testsuite
2018-10-15  Bin Cheng  

PR tree-optimization/87022
* gcc.dg/tree-ssa/pr87022.c: New test.

Added:
branches/gcc-8-branch/gcc/testsuite/gcc.dg/tree-ssa/pr87022.c
Modified:
branches/gcc-8-branch/gcc/ChangeLog
branches/gcc-8-branch/gcc/testsuite/ChangeLog
branches/gcc-8-branch/gcc/tree-loop-distribution.c

[Bug tree-optimization/88932] [8/9 Regression] ICE: verify_ssa failed (Error: definition in block 29 does not dominate use in block 25)

[amker at gcc dot gnu.org]

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

--- Comment #7 from bin cheng  ---
Author: amker
Date: Fri Feb  1 02:56:41 2019
New Revision: 268440

URL: https://gcc.gnu.org/viewcvs?rev=268440=gcc=rev
Log:
Backport from mainline
2019-02-01  Bin Cheng  

PR tree-optimization/88932
* tree-predcom.c (try_combine_chains): Get loop bbs in dom order.

gcc/testsuite
2019-02-01  Bin Cheng  

PR tree-optimization/88932
* gfortran.dg/pr88932.f90: New test.

Added:
branches/gcc-8-branch/gcc/testsuite/gfortran.dg/pr88932.f90
Modified:
branches/gcc-8-branch/gcc/ChangeLog
branches/gcc-8-branch/gcc/testsuite/ChangeLog
branches/gcc-8-branch/gcc/tree-predcom.c

[Bug tree-optimization/88932] [8/9 Regression] ICE: verify_ssa failed (Error: definition in block 29 does not dominate use in block 25)

[amker at gcc dot gnu.org]

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

--- Comment #6 from bin cheng  ---
Author: amker
Date: Fri Feb  1 02:39:52 2019
New Revision: 268439

URL: https://gcc.gnu.org/viewcvs?rev=268439=gcc=rev
Log:
PR tree-optimization/88932
* tree-predcom.c (try_combine_chains): Get loop bbs in dom order.

gcc/testsuite
* gfortran.dg/pr88932.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/pr88932.f90
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-predcom.c

[Bug tree-optimization/89134] A missing optimization opportunity for a simple branch in loop

[innat_xue at hotmail dot com]

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

--- Comment #8 from Feng Xue  ---
My mistake, transformation should be:

void f (std::map m)
{
for (auto it = m.begin (); it != m.end (); ++it) {
if (b) {
b = do_something();
} else {
++it;
break;
}
}

for (; it != m.end (); ++it);  /* get an empty loop */
}


(In reply to Feng Xue from comment #7)
> Even loop contains calls with side effects, but only in one condition branch
> path, we can still do some kind of optimization.
> 
> Suppose a loop as:
> 
> void f (std::map m)
> {
> for (auto it = m.begin (); it != m.end (); ++it) {
> if (b) {
> b = do_something();/* Has effect on b */
> } else {
>/* No effect on b */
> }
> }
> }
> 
> We can transform it to:
> 
> void f (std::map m)
> {
> for (auto it = m.begin (); it != m.end (); ++it) {
> if (b) {
> b = do_something();
> ++it;
> break;
> }
> }
> 
> for (; it != m.end (); ++it);  /* get an empty loop */
> }
> 
> This code takes less computation, especially when 'b' is always evaluated to
> be false.

[Bug tree-optimization/89134] A missing optimization opportunity for a simple branch in loop

[innat_xue at hotmail dot com]

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

Feng Xue  changed:

   What|Removed |Added

 CC||innat_xue at hotmail dot com

--- Comment #7 from Feng Xue  ---
Even loop contains calls with side effects, but only in one condition branch
path, we can still do some kind of optimization.

Suppose a loop as:

void f (std::map m)
{
for (auto it = m.begin (); it != m.end (); ++it) {
if (b) {
b = do_something();/* Has effect on b */
} else {
   /* No effect on b */
}
}
}

We can transform it to:

void f (std::map m)
{
for (auto it = m.begin (); it != m.end (); ++it) {
if (b) {
b = do_something();
++it;
break;
}
}

for (; it != m.end (); ++it);  /* get an empty loop */
}

This code takes less computation, especially when 'b' is always evaluated to be
false.

[Bug tree-optimization/89134] A missing optimization opportunity for a simple branch in loop

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-02-01
 Ever confirmed|0   |1

--- Comment #6 from Martin Sebor  ---
The optimized dump of the following function:

  void f (std::map m)
  {
for (auto it = m.begin (); it != m.end (); ++it);
  }

shows the following loop:

   [local count: 955630224]:
  # it_14 = PHI <_4(2), _7(3)>
  _7 = std::_Rb_tree_increment (it_14);
  if (_7 != _11)
goto ; [89.00%]
  else
goto ; [11.00%]

The _Rb_tree_increment() function that implements the iterator increment is
declared pure in libstdc++-v3/include/bits/stl_tree.h:

   __attribute__ ((__pure__)) _Rb_tree_node_base*
_Rb_tree_increment(_Rb_tree_node_base* __x) throw ();

and defined in libstdc++-v3/src/c++98/tree.cc, so GCC should be able to make
use of the pure attribute to eliminate the loop since pure functions cannot
change the observable state of the program.  (This works when
_Rb_tree_increment() is defined in the test case above so that GCC sees that
its definition does, in fact, meet the requirements of a pure function.)

So I can confirm that GCC doesn't eliminate the empty loop.  Once the loop
contains calls to functions that aren't pure (like do_something() in comment
#0) the same optimization would no longer be valid.

[Bug tree-optimization/89145] GCC does not assume that two different external variables have different addresses

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-02-01
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
I can confirm this, though it's a known limitation documented in the
symtab_node::equal_address_to() function in symtab.c, and there probably is at
least one bug about it in Bugzilla.

  /* TODO: Alias oracle basically assume that addresses of global variables
 are different unless they are declared as alias of one to another while
 the code folding comparsions doesn't.
 We probably should be consistent and use this fact here, too, but for
 the moment return false only when we are called from the alias oracle.  */

This refers to assumptions about extern variables being distinct such as in the
test case below:

  int bar (void)
  {
int tmp = a;
b = 0;
if (tmp != a)   // folded to false
  __builtin_abort ();   // eliminated
  }

As a data point, Clang folds the the equality in the test case in comment #0 to
false.

That said, GCC itself makes it easy to violate this assumptions by making it
possible to define aliases such as in:

  int a;
  extern __attribute__ ((alias ("a"))) int b;

  extern int foo (void);

  int main (void)
  {
int i = foo ();
__builtin_printf ("%i\n", i);
  }

[Bug tree-optimization/89134] A missing optimization opportunity for a simple branch in loop

[jiangning.liu at amperecomputing dot com]

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

--- Comment #5 from Jiangning Liu  ---
The loop below should be treated as a finite loop,

for (iter = booktable.begin(); iter!=booktable.end(); ++iter) {
   ...
}

so there is a chance to optimize away the empty loop, in which do_something
doesn't exist at all.

[Bug c++/88983] [7/8 Regression] ICE in label_matches, at cp/constexpr.c:4035

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Target Milestone|--- |7.5
Summary|ICE in label_matches, at|[7/8 Regression] ICE in
   |cp/constexpr.c:4035 |label_matches, at
   ||cp/constexpr.c:4035

--- Comment #6 from Marek Polacek  ---
Fixed on trunk so far.

[Bug c++/88983] ICE in label_matches, at cp/constexpr.c:4035

[mpolacek at gcc dot gnu.org]

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

--- Comment #5 from Marek Polacek  ---
Author: mpolacek
Date: Fri Feb  1 00:30:46 2019
New Revision: 268438

URL: https://gcc.gnu.org/viewcvs?rev=268438=gcc=rev
Log:
PR c++/88983 - ICE with switch in constexpr function.
* constexpr.c (cxx_eval_switch_expr): Use SWITCH_COND and SWITCH_BODY.
(cxx_eval_constant_expression) : Don't look for the
label in the else branch if we found it in the then branch.

* g++.dg/cpp1y/constexpr-88983.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp1y/constexpr-88983.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/constexpr.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/89148] New: [AVR] Merge plugin to place C++ vtables in flash memory

[f.mach4 at gmail dot com]

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

Bug ID: 89148
   Summary: [AVR] Merge plugin to place C++ vtables in flash
memory
   Product: gcc
   Version: 8.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: f.mach4 at gmail dot com
  Target Milestone: ---

Hello,

C++ code using virtual functions and compiled with AVR-G++ results in excessive
SRAM usage on AVR devices. This is because vtables are copied into SRAM, when
it would instead be sufficient to access them from flash memory. This behaviour
has been known and discussed (e.g. in #43745) for quite a few years.

I have run into this issue myself, and know that it is a pain point of using
C++ on AVR for many in the Arduino and AVR communities. It may even contribute
to the reduced usage of C++ on AVR. (Illustration: searching 'AVR' on Github
returns 4440 results in C and only 1251 in C++.)

Anyway, I recently stumbled across a very elegant looking solution to this
problem, in the form of a GCC/G++ plugin. According to the plugin author
(https://github.com/jcmvbkbc/avr-flash-vtbl), it effectively adds the __flash
attribute to C++ vtables and vtable pointer types. Further analysis of the
issue is at https://habrahabr.ru/company/amperka/blog/264041 (need Google
translate because it's in Russian).

The full source of the plugin is just 18 lines of C:

#include 
#include 

int plugin_is_GPL_compatible = 1;

static void fn(void *gcc_data, void *user_data) {
TYPE_ADDR_SPACE (TREE_TYPE (vtbl_type_node)) = 1;
TYPE_ADDR_SPACE (TREE_TYPE (vtbl_ptr_type_node)) = 1;
}

int plugin_init (struct plugin_name_args *plugin_info,
 struct plugin_gcc_version *version) {
register_callback("", PLUGIN_START_UNIT, fn, NULL);
return 0;
}

So my question is, is there any way that this wonderful solution to a long
standing problem could be integrated into mainline G++, for example as a
target-specific flag (e.g. -fflash-vtables)? That way, it would be accessible
to the wider AVR community, many of whom would not know how to compile a GCC
plugin.

Many thanks,
Max

[Bug tree-optimization/89134] A missing optimization opportunity for a simple branch in loop

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org

--- Comment #4 from Martin Sebor  ---
Right, the problem is that do_something() could do one of the things that the
standard says permit loops to iterate infinitely:

  An iteration statement whose controlling expression is not a constant
expression, that performs no input/output operations, does not access volatile
objects, and performs no synchronization or atomic operations in its body,
controlling expression, or (in the case of for statement) its  expression-3,
may be assumed by the implementation to terminate.

If do_something() were declared pure like inc() it couldn't do any of those
things either and GCC should be able to assume the loop terminates.  It
doesn't, and in fact, it doesn't even in its absence.  For example, GCC doesn't
think the following loop necessarily terminates either:

  void test (int n)
  {
for (int i = 0; i < n; i = inc (i));
  }

Not even when inc() is declared const.

[Bug middle-end/89137] gcc/omp-low.c:7135: possible read of uninit memory ?

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Thu Jan 31 23:05:01 2019
New Revision: 268434

URL: https://gcc.gnu.org/viewcvs?rev=268434=gcc=rev
Log:
PR middle-end/89137
* omp-low.c (lower_omp_task_reductions): Drop redundant test to avoid
bogus clang warning.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/omp-low.c

[Bug lto/89147] flto removes functions implemented in asm

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
>Possible workarounds are welcome.

Use -ffat-lto-objects or use a .s file.

[Bug fortran/89077] ICE using * as len specifier for character parameter

[anlauf at gmx dot de]

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

--- Comment #8 from Harald Anlauf  ---
OK, here's another one for fun:

program pr89077_4
  implicit none
  character(*), parameter :: s = 7HForward
  print *, '#', s, '#', len (s)
end program pr89077_4

prints:

 #Forward #   8

This time it is really padded with a space which comes out of the blue.

Oracle sunf95 prints:

 #Forward# 7

Intel rejects it.

[Bug lto/89147] New: flto removes functions implemented in asm

[Hi-Angel at yandex dot ru]

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

Bug ID: 89147
   Summary: flto removes functions implemented in asm
   Product: gcc
   Version: 8.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Hi-Angel at yandex dot ru
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

This came up while researching why -flto build of Mesa fails with linking
errors. The asm snippet below is from an auto-generated code.

Possible workarounds are welcome.

# Steps to reproduce (in terms of terminal commands):

$ cat test.c 
__asm__( ".globl " "gl""NewList" "\n"
 ".type " "gl""NewList" ", @function\n"
 ".balign 16\n" "gl""NewList" ":""\n"
 "\t""call x86_current_tls\n\t"
 "movl %gs:(%eax), %eax\n\t"
 "jmp *(4 * " "0" ")(%eax)""\n"
 );
$ gcc -O3 test.c -o test.o -c -flto
$ nm test.o

# Expected

Output of `nm test.o`:
 T glNewList
 U x86_current_tls

# Actual

Output of `nm test.o`: 
nm: test.o: no symbols

[Bug c++/88983] ICE in label_matches, at cp/constexpr.c:4035

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

[Bug c++/88983] ICE in label_matches, at cp/constexpr.c:4035

[mpolacek at gcc dot gnu.org]

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

--- Comment #4 from Marek Polacek  ---
I except to have a fix in a bit.

[Bug target/89146] New: arm: "nor" constraint prefers memory reference over constant

[fw at gcc dot gnu.org]

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

Bug ID: 89146
   Summary: arm: "nor" constraint prefers memory reference over
constant
   Product: gcc
   Version: 8.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fw at gcc dot gnu.org
  Target Milestone: ---
Target: armv7l-unknown-linux-gnueabihf

This example:

#define C "nor"
void
f (int *x)
{
  asm volatile ("MARK %0, %1, %2, %3" :: C(0), C(x), C("string"), C(*x));
}

expands to:

MARK .L3, r0, r3, [r0]

The .L3 is entirely unexpected.

This probably does not matter to real Arm instructions because they do not have
a "no" alternative in their constraints.  But it also occurs with Systemtap
probes.  We could use "nr" instead, but that regresses slightly in case of
indirect memory references.

In the downstream bug, Jakub identified the source of the behavior:

“
The pushing of the constants into minipool happens in arm_reorg ->
note_invalid_constants
  /* Things we need to fix can only occur in inputs.  */
  if (recog_data.operand_type[opno] != OP_IN)
continue;

  /* If this alternative is a memory reference, then any mention
 of constants in this alternative is really to fool reload
 into allowing us to accept one there.  We need to fix them up
 now so that we output the right code.  */
  if (op_alt[opno].memory_ok)
{
  rtx op = recog_data.operand[opno];

  if (CONSTANT_P (op))
{
  if (do_pushes)
push_minipool_fix (insn, address, recog_data.operand_loc[opno],
   recog_data.operand_mode[opno], op);
}
and the rule it uses is simple, if the constraint allows a memory, then it
pushes it into memory, no matter whether it is also allowed to be a constant or
not.
”

[Bug fortran/88669] Contiguous attribute wrongly rejected

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

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

--- Comment #5 from Thomas Koenig  ---
Fixed on trunk, closing.

[Bug fortran/88669] Contiguous attribute wrongly rejected

[tkoenig at gcc dot gnu.org]

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

--- Comment #4 from Thomas Koenig  ---
Author: tkoenig
Date: Thu Jan 31 22:21:28 2019
New Revision: 268432

URL: https://gcc.gnu.org/viewcvs?rev=268432=gcc=rev
Log:
2019-01-31  Thomas Koenig  

PR fortran/88669
* resolve.c (resolve_component): If the reference is a BT_CLASS,
copy the contiguous attribute from the reference and use the
correct attributes.

2019-01-31  Thomas Koenig  

PR fortran/88669
* gfortran.dg/contiguous_9.f90: New test.


Added:
trunk/gcc/testsuite/gfortran.dg/contiguous_9.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/resolve.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/89077] ICE using * as len specifier for character parameter

[anlauf at gmx dot de]

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

--- Comment #7 from Harald Anlauf  ---
(In reply to Harald Anlauf from comment #6)

Playing around and getting completely lost during a gdb session,
I became suspicious that the second issue has to do with missed
padding that interestingly occurs also with Hollerith constants:

program pr89077_3
  implicit none
  integer,  parameter :: m = 20
  character(*), parameter :: s = 'Forward'
  character(m), parameter :: t = s
  character(m), parameter :: u = transfer (s, s)
  character(m), parameter :: v = 7HFORWARD
  character(m), parameter :: w = transfer (s, s) // ""
  print *, t, '#'
  print *, u, '#'
  print *, v, '#'
  print *, w, '#'
end program pr89077_3

This prints:

 % ./a.out | cat -v
 Forward #
 Forward^@^@^@Q^@M-P^@p^@^@^@^@a#
 FORWARD ^@^@Q^@M-P^@M-Pa^H^@M-ha#
 Forward #

[Bug c++/88983] ICE in label_matches, at cp/constexpr.c:4035

[mpolacek at gcc dot gnu.org]

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

--- Comment #3 from Marek Polacek  ---
I think I see the problem: we're evaluating the body of the switch, and cond is
"1" so we're jumping over everything until we find "case 1":

if (1)
  {
case 1:;
return  = 1;
  }
else
  {
default:;
  }

4681 case COND_EXPR:
4682   if (jump_target && *jump_target)

here jump target is "1"

4683 {
4684   /* When jumping to a label, the label might be either in the
4685  then or else blocks, so process then block first in skipping
4686  mode first, and if we are still in the skipping mode at its
end,
4687  process the else block too.  */
4688   r = cxx_eval_constant_expression (ctx, TREE_OPERAND (t, 1),
4689 lval, non_constant_p,
overflow_p,
4690 jump_target);

we found "case 1" in the then branch, but the next statement was "return", so
we have a new jump_target, which...

4691   if (*jump_target)

...confuses this condition, and we go looking to the else branch...

4692 r = cxx_eval_constant_expression (ctx, TREE_OPERAND (t, 2),
4693   lval, non_constant_p,
overflow_p,
4694   jump_target);

...where we crash.

[Bug tree-optimization/89145] New: GCC does not assume that two different external variables have different addresses

[m...@nieper-wisskirchen.de]

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

Bug ID: 89145
   Summary: GCC does not assume that two different external
variables have different addresses
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: m...@nieper-wisskirchen.de
  Target Milestone: ---

The module:

**
extern int p;
extern int q;

int foo (void)
{
return  == 
}
**

is compiled by `gcc -O3' to:

**
foo:
movl$p, %eax
cmpq$q, %rax
sete%al
movzbl  %al, %eax
ret
**

When at least one of the variables is declared static, gcc's optimizer kicks in
and yields:

**
foo:
xorl%eax, %eax
ret
**

Either, `gcc' is missing an optimization in the case of external variables, or
the addresses of different external variables can be the same, which sounds
strange to me.

A test with clang showed that it always produces the latter, optimized version.

[Bug target/86487] [7/8/9 Regression] insn does not satisfy its constraints on arm big-endian

[vmakarov at gcc dot gnu.org]

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

--- Comment #11 from Vladimir Makarov  ---
(In reply to avieira from comment #10)
> Hi Vlad,
> 
> I don't think it is a duplication.

Sorry, I was not clear.  My comment relates to test

#include 
int32x2_t b(long c, ...) {}

$ arm-none-eabi-gcc -march=armv7-a -c test.c -mfloat-abi=hard -mfpu=neon 
test.c: In function 'b':
test.c:1:1: error: insn does not satisfy its constraints:
1 | __simd64_int32_t b(long c, ...) {}
  | ^~~~
(insn 6 11 9 2 (set (reg/i:V2SI 0 r0)
(reg:V2SI 2 r2 [orig:110  ] [110])) "test.c":1:1 939
{*neon_movv2si}
 (nil))

[Bug middle-end/89008] [7/8 Regression] O2 and O1 results differ for simple test

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

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

--- Comment #16 from Bill Schmidt  ---
Latent SLSR bug is now fixed everywhere also.

[Bug middle-end/89008] [7/8 Regression] O2 and O1 results differ for simple test

[wschmidt at gcc dot gnu.org]

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

--- Comment #15 from Bill Schmidt  ---
Author: wschmidt
Date: Thu Jan 31 21:55:45 2019
New Revision: 268431

URL: https://gcc.gnu.org/viewcvs?rev=268431=gcc=rev
Log:
2018-01-31  Bill Schmidt  

Backport from mainline
2018-01-31  Bill Schmidt  

PR tree-optimization/89008
* gimple-ssa-strength-reduction.c (slsr_process_mul): Don't
process anything of the form X * 0.


Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/gimple-ssa-strength-reduction.c

[Bug tree-optimization/89143] [9 Regression] comparison of abs(i) against excessive constant less than UXXX_MAX no longer folded

[jakub at gcc dot gnu.org]

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

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

Untested fix.

[Bug c++/88983] ICE in label_matches, at cp/constexpr.c:4035

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #2 from Marek Polacek  ---
The ICE started with r217670 (though it's not the same backtrace).

[Bug target/89071] AVX vcvtsd2ss lets us avoid PXOR dependency breaking for scalar float<->double and other scalar xmm,xmm instructions

[ubizjak at gmail dot com]

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

--- Comment #12 from Uroš Bizjak  ---
(In reply to Peter Cordes from comment #10)

> It also bizarrely uses it for VMOVSS, which gcc should only emit if it
> actually wants to merge (right?).  *If* this part of the patch isn't a bug
> 
> - return "vmovss\t{%1, %0, %0|%0, %0, %1}";
> + return "vmovss\t{%d1, %0|%0, %d1}";
>  
> then even better would be vmovaps %1, %0 (which can benefit from
> mov-elimination, and doesn't need a port-5-only ALU uop.)  Same for vmovsd
> of course.

This is actually overridden in mode calculations, where it is disabled for
TARGET_SSE_PARTIAL_REG_DEPENDENCY targets.

[Bug c++/88983] ICE in label_matches, at cp/constexpr.c:4035

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-01-31
 CC||dmalcolm at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from David Malcolm  ---
Confirmed, *jump_target is a RETURN_EXPR here:

4000  switch (TREE_CODE (*jump_target))
4001{
4002case LABEL_DECL:
[..]
4006  break;
4007
4008case INTEGER_CST:
[..]
4032  break;
4033
4034default:
4035  gcc_unreachable ();  <--- aborts here
4036}

[Bug c++/80864] [7/8 Regression] Brace-initialization of a constexpr variable of an array in a POD triggers ICE from templates

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

Summary|[7/8/9 Regression]  |[7/8 Regression]
   |Brace-initialization of a   |Brace-initialization of a
   |constexpr variable of an|constexpr variable of an
   |array in a POD triggers ICE |array in a POD triggers ICE
   |from templates  |from templates

--- Comment #10 from Marek Polacek  ---
Fixed on trunk so far.

[Bug c++/80864] [7/8/9 Regression] Brace-initialization of a constexpr variable of an array in a POD triggers ICE from templates

[mpolacek at gcc dot gnu.org]

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

--- Comment #9 from Marek Polacek  ---
Author: mpolacek
Date: Thu Jan 31 20:21:11 2019
New Revision: 268428

URL: https://gcc.gnu.org/viewcvs?rev=268428=gcc=rev
Log:
PR c++/89083, c++/80864 - ICE with list initialization in template.
* constexpr.c (adjust_temp_type): Use copy_node and change the type
instead of using build_constructor.
* decl.c (reshape_init_r): Don't reshape a digested initializer.
Return the initializer for COMPOUND_LITERAL_P.

* g++.dg/cpp0x/initlist107.C: New test.
* g++.dg/cpp0x/initlist108.C: New test.
* g++.dg/cpp0x/initlist109.C: New test.
* g++.dg/cpp0x/initlist110.C: New test.
* g++.dg/cpp0x/initlist111.C: New test.
* g++.dg/cpp0x/initlist112.C: New test.
* g++.dg/init/ptrfn4.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/initlist107.C
trunk/gcc/testsuite/g++.dg/cpp0x/initlist108.C
trunk/gcc/testsuite/g++.dg/cpp0x/initlist109.C
trunk/gcc/testsuite/g++.dg/cpp0x/initlist110.C
trunk/gcc/testsuite/g++.dg/cpp0x/initlist111.C
trunk/gcc/testsuite/g++.dg/cpp0x/initlist112.C
trunk/gcc/testsuite/g++.dg/init/ptrfn4.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/constexpr.c
trunk/gcc/cp/decl.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/89083] [9 Regression] ICE in reshape_init_r, at cp/decl.c:6172

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #6 from Marek Polacek  ---
Fixed.

[Bug c++/89083] [9 Regression] ICE in reshape_init_r, at cp/decl.c:6172

[mpolacek at gcc dot gnu.org]

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

--- Comment #5 from Marek Polacek  ---
Author: mpolacek
Date: Thu Jan 31 20:21:11 2019
New Revision: 268428

URL: https://gcc.gnu.org/viewcvs?rev=268428=gcc=rev
Log:
PR c++/89083, c++/80864 - ICE with list initialization in template.
* constexpr.c (adjust_temp_type): Use copy_node and change the type
instead of using build_constructor.
* decl.c (reshape_init_r): Don't reshape a digested initializer.
Return the initializer for COMPOUND_LITERAL_P.

* g++.dg/cpp0x/initlist107.C: New test.
* g++.dg/cpp0x/initlist108.C: New test.
* g++.dg/cpp0x/initlist109.C: New test.
* g++.dg/cpp0x/initlist110.C: New test.
* g++.dg/cpp0x/initlist111.C: New test.
* g++.dg/cpp0x/initlist112.C: New test.
* g++.dg/init/ptrfn4.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/initlist107.C
trunk/gcc/testsuite/g++.dg/cpp0x/initlist108.C
trunk/gcc/testsuite/g++.dg/cpp0x/initlist109.C
trunk/gcc/testsuite/g++.dg/cpp0x/initlist110.C
trunk/gcc/testsuite/g++.dg/cpp0x/initlist111.C
trunk/gcc/testsuite/g++.dg/cpp0x/initlist112.C
trunk/gcc/testsuite/g++.dg/init/ptrfn4.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/constexpr.c
trunk/gcc/cp/decl.c
trunk/gcc/testsuite/ChangeLog

[Bug target/89071] AVX vcvtsd2ss lets us avoid PXOR dependency breaking for scalar float<->double and other scalar xmm,xmm instructions

[uros at gcc dot gnu.org]

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

--- Comment #11 from uros at gcc dot gnu.org ---
Author: uros
Date: Thu Jan 31 20:06:42 2019
New Revision: 268427

URL: https://gcc.gnu.org/viewcvs?rev=268427=gcc=rev
Log:
PR target/89071
* config/i386/i386.md (*extendsfdf2): Split out reg->reg
alternative to avoid partial SSE register stall for TARGET_AVX.
(truncdfsf2): Ditto.
(sse4_1_round2): Ditto.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.md

[Bug rtl-optimization/88296] [9 Regression] Infinite loop in lra_split_hard_reg_for

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug rtl-optimization/88296] [9 Regression] Infinite loop in lra_split_hard_reg_for

[vmakarov at gcc dot gnu.org]

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

--- Comment #5 from Vladimir Makarov  ---
(In reply to Jakub Jelinek from comment #3)
> for Vlad the question
> is just whether r266862 is a real fix or just made it latent.  Given that
> both are IRA costs changes, I assume it is a real fix.

I've checked the generated code difference.  The recent code uses more accurate
register classes and as the result avoid LRA cycling.  So I believe the patch
is a real fix for the PR.  But I think there is still possibility that the 1st
insn scheduler can create a situation when RA (as the old reload) can fail
because of existing constraints in hard register splitting in LRA.  This
problem is less severe every year but still exists and honestly I don't know
when it will be fully solved.

As for this PR, I think it should be closed.

[Bug lto/89084] [9 Regression] ICE in get_partitioning_class, at symtab.c:1892

[dmalcolm at gcc dot gnu.org]

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

--- Comment #2 from David Malcolm  ---
Fails this assertion:

1892  gcc_checking_assert (vnode->definition);

(gdb) p vnode
$3 = 

[Bug tree-optimization/89143] [9 Regression] comparison of abs(i) against excessive constant less than UXXX_MAX no longer folded

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

[Bug target/89125] Misoptimization of converting sin(x) and cos(x) into sincos(x,,)

[kargl at gcc dot gnu.org]

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

--- Comment #8 from kargl at gcc dot gnu.org ---
(In reply to kargl from comment #6)
> Checking with FreeBSD developers on C99 compliance.

The answer is 'no'.  FreeBSD's C runtime libraries 
(libc+libm) are not fully C99 complaint.  It is a shame,
too.

Unfortunately and I should have remembered, FreeBSD's C runtime
libraries (ie libc+libm) are not C99 compliant.  The problem (for me)
is that function_c99_math_complex indicates that libm includes
a complete set of C99 complex math function, which of course
it doesn't.  Testing with GCC trunk gives

1 default_libc_has_function  (C99 compliant libc+libm)
2 no_c99_libc_has_function   (FreeBSD current setting)

  12
=== gcc Summary ===
# of expected passes134923   134887
# of unexpected failures171  207   <-- This is good.
# of unexpected successes   27   27
# of expected failures  550  550
# of unresolved testcases   14   14
# of unsupported tests   

=== g++ Summary ===
# of expected passes124009   124009
# of unexpected failures41   41
# of expected failures  548  548
# of unsupported tests  5585 5585

=== gfortran Summary ===
# of expected passes4899248993
# of unexpected failures21 <-- This is bad.
# of expected failures  130  130
# of unsupported tests  88   88

'This is bad' occurs because FreeBSD is missing cexpl
and the fallback in libgfortran/intrinsics/c99_functions.c
seems to be broken on FreeBSD if default_libc_has_function
is used.

[Bug lto/89084] [9 Regression] ICE in get_partitioning_class, at symtab.c:1892

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-01-31
 CC||dmalcolm at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from David Malcolm  ---
Confirmed (on godbolt with x86_64 trunk, and a regression relative to gcc 8.2)

[Bug c++/89144] New: GCC emits undefined references when a constexpr initializer_list appears in a template function

[m101010a at gmail dot com]

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

Bug ID: 89144
   Summary: GCC emits undefined references when a constexpr
initializer_list appears in a template function
   Product: gcc
   Version: 8.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: m101010a at gmail dot com
  Target Milestone: ---

$ cat x.cpp
#include 
template  void b() {
constexpr std::initializer_list c{};
}
int main() { b(); }
$ g++ x.cpp
/bin/ld: /tmp/ccqq90fA.o: in function `void b()':
x.cpp:(.text._Z1bIiEvv[_Z1bIiEvv]+0x7): undefined reference to `._0'
collect2: error: ld returned 1 exit status
$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/8.2.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib
--libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared
--enable-threads=posix --enable-libmpx --with-system-zlib --with-isl
--enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu
--disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object
--enable-linker-build-id --enable-lto --enable-plugin
--enable-install-libiberty --with-linker-hash-style=gnu
--enable-gnu-indirect-function --enable-multilib --disable-werror
--enable-checking=release --enable-default-pie --enable-default-ssp
--enable-cet=auto
Thread model: posix
gcc version 8.2.1 20181127 (GCC) 

This happens whether or not the initializer list has any elements.  It does not
happen if the list is not constexpr, and does not happen if b is not a
template.  This also happens when using mingw.

[Bug tree-optimization/89134] A missing optimization opportunity for a simple branch in loop

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

 CC||dmalcolm at gcc dot gnu.org

--- Comment #3 from David Malcolm  ---
"inc" may be pure, but "do_something" isn't, so I don't see how it's valid to
optimize away the loop.

Consider e.g. this implementation in another TU:

int call_count;

int do_something(void)
{
  call_count++;
  return 1;
}

...or somesuch.

(also "b" is global, so presumably there could be another thread touching it,
or observing the changes made by the loop)

[Bug target/88917] [8/9 Regression] Error: can't resolve `.text' {.text section} - `.LCFI2' {.text.unlikely section} with -fno-dwarf2-cfi-asm

[fw at gcc dot gnu.org]

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

Florian Weimer  changed:

   What|Removed |Added

 CC||hjl.tools at gmail dot com

--- Comment #3 from Florian Weimer  ---
Isn't -fasynchronous-unwind-tables part of the GNU/Linux ABI and enabled by
default?  Without it, asynchronous cancellation does not work.

Can we simplify this if we require frame pointers when using inline thunks?  Or
get rid of inline thunks altogether?

[Bug c/89127] missing -Wtype-limits for trivially false expressions

[msebor at gcc dot gnu.org]

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

--- Comment #3 from Martin Sebor  ---
I see what you mean.  It might perhaps be useful to mention the bigint rule of
thumb in the manual.  At the same time, the warning still doesn't work even
under this restricted interpretation.  For example, in:

  void f (unsigned char i)
  {
if (2 * i > 2 * UCHAR_MAX)
  __builtin_abort ();
  }

the comparison is trivially false due to the limited range of i's type.  GCC
sees that and in EVRP eliminates it, but without issuing the warning (or a
warning).

That said, the distinction is rather subtle between (i * i < 0) being false
because of multiplication's mathematical properties and (2 * i > 2 * UCHAR_MAX)
being false because of i's limited range.  As a user, my expectation is to get
a warning for comparisons that cannot be true, especially in controlling
expressions of conditional and iteration statements.  Whether that's because of
a limited range of the type of the expression or for some other reason is
unimportant.  What matters to me is that the code I wrote is not dead.

Incidentally, besides the warning not working as I expect, the test cases in
comment #0 were partly prompted by the implementation of the warning in
vr-values.c where I had initially assumed some of these expressions might be
handled.  Obviously, they're not because, as the original dump shows, they
never make it anywhere near VRP, but I hadn't taken the time to come up with
test cases that do make it there.  I have now spent some more time trying to
come up with one but so far no luck.  It doesn't even look like anything in the
test suite exercises that code, even with -Wtype-limits enabled by default.

Here are a few other trivial examples where a warning would be helpful (and,
IIUC, should be issued even under the strict interpretation):

  extern unsigned char i;

  if (i >> 31 != 0) __builtin_abort ();
  if (i / 2 > 200) __builtin_abort ();
  if (i & 0x100 != 0) __builtin_abort ();

And here's one where GCC not only doesn't warn, the trunk doesn't even fold it
anymore (GCC 8 does fold it; this is due to pr89143):

  void f (signed char i)
  {
if (__builtin_abs (i) > SCHAR_MAX + 1)
  __builtin_abort ();
  }

[Bug tree-optimization/89143] [9 Regression] comparison of abs(i) against excessive constant less than UXXX_MAX no longer folded

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||missed-optimization
  Known to work||7.3.0, 9.0
  Known to fail||9.0

--- Comment #1 from Martin Sebor  ---
Bisection points to r261681:

gcc/ChangeLog:

2018-06-16  Kugan Vivekanandarajah  

PR middle-end/64946
* cfgexpand.c (expand_debug_expr): Hande ABSU_EXPR.
* config/i386/i386.c (ix86_add_stmt_cost): Likewise.
* dojump.c (do_jump): Likewise.
* expr.c (expand_expr_real_2): Check operand type's sign.
* fold-const.c (const_unop): Handle ABSU_EXPR.
(fold_abs_const): Likewise.
* gimple-pretty-print.c (dump_unary_rhs): Likewise.
* gimple-ssa-backprop.c (backprop::process_assign_use): Likesie.
(strip_sign_op_1): Likesise.
* match.pd: Add new pattern to generate ABSU_EXPR.
* optabs-tree.c (optab_for_tree_code): Handle ABSU_EXPR.
* tree-cfg.c (verify_gimple_assign_unary): Likewise.
* tree-eh.c (operation_could_trap_helper_p): Likewise.
* tree-inline.c (estimate_operator_cost): Likewise.
* tree-pretty-print.c (dump_generic_node): Likewise.
* tree-vect-patterns.c (vect_recog_sad_pattern): Likewise.
* tree.def (ABSU_EXPR): New.

[Bug tree-optimization/89143] New: [9 Regression] comparison of abs(i) against excessive constant less than UXXX_MAX no longer folded

[msebor at gcc dot gnu.org]

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

Bug ID: 89143
   Summary: [9 Regression] comparison of abs(i) against excessive
constant less than UXXX_MAX no longer folded
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

While looking into bug 89127 I noticed that while GCC 8 and prior fold the
comparison to false in the if controlling expression below due to the limited
range of i's type, GCC 9 no longer performs this folding unless the constant is
 UCHAR_MAX and greater.  Same for short and SHRT_MAX + 1.

$ cat u.c && gcc -S -O2 -Wall -Wextra -Wtype-limits
-fdump-tree-optimized=/dev/stdout u.c
void f (signed char i)
{
  if (__builtin_abs (i) > 128)
__builtin_abort ();
}

;; Function f (f, funcdef_no=0, decl_uid=1906, cgraph_uid=1, symbol_order=0)

f (signed char i)
{
  unsigned char _1;

   [local count: 1073741824]:
  _1 = ABSU_EXPR ;
  if (_1 > 128)
goto ; [0.00%]
  else
goto ; [100.00%]

   [count: 0]:
  __builtin_abort ();

   [local count: 1073741824]:
  return;

}

[Bug d/87864] libdruntime doesn't link with /bin/ld before Solaris 11.4

[johannespfau at gmail dot com]

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

Johannes Pfau  changed:

   What|Removed |Added

 CC||johannespfau at gmail dot com

--- Comment #7 from Johannes Pfau  ---
> The Minfo_Bracketing assert in sections_elf_shared.d fails now, of
> course, but the file is usable even without linker-provided
> bracketing.  Should this go completely?

I think the assert should go, it doesn't belong there anyway. Minfo_Bracketing
is unused then, AFAICS, so it should be fine to also remove it from
gcc/config.d.

Other changes look fine.

[Bug target/88917] [8/9 Regression] Error: can't resolve `.text' {.text section} - `.LCFI2' {.text.unlikely section} with -fno-dwarf2-cfi-asm

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||fw at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
So, perhaps easiest is to revert the PR87414 changes and just error out on
-fasynchronous-unwind-tables with -mindirect-branch=thunk-inline.

The following testcase shows various cases:
void foo (char *);

int
f1 (int (*f) (void))
{
  return f ();
}

int
f2 (int (*f) (void))
{
  foo (0);
  return f ();
}

int
f3 (int (*f) (void))
{
  foo (0);
  return f () + 1;
}

int
f4 (int (*f) (void), int x)
{
  char buf[x];
  foo (buf);
  return f () + 1;
}

__attribute__((optimize ("no-omit-frame-pointer"))) int
f5 (int (*f) (void))
{
  foo (0);
  return f ();
}

The unwind info is incorrect in f3 (the CFA is already %rsp+16 before the call,
so for the mov + ret instruction we need %rsp+24 and then revert), f4 (CFA is
%rbp, so we shouldn't change CFA offset at all).
So, we'd need to figure out if CFA is sp or bp at the instruction (is it call
always?) for which we emit the thunk and only if it is sp, increase offset by
word size and decrease afterwards.
Furthermore, for -fno-dwarf2-cfi-asm, we likely need to search the CFI
instruction array and find where exactly to insert the new CFI, rather than
appending it.  What a mess!

[Bug d/88150] Use sections_elf_shared.d on Solaris

[johannespfau at gmail dot com]

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

Johannes Pfau  changed:

   What|Removed |Added

 CC||code at dawg dot eu,
   ||johannespfau at gmail dot com

--- Comment #8 from Johannes Pfau  ---
Regarding the _d_dso_registry issue: Yes, as far as I can see it is a bug that
handleForName dlcloses the handle here. I think what happened is this:

handleForName is used in one place with the comment
// get handle without loading the library
so it is supposed to unload the library there.
But it is also called from handleForAddr which is used to get the DSO handle to
be stored using setDSOForHandle. I think here, it's not really valid to store
the closed handle.

Let's ping the expert here though, I've added Martin Nowak to CC.

[Bug debug/87451] FAIL: gcc.dg/debug/dwarf2/inline5.c

[sje at gcc dot gnu.org]

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

--- Comment #11 from Steve Ellcey  ---
(In reply to Richard Biener from comment #10)
> (In reply to Steve Ellcey from comment #9)

> Looks like that's because of different expected comment characters,
> # vs. // in your file.  The pattern for the comment stuff is
> 
> \[^#/!\]*\[#/!\] DW
> 
> skip until first comment-char (ok), then consume comment (bogus).  Adding
> + might help.  Can you check that?

Yes, that patch fixed the failure I was seeing on aarch64.

[Bug rtl-optimization/88596] [9 Regression] ICE: Maximum number of LRA assignment passes is achieved (30)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
I can't reproduce even with r267379 (nor current trunk).  Tried even with
-mtune=skylake-avx512, -mtune=haswell, -mtune=generic, nothing triggers it.

[Bug debug/87295] [8 Regression][early debug] ICE with -ffat-lto-objects -fdebug-types-section -g

[hubicka at gcc dot gnu.org]

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

--- Comment #7 from Jan Hubicka  ---
It seems that this breaks debug-types-sections w/o LTO as well now.
./xgcc -B ./ -O2 -g ~/tramp3d-v44.ii -fdebug-types-section
/aux/hubicka/tramp3d-v4b.cpp:56088:1: internal compiler error: in
build_abbrev_table, at dwarf2out.c:9061
56088 | }
  | ^
0x720707 build_abbrev_table
../../gcc/dwarf2out.c:9061
0xc3dee7 build_abbrev_table
../../gcc/dwarf2out.c:9112
0xc40e7b output_comdat_type_unit
../../gcc/dwarf2out.c:11237
0xc6678d dwarf2out_finish
../../gcc/dwarf2out.c:31496
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/89122] bad fix-it hint for FLT_MAX when is included

[dmalcolm at gcc dot gnu.org]

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

--- Comment #3 from David Malcolm  ---
Author: dmalcolm
Date: Thu Jan 31 18:09:29 2019
New Revision: 268426

URL: https://gcc.gnu.org/viewcvs?rev=268426=gcc=rev
Log:
Fix bogus fix-it for FLT_MAX (PR c/89122)

PR c/89122 reports that we emit a bogus fix-it hint for the case where
the code uses FLT_MAX, but has included  rather than :

x.c:3:11: error: 'FLT_MAX' undeclared here (not in a function); did you
  mean 'INT_MAX'?
3 | float f = FLT_MAX;
  |   ^~~
  |   INT_MAX

This patch adds some knowledge of  (and ) to
known-headers.cc, fixing the issue:

x.c:3:11: error: 'FLT_MAX' undeclared here (not in a function)
3 | float f = FLT_MAX;
  |   ^~~
x.c:2:1: note: 'FLT_MAX' is defined in header ''; did you forget
  to '#include '?
1 | #include 
  +++ |+#include 
2 |

gcc/c-family/ChangeLog:
PR c/89122
* known-headers.cc (get_stdlib_header_for_name): Add
{FLT|DBL|LDBL}_{MAX|MIN} to "hints" array.

gcc/testsuite/ChangeLog:
PR c/89122
* g++.dg/spellcheck-stdlib.C (test_FLT_MAX): New test.
* gcc.dg/spellcheck-stdlib.c (test_FLT_MAX): New test.


Modified:
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/known-headers.cc
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/spellcheck-stdlib.C
trunk/gcc/testsuite/gcc.dg/spellcheck-stdlib.c

[Bug c/89122] bad fix-it hint for FLT_MAX when is included

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #4 from David Malcolm  ---
Should be fixed by r268426.

[Bug preprocessor/89142] Allow poisoning identifier from the command line

[fw at gcc dot gnu.org]

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

Florian Weimer  changed:

   What|Removed |Added

 CC||fw at gcc dot gnu.org

--- Comment #2 from Florian Weimer  ---
And with bash, you don't even need a separate file, you can use something like
this:

  -include <(echo '#pragma GCC poison IDENTIFIER')

[Bug bootstrap/88714] [9 regression] bootstrap comparison failure on armv7l since r265398

[matmal01 at gcc dot gnu.org]

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

--- Comment #31 from Matthew Malcomson  ---
(In reply to Jakub Jelinek from comment #30)
> (In reply to Matthew Malcomson from comment #29)
> > I've been working on a patch that does very similar to the draft patch 
> > posted
> > above, and I notice a few things I've tried to avoid in it.
> > I doubt there are any actual bugs, since I don't know if the patterns that
> > trigger actual faults can occur at the moment.
> > 
> > 
> > 
> > Using the `address_operand` predicate and 'p' constraint to ensure the
> > address
> > is a valid address would use the mode SImode of the operand rather than
> > checking
> > it's valid for the DImode of the emitted ldrd.
> 
> Sure, but does it really matter?
> This is a post reload pattern created by the peephole2s, so nothing that can
> be matched out of the blue sky like combiner normally matches.
> So, if it didn't pass the conditions in the peephole2s, the patterns
> wouldn't be created.

True -- as I mentioned I don't know if a problematic pattern could actually
occur, so I doubt this is actually a problem.

> Are there any addresses that pass arm_legitimate_address_p (DImode, x, true)
> and fail address_operand (x, SImode)?  From brief skimming I couldn't find
> anything.
> So, would you be happy if the && arm_legitimate_address_p (DImode, XEXP
> (operands[n], 0), true)
> condition is added to the insn conditions (after the rtx_equal_p check)?

That sounds good to me.

> 
> > There's a similar problem to the `address_operand` one above with using the
> > `arm_count_output_move_double_insns` function.
> > 
> > It's called on the original operands, which means it eventually calls
> > `output_move_double` with the first two operands (which are in SImode).
> > 
> > This function has some calls to `reg_overlap_mentioned_p`, which depends on
> > the
> > number of hard registers for a given registers mode.
> > 
> > I've only found cases where the `arm_count_output_move_double_insns` 
> > function
> > returns something other than what it should in cases that only match because
> > of
> > the `address_operand` problem above.
> > 
> > This could be replaced by a wrapper that generates DImode registers
> > specifically
> > for checking this.
> 
> For non-vfp or iwmmxt, the length is always 8, are there cases in the vfp
> insn that the length is not 8?

I believe the length *can* be 4 non-vfp, vfp, or iwmmxt (the case below
produces a single ldrd when compiled with each of them).

int __RTL (startwith ("peephole2")) foo_x4 (int *a)
{
(function "foo_x4"
  (insn-chain
(cnote 1 NOTE_INSN_DELETED)
(block 2
  (edge-from entry (flags "FALLTHRU"))
  (cnote 3 [bb 2] NOTE_INSN_BASIC_BLOCK)
  (cinsn 101 (set (reg:SI r2)
  (mem/c:SI (plus:SI (reg:SI r0) (const_int 8)) [0 S4
A64])) "/home/matmal01/test.c":18)
  (cinsn 102 (set (reg:SI r3)
  (mem/c:SI (plus:SI (reg:SI r0) (const_int 12)) [0 S4
A32])) "/home/matmal01/test.c":18)
  (cinsn 103 (set (reg:SI r0)
  (plus:SI (reg:SI r2) (reg:SI r3)))
"/home/matmal01/test.c":18)
  (edge-to exit (flags "FALLTHRU"))
) ;; block 2
  ) ;; insn-chain
  (crtl
(return_rtx 
  (reg/i:SI r0)
) ;; return_rtx
  ) ;; crtl
) ;; function "main"
}




Something else I've just noticed:
When compiling for vfp or iwmmxt, the ldm2_ define_insn matches the simpler
case below as it comes first in the md order.
That means we get a ldm instruction instead of the ldrd.

int __RTL (startwith ("peephole2")) foo_x5 (int *a)
{
(function "foo_x5"
  (insn-chain
(cnote 1 NOTE_INSN_DELETED)
(block 2
  (edge-from entry (flags "FALLTHRU"))
  (cnote 3 [bb 2] NOTE_INSN_BASIC_BLOCK)
  (cinsn 101 (set (reg:SI r2)
  (mem/c:SI (reg:SI r0) [0 S4 A64]))
"/home/matmal01/test.c":18)
  (cinsn 102 (set (reg:SI r3)
  (mem/c:SI (plus:SI (reg:SI r0) (const_int 4)) [0 S4
A32])) "/home/matmal01/test.c":18)
  (cinsn 103 (set (reg:SI r0)
  (plus:SI (reg:SI r2) (reg:SI r3)))
"/home/matmal01/test.c":18)
  (edge-to exit (flags "FALLTHRU"))
) ;; block 2
  ) ;; insn-chain
  (crtl
(return_rtx 
  (reg/i:SI r0)
) ;; return_rtx
  ) ;; crtl
) ;; function "main"
}

[Bug preprocessor/89142] Allow poisoning identifier from the command line

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||jakub at gcc dot gnu.org
 Resolution|--- |WONTFIX

--- Comment #1 from Jakub Jelinek  ---
Just put it into a new header file and use
-include /whatever/header_with_gcc_poison.h
on the command line.

[Bug libfortran/78314] [aarch64] ieee_support_halting does not report unsupported fpu traps correctly

[nsz at gcc dot gnu.org]

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

nsz at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #15 from nsz at gcc dot gnu.org ---
i unassigned myself as i'm not working on this right now.

[Bug libfortran/78314] [aarch64] ieee_support_halting does not report unsupported fpu traps correctly

[nsz at gcc dot gnu.org]

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

--- Comment #14 from nsz at gcc dot gnu.org ---
(In reply to Uroš Bizjak from comment #13)
> (In reply to nsz from comment #12)
> > i don't know how to change this to false for IEEE_SUPPORT_HALTING
> > on aarch64 and arm targets, but that would be a possible fix.
> 
> --cut here--
> Index: libgfortran/config/fpu-glibc.h

that only turns the runtime check into "always false"

but the compile time check is still "always true".

which is still broken.

[Bug preprocessor/89142] New: Allow poisoning identifier from the command line

[Simon.Richter at hogyros dot de]

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

Bug ID: 89142
   Summary: Allow poisoning identifier from the command line
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: preprocessor
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Simon.Richter at hogyros dot de
  Target Milestone: ---

I'm currently refactoring a program that uses a preprocessor symbol in various
places, and I'd like to generate errors for all uses.

There is no common header file in which I could place a `#pragma gcc poison`
directive, but I can modify the CPPFLAGS globally.

It would be nice to have a way to add poisoned preprocessor symbols from the
command line.

[Bug tree-optimization/88107] [7/8/9 Regression] ICE in find_outermost_region_in_block, at tree-cfg.c:7157

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #4 from Jakub Jelinek  ---
Created attachment 45577
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45577=edit
gcc9-pr88107.patch

Untested fix.

[Bug middle-end/89008] [7/8 Regression] O2 and O1 results differ for simple test

[wschmidt at gcc dot gnu.org]

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

--- Comment #14 from Bill Schmidt  ---
Author: wschmidt
Date: Thu Jan 31 17:14:36 2019
New Revision: 268425

URL: https://gcc.gnu.org/viewcvs?rev=268425=gcc=rev
Log:
2018-01-31  Bill Schmidt  

Backport from mainline
2018-01-31  Bill Schmidt  

PR tree-optimization/89008
* gimple-ssa-strength-reduction.c (slsr_process_mul): Don't
process anything of the form X * 0.


Modified:
branches/gcc-8-branch/gcc/ChangeLog
branches/gcc-8-branch/gcc/gimple-ssa-strength-reduction.c

[Bug rtl-optimization/88596] [9 Regression] ICE: Maximum number of LRA assignment passes is achieved (30)

[asolokha at gmx dot com]

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

--- Comment #2 from Arseny Solokha  ---
I'll check it on the next trunk snapshot and report back next Monday.

[Bug bootstrap/88714] [9 regression] bootstrap comparison failure on armv7l since r265398

[jakub at gcc dot gnu.org]

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

--- Comment #30 from Jakub Jelinek  ---
(In reply to Matthew Malcomson from comment #29)
> I've been working on a patch that does very similar to the draft patch posted
> above, and I notice a few things I've tried to avoid in it.
> I doubt there are any actual bugs, since I don't know if the patterns that
> trigger actual faults can occur at the moment.
> 
> 
> 
> Using the `address_operand` predicate and 'p' constraint to ensure the
> address
> is a valid address would use the mode SImode of the operand rather than
> checking
> it's valid for the DImode of the emitted ldrd.

Sure, but does it really matter?
This is a post reload pattern created by the peephole2s, so nothing that can be
matched out of the blue sky like combiner normally matches.
So, if it didn't pass the conditions in the peephole2s, the patterns wouldn't
be created.
Are there any addresses that pass arm_legitimate_address_p (DImode, x, true)
and fail address_operand (x, SImode)?  From brief skimming I couldn't find
anything.
So, would you be happy if the && arm_legitimate_address_p (DImode, XEXP
(operands[n], 0), true)
condition is added to the insn conditions (after the rtx_equal_p check)?

> There's a similar problem to the `address_operand` one above with using the
> `arm_count_output_move_double_insns` function.
> 
> It's called on the original operands, which means it eventually calls
> `output_move_double` with the first two operands (which are in SImode).
> 
> This function has some calls to `reg_overlap_mentioned_p`, which depends on
> the
> number of hard registers for a given registers mode.
> 
> I've only found cases where the `arm_count_output_move_double_insns` function
> returns something other than what it should in cases that only match because
> of
> the `address_operand` problem above.
> 
> This could be replaced by a wrapper that generates DImode registers
> specifically
> for checking this.

For non-vfp or iwmmxt, the length is always 8, are there cases in the vfp insn
that the length is not 8?

> I think generation of patterns of the form 
> (plus:SI (plus:SI (reg) (const_int)) (const_int)) 
> which can happen with these peepholes isn't very nice.

Why?  I've done that intentionally, so that it is easy to verify it is 4 bytes
appart, otherwise one needs to handle all the different cases where address is
this and that etc.  This whole MEM isn't an operand in the instruction, just
mere RTL.  Combiner doesn't run after peephole2 and if something tries to
canonicalize that some way, it will simply fail to be recognized and it will
not try that canonicalization.

[Bug libfortran/78314] [aarch64] ieee_support_halting does not report unsupported fpu traps correctly

[ubizjak at gmail dot com]

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

--- Comment #13 from Uroš Bizjak  ---
(In reply to nsz from comment #12)
> i don't know how to change this to false for IEEE_SUPPORT_HALTING
> on aarch64 and arm targets, but that would be a possible fix.

--cut here--
Index: libgfortran/config/fpu-glibc.h
===
--- libgfortran/config/fpu-glibc.h  (revision 268424)
+++ libgfortran/config/fpu-glibc.h  (working copy)
@@ -129,6 +129,10 @@
 int
 support_fpu_trap (int flag)
 {
+#if defined(__arm__) || defined(__aarch64__)
+  return 0;
+#endif
+
   return support_fpu_flag (flag);
 }

--cut here--

[Bug c++/89138] ICE on valid C++11 code: in expand_expr_real_1, at expr.c:9993

[asolokha at gmx dot com]

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

Arseny Solokha  changed:

   What|Removed |Added

 CC||asolokha at gmx dot com

--- Comment #2 from Arseny Solokha  ---
I guess it may be a duplicate of PR60855 and (or) PR86432.

[Bug rtl-optimization/88596] [9 Regression] ICE: Maximum number of LRA assignment passes is achieved (30)

[vmakarov at gcc dot gnu.org]

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

Vladimir Makarov  changed:

   What|Removed |Added

 CC||vmakarov at gcc dot gnu.org

--- Comment #1 from Vladimir Makarov  ---
I cannot reproduce it anymore on today trunk.  Probably some recent RA patch
solved the problem.

[Bug libbacktrace/89136] libbacktrace/elf.c:2941: suspicious assignment

[dcb314 at hotmail dot com]

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

--- Comment #7 from David Binderman  ---
(In reply to Tom de Vries from comment #5)
> Thanks for finding and reporting this.

You are welcome. I was testing new clang-8.0.0-rc1
and hadn't compiled gcc with clang for a while.

clang warns for "=+" and it isn't a new warning in clang-8.0.0-rc1.

[Bug bootstrap/88714] [9 regression] bootstrap comparison failure on armv7l since r265398

[matmal01 at gcc dot gnu.org]

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

Matthew Malcomson  changed:

   What|Removed |Added

 CC||matmal01 at gcc dot gnu.org

--- Comment #29 from Matthew Malcomson  ---
Hi Jakub,

I've been working on a patch that does very similar to the draft patch posted
above, and I notice a few things I've tried to avoid in it.
I doubt there are any actual bugs, since I don't know if the patterns that
trigger actual faults can occur at the moment.



Using the `address_operand` predicate and 'p' constraint to ensure the address
is a valid address would use the mode SImode of the operand rather than
checking
it's valid for the DImode of the emitted ldrd.

If this happens we generate an ICE in the `adjust_address` call just before
`output_move_double`.

I don't know if such a pattern can actually be generated, but we could use
`arm_legitimate_address_p (DImode, XEXP (operands[1], 0), true)` in the
condition to avoid it just in case.



There's a similar problem to the `address_operand` one above with using the
`arm_count_output_move_double_insns` function.

It's called on the original operands, which means it eventually calls
`output_move_double` with the first two operands (which are in SImode).

This function has some calls to `reg_overlap_mentioned_p`, which depends on the
number of hard registers for a given registers mode.

I've only found cases where the `arm_count_output_move_double_insns` function
returns something other than what it should in cases that only match because of
the `address_operand` problem above.

This could be replaced by a wrapper that generates DImode registers
specifically
for checking this.

---

I think generation of patterns of the form 
(plus:SI (plus:SI (reg) (const_int)) (const_int)) 
which can happen with these peepholes isn't very nice.
I can't find any constraint against these patterns in the canonicalization
rules (maybe there should be?) so I can't say this is an actual problem.


As an example: the following
int __RTL (startwith ("peephole2")) foo_x4 (int *a)
{
(function "foo_x4"
  (insn-chain
(cnote 1 NOTE_INSN_DELETED)
(block 2
  (edge-from entry (flags "FALLTHRU"))
  (cnote 3 [bb 2] NOTE_INSN_BASIC_BLOCK)
  (cinsn 101 (set (reg:SI r2)
  (mem/c:SI (plus:SI (reg:SI r0) (const_int 8)) [0 S4
A64])) "/home/matmal01/test.c":18)
  (cinsn 102 (set (reg:SI r3)
  (mem/c:SI (plus:SI (reg:SI r0) (const_int 12)) [0 S4
A32])) "/home/matmal01/test.c":18)
  (cinsn 103 (set (reg:SI r0)
  (plus:SI (reg:SI r2) (reg:SI r3)))
"/home/matmal01/test.c":18)
  (edge-to exit (flags "FALLTHRU"))
) ;; block 2
  ) ;; insn-chain
  (crtl
(return_rtx 
  (reg/i:SI r0)
) ;; return_rtx
  ) ;; crtl
) ;; function "main"
}

Produces
(insn 104 3 103 2 (parallel [
(set (reg:SI 2 r2)
(mem/c:SI (plus:SI (reg:SI 0 r0)
(const_int 8 [0x8])) [0 S4 S4 A64]))
(set (reg:SI 3 r3)
(mem/c:SI (plus:SI (plus:SI (reg:SI 0 r0)
(const_int 8 [0x8]))
(const_int 4 [0x4])) [0 S4 S4 A32]))
]) -1
 (nil))


Maybe we could use the existing operands, and match with
`rtx_equal_p (..., plus_constant (...))`
so that the plus_constant can take care of adding the constants together.
This is what we do in the load_pair patterns for aarch64.




There are a few other tidy-up points around the define_insn patterns, but
overall I believe they can be merged into one pattern.
The difference between the 'q' and 'r' constraints are using either CORE_REGS
or
GENERAL_REGS, where CORE_REGS allows r13 and GENERAL_REGS doesn't.
I guess this is from a line in infocenter that mentions r12 is strongly
recommended to not be used as the first register for ldrdb, as this is stopped
by requiring both the first and second register to not be r13.
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0489c/Cihjffga.html

[Bug libfortran/78314] [aarch64] ieee_support_halting does not report unsupported fpu traps correctly

[nsz at gcc dot gnu.org]

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

--- Comment #12 from nsz at gcc dot gnu.org ---
this got reverted because of bug 88678

and because compile time and runtime support_halting are different.

the compile time value is unconditionally true, which is wrong for
aarch64 and arm:

gcc/fortran/simplify.c:
gfc_expr *
simplify_ieee_support (gfc_expr *expr)
{
  /* We consider that if the IEEE modules are loaded, we have full support
 for flags, halting and rounding, which are the three functions
 (IEEE_SUPPORT_{FLAG,HALTING,ROUNDING}) allowed in constant
 expressions. One day, we will need libgfortran to detect support and
 communicate it back to us, allowing for partial support.  */

  return gfc_get_logical_expr (gfc_default_logical_kind, >where,
   true);
}

i don't know how to change this to false for IEEE_SUPPORT_HALTING
on aarch64 and arm targets, but that would be a possible fix.

[Bug target/86487] [7/8/9 Regression] insn does not satisfy its constraints on arm big-endian

[avieira at gcc dot gnu.org]

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

--- Comment #10 from avieira at gcc dot gnu.org ---
Hi Vlad,

I don't think it is a duplication. I believe this PR is caused by an issue with
'uses_hard_regs_p' and paradoxical subregs. I proposed a patch in
https://gcc.gnu.org/ml/gcc-patches/2019-01/msg00307.html , though it has a
mistake, I forgot to add '|| SUBREG_P (x)' to the 'if (REG_P (x))' line since x
can now be a subreg.  I haven't had much time lately, but I am now running the
last bootstrap, have done arm and aarch64, now doing x86.

I can't reproduce this on GCC 9 but I can on 8 and earlier and the latent bug
is still there on 9. So I believe we should fix it regardless.

Once the bootstrap is done Ill post the fixed patch + testcase (really only
useful for gcc-8) on the mailing list.

Cheers,
Andre

[Bug target/86487] [7/8/9 Regression] insn does not satisfy its constraints on arm big-endian

[vmakarov at gcc dot gnu.org]

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

Vladimir Makarov  changed:

   What|Removed |Added

 CC||vmakarov at gcc dot gnu.org

--- Comment #9 from Vladimir Makarov  ---
  I believe the PR is duplication of PR88850 (see my comments there).  The cost
of register movement in insn 6 is 2.  LRA/reload does not check constraints for
such cost and at the very LRA end (when there is a check for all insn
constraints) the error is reported.

[Bug preprocessor/89141] New: Documentation of -H ignores effect of include guards

[osemwaro.pedro at ocado dot com]

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

Bug ID: 89141
   Summary: Documentation of -H ignores effect of include guards
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: preprocessor
  Assignee: unassigned at gcc dot gnu.org
  Reporter: osemwaro.pedro at ocado dot com
  Target Milestone: ---

Created attachment 45576
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45576=edit
Four short files with diamond include graph

I have recently been trying to figure out how to construct include graphs from
the GCC preprocessor's output, so that I can give the preprocessor the options
that I would use when compiling my code, to ensure that macros (and comments)
are treated correctly. The documentation of the -H option
(https://gcc.gnu.org/onlinedocs/gcc/Preprocessor-Options.html#index-H) led me
to believe that the include stack that it prints would give me the information
that I need. But after carefully examining its output, I realised that it omits
header files that contain include guards, the second time it encounters them.

The attachment demonstrates this. Its four files have the following include
graph:

  +-> d.hpp <-+
  |   | 
b.hpp <-- a.cpp --> c.hpp

and all three .hpp files have include graphs, but GCC prints the following
include stack:

$ g++ -E -H a.cpp 2>&1 1> /dev/null
. b.hpp
.. d.hpp
. c.hpp

I.e. it ignores the fact that c.hpp includes d.hpp.

This treatment of include guards should be described in the documentation (as
should the fact that the include stack is written to standard error). Googling
"gcc include graph" shows that there are a few other people who suggest
constructing include graphs based on -H, so I suspect that I'm not the only
person who has been (or would be) surprised to learn that this leads to
incomplete include graphs.

FWIW, I'm using GCC v. 5.4.0 on Ubuntu 16.04.

[Bug c++/88752] [8 Regression] ICE in enclosing_instantiation_of, at cp/pt.c:13328

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

Summary|[8/9 Regression] ICE in |[8 Regression] ICE in
   |enclosing_instantiation_of, |enclosing_instantiation_of,
   |at cp/pt.c:13328|at cp/pt.c:13328

--- Comment #6 from Jason Merrill  ---
Fixed on trunk so far.

[Bug tree-optimization/88932] [8/9 Regression] ICE: verify_ssa failed (Error: definition in block 29 does not dominate use in block 25)

[rguenther at suse dot de]

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

--- Comment #5 from rguenther at suse dot de  ---
On Thu, 31 Jan 2019, amker.cheng at gmail dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88932
> 
> bin.cheng  changed:
> 
>What|Removed |Added
> 
>  CC||amker.cheng at gmail dot com
> 
> --- Comment #4 from bin.cheng  ---
> (In reply to Jakub Jelinek from comment #3)
> > This has been approved for trunk, are you going to commit it?
> 
> Thanks for reminding, will commit it tomorrow.  I would also need an approval
> for 8 branch.

It's a regression so there's no need for an extra approval, but still - 
OK.

[Bug c++/88752] [8/9 Regression] ICE in enclosing_instantiation_of, at cp/pt.c:13328

[jason at gcc dot gnu.org]

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

--- Comment #5 from Jason Merrill  ---
Author: jason
Date: Thu Jan 31 15:03:21 2019
New Revision: 268424

URL: https://gcc.gnu.org/viewcvs?rev=268424=gcc=rev
Log:
PR c++/88752 - ICE with lambda and constexpr if.

In this testcase, we look for an instantiation of the outer lambda from
within the inner lambda.  enclosing_instantiation_of didn't handle this
properly, as it assumed that any references would be from the same lambda
nesting depth.  Fixed thus.

* cp-tree.h (LAMBDA_EXPR_INSTANTIATED): New.
* pt.c (tsubst_lambda_expr): Set it.
(instantiated_lambda_fn_p): Check it.
(enclosing_instantiation_of): Use it.

Added:
trunk/gcc/testsuite/g++.dg/cpp1z/constexpr-if26.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/pt.c

[Bug ipa/89139] GCC emits code for static functions that aren't used by the optimized code

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
 CC||marxin at gcc dot gnu.org
  Component|tree-optimization   |ipa
Version|unknown |9.0

--- Comment #1 from Richard Biener  ---
It's likely eliminating the last use too late.

[Bug tree-optimization/88932] [8/9 Regression] ICE: verify_ssa failed (Error: definition in block 29 does not dominate use in block 25)

[amker.cheng at gmail dot com]

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

bin.cheng  changed:

   What|Removed |Added

 CC||amker.cheng at gmail dot com

--- Comment #4 from bin.cheng  ---
(In reply to Jakub Jelinek from comment #3)
> This has been approved for trunk, are you going to commit it?

Thanks for reminding, will commit it tomorrow.  I would also need an approval
for 8 branch.

[Bug other/89140] New: libiberty/pex-unix.c fails to compile in aarch64-to-x86_64 cross build

[bneumeier at gmail dot com]

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

Bug ID: 89140
   Summary: libiberty/pex-unix.c fails to compile in
aarch64-to-x86_64 cross build
   Product: gcc
   Version: 8.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bneumeier at gmail dot com
  Target Milestone: ---

Created attachment 45575
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45575=edit
patch to correct pex-unix.c header file inclusion

In an aarch64-to-x86_64 cross-GCC build scenario, the libiberty configuration
process determines that getrusage is not available but wait4 is. This leads to
a situation where resource.h is not included, but there is a declaration of
type struct rusage.

I was able to get the compile to succeed without issues just by changing the
condition under which resource.h is included, see attached patch.

[Bug tree-optimization/89139] New: GCC emits code for static functions that aren't used by the optimized code

[m...@nieper-wisskirchen.de]

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

Bug ID: 89139
   Summary: GCC emits code for static functions that aren't used
by the optimized code
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: m...@nieper-wisskirchen.de
  Target Milestone: ---

Consider the following C module.

**
typedef struct cont
{
void (*f) (struct cont, int a);
} Cont;

int quux (int a);

static void g (Cont c, Cont d, int a)
{
if (quux (a))
  return g (c, d, a + 1);
c.f (d, a * 2); // XXX
}

void bar (struct cont, int a);

static void h (Cont d, int a)
{
if (d.f != bar)
  d.f (d, a);
}

void foo (int a)
{
g ((Cont) { h }, (Cont) { bar }, a);
}
**

I compiled the code with the x86-64 gcc (trunk) version on https://godbolt.org
and I get:

**
h:
cmpq$bar, %rdi
je  .L1
jmp *%rdi
.L1:
ret
foo:
pushq   %rbx
movl%edi, %ebx
jmp .L6
.L8:
addl$1, %ebx
.L6:
movl%ebx, %edi
callquux
testl   %eax, %eax
jne .L8
popq%rbx
ret
**

As one can see, code for the function `h' is emitted but nowhere used.

Interestingly, when I replace `a * 2' in the line marked with XXX by `a', gcc
does not emit code for `h':

**
foo:
pushq   %rbx
movl%edi, %ebx
jmp .L3
.L6:
addl$1, %ebx
.L3:
movl%ebx, %edi
callquux
testl   %eax, %eax
jne .L6
popq%rbx
ret
**

[Bug ipa/89104] ICE: Segmentation fault (in tree_int_cst_elt_check)

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
(In reply to Wilco from comment #5)
> I agree backend specific warnings are not ideal but it's unclear whether a
> better solution exists beyond just not emitting these warnings at all and
> letting the user figure it out.

I'd say it belongs to -fopt-info or similar stuff, when one wants to
investigate why something isn't vectorized etc.

> However the key question is why do testcases which do not specifically test
> for a specific warning fail if an extra warning is emitted? That's
> completely harmless in most cases.

That is the standard behavior of most of the testsuites (except for
gcc.c-torture/* which uses -w), and it is a good idea to FAIL for unexpected
warnings.

[Bug ipa/89104] ICE: Segmentation fault (in tree_int_cst_elt_check)

[wilco at gcc dot gnu.org]

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

--- Comment #5 from Wilco  ---
(In reply to Jakub Jelinek from comment #4)
> I really don't like these aarch64 warnings, declare simd is an optimization
> (admittedly with ABI consequences) and warning about this by default is
> weird,
> + it is going to be a pain, any time any declare simd testcase is added
> there is potential "regression" on aarch64.
> Plus it really looks like a bug in this case, there is no mixed type at all,
> the int * argument is uniform, so should be passed as any other pointer, and
> all the others are int and so should use the same vector int type.

I agree backend specific warnings are not ideal but it's unclear whether a
better solution exists beyond just not emitting these warnings at all and
letting the user figure it out.

However the key question is why do testcases which do not specifically test for
a specific warning fail if an extra warning is emitted? That's completely
harmless in most cases.

[Bug c++/88394] [8/9 Regression] g++ ICE (Segmentation fault) in insert_capture_proxy

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Related to e.g. PR89138 - lambdas and VLAs don't play nicely together right
now.

[Bug tree-optimization/88932] [8/9 Regression] ICE: verify_ssa failed (Error: definition in block 29 does not dominate use in block 25)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
This has been approved for trunk, are you going to commit it?

[Bug c++/88988] [8 Regression] ICE: Segmentation fault (in lookup_name_real_1)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[8/9 Regression] ICE:   |[8 Regression] ICE:
   |Segmentation fault (in  |Segmentation fault (in
   |lookup_name_real_1) |lookup_name_real_1)

--- Comment #5 from Jakub Jelinek  ---
Fixed on the trunk so far.

[Bug rtl-optimization/89116] [8/9 Regression] ICE in cfg_layout_redirect_edge_and_branch_force, at cfgrtl.c:4482

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Yeah, this is the same bug as PR85408.  I haven't heard from Honza any comments
on https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85408#c2
Honza?

[Bug middle-end/89008] [7/8 Regression] O2 and O1 results differ for simple test

[wschmidt at gcc dot gnu.org]

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

--- Comment #13 from Bill Schmidt  ---
Author: wschmidt
Date: Thu Jan 31 13:53:06 2019
New Revision: 268422

URL: https://gcc.gnu.org/viewcvs?rev=268422=gcc=rev
Log:
2018-01-31  Bill Schmidt  

PR tree-optimization/89008
* gimple-ssa-strength-reduction.c (slsr_process_mul): Don't
process anything of the form X * 0.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimple-ssa-strength-reduction.c