On Tue, Mar 19, 2019 at 8:53 PM Jeff Law wrote:
>
> On 3/6/19 3:05 AM, Richard Biener wrote:
> > On Tue, Mar 5, 2019 at 10:36 PM Jeff Law wrote:
> >>
> >> On 3/5/19 7:44 AM, Richard Biener wrote:
> >>
> >>> So fixing it properly with also re-optimize_stmt those stmts so we'd CSE
> >>> the MAX_EXP
See the corresponding thread on gcc-help:
"ggc_collect() discarding/reusing remap_debug_filename() output, thus producing
invalid objects"
Regards
Thomas
make-ggc-pick-up-comp_dir_string-cache-value.patch
Description: make-ggc-pick-up-comp_dir_string-cache-value.patch
Hi,
the unicode tables in std.internal.unicode_tables are apparently auto
generated and loaded at (libphobos) compile time. They are also in
little endian format. Is the tool to generate them available somewhere?
I wanted to start converting them to little endian before loading but
this will pr
Hi!
On Fri, 26 Aug 2016 08:16:43 -0700, Cesar Philippidis
wrote:
> While working on [...], I noticed
If only all such issues would end up in their own PRs, instead of mixing
them with other changes...
> that the fortran FE wasn't permitting
> named functions inside acc routine directives. E.g.
Hi!
Are there any further questions, or am I good to commit my patch as
posted?
On Thu, 14 Mar 2019 08:38:30 +0100, I wrote:
> On Wed, 13 Mar 2019 23:13:46 +0100, Thomas Koenig
> wrote:
> > Am 13.03.19 um 18:50 schrieb Thomas Schwinge:
> > >> There are many ways to deal with it without bumping
Hi Kyrill
On 12/03/2019 12:03, Kyrill Tkachov wrote:
> Hi Sudi,
>
> On 2/22/19 10:45 AM, Sudakshina Das wrote:
>> Hi
>>
>> This patch documents the addition of the new Armv8.5-A and corresponding
>> extensions in the gcc-9/changes.html.
>> As per https://gcc.gnu.org/about.html, I have used W3 Val
On Wed, 20 Mar 2019 at 10:57, Robin Dapp wrote:
>
> Hi,
>
> the unicode tables in std.internal.unicode_tables are apparently auto
> generated and loaded at (libphobos) compile time. They are also in
> little endian format. Is the tool to generate them available somewhere?
> I wanted to start co
On Wed, Mar 20, 2019 at 10:36 AM Otto, Thomas wrote:
>
> See the corresponding thread on gcc-help:
>
> "ggc_collect() discarding/reusing remap_debug_filename() output, thus
> producing invalid objects"
Hmm, but AFAICS it can end up on the heap if plain get_src_pwd ()
result survives. I vaguely
Hello Simon,
On 3/19/19 5:02 PM, Simon Wright wrote:
Ping?
Sorry for the delay! Thank you for the notice; I’ll try to get our fix
ported as soon as possible (hopefully before the end of the week).
Cheers,
--
Pierre-Marie de Rodat
> > "ggc_collect() discarding/reusing remap_debug_filename() output, thus
> > producing invalid objects"
>
> Hmm, but AFAICS it can end up on the heap if plain get_src_pwd () result
> survives. I vaguely remember GC being happy with heap strings (due to
> identifiers?), but not sure. Otherwise t
This patch addresses a compiler incompatibility with non-capturing
lambdas. Specifically, when a lambda's functions are comdat, we place
the static _FUN function in the same comdat group as the operator()
function.
This breaks link compatibility with clang, where the static function is
named
On 3/19/19 2:14 PM, Jakub Jelinek wrote:
Hi!
add_capture when parsing a lambda introducer uses the IDENTIFIER_MARKED
bit to detect duplicate captures.
I guess in strict C++11 that could have worked, if the introducer could
contain just identifiers, but in C++14 it has 2 problems:
The followin
On Wed, Mar 20, 2019 at 10:34:51AM -0400, Nathan Sidwell wrote:
> On 3/19/19 2:14 PM, Jakub Jelinek wrote:
> > add_capture when parsing a lambda introducer uses the IDENTIFIER_MARKED
> > bit to detect duplicate captures.
> > I guess in strict C++11 that could have worked, if the introducer could
>
On Wed, Mar 20, 2019 at 2:44 PM Otto, Thomas wrote
>
> > > "ggc_collect() discarding/reusing remap_debug_filename() output, thus
> > > producing invalid objects"
> >
> > Hmm, but AFAICS it can end up on the heap if plain get_src_pwd () result
> > survives. I vaguely remember GC being happy with h
On 3/20/19 10:48 AM, Jakub Jelinek wrote:
On Wed, Mar 20, 2019 at 10:34:51AM -0400, Nathan Sidwell wrote:
On 3/19/19 2:14 PM, Jakub Jelinek wrote:
add_capture when parsing a lambda introducer uses the IDENTIFIER_MARKED
bit to detect duplicate captures.
I guess in strict C++11 that could have wo
Hi,
there is a bug in the current support for -flive-patching=inline-only-static:
it rejects inlining of external always_inline routine, therefore triggers a
compilation time error.
we should always inline “always_inline” routines.
please review the following simple patch, it has been bootstr
Even if a global register is being clobbered in a function we usually
do not save and restore it. However, we still have to do this if it is
a special register. Most of the places in the backend handle this
correctly but not the prologue/epilogue optimization.
Bootstrapped and regression tested on
Hi Harald,
My reading of the standard suggests that this is not allowed:
SOURCE shall be a scalar or array of any type.
MOLD shall be a scalar or array of any type. ...
I read the stanard differently. For comparison, look at UNPACK:
# VECTOR shall be a rank-one array of any type.
a
On Fri, Mar 15, 2019 at 10:53:35AM -0300, Alexandre Oliva wrote:
> On Mar 14, 2019, Jason Merrill wrote:
>
> >> You can use VAR_P for this.
>
> > OK with that change.
>
> Thanks, I went ahead and also added a test before dereferencing it,
> since there was evidence shortly thereafter that it co
Hi!
Already in the PR71446 patch I used ugly and slow code to avoid allocating
memory in a hash_set all the time, even when it will be used only rarely and
in PR89767 I've reached it again.
While e.g. a vec is POD that even doesn't have a constructor and auto_vec
has quite a cheap ctor, hash_set/
On Wed, Mar 20, 2019 at 11:10:19AM -0400, Nathan Sidwell wrote:
> I was unclear. I was for the lazy creation of the hash. I just think it
> can be lazily created at either the first or second explicit capture.
On top of the https://gcc.gnu.org/ml/gcc-patches/2019-03/msg00991.html
patch I've just
On 3/20/19 1:15 PM, Jakub Jelinek wrote:
On Wed, Mar 20, 2019 at 11:10:19AM -0400, Nathan Sidwell wrote:
I was unclear. I was for the lazy creation of the hash. I just think it
can be lazily created at either the first or second explicit capture.
On top of the https://gcc.gnu.org/ml/gcc-patc
Hi Janus,
the attached one-line patch fixes an ICE-on-invalid regression with
abstract interfaces. Regtests cleanly on x86_64-linux-gnu. Ok for
trunk and the release branches (7 and 8)?
OK for all.
Thanks for the patch!
Regards
Thomas
Thanks, Pierre-Marie: it'd be a shame if 9.1 couldn't handle IPv4.
--S
> On 20 Mar 2019, at 13:31, Pierre-Marie de Rodat wrote:
>
> Hello Simon,
>
> On 3/19/19 5:02 PM, Simon Wright wrote:
>> Ping?
>
> Sorry for the delay! Thank you for the notice; I’ll try to get our fix ported
> as soon as
On Wed, 20 Mar 2019 at 12:27, Iain Buclaw wrote:
>
> On Wed, 20 Mar 2019 at 10:57, Robin Dapp wrote:
> >
> > Hi,
> >
> > the unicode tables in std.internal.unicode_tables are apparently auto
> > generated and loaded at (libphobos) compile time. They are also in
> > little endian format. Is the
> > > > "ggc_collect() discarding/reusing remap_debug_filename() output,
> > > > thus producing invalid objects"
> > >
> > > Hmm, but AFAICS it can end up on the heap if plain get_src_pwd ()
> > > result survives. I vaguely remember GC being happy with heap
> > > strings (due to identifiers?), but
On 2/26/19 6:32 PM, Martin Sebor wrote:
> Please disregard the original patch and consider the attached
> version instead.
>
> On 2/26/19 5:03 PM, Martin Sebor wrote:
>> The false positive in PR89350 is due to -Wstringop-overflow
>> trusting that the sizetype offset in POINTER_PLUS_EXPR means
>> t
Hi Thomas,
based on your comments I'll withdraw the patch, but read on...
On 03/20/19 17:14, Thomas Koenig wrote:
> Hi Harald,
>
>> My reading of the standard suggests that this is not allowed:
>>
>>SOURCE shall be a scalar or array of any type.
>>
>>MOLD shall be a scalar or array of any
On Mar 20, 2019, Marek Polacek wrote:
> This test fails with
> pr88534.C:58:1: sorry, unimplemented: string literal in function template
> signature
Interesting... gcc-8 rejected it with an error message rejecting the
template parameter, but my latest trunk build (dated Mar 13, r269641)
compil
Jonathan Wakely writes:
> On 11/03/19 21:24 -0700, Thomas Rodgers wrote:
>>Let's try this patch -
>>
>
>
> The feature test macro should be 201603L (in and
> ):
>
> +// Feature test macro for parallel algorithms
> +# define __cpp_lib_parallel_algorithm 201703L
>
> ***
>
> The new files have cop
On Wed, 20 Mar 2019 at 22:05, Thomas Rodgers wrote:
> > +#if __cplusplus < 201703L
> > +# include
> > +#else
> >
> > We only give that warning for C++11 headers, but for anything newer it
> > should be just:
> >
> > +#if __cplusplus >= 201703L
>
> Did you mean
>
> +#if __cplusplus >= 201603L
>
>
The fix for 77656 caused us to call convert_nontype_argument even for
value-dependent arguments, to perform the conversion in order to avoid
a bogus warning.
In this case, the argument is Pod{N}. The call to build_converted_constant_expr
in convert_nontype_argument produces Pod::operator Enum(&{N
On Wed, Mar 20, 2019 at 01:05:10PM -0700, Thomas Rodgers wrote:
> > We only give that warning for C++11 headers, but for anything newer it
> > should be just:
> >
> > +#if __cplusplus >= 201703L
>
> Did you mean
>
> +#if __cplusplus >= 201603L
I guess so:
http://eel.is/c++draft/support.limits.ge
On Wed, Mar 20, 2019 at 09:13:42PM +0100, Jakub Jelinek wrote:
> On Wed, Mar 20, 2019 at 01:05:10PM -0700, Thomas Rodgers wrote:
> > > We only give that warning for C++11 headers, but for anything newer it
> > > should be just:
> > >
> > > +#if __cplusplus >= 201703L
> >
> > Did you mean
> >
> >
The issue here is that declval().d is considered instantiation-dependent
within a template, as the access to 'd' might depend on the particular
specialization. But when we're deducing template arguments for a call, we
know that the call and the arguments are non-dependent, so we can do the
substit
On Wed, 20 Mar 2019 at 22:15, Jakub Jelinek wrote:
>
> On Wed, Mar 20, 2019 at 09:13:42PM +0100, Jakub Jelinek wrote:
> > On Wed, Mar 20, 2019 at 01:05:10PM -0700, Thomas Rodgers wrote:
> > > > We only give that warning for C++11 headers, but for anything newer it
> > > > should be just:
> > > >
>
Ignore
Thomas Rodgers writes:
> Jonathan Wakely writes:
>
>> On 11/03/19 21:24 -0700, Thomas Rodgers wrote:
>>>Let's try this patch -
>>>
>>
>>
>> The feature test macro should be 201603L (in and
>> ):
>>
>> +// Feature test macro for parallel algorithms
>> +# define __cpp_lib_parallel_algorithm
Iain Buclaw writes:
> On Fri, 15 Mar 2019 at 16:50, Robin Dapp wrote:
>>
>> Hi,
>>
>> during the last few days I tried to get D running on s390x (apparently
>> the first Big Endian platform to try it?). I did not yet go through the
>> code systematically and add a version(SystemZ) in every plac
See attached.
20190320-pstl-integration.patch.bz2
Description: revised pstl integration patch
Jonathan Wakely writes:
> On 11/03/19 21:24 -0700, Thomas Rodgers wrote:
>>Let's try this patch -
>>
>
>
> The feature test macro should be 201603L (in and
> )
Hi Jason ---
On 17/03/19 21:06, Jason Merrill wrote:
Earlier changes to defer instantiating a defaulted noexcept-specifier that
depends on yet-unparsed default member initializers broke this testcase,
where instantiation fails for another reason. In this case there's no
reason to defer and try
20190320-1-pstl-integration.patch.bz2
Description: Revised pstl integration patch
This time with the changelog reflecting the updated files in include/std
Thomas Rodgers writes:
> See attached.
>
> Jonathan Wakely writes:
>
>> On 11/03/19 21:24 -0700, Thomas Rodgers wrote:
20190320-2-pstl-integration.patch.bz2
Description: Revised pstl integration patch
Fixed a failing test.
Thomas Rodgers writes:
> This time with the changelog reflecting the updated files in include/std
>
> Thomas Rodgers writes:
>
>> See attached.
>>
>> Jonathan
On 3/20/19 1:12 PM, Jakub Jelinek wrote:
Already in the PR71446 patch I used ugly and slow code to avoid allocating
memory in a hash_set all the time, even when it will be used only rarely and
in PR89767 I've reached it again.
While e.g. a vec is POD that even doesn't have a constructor and auto
Am Mi., 20. März 2019 um 18:26 Uhr schrieb Thomas Koenig
:
>
> Hi Janus,
>
> > the attached one-line patch fixes an ICE-on-invalid regression with
> > abstract interfaces. Regtests cleanly on x86_64-linux-gnu. Ok for
> > trunk and the release branches (7 and 8)?
>
> OK for all.
Thanks, Thomas. Com
On 3/20/19 4:50 PM, Paolo Carlini wrote:
Hi Jason ---
On 17/03/19 21:06, Jason Merrill wrote:
Earlier changes to defer instantiating a defaulted noexcept-specifier
that
depends on yet-unparsed default member initializers broke this testcase,
where instantiation fails for another reason. In th
On Wed, Mar 20, 2019 at 05:32:16PM -0400, Jason Merrill wrote:
> > Does this look reasonable, or do you have other proposals?
>
> IMO if you need to guard usage with
>
> + if (some_type_hash_table.size () == 0)
> + some_type_hash_table.create ();
>
> this isn't any better than
>
> /*
On Wed, Mar 20, 2019 at 04:56:33PM -0300, Alexandre Oliva wrote:
> On Mar 20, 2019, Marek Polacek wrote:
>
> > This test fails with
> > pr88534.C:58:1: sorry, unimplemented: string literal in function template
> > signature
>
> Interesting... gcc-8 rejected it with an error message rejecting t
On Wed, Mar 20, 2019 at 05:55:04PM -0400, Marek Polacek wrote:
> On Wed, Mar 20, 2019 at 04:56:33PM -0300, Alexandre Oliva wrote:
> > On Mar 20, 2019, Marek Polacek wrote:
> >
> > > This test fails with
> > > pr88534.C:58:1: sorry, unimplemented: string literal in function template
> > > signatu
On Wed, Mar 20, 2019 at 10:58:32PM +0100, Jakub Jelinek wrote:
> On Wed, Mar 20, 2019 at 05:55:04PM -0400, Marek Polacek wrote:
> > On Wed, Mar 20, 2019 at 04:56:33PM -0300, Alexandre Oliva wrote:
> > > On Mar 20, 2019, Marek Polacek wrote:
> > >
> > > > This test fails with
> > > > pr88534.C:58:
The PRs originated in gfc_element_size lacking a treatment of
procedure pointers, which has been added. The testcase is currently
a pure compile test. When a reduced run-time test for PR83515
becomes available, it will be added to the testsuite.
Regtested on x86_64-pc-linux-gnu.
OK for trunk?
Hi!
As mentioned in the PR, if e.g. build_aligned_type creates some specially
aligned variant of some TYPE_MAIN_VARIANT, that type doesn't appear in the
IL during free_lang_data and later on we call build_aligned_type with the
same arguments as before, we'll get the previously created aligned vari
Hi,
This patch adds a new visit method in the decl walker to handle
functions whose return type is instantiated from a nested template (a
voldemort type), as it needs to be ensured that all members of the
instance are emitted before finishing the outer function, otherwise
they will be removed duri
More pings!
On Fri, Mar 08, 2019 at 09:56:05AM +, co...@sdf.org wrote:
> Ping.
>
> Link for possible convenience :-)
> https://gcc.gnu.org/ml/gcc-patches/2019-02/msg01899.html
Hi
For now, gcc can not fold code like:
const char a[5] = "123"
__builtin_memchr (a, '7', sizeof a)
It tries to avoid folding out of string length although length of a is 5.
This is a bit conservative, it's safe to folding memchr/bcmp/memcmp
builtins when constant string stores in array with som
On Thu, Mar 21, 2019 at 12:57 PM JunMa wrote:
>
> Hi
> For now, gcc can not fold code like:
>
> const char a[5] = "123"
> __builtin_memchr (a, '7', sizeof a)
>
> It tries to avoid folding out of string length although length of a is 5.
> This is a bit conservative, it's safe to folding memchr/bcmp
在 2019/3/21 下午1:06, Bin.Cheng 写道:
On Thu, Mar 21, 2019 at 12:57 PM JunMa wrote:
Hi
For now, gcc can not fold code like:
const char a[5] = "123"
__builtin_memchr (a, '7', sizeof a)
It tries to avoid folding out of string length although length of a is 5.
This is a bit conservative, it's safe
56 matches
Mail list logo
