On 11/23/19 9:53 PM, Bernd Schmidt wrote:
> I'll spend a few more days trying to see if I can do something about the
> bootstrap failure Mikael saw (currently trying to do a two-stage cross
> build rather than a really slow bootstrap).
Whew, I think I have it. One tst instruction eliminated when i
From: Andrew Pinski
Hi if we have a aarch64 compiler that has a big-endian
multi-lib, it fails to compile libstdc++ because
simd_fast_mersenne_twister_engine is only defined for little-endian
in ext/random but ext/opt_random.h thinks it is defined always.
OK? Built an aarch64-elf toolchain whic
On 11/23/19 6:09 PM, Segher Boessenkool wrote:
On Sat, Nov 23, 2019 at 06:01:28PM -0500, Nicholas Krause wrote:
Please just CC to this conversation as I keep getting removed.
Everyone who was on Cc: for this thread still is. This is how email
works. If you want to see everything on the lis
On Sat, Nov 23, 2019 at 06:01:28PM -0500, Nicholas Krause wrote:
> Please just CC to this conversation as I keep getting removed.
Everyone who was on Cc: for this thread still is. This is how email
works. If you want to see everything on the list, subscribe to the
mailing list?
Segher
On 11/23/19 5:34 PM, Segher Boessenkool wrote:
Hi!
On Mon, Nov 18, 2019 at 05:55:13PM +, Richard Sandiford wrote:
Richard Sandiford writes:
(It's 23:35 local time, so it's still just about stage 1. :-))
Or actually, just under 1 day after end of stage 1. Oops.
Could have sworn stage
Hi!
On Mon, Nov 18, 2019 at 05:55:13PM +, Richard Sandiford wrote:
> Richard Sandiford writes:
> > (It's 23:35 local time, so it's still just about stage 1. :-))
>
> Or actually, just under 1 day after end of stage 1. Oops.
> Could have sworn stage 1 ended on the 17th :-( Only realised
> I
On 11/23/19 6:36 PM, Jeff Law wrote:
> Not really. I've already indicated to Bernd that he should go ahead and
> commit the changes and we can iterate on any problems that arise.
In the meantime I've made an aranym setup in addition to the qemu setup
I had, and I've not been able to reproduce fa
On Sat, 2019-11-23 at 10:36 -0700, Jeff Law wrote:
>
> > Any news on this? I would be in favor of merging these patches as I
> > have
> > tested them successfully on Debian by building the gcc-snapshot
> > package
> > with the patches applied. I used all four patches plus the
> > additional one
>
On 11/23/19 10:14 AM, John Paul Adrian Glaubitz wrote:
> Hi Jeff!
>
>> On 11/13/19 6:23 AM, Bernd Schmidt wrote:
>>> Once more with patch.
>>>
>>>
>>> Bernd
>>>
>>>
>>> m68k-2.diff
>>>
>>> PR target/91851
>>> * config/m68k/m68k-protos.h (output-dbcc_and_branch): Adjust
>>>
Hi Jeff!
> On 11/13/19 6:23 AM, Bernd Schmidt wrote:
>> Once more with patch.
>>
>>
>> Bernd
>>
>>
>> m68k-2.diff
>>
>> PR target/91851
>> * config/m68k/m68k-protos.h (output-dbcc_and_branch): Adjust
>> declaration.
>> (m68k_init_cc): New declar
On 11/21/19 7:42 PM, Joseph Myers wrote:
> attribs.c has code to ignore all scoped attributes appertaining to
> types except when they are part of the definition of that type.
>
> I think the premise of that code is incorrect, and its presence is a
> bug; such attributes are clearly valid in both
On 11/22/19 9:40 AM, Joseph Myers wrote:
> Code that directly uses _Decimal* types on architectures not
> supporting DFP is properly diagnosed ("error: decimal floating-point
> not supported for this target"), via a call to
> targetm.decimal_float_supported_p, if the _Decimal32, _Decimal64 or
> _De
Am 23.11.19 um 14:15 schrieb Thomas Koenig:
* gfortran.dg/eof_4.f90: New test.
This should be eof_6.f90 (and will be on commit).
Regards
Thomas
Actually, that was 92422. ChangeLog changed correspondingly.
Hi,
the PR is a gcc-9 only regression, for which I just committed a test
case to trunk.
We can then check what fixed this...
2019-11-23 Thomas Koenig
PR fortran/92442
* gfortran.dg/bounds_check_21.f90: New test.
! { dg-do compile }
! { dg-options "-Warray-bounds -O2" }
! PR
> Hi Honza,
>
> > > >
> > > > > I checked update_jump_functions_after_inlining(), and found one
> > > > suspicious place:
> > > > >
> > > > > for (i = 0; i < count; i++)
> > > > > {
> > > > > struct ipa_jump_func *dst = ipa_get_ith_jump_func (args, i);
> > > > > if (!top)
> > > >
Hi Honza,
> > >
> > > > I checked update_jump_functions_after_inlining(), and found one
> > > suspicious place:
> > > >
> > > > for (i = 0; i < count; i++)
> > > > {
> > > > struct ipa_jump_func *dst = ipa_get_ith_jump_func (args, i);
> > > > if (!top)
> > > > {
> > > >
Hello world,
the attached patch fixes a case where transforming
do j = 1,1000
read (20,*,end=1)(tdat(j,k),k=1,10)
end do
1 continue
which on straight transformation yields
DO main:j=1 1000 1
READ UNIT=20 FMT=-1
DO main:k=1 10 1
TRANSFER main:tdat(main:j , main:k)
Hi,
This patch adds opt_for_fn for all cross module params used by inliner
so they can be modified at function granuality. With inlining almost always
there are three functions to consider (callee and caller of the inlined edge
and the outer function caller is inlined to).
I always use the outer
Hi!
This fixes various comment spelling errors aspell -c found.
Committed as obvious to trunk.
2019-11-23 Jakub Jelinek
* ipa-fnsummary.c: Fix comment typos.
* ipa-ref.h: Likewise.
* ipa-predicate.h: Likewise.
* ipa-split.c: Likewise.
* ipa-inline-analy
On Sat, Nov 23, 2019 at 2:09 AM Jakub Jelinek wrote:
>
> Hi!
>
> The following testcase ICEs, because ix86_md_asm_adjust emits an invalid
> insn that isn't matched. setcc_qi output is nonimmediate_operand and so is
> fine, but the problem is if we decide to do a ZERO_EXTEND, because
> zero_extend
21 matches
Mail list logo
