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
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 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
> > =
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 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 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-
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 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
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
> 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.
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.
>
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
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,
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
14 matches
Mail list logo
