On Sun, Feb 17, 2019 at 07:18:52PM +0100, Thomas Koenig wrote:
> I'd still like confirmation from one of the POWER people that
> this also fixes the bug on that architecture.
I bootstrapped and regression tested on powerpc64le-linux, and confirm
that the patch fixes the bug. Thanks!
--
Alan Mod
Committed as rev. 268974.
Thanks for the review!
Harald
On 02/17/19 21:40, Thomas Koenig wrote:
> Hi Harald,
>
>> Ping!
>
>> On 02/11/19 23:09, Harald Anlauf wrote:
>>> The attached patch moves the check for this F2018 obsolescent feature
>>> to a better place where the warning is only emitted
Committed as rev. 268973.
Thanks for the review!
Harald
On 02/17/19 21:45, Thomas Koenig wrote:
> Hi Harald,
>
>> OK for trunk?
>
> OK.
>
> Thanks for the patch!
>
> Regards
>
> Thomas
>
On Sun, Feb 17, 2019 at 10:50 AM Uros Bizjak wrote:
>
> On Sun, Feb 17, 2019 at 6:28 PM H.J. Lu wrote:
>
> > > > > > > On Sat, Feb 16, 2019 at 11:46 PM H.J. Lu
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > PR target/89021
> > > > > > > > * config/i386/i386.c
> > > > > >
On Sun, Feb 17, 2019 at 10:49 AM Uros Bizjak wrote:
>
> On Sun, Feb 17, 2019 at 6:37 PM H.J. Lu wrote:
>
> > > > > > > > > On x86-64, since __m64 is returned and passed in XMM
> > > > > > > > > registers, we can
> > > > > > > > > emulate MMX intrinsics with SSE instructions. To support it,
> >
Hi Harald,
OK for trunk?
OK.
Thanks for the patch!
Regards
Thomas
Hi Harald,
Ping!
On 02/11/19 23:09, Harald Anlauf wrote:
The attached patch moves the check for this F2018 obsolescent feature
to a better place where the warning is only emitted when the COMMON is
declared. No warning should be emitted when such a legacy module is
simply used.
Regtested o
Hello Segher,
On Sun, 2019-02-17 at 13:09 -0600, Segher Boessenkool wrote:
> On Sun, Feb 17, 2019 at 04:59:40PM +, Дилян Палаузов wrote:
> > My point is to reorgnize the approach in such a way, that sending reminders
> > gets irrelevant (has no impact) and
> > therefore not necessary.
> >
>
Ping!
On 02/11/19 23:09, Harald Anlauf wrote:
> The attached patch moves the check for this F2018 obsolescent feature
> to a better place where the warning is only emitted when the COMMON is
> declared. No warning should be emitted when such a legacy module is
> simply used.
>
> Regtested on x86
On Sun, Feb 17, 2019 at 04:59:40PM +, Дилян Палаузов wrote:
> As a matter of fact patches are not reviewed for whatever reason in
> reasonable time.
Yes. This is an age-old problem.
> My point is to reorgnize the approach in such a way, that sending reminders
> gets irrelevant (has no impa
On Sun, Feb 17, 2019 at 6:28 PM H.J. Lu wrote:
> > > > > > On Sat, Feb 16, 2019 at 11:46 PM H.J. Lu
> > > > > > wrote:
> > > > > > >
> > > > > > > PR target/89021
> > > > > > > * config/i386/i386.c (ix86_expand_vector_init_duplicate):
> > > > > > > Set
> > > > > > > mmx
On Sun, Feb 17, 2019 at 6:37 PM H.J. Lu wrote:
> > > > > > > > On x86-64, since __m64 is returned and passed in XMM registers,
> > > > > > > > we can
> > > > > > > > emulate MMX intrinsics with SSE instructions. To support it, we
> > > > > > > > added
> > > > > > > >
> > > > > > > > #define TA
Hello world,
the attached patch fixes a rather bad ABI violation on POWER systems.
In the absence of an explicit interface and if a procedure is not in
the same file, gfortran currently generates wrong function decls -
a longstanding problem that also creates problems with LTO, because
it (corre
Also fixed by r268969. There was a sorry, because IMPLICIT_CONV_EXPR
got to write_expression. I also noticed a change in how we mangle
a decltype with a brace-init-list, so I've added a test for that too.
Tested on x86_64-linux, applying to trunk.
2019-02-17 Marek Polacek
PR c++/893
On Sun, Feb 17, 2019 at 9:27 AM Uros Bizjak wrote:
>
> On Sun, Feb 17, 2019 at 6:10 PM H.J. Lu wrote:
> >
> > On Sun, Feb 17, 2019 at 7:57 AM Uros Bizjak wrote:
> > >
> > > On Sun, Feb 17, 2019 at 4:53 PM Uros Bizjak wrote:
> > >
> > > > > > > On x86-64, since __m64 is returned and passed in XM
Hi Steve,
On Sat, Feb 16, 2019 at 05:23:58PM +0100, Thomas Koenig wrote:
Also, we seem to have a lot of issues with IEEE flags
when calculating NORM2, this would also need to be
addressed.
Which IEEE flags and are you referring using the
Fortran modules or -ffpe-trap?
I checked out the so
On Sun, Feb 17, 2019 at 9:22 AM Uros Bizjak wrote:
>
> On Sun, Feb 17, 2019 at 6:15 PM H.J. Lu wrote:
>
> > > > > On Sat, Feb 16, 2019 at 11:46 PM H.J. Lu wrote:
> > > > > >
> > > > > > PR target/89021
> > > > > > * config/i386/i386.c (ix86_expand_vector_init_duplicate):
> > > >
Fixed by r268969 and it's a nice test (thanks Lars).
Tested on x86_64-linux, applying to trunk.
2019-02-17 Marek Polacek
PR c++/89315
* g++.dg/cpp0x/initlist114.C: New test.
diff --git gcc/testsuite/g++.dg/cpp0x/initlist114.C
gcc/testsuite/g++.dg/cpp0x/initlist114.C
new file
On Sun, Feb 17, 2019 at 6:10 PM H.J. Lu wrote:
>
> On Sun, Feb 17, 2019 at 7:57 AM Uros Bizjak wrote:
> >
> > On Sun, Feb 17, 2019 at 4:53 PM Uros Bizjak wrote:
> >
> > > > > > On x86-64, since __m64 is returned and passed in XMM registers, we
> > > > > > can
> > > > > > emulate MMX intrinsics
On Sun, Feb 17, 2019 at 6:15 PM H.J. Lu wrote:
> > > > On Sat, Feb 16, 2019 at 11:46 PM H.J. Lu wrote:
> > > > >
> > > > > PR target/89021
> > > > > * config/i386/i386.c (ix86_expand_vector_init_duplicate): Set
> > > > > mmx_ok to true if TARGET_MMX_WITH_SSE is true.
> >
On Sun, Feb 17, 2019 at 9:08 AM Uros Bizjak wrote:
>
> On Sun, Feb 17, 2019 at 6:03 PM H.J. Lu wrote:
> >
> > On Sun, Feb 17, 2019 at 8:24 AM Uros Bizjak wrote:
> > >
> > > On Sat, Feb 16, 2019 at 11:46 PM H.J. Lu wrote:
> > > >
> > > > PR target/89021
> > > > * config/i386/i386
On Sun, Feb 17, 2019 at 7:57 AM Uros Bizjak wrote:
>
> On Sun, Feb 17, 2019 at 4:53 PM Uros Bizjak wrote:
>
> > > > > On x86-64, since __m64 is returned and passed in XMM registers, we can
> > > > > emulate MMX intrinsics with SSE instructions. To support it, we added
> > > > >
> > > > > #define
On Sun, Feb 17, 2019 at 6:03 PM H.J. Lu wrote:
>
> On Sun, Feb 17, 2019 at 8:24 AM Uros Bizjak wrote:
> >
> > On Sat, Feb 16, 2019 at 11:46 PM H.J. Lu wrote:
> > >
> > > PR target/89021
> > > * config/i386/i386.c (ix86_expand_vector_init_duplicate): Set
> > > mmx_ok to tr
On Sun, Feb 17, 2019 at 8:24 AM Uros Bizjak wrote:
>
> On Sat, Feb 16, 2019 at 11:46 PM H.J. Lu wrote:
> >
> > PR target/89021
> > * config/i386/i386.c (ix86_expand_vector_init_duplicate): Set
> > mmx_ok to true if TARGET_MMX_WITH_SSE is true.
> > (ix86_expand_vect
Hello Segher,
your prompt answer is appreciated.
As a matter of fact patches are not reviewed for whatever reason in reasonable
time.
My point is to reorgnize the approach in such a way, that sending reminders
gets irrelevant (has no impact) and
therefore not necessary.
Currently priority is
On Sat, Feb 16, 2019 at 03:54:21PM -0500, Marek Polacek wrote:
> I noticed this test fails in c++2a since the implementation of P0846
> landed in r265734. Since it's in g++.old-deja/, I never noticted the
> fail (but I don't see any others). This patch tweaks a dg-error in
> order to make it pass
On Sat, Feb 16, 2019 at 11:46 PM H.J. Lu wrote:
>
> PR target/89021
> * config/i386/i386.c (ix86_expand_vector_init_duplicate): Set
> mmx_ok to true if TARGET_MMX_WITH_SSE is true.
> (ix86_expand_vector_init_one_nonzero): Likewise.
> (ix86_expand_vector_init
On Sat, 16 Feb 2019 at 13:44, Matthias Klose wrote:
>
> On 12.02.19 21:54, Iain Buclaw wrote:
> > On Tue, 12 Feb 2019 at 10:40, Richard Biener
> > wrote:
> >>
> >> On Sat, Feb 9, 2019 at 10:37 AM Iain Buclaw wrote:
> >>>
> >>> On Mon, 28 Jan 2019 at 13:10, Richard Biener
> >>> wrote:
>
>
On Sun, Feb 17, 2019 at 4:53 PM Uros Bizjak wrote:
> > > > On x86-64, since __m64 is returned and passed in XMM registers, we can
> > > > emulate MMX intrinsics with SSE instructions. To support it, we added
> > > >
> > > > #define TARGET_MMX_WITH_SSE (TARGET_64BIT && TARGET_SSE2)
> > > >
> > >
On Sun, Feb 17, 2019 at 2:42 PM H.J. Lu wrote:
>
> On Sun, Feb 17, 2019 at 2:33 AM Uros Bizjak wrote:
> >
> > On 2/16/19, H.J. Lu wrote:
> > > On x86-64, since __m64 is returned and passed in XMM registers, we can
> > > emulate MMX intrinsics with SSE instructions. To support it, we added
> > >
On Sun, Feb 17, 2019 at 2:33 AM Uros Bizjak wrote:
>
> On 2/16/19, H.J. Lu wrote:
> > On x86-64, since __m64 is returned and passed in XMM registers, we can
> > emulate MMX intrinsics with SSE instructions. To support it, we added
> >
> > #define TARGET_MMX_WITH_SSE (TARGET_64BIT && TARGET_SSE2)
On Sun, Feb 17, 2019 at 1:45 AM Uros Bizjak wrote:
>
> On 2/16/19, H.J. Lu wrote:
> > With SSE emulation of MMX intrinsics, we should make _mm_empty () as NOP
> > for TARGET_MMX_WITH_SSE.
>
> NAK. NOP can be emitter only for !TARGET_MMX.
>
I changed it to
"TARGET_MMX || TARGET_MMX_WITH_SSE"
{
On Sat, Feb 16, 2019 at 08:51:33AM -1000, Jason Merrill wrote:
> > The likely case is still that nothing has changed in between, so this patch
> > just quickly verifies if that is the case (by comparing
> > CONSTRUCTOR_ELT (ctor, 0) with the previously saved value of that and by
> > checking if at
Hi,
here, when we don't see an initializer we believe we are surely dealing
with a case of C++17 template argument deduction for class templates,
but, in fact, it's just an ill-formed C++14 template variable
specialization. Conveniently, we can use here too the predicate
variable_template_spe
On 2/16/19, H.J. Lu wrote:
> On x86-64, since __m64 is returned and passed in XMM registers, we can
> emulate MMX intrinsics with SSE instructions. To support it, we added
>
> #define TARGET_MMX_WITH_SSE (TARGET_64BIT && TARGET_SSE2)
>
> ;; Define instruction set of MMX instructions
> (define_att
On 2/16/19, H.J. Lu wrote:
> With SSE emulation of MMX intrinsics, we should make _mm_empty () as NOP
> for TARGET_MMX_WITH_SSE.
NAK. NOP can be emitter only for !TARGET_MMX.
Uros.
>
> PR target/89021
> * config/i386/mmx.md (mmx_): Renamed to ...
> (*mmx_): This.
> (mmx_
36 matches
Mail list logo
