On Wed, Oct 18, 2017 at 5:25 PM, H.J. Lu wrote:
> config/plugins.m4 has
>
> if test "$plugins" = "yes"; then
> AC_SEARCH_LIBS([dlopen], [dl])
> fi
>
> Plugin uses dlsym, but libasan.so only intercepts dlopen, not dlsym:
>
> [hjl@gnu-tools-1 binutils-text]$ nm -D /lib64/libasan.so.4| grep "
On Mon, Mar 26, 2018 at 4:06 AM, H.J. Lu wrote:
> On Sat, Mar 17, 2018 at 5:55 AM, H.J. Lu wrote:
>> On Fri, Dec 8, 2017 at 5:02 AM, H.J. Lu wrote:
>>> On Tue, Oct 24, 2017 at 5:31 AM, H.J. Lu wrote:
PLT should be avoided with shadow stack in 32-bit mode if more than 2
parameters are
Hello world,
here is the second version of the fix for PR 85102. This
is a much more general approach, which actually uses simplification
(while avoiding some "interesting" regressions when resolving, or
simplifying, too soon...)
Thanks to Dominique for the hint about the problem with my first p
On Mon, Mar 26, 2018 at 4:04 AM, H.J. Lu wrote:
> On Mon, Mar 19, 2018 at 10:04 AM, H.J. Lu wrote:
>>>
>>> Here are GCC 6 patches to backport all -mindirect-branch= patches.
>>> OK for GCC 6.
>>>
>>
>
> PING:
>
> https://gcc.gnu.org/ml/gcc-patches/2018-03/msg00884.html
>
PING.
--
H.J.
On Mon, Mar 26, 2018 at 4:09 AM, H.J. Lu wrote:
> On Fri, Jan 26, 2018 at 6:23 AM, H.J. Lu wrote:
>> On Sun, Jan 7, 2018 at 7:11 PM, H.J. Lu wrote:
>>> On Tue, Oct 24, 2017 at 10:58 AM, H.J. Lu wrote:
On Tue, Oct 24, 2017 at 10:40 AM, Andi Kleen wrote:
> "H.J. Lu" writes:
>> ---
On Mon, Apr 02, 2018 at 02:05:29PM +0200, Thomas König wrote:
> + if (as->type == AS_EXPLICIT)
> + {
> + for (int i = 0; i < as->rank; i++)
> + {
> + gfc_expr *e, *n;
> + e = as->lower[i];
> + if (e->expr_type != EXPR_CONSTANT)
> + {
On Tue, 27 Mar 2018, Richard Biener wrote:
> > > so this is kind-of global regs being live across all BBs? This sounds
> > > a bit stupid to me, but well ... IMHO those refs should be at
> > > specific insns like calls.
> > >
> > > So maybe, with a big fat comment, it is OK to ignore artificial
>
Hello, gentle maintainer.
This is a message from the Translation Project robot. (If you have
any questions, send them to .)
A new POT file for textual domain 'gcc' has been made available
to the language teams for translation. It is archived as:
http://translationproject.org/POT-files/gcc-
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'gcc' has been submitted
by the Danish team of translators. The file is available at:
http://translationproject.org/latest/gcc/da.po
(This file, 'gcc-8.1-b20180128.da.po', h
I noticed this on one recent page, and looking into it then ended
up fixing a dozen more, historical and current.
Committed.
Gerald
Index: htdocs/frontends.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/frontends.html,v
retrieving revis
On 2/8/18 2:44 PM, Peter Bergner wrote:
> I have committed the following obvious testsuite patch to fix PR81143.
> The "bug" is that __ORDER_LITTLE_ENDIAN__ is always defined for both
> little and big endian compiles. I checked and this is the only use
> of this in the gcc.target/powerpc/ director
On Tue, 20 Feb 2018, Bogdan Harjoc wrote:
> __VA_OPT__ was documented after 7.3.0 and the eprintf example for it
> ends with two backslashes instead of one:
>
> https://gcc.gnu.org/onlinedocs/cpp/Variadic-Macros.html
Thank you for reporting this, Bogdan.
I just fixed this per the patch below.
G
Hi Steve,
else
gfc_free_expr (n);
Don't you need the above changes to avoid leaking memory?
Correct.
OK with those changes?
Regards
Thomas
In this testcase, we have (auto...), a function parameter pack without
a declarator. Because there is no declarator, we were never hitting
the code for turning the auto type into a template parameter pack, so
the ... ended up being parsed as a C-style trailing ellipsis.
Tested x86_64-pc-linux-gnu
Attached is a patch to remove the hyphen from uses of side-effect
in the manual as per the comment in:
https://gcc.gnu.org/ml/gcc-patches/2018-04/msg00021.html
Although both forms are common, "side effect" (without the hyphen)
is more prevalent in current English and I think it's better to be
On Sat, Mar 31, 2018 at 7:12 AM, Alexandre Oliva wrote:
> On Mar 30, 2018, Jason Merrill wrote:
>
>> On Fri, Mar 30, 2018 at 3:55 AM, Alexandre Oliva wrote:
>>> Types defined within a __builtin_offsetof argument don't always get
>>> properly recorded as members of their context types
>
>>> I sup
On 04/02/2018 12:09 AM, Sandra Loosemore wrote:
On 03/27/2018 03:21 PM, Pedro Alves wrote:
On 03/27/2018 09:19 PM, Martin Sebor wrote:
On 03/27/2018 01:38 PM, Pedro Alves wrote:
On 03/27/2018 07:18 PM, Martin Sebor wrote:
+Because a @code{pure} function can have no side-effects it does not
This is a fix for PR 84660 which is a combine bug with SHIFT_COUNT_TRUNCATED.
It seems that use of SHIFT_COUNT_TRUNCATED is discouraged now, so rather than
fix combine this fixes the RISC-V backend to stop using SHIFT_COUNT_TRUNCATED.
This required adding 6 new patterns, and changing the existing p
On Fri, Mar 23, 2018 at 5:33 AM, Richard Biener
wrote:
> I'm leaving the "simple" combiner patch to review by others
> but for RISC-V you could simply #define SHIFT_COUNT_TRUNCATED to zero
> to fix the issue. Then add patterns if it turns out to be required
> to avoid regressions. For example x8
I committed r259020 to fix a couple of typos in the documentation
of the -Wrestrict option. The diff is below for reference.
Martin
Index: gcc/doc/invoke.texi
===
--- gcc/doc/invoke.texi (revision 259019)
+++ gcc/doc/invoke.texi (w
On 3/28/18 7:21 PM, Segher Boessenkool wrote:
> On Wed, Mar 28, 2018 at 07:13:36PM -0500, Peter Bergner wrote:
>> Do we care enough to fix these on the release branches? If so, I
>> can backport them easily, since they're not that involved.
>> I'll leave it up to you to decide.
>
> If it's easy,
On 3/30/18 6:15 PM, Segher Boessenkool wrote:
> But okay (with the fixes), and okay for 7. Thanks!
Ok, committed now to trunk and GCC 7 with your suggestions. Thanks!
Peter
On Sat, Mar 31, 2018 at 4:23 AM, Alexandre Oliva wrote:
> On Mar 30, 2018, Jason Merrill wrote:
>
>> True, it looks like sometimes we build a TEMPLATE_ID_EXPR with an
>> IDENTIFIER_NODE. Looking at tsubst_copy_and_build, I see that we
>> don't call finish_id_expression when substituting such a
>
On Sat, Mar 31, 2018 at 2:24 AM, Alexandre Oliva wrote:
> On Mar 30, 2018, Jason Merrill wrote:
>
>> I don't think we need this; if arg is overloaded, we take the
>> type_unknown_p early exit, so the code lower down is always dealing
>> with a single function.
>
> Aah, that's why it seemed to me
24 matches
Mail list logo
