* include/pstl/algorithm_impl.h: Uglify identfiers.
* include/pstl/numeric_impl.h: Uglify identfiers.
* include/pstl/parallel_backend_tbb.h: Uglify identfiers.
>From b75813e885c50e667a1474c1d0e1fc47ee893d6e Mon Sep 17 00:00:00 2001
From: Thomas Rodgers
Date: Thu, 11
The test fell back to long long and long when __int128 is not
available, but it assumed sizeof(long) < sizeof(long long) because of
a shift count that would be out of range for a long long if their
widths are the same. Fixed by splitting it up into two shifts.
Tested on x86_64-linux-gnu, -m64
On Apr 5, 2019, Richard Biener wrote:
> Looks OK but can you adjust the testcase to actually test
> something?
Doh, I *knew* I'd failed to do something I should have ;-)
I resorted to the trick you used in pr89892.c, of using a more complex
expression to get UNSUPPORTED results instead of
Reinhold,
Thanks for the insights !
That means there is currently an other issue since copy-in is performed
even if the argument is declared as ASYNCHRONOUS.
I gave the copy-in mechanism some more thoughts, and as a library
developers, I can clearly see a need *not* to do that
on a
On 11/04/19 17:36 -0400, Marek Polacek wrote:
This patch deals with constexpr functions and whether or not they should be
noexcept.
CWG 1129 specified that constexpr functions are noexcept: it was a special case
in [expr.unary.noexcept]. This was accidentally removed in
but the CWG conclusion
This patch deals with constexpr functions and whether or not they should be
noexcept.
CWG 1129 specified that constexpr functions are noexcept: it was a special case
in [expr.unary.noexcept]. This was accidentally removed in
but the CWG conclusion was to keep it as-is.
Clearly we need to
Hi,
This patch merges the libphobos library with upstream phobos cf95639ff.
Backports port fixes from upstream that have been committed since last sync.
Bootstrapped and regression tested on x86_64-linux-gnu.
Committed to trunk as r270296.
--
Iain
diff --git a/libphobos/src/MERGE
Hi,
This patch merges the libdruntime sub-library with upstream druntime 175bf5fc.
Backports extern(C) bindings from upstream druntime that have been
committed since the last sync. Notably, the Solaris port has been
undergoing a some testing to get it all passing.
Bootstrapped and regression
Hi,
This patch merges the D front-end implementation with dmd upstream d7ed327ed.
Backports fix for an ICE that occurred when accessing empty array in CTFE.
Bootstrapped and regression tested on x86_64-linux-gnu.
Committed to trunk as r270294.
--
Iain
---
diff --git a/gcc/d/dmd/MERGE
removed (patch version applied attached).
Tested x86_64-linux, committed to trunk.
Jonathan Wakely writes:
> On 10/04/19 23:59 +0100, Jonathan Wakely wrote:
>>On 10/04/19 15:57 -0700, Thomas Rodgers wrote:
>>>Ok, lets try this again.
>>>
On 09/04/19 15:23 -0700, Thomas Rodgers wrote:
Hello world,
I have just committed the attached patch as obvious and simple. It
fixes an error message so that it can be extracted for translation.
No test case because it does not change anything (which was verified
by regression-testing).
Regards
Thomas
2019-04-11 Thomas Koenig
[except.spec] says that "In a noexcept-specifier, the constant-expression,
if supplied, shall be a contextually converted constant expression of type
bool". We now have a dedicated function for creating such an expression,
so build_noexcept_spec should make use of it.
As a consequence, we now
The epiphany-elf target aligns structs to 8 bytes, which causes the
static_assert(alignof(_Chunk) == 1) to fail.
Instead of requiring _Chunks to be positionable at any alignment, ensure
new buffers are aligned to alignof(_Chunk). Because the buffer size is a
power of two, we know that both the
Hi Robin,
>> This will occur on any 32-bit target. The following patch (using
>> ssize_t instead) allowed the code to compile:
>
> thanks, included your fix and attempted a more generic version of the
> 186 test.
>
> I also continued debugging some fails further:
>
> - Most of the MurmurHash
On Thu, 2019-04-11 at 17:00 +0100, Richard Earnshaw (lists) wrote:
>
>
> Please add _alt at the end, to distinguish from the insn above.
>
> Otherwise OK.
I added _alt, I also had to move the "0" contraint and the "r"
constraint. I had "0" with operand 3 instead of operand 1 and
that caused a
When -fpatchable-relocation-entry is used, gcc places nops on the
prologue of each compiled function and creates a section named
__patchable_function_entries which holds relocation entries for the
positions in which the nops were placed. As is, gcc creates this
section without the proper section
Hello,
Attached you some of our factory made custom box with custom logo you
may interest as following.
Best regards
Slite
Best regards,
Slite
-
SLC-PACKAGE CO.LTD
www.slcpackage.com
Always Serve you by Heart
Address: No.10 Hualai Packaging Industry Park,Yuwu
.type _Z7_Z3fooii, @gnu_indirect_function
.set _Z7_Z3fooii,_Z3fooi.resolver
.text
.p2align 4
.globl _Z3barv
.type _Z3barv, @function
_Z3barv:
.LFB3:
.cfi_startproc
movl $2, %edi
jmp _Z7_Z3fooii
.cfi_endproc
.LFE3:
.size _
On 11/04/2019 16:21, Steve Ellcey wrote:
> On Thu, 2019-04-11 at 14:58 +, Steve Ellcey wrote:
>>
>>> You've removed the ..._noshift_alt variant. That wasn't my
>>> intention,
>>> so perhaps you misunderstood what I was trying to say.
>>>
>>> The two versions are both needed, since the
Hi Iain,
> @Rainer Orth any last requests before I commit the fix for PR
> d/89255? That will make testing individual library modules easier I
> guess.
no, the patch is perfectly fine as is. Sorry for not following up
earlier; I've now tested it successfully on Solaris 11.[345]/x86 and am
On Sat, 6 Apr 2019 at 19:05, Iain Buclaw wrote:
>
> On Sat, 6 Apr 2019 at 17:27, Matthias Klose wrote:
> >
> > On 29.03.19 23:23, Iain Buclaw wrote:
> > > On Mon, 18 Feb 2019 at 14:26, Matthias Klose wrote:
> > >>
> > >>
> > >> sorry, I didn't mean to propose to rename the option, so
> > >>
On Thu, 11 Apr 2019 at 17:43, Robin Dapp wrote:
>
> Hi Rainer,
>
> > This will occur on any 32-bit target. The following patch (using
> > ssize_t instead) allowed the code to compile:
>
> thanks, included your fix and attempted a more generic version of the
> 186 test.
>
> I also continued
Hi Rainer,
> This will occur on any 32-bit target. The following patch (using
> ssize_t instead) allowed the code to compile:
thanks, included your fix and attempted a more generic version of the
186 test.
I also continued debugging some fails further:
- Most of the MurmurHash fails are
On Thu, 2019-04-11 at 14:58 +, Steve Ellcey wrote:
>
> > You've removed the ..._noshift_alt variant. That wasn't my
> > intention,
> > so perhaps you misunderstood what I was trying to say.
> >
> > The two versions are both needed, since the register tie is not
> > orthogonal to the
Hi,
over the last few days I spent some time on this regression, which at
first seemed just a minor error-recovery issue, but then I noticed that
very slightly tweeking the original testcase uncovered a pretty serious
ICE on valid:
template void
fk (XE..., int/*SW*/);
void
w9 (void)
{
fk
On 4/11/19 3:50 AM, Jakub Jelinek wrote:
Hi!
While looking into another PR, I've noticed that in two spots the
parser->type_definition_forbidden_message messages are untranslatable,
we construct them at runtime from 3 strings using concat.
The following patch fixes it by adding a const char *
Hi,
this reorganization of cgraph_node:clone_of_p() prevents verifier
falsely ICEing because it cannot recognize that a former thunk (expanded
even before reaching pass pipeline) was cloned by IPA-CP.
It basically traverses the clone_of chain at each step of thunk chain
traversal, rather than
On Thu, 2019-04-11 at 09:59 +0100, Richard Earnshaw (lists) wrote:
>
> >
> > 2018-04-10 Steve Ellcey
> >
> > PR rtl-optimization/87763
> > * config/aarch64/aarch64-protos.h
> > (aarch64_masks_and_shift_for_bfi_p):
> > New prototype.
> > * config/aarch64/aarch64.c
On 4/11/19 2:31 AM, Tom de Vries wrote:
Hi Sandra,
thanks for the review.
I've attached the updated patch, as well as the resulting relevant
gcc.info portion.
OK for trunk?
This version looks OK. Thanks for helping to improve the docs!
-Sandra
Hi Dominique,
Yes indeed - I used int(kind(loc(res))) to achieve the same effect.
I am looking for but failing to find a similar problem for PR89846.
Tomorrow I turn my attention to an incorrect cast in the compiler.
Regards
Paul
On Thu, 11 Apr 2019 at 14:54, Dominique d'Humières wrote:
>
>
With the following code
module cdesc
interface
function cdesc_f08(buf, expected) result (res) BIND(C, name="cdesc_c")
USE, INTRINSIC :: ISO_C_BINDING
implicit none
INTEGER(C_INT) :: res
type(*), dimension(..), INTENT(INOUT) :: buf
type(c_ptr),INTENT(IN) ::
On Tue, Mar 12, 2019 at 10:58:14AM +0100, Jakub Jelinek wrote:
> These are the only remaining cases of gcc-internal-format diagnostics using
> HOST_WIDE_INT_PRINT*. That is wrong because the string depends on the exact
> host, and xgettext doesn't handle it anyway, so in gcc.pot the messages are
Hi!
While doing make gcc.pot, I've noticed warnings about unterminated string
in loongson-mmintrin.h.
I don't have any usable mips setup, but just tried:
/tmp/1a.c:
# error "You must select -mloongson-mmi or -march=loongson2e/2f/3a to use
loongson-mmiintrin.h"
/tmp/1b.c:
# error You must
On Thu, 11 Apr 2019, Jan Hubicka wrote:
> > On Thu, 11 Apr 2019, Jan Hubicka wrote:
> >
> > > Hi,
> > > the LTO streaming forks for every partition. With the number of
> > > partitions incrased to 128 and relatively large memory usage (around
> > > 5GB) needed to WPA firefox this causes kernel
Hi!
These 3 *.opt messages are printed using:
opts-common.c: error_at (loc, option->missing_argument_error, opt);
opts-common.c: error_at (loc, e->unknown_error, arg);
opts-common.c:warning_at (loc, 0, decoded->warn_message, opt);
and so they do support the various gcc-internal-format
On 4/11/19 1:15 PM, Jakub Jelinek wrote:
> On Thu, Apr 11, 2019 at 01:10:00PM +0200, Richard Biener wrote:
>> On Thu, Apr 11, 2019 at 12:47 PM Jakub Jelinek wrote:
>>>
>>> On Thu, Apr 11, 2019 at 12:44:40PM +0200, Martin Liška wrote:
On 4/11/19 11:57 AM, Richard Biener wrote:
> On Thu,
> On Thu, 11 Apr 2019, Jan Hubicka wrote:
>
> > Hi,
> > the LTO streaming forks for every partition. With the number of
> > partitions incrased to 128 and relatively large memory usage (around
> > 5GB) needed to WPA firefox this causes kernel to spend a lot of time
> > probably by copying the
On Thu, 11 Apr 2019, Jan Hubicka wrote:
> Hi,
> the LTO streaming forks for every partition. With the number of
> partitions incrased to 128 and relatively large memory usage (around
> 5GB) needed to WPA firefox this causes kernel to spend a lot of time
> probably by copying the page tables.
>
>
Hi,
the LTO streaming forks for every partition. With the number of
partitions incrased to 128 and relatively large memory usage (around
5GB) needed to WPA firefox this causes kernel to spend a lot of time
probably by copying the page tables.
This patch makes the streamer to for only
On Thu, Apr 11, 2019 at 01:10:00PM +0200, Richard Biener wrote:
> On Thu, Apr 11, 2019 at 12:47 PM Jakub Jelinek wrote:
> >
> > On Thu, Apr 11, 2019 at 12:44:40PM +0200, Martin Liška wrote:
> > > On 4/11/19 11:57 AM, Richard Biener wrote:
> > > > On Thu, Apr 11, 2019 at 10:37 AM Martin Liška
On Thu, Apr 11, 2019 at 12:47 PM Jakub Jelinek wrote:
>
> On Thu, Apr 11, 2019 at 12:44:40PM +0200, Martin Liška wrote:
> > On 4/11/19 11:57 AM, Richard Biener wrote:
> > > On Thu, Apr 11, 2019 at 10:37 AM Martin Liška wrote:
> > >>
> > >> Hi.
> > >>
> > >> The patch is catching duplicate
On Wed, 10 Apr 2019 at 11:57, Richard Earnshaw (lists)
wrote:
>
> 'to N' is now redundant and misleading given the earlier change to use
> .
>
> Removed
>
> * config/aarch64/aarch64.opt (msve-vector-bits): Remove redundant and
> obsolete reference to N.
>
Hi Richard,
I've just
On Thu, Apr 11, 2019 at 12:44:40PM +0200, Martin Liška wrote:
> On 4/11/19 11:57 AM, Richard Biener wrote:
> > On Thu, Apr 11, 2019 at 10:37 AM Martin Liška wrote:
> >>
> >> Hi.
> >>
> >> The patch is catching duplicate 'default' values in target attribute.
> >>
> >> Patch can bootstrap on
On 4/11/19 11:57 AM, Richard Biener wrote:
> On Thu, Apr 11, 2019 at 10:37 AM Martin Liška wrote:
>>
>> Hi.
>>
>> The patch is catching duplicate 'default' values in target attribute.
>>
>> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>>
>> Ready to be installed?
>
> I
Hi Matthew,
On 4/11/19 10:26 AM, Matthew Malcomson wrote:
r269586 changed the format of some warning messages.
Each switch in the warning message is now surrounded by single quotes.
This commit updates the regex's in arm.exp dejagnu files to match the
new format and remove the extra 20+ FAILs
On Thu, Apr 11, 2019 at 10:37 AM Martin Liška wrote:
>
> Hi.
>
> The patch is catching duplicate 'default' values in target attribute.
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>
> Ready to be installed?
I wonder if it isn't better to ignore duplicate "default"s
Hi all,
I am planning to commit the following patch
--- ../_clean/gcc/fortran/module.c 2019-03-21 20:46:46.0 +0100
+++ gcc/fortran/module.c2019-04-11 10:28:37.0 +0200
@@ -7144,8 +7144,12 @@ gfc_use_module (gfc_use_list *module)
for (p = gfc_state_stack; p; p =
On Thu, 11 Apr 2019, Jakub Jelinek wrote:
> On Thu, Apr 11, 2019 at 09:54:24AM +0200, Richard Biener wrote:
> > > Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
> > >
> > > During those 2 bootstraps/regtests, data.load_found has been set just
> > > on the new testcase on
r269586 changed the format of some warning messages.
Each switch in the warning message is now surrounded by single quotes.
This commit updates the regex's in arm.exp dejagnu files to match the
new format and remove the extra 20+ FAILs on excess errors that are
introduced on certain variations
On Thu, Apr 11, 2019 at 10:38 AM Martin Liška wrote:
>
> Hi.
>
> The patch is adding missing AVX512 ISAs for target and target_clone
> attributes.
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>
> Ready to be installed?
> Thanks,
> Martin
>
> gcc/ChangeLog:
>
>
On Thu, Apr 11, 2019 at 09:54:24AM +0200, Richard Biener wrote:
> > Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
> >
> > During those 2 bootstraps/regtests, data.load_found has been set just
> > on the new testcase on ia32.
>
> Hmm, I wonder whether we really need to DCE
On 10/04/2019 21:31, Steve Ellcey wrote:
> On Wed, 2019-04-10 at 11:10 +0100, Richard Earnshaw (lists) wrote:
>>
>> OK with those changes.
>>
>> R.
>
> I made the changes you suggested and checked in the patch. Just to be
> complete, here is the final version of the patch that I checked in.
>
>
On 3/28/19 9:52 AM, Martin Liška wrote:
> Hi.
>
> Backporting one documentation fix.
>
> Martin
>
One more patch that I'm going to backport.
Martin
>From a096ce6d9f8e636815af5a237881e1ba443f1b18 Mon Sep 17 00:00:00 2001
From: marxin
Date: Fri, 8 Mar 2019 12:55:40 +
Subject: [PATCH]
On Thu, 11 Apr 2019, Jakub Jelinek wrote:
> On Thu, Apr 11, 2019 at 09:54:24AM +0200, Richard Biener wrote:
> > > The following patch just punts if we find loads from stack slots in
> > > between
> > > where they are pushed and the const/pure call. In addition to that, I've
> > > outlined the
On Thu, Apr 11, 2019 at 09:54:24AM +0200, Richard Biener wrote:
> > The following patch just punts if we find loads from stack slots in between
> > where they are pushed and the const/pure call. In addition to that, I've
> > outlined the same largish sequence that had 3 copies in the function
Hi.
The patch is adding missing AVX512 ISAs for target and target_clone
attributes.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed?
Thanks,
Martin
gcc/ChangeLog:
2019-04-10 Martin Liska
PR target/89929
* config/i386/i386.c
Hi.
The patch is catching duplicate 'default' values in target attribute.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed?
Thanks,
Martin
gcc/ChangeLog:
2019-04-10 Martin Liska
PR middle-end/89970
* multiple_target.c
[ was: Re: [RFC, doc] Note variable shadowing at max macro using
statement expression ]
On 09-04-19 22:51, Sandra Loosemore wrote:
> On 4/8/19 5:38 AM, Tom de Vries wrote:
>> Hi,
>>
>> When suggesting to rewrite the unsafe (with respect to multiple
>> evaluation of
>> arguments) macro definition:
On Wed, Apr 10, 2019 at 7:48 AM bin.cheng wrote:
>
> Hi,
> This patch fixes ICE reported by PR90021. The issue has been there since
> loop interchange
> and recently exposed by patch for PR89725. As PR comment suggests, we have
> equal access
> function {{1, +, 1}_6, +, 1}_4 and _6 is of
On Wed, Apr 10, 2019 at 9:49 PM Jonathan Wakely wrote:
>
> On 10/04/19 13:55 -0500, Qing Zhao wrote:
> >Hi, Jonathan,
> >
> >thanks for your review on the documentation change for -flive-patching
> >option.
> >
> >>
> >>> --- a/gcc/doc/invoke.texi
> >>> +++ b/gcc/doc/invoke.texi
> >>> @@ -416,6
On Thu, 11 Apr 2019, Jakub Jelinek wrote:
> Hi!
>
> The following testcase is miscompiled, because the result of
> a DImode (doubleword) right shift is used in a QImode subreg as well as
> later on pushed into a stack slot as an argument to a const function
> whose result isn't used. The RA
Hi!
While looking into another PR, I've noticed that in two spots the
parser->type_definition_forbidden_message messages are untranslatable,
we construct them at runtime from 3 strings using concat.
The following patch fixes it by adding a const char * member
to the parser structure and passing
Hi!
The following testcase is miscompiled, because the result of
a DImode (doubleword) right shift is used in a QImode subreg as well as
later on pushed into a stack slot as an argument to a const function
whose result isn't used. The RA because of the weirdo target tuning
reuses the REG_EQUIV
63 matches
Mail list logo
