Hi,
Firefox contains ODR violations in some of bigger classes which we
report correctly during ODR type merging but then find it necessary to
complain about every single method during symbol table merging. This
patch silences the later warning since having one is enough.
Bootstrapped/regtested x86
As discussed in the PR log, it seems difficult to simplify zero sized
arrays and keep gimple verification happy. Since this has only minor
effect on memory use, I am disabling it for GCC9 and will re-visit the
issue for GCC 10.
Bootstrapped/regtested x86_64-linux.
Honza
PR lto/88140
Hi Steve
On 21/12/18 8:01 PM, Steve Kargl wrote:
> On Fri, Dec 21, 2018 at 07:39:45PM +, Joseph Myers wrote:
>> On Fri, 21 Dec 2018, Steve Kargl wrote:
>>
>>> scalbln(double x, long n)
>>> {
>>>
>>> return (scalbn(x, (n > NMAX) ? NMAX : (n < NMIN) ? NMIN : (int)n));
>>> }
>>>
>>> A se
Hi Jan
On 22/12/18 8:08 PM, Jan Hubicka wrote:
> Hi,
> while fixing Firefox issues I also noticed that type simplification
> completely disabled type based devirtualization on LTO path. Problem
> is that method pointers now point to simplified type and
> obj_type_ref_class is not ready for that.
>
> UNRESOLVED: g++-dg-lto-devirt-13-01.exe scan-tree-dump-times ssa
> "OBJ_TYPE_REF" 0
> UNRESOLVED: g++-dg-lto-devirt-13-11.exe scan-tree-dump-times ssa
> "OBJ_TYPE_REF" 0
> UNRESOLVED: g++-dg-lto-devirt-13-21.exe scan-tree-dump-times ssa
> "OBJ_TYPE_REF" 0
> UNRESOLVED: g++-dg-lto-devirt-14-01.
This patch factors handling of non-SSA_NAME arguments out of
get_range_strlen. It is the equivalent of patch #1 from Martin's
original submission. Again, this should not affect behavior of GCC at all.
I'm attaching the normal diff as well as a -b diff which shows that most
of the change is jus
On Mon, Dec 24, 2018 at 12:26:46PM +, Sudakshina Das wrote:
> >
> I am observing your new test pr88328.f90 failing on
> arm-none-linux-gnueabihf:
> Excess errors:
> /build/src/gcc/gcc/testsuite/gfortran.dg/ieee/ieee_9.f90:20:36: Error:
> Invalid kind for REAL at (1)
> /build/src/gcc/gcc/tests
I've added the following patch to a recently committed testcase.
Index: gcc/testsuite/gfortran.dg/ieee/ieee_9.f90
===
--- gcc/testsuite/gfortran.dg/ieee/ieee_9.f90 (revision 267413)
+++ gcc/testsuite/gfortran.dg/ieee/ieee_9.f90 (w
On December 24, 2018 4:15:09 PM GMT+01:00, Jan Hubicka wrote:
>> UNRESOLVED: g++-dg-lto-devirt-13-01.exe scan-tree-dump-times ssa
>> "OBJ_TYPE_REF" 0
>> UNRESOLVED: g++-dg-lto-devirt-13-11.exe scan-tree-dump-times ssa
>> "OBJ_TYPE_REF" 0
>> UNRESOLVED: g++-dg-lto-devirt-13-21.exe scan-tree-dump-
> On December 24, 2018 4:15:09 PM GMT+01:00, Jan Hubicka wrote:
> >> UNRESOLVED: g++-dg-lto-devirt-13-01.exe scan-tree-dump-times ssa
> >> "OBJ_TYPE_REF" 0
> >> UNRESOLVED: g++-dg-lto-devirt-13-11.exe scan-tree-dump-times ssa
> >> "OBJ_TYPE_REF" 0
> >> UNRESOLVED: g++-dg-lto-devirt-13-21.exe sca
On Mon, Dec 24, 2018 at 8:05 PM Steve Kargl <
s...@troutmask.apl.washington.edu> wrote:
> I've added the following patch to a recently committed testcase.
>
> Index: gcc/testsuite/gfortran.dg/ieee/ieee_9.f90
> ===
> --- gcc/testsuite/
On Mon, Dec 24, 2018 at 09:29:50PM +0200, Janne Blomqvist wrote:
> On Mon, Dec 24, 2018 at 8:05 PM Steve Kargl <
> s...@troutmask.apl.washington.edu> wrote:
>
> > I've added the following patch to a recently committed testcase.
> >
> > Index: gcc/testsuite/gfortran.dg/ieee/ieee_9.f90
> > =
All,
The IEEE modules and -ffpe-trap are to some extent orthogonal
features of gfortran. Unfortunately, some users have the
expectation of using -ffpe-trap for debugging while also using only
some of the mechanisms provided by the IEEE modules. For example,
% t.f90
program test
use, i
On Mon, Dec 24, 2018 at 9:42 PM Steve Kargl <
s...@troutmask.apl.washington.edu> wrote:
> On Mon, Dec 24, 2018 at 09:29:50PM +0200, Janne Blomqvist wrote:
> > On Mon, Dec 24, 2018 at 8:05 PM Steve Kargl <
> > s...@troutmask.apl.washington.edu> wrote:
> >
> > > I've added the following patch to a r
14 matches
Mail list logo
