elling location of _Pragma in DO_PRAGMA and has to be converted to the
expansion
point of the macro to get the expected result.
Bootstrapped and reg-tested on x86_64-pc-linux-gnu.
Is it OK for trunk?
Thanks
Bernd.libcpp:
2018-07-04 Bernd Edlinger
* macro.c (enter_macro_context): Ch
Ping: https://gcc.gnu.org/ml/gcc-patches/2018-07/msg00197.html
On 07/04/18 12:53, Bernd Edlinger wrote:
> Hi,
>
> currently _Pragma("GCC diagnostic ...") does not properly
> work in macro expansions.
>
> Consider the following code:
>
> #def
Hi,
this fixes PR middle-end/86528.
Bootstrapped and reg-tested on x86_64-pc-linux-gnu.
Is it OK for trunk?
Thanks
Bernd.
gcc:
2018-07-04 Bernd Edlinger
PR middle-end/86528
* builtins.c (check_access): Bail out if range[0] is no INTEGER_CST.
* expr.c (string_constant): Fix the element
if (TREE_CODE (idx) != INTEGER_CST
&& TREE_CODE (argtype) == POINTER_TYPE)
{
/* From a pointer (but not array) argument extract the variable
index to prevent get_addr_base_and_unit_offset() from failing
due to it.
> @@ -633,12 +642,17 @@ c_strlen (tree src, int only_value)
> return ssize_int (0);
>
>/* We don't know the starting offset, but we do know that the string
> - has no internal zero bytes. We can assume that the offset falls
> - within the bounds of the string; otherwise,
/* Support only properly NUL-terminated strings but handle
consecutive strings within the same array, such as the six
substrings in "1\0002\0003". */
return NULL;
}
Bootstrapped and reg-tested on x86_64-pc-linux-gnu.
Is it OK for trunk?
Thanks
Bernd.
2
On 07/19/18 20:11, Jeff Law wrote:
> On 07/19/2018 12:04 PM, Bernd Edlinger wrote:
>> Hi,
>>
>>
>> this fixes a few minor nits, which I spotted while
>> looking at the string folding functions:
>>
>> string_constant: Remove impossible check: TREE_CODE (
On 07/19/18 22:03, Martin Sebor wrote:
> On 07/19/2018 07:23 AM, Bernd Edlinger wrote:
>>> @@ -633,12 +642,17 @@ c_strlen (tree src, int only_value)
>>> return ssize_int (0);
>>>
>>> /* We don't know the starting offset, but we do know th
>@@ -11413,8 +11429,10 @@ string_constant (tree arg, tree *ptr_offset)
> const char a[4] = "abc\000\000";
> The excess elements contribute to TREE_STRING_LENGTH()
> but not to strlen(). */
>- unsigned HOST_WIDE_INT length
>-= strnlen (TREE_STRING_POINTER (init), TREE_STRING_LEN
>@@ -605,14 +605,21 @@ c_strlen (tree src, int only_value)
>
> /* Set MAXELTS to sizeof (SRC) / sizeof (*SRC) - 1, the maximum possible
> length of SRC. Prefer TYPE_SIZE() to TREE_STRING_LENGTH() if possible
>- in case the latter is less than the size of the array. */
>- HOST_WIDE_IN
> if (TREE_CODE (arg) == ADDR_EXPR)
> {
>+ tree argtype = TREE_TYPE (arg);
>+ chartype = argtype;
This assignment should be unnecessary here. Right?
>+
> arg = TREE_OPERAND (arg, 0);
> tree ref = arg;
> if (TREE_CODE (arg) == ARRAY_REF)
> {
> tree
Hi!
This fixes a not NUL terminated STRING_CST object.
Bootstrapped and reg-tested on x86_64-pc-linux-gnu.
Is it OK for trunk?
Thanks
Bernd.
2018-07-20 Bernd Edlinger
* gimple-fold.c (gimple_fold_builtin_printf): Don't create a not NUL
terminated STRING_CST object.
--- g
Martin,
when I look at tree-ssa-forwprop.c:
str1 = string_constant (src1, &off1);
if (str1 == NULL_TREE)
break;
if (!tree_fits_uhwi_p (off1)
|| compare_tree_int (off1, TREE_STRING_LENGTH (str1) - 1) > 0
I think I have found a valid test case where the latest patch
does generate invalid code:
$ cat part.c
static const char a[3][8] = { "1234", "12345", "123456" };
int main ()
{
volatile int i = 1;
int n = __builtin_strlen (*(&a[1]+i));
if (n != 6)
__builtin_abort ();
}
$ gcc part.c
On 07/21/18 00:15, Martin Sebor wrote:
> On 07/20/2018 08:51 AM, Bernd Edlinger wrote:
>> Martin,
>>
>> when I look at tree-ssa-forwprop.c:
>>
>> str1 = string_constant (src1, &off1);
>> if (str1 == NULL_TREE)
>
On 07/21/18 01:58, Martin Sebor wrote:
> On 07/20/2018 03:11 PM, Bernd Edlinger wrote:
>> I think I have found a valid test case where the latest patch
>> does generate invalid code:
>
> This is due to another bug in string_constant() that's latent
> on trunk bu
Hi,
this fixes an use of a buffer after the block scope
in hsa-dump.c: "buf" is assigned to "name" and used after
the scope ends in a fprintf.
I have not done any real checks, except boot-strapping with
all languages.
Is it OK for trunk?
Thanks
Bernd.
2018-07-22 Bernd Edl
Edlinger
PR c/86617
* genmatch.c (dt_operand::gen_match_op): Avoid folding volatile values.
testsuite:
2018-07-23 Bernd Edlinger
PR c/86617
* gcc.dg/pr86617.c: New test.
Index: gcc/genmatch.c
===
--- gcc/genmatch.c (revision
nings.
Bootstrapped and reg-tested on x86_64-pc-linux-gnu.
Is it OK for trunk?
Thanks
Bernd.gcc:
2018-07-24 Bernd Edlinger
* gimple-fold.c (get_range_strlen): Add a check for type casts.
Use outermost enclosing array size instead of innermost one.
* tree-ssa-str
On 07/24/18 23:46, Jeff Law wrote:
> On 07/24/2018 01:59 AM, Bernd Edlinger wrote:
>> Hi!
>>
>> This patch makes strlen range computations more conservative.
>>
>> Firstly if there is a visible type cast from type A to B before passing
>> then value to strle
On 07/24/18 16:50, Richard Biener wrote:
> On Tue, 24 Jul 2018, Bernd Edlinger wrote:
>
>> Hi!
>>
>> This patch makes strlen range computations more conservative.
>>
>> Firstly if there is a visible type cast from type A to B before passing
>> then value
> @@ -567,13 +597,17 @@ string_length (const void *ptr, unsigned eltsize,
> unsigned maxelts)
> accesses. Note that this implies the result is not going to be emitted
>into the instruction stream.
>
> + When ARR is non-null and the string is not properly nul-terminated,
> + set *ARR
I have one more example similar to PR86259, that resembles IMHO real world code:
Consider the following:
int fun (char *p)
{
char buf[16];
assert(strlen(p) < 4); //here: security relevant check
sprintf(buf, "echo %s - %s", p, p); //here: security relevant code
return system(buf);
}
W
, as far as I can see.
Bootstrapped and reg-tested on x86_64-pc-linux-gnu.
Is it OK for trunk?
Thanks
Bernd.
2018-07-29 Bernd Edlinger
* tree-ssa-forwprop.c (simplify_builtin_call): Don't create a not NUL
terminated string literal.
Index: gcc/tree-ssa-forwp
trunk?
Thanks
Bernd.
gcc:
2018-07-29 Bernd Edlinger
PR middle-end/86711
PR middle-end/86714
* builtins.c (c_strlen): Use tree_to_shwi because maxelts is signed.
* expr.c (string_constant): Don't return truncated string literals.
* fold-const.c (c_ge
send it to gcc-patches anyway, hope you don't mind...
The patch is relative to the other patch here:
https://gcc.gnu.org/ml/gcc-patches/2018-07/msg01800.html
Bootstrapped and reg-tested on x86_64-pc-linux-gnu.
Is it OK for trunk?
Thanks
Bernd.gcc/c:
2018-07-30 Bernd Edlinger
* c-typ
On 07/30/18 15:03, Richard Biener wrote:
> On Mon, 30 Jul 2018, Bernd Edlinger wrote:
>
>> Hi,
>>
>> this is how I would like to handle the over length strings issue in the C FE.
>> If the string constant is exactly the right length and ends in one explicit
>&
On 07/30/18 01:05, Martin Sebor wrote:
> On 07/29/2018 04:56 AM, Bernd Edlinger wrote:
>> Hi!
>>
>> This fixes two wrong code bugs where string_constant
>> returns over length string constants. Initializers
>> like that are rejected in C++, but valid in C.
>
On 07/30/18 17:57, Jakub Jelinek wrote:
> On Mon, Jul 30, 2018 at 03:52:39PM +, Joseph Myers wrote:
>> On Mon, 30 Jul 2018, Bernd Edlinger wrote:
>>
>>> In the moment I would already be happy if all STRING_CSTs would
>>> be zero terminated.
>>
>> ge
On 07/30/18 18:01, Joseph Myers wrote:
> On Mon, 30 Jul 2018, Jakub Jelinek wrote:
>
>> On Mon, Jul 30, 2018 at 03:52:39PM +, Joseph Myers wrote:
>>> On Mon, 30 Jul 2018, Bernd Edlinger wrote:
>>>
>>>> In the moment I would already be happy if all
On 07/30/18 21:52, Martin Sebor wrote:
> On 07/30/2018 09:24 AM, Bernd Edlinger wrote:
>> On 07/30/18 01:05, Martin Sebor wrote:
>>> On 07/29/2018 04:56 AM, Bernd Edlinger wrote:
>>>> Hi!
>>>>
>>>> This fixes two wrong code bugs where str
Hi,
>@@ -621,6 +674,12 @@ c_strlen (tree src, int only_value)
> maxelts = maxelts / eltsize - 1;
> }
>
>+ /* Unless the caller is prepared to handle it by passing in a non-null
>+ ARR, fail if the terminating nul doesn't fit in the array the string
>+ is stored in (as in cons
x86_64-pc-linux-gnu.
Is it OK for trunk?
Thanks
Bernd.
2018-07-31 Bernd Edlinger
* gcc-interface/trans.c (gnat_to_gnu): Make string literal properly
NUL terminated.
* gcc-interface/utils2.c (expand_sloc): Likewise.
diff -pur gcc/ada/gcc-interface/trans.c gcc/ada/gcc-interface/trans.c
--- gcc
Hi,
could someone please review this patch and check it in into the GO FE?
Thanks
Bernd.
2018-07-31 Bernd Edlinger
* go-gcc.cc (Gcc_backend::string_constant_expression): Make string
literal properly NUL terminated.
diff -pur gcc/go/go-gcc.cc gcc/go/go-gcc.cc
--- gcc/go/go-gcc.cc 2018-06
On 07/30/18 15:03, Richard Biener wrote:
> On Mon, 30 Jul 2018, Bernd Edlinger wrote:
>
>> Hi,
>>
>> this is how I would like to handle the over length strings issue in the C FE.
>> If the string constant is exactly the right length and ends in one explicit
>&
On 07/31/18 16:40, Ian Lance Taylor wrote:
> On Tue, Jul 31, 2018 at 5:14 AM, Bernd Edlinger
> wrote:
>>
>> could someone please review this patch and check it in into the GO FE?
>
> I don't understand why the change is correct, and you didn't explain
> i
> Certainly not every "strlen" has these semantics. For example,
> this open-coded one doesn't:
>
>int len = 0;
>for (int i = 0; s.a[i]; ++i)
> ++len;
>
> It computes 2 (with no warning for the out-of-bounds access).
>
yes, which is questionable as well, but that happens only
if t
> The change to have all STRING_CSTs NUL terminated (but that NUL
> termination not necessarily inclided in STRING_LENGTH) is a good
> one.
>
> I'm not sure how we can reliably verify NUL termination after the
> fact though and build_string already makes sure to NUL terminate
> STRING_CSTs. So if
>> > The change to have all STRING_CSTs NUL terminated (but that NUL
>> > termination not necessarily inclided in STRING_LENGTH) is a good
>> > one.
>> >
>> > I'm not sure how we can reliably verify NUL termination after the
>> > fact though and build_string already makes sure to NUL terminate
>> >
Oops,
thanks for fixing this problem.
To my excuse I would like to note,
that the script error does not happen on x86_64-pc-linux-gnu,
probably it would only happen when a file is left over.
Since usually this is never executed because $outs is empty:
foreach f $outs {
file delete $
cls with
>> DECL_IGNORED_P to UNKNOWN_LOCATION.
>>
>> 2021-07-24 Bernd Edlinger
>>
>> PR debug/101598
>> * gcc-interface/trans.c (Subprogram_Body_to_gnu): Set the
>> DECL_SOURCE_LOCATION of DECL_IGNORED_P gnu_subprog_decl to
>>
On 8/4/21 4:33 PM, Eric Botcazou wrote:
>> The location of these ignored Ada decls looks completely sane to me.
>> However, it was an unintentional side effect of the patch to allow
>> minimal debugging of ignored decls. This means we can now step into
>> those functions or set line breakpoints th
On 8/9/21 4:37 PM, Eric Botcazou wrote:
>> But it is okay that we can set a breakpoint on defs__struct1IP,
>> in the test case of PR 101598.
>> And the debugger shall only show assembler here.
>> Right?
>
> The defs__struct1IP procedure should be totally transparent for the user, so
> setting a b
On 8/10/21 10:56 PM, Eric Botcazou wrote:
>> Ah, thanks, I tried it but the defs__struct1IP function has
>> DECL_IGNORED_P = false when I build it with -gnatD.
>>
>> So that would not be affected by setting DECL_SOURCE_LOCATION to
>> UNKNOWN_LOCATION as done in the proposed patch, because that is o
Ping...
On 10/18/19 3:19 PM, Bernd Edlinger wrote:
> Ping...
>
> for the c++ FE and testsuite changes in the updated patch
> here: https://gcc.gnu.org/ml/gcc-patches/2019-10/msg00916.html
>
>
> Thanks
> Bernd.
>
>
>
>
> On 10/12/19 8:10 PM, Bernd
Ping...
I'd like to ping for this patch:
https://gcc.gnu.org/ml/gcc-patches/2019-10/msg01459.html
Thanks
Bernd.
On 10/20/19 9:58 PM, Bernd Edlinger wrote:
> Hi,
>
> this fixes an issue with the gdb step-over aka. "n" command.
>
> It can be seen when you debug
Ping...
On 10/27/19 9:14 AM, Bernd Edlinger wrote:
> Ping...
>
> I'd like to ping for this patch:
> https://gcc.gnu.org/ml/gcc-patches/2019-10/msg01459.html
>
>
> Thanks
> Bernd.
>
> On 10/20/19 9:58 PM, Bernd Edlinger wrote:
>> Hi,
>>
>&g
, there are still more issues with can_convert, but I
would
like to fix the regression here without digging any deeper in the mud, at least
for now.
Boot-strapped and reg-tested on x86_64-pc-linux-gnu.
Is it OK for trunk?
Thanks
Bernd.
2019-11-08 Bernd Edlinger
PR c++/92365
* name-lookup.c
Ping...
On 11/2/19 7:49 AM, Bernd Edlinger wrote:
> Ping...
>
> On 10/27/19 9:14 AM, Bernd Edlinger wrote:
>> Ping...
>>
>> I'd like to ping for this patch:
>> https://gcc.gnu.org/ml/gcc-patches/2019-10/msg01459.html
>>
>>
>> Thanks
&
From: Bernd Edlinger
Date: Sun, 1 Nov 2020 07:32:20 +0100
Subject: [PATCH] Fix PR97205
This makes sure that stack allocated SSA_NAMEs are
at least MODE_ALIGNED. Also increase the MEM_ALIGN
for the corresponding rtl objects.
gcc:
2020-11-01 Bernd Edlinger
PR target/97205
* cfgexpand.c
On 11/2/20 3:07 PM, Richard Biener wrote:
> On Mon, 2 Nov 2020, Bernd Edlinger wrote:
>
>> Hi,
>>
>> this makes sure that stack allocated SSA_NAMEs are
>> at least MODE_ALIGNED. Also increase the MEM_ALIGN
>> for the corresponding rtl objects.
>>
>&g
On 11/3/20 10:34 AM, Richard Biener wrote:
> On Mon, 2 Nov 2020, Bernd Edlinger wrote:
>
>> On 11/2/20 3:07 PM, Richard Biener wrote:
>>> On Mon, 2 Nov 2020, Bernd Edlinger wrote:
>>>
>>>> Hi,
>>>>
>>>> this makes sure th
On 11/3/20 11:16 AM, Richard Biener wrote:
> On Tue, 3 Nov 2020, Bernd Edlinger wrote:
>
>>
>>
>> On 11/3/20 10:34 AM, Richard Biener wrote:
>>> On Mon, 2 Nov 2020, Bernd Edlinger wrote:
>>>
>>>> On 11/2/20 3:07 PM, Richard Biener
= array_size;
This happened due to a merge conflict a long time ago.
Bootstrapped and regtested on x86_64-pc-linux-gnu.
I think this qualifies as obvious, so I will commit it now.
Thanks
Bernd.
From 48a85b06992e4d915f29998f8db96ec2a019ea16 Mon Sep 17 00:00:00 2001
From: Bernd Edlinger
Dat
17 00:00:00 2001
From: Bernd Edlinger
Date: Mon, 2 Nov 2020 11:43:44 +0100
Subject: [PATCH] libgcc: Add a weak stub for __sync_synchronize
This patch adds a default implementation for __sync_synchronize,
which prevents many unresolved symbol errors on arm-none-eabi.
This happens often in C
Ping...
I'd like to ping for this patch:
https://gcc.gnu.org/pipermail/gcc-patches/2020-November/557886.html
Thanks
Bernd.
On 11/3/20 4:08 PM, Bernd Edlinger wrote:
> Hi,
>
> this fixes a problem with a missing symbol __sync_synchronize
> which happens when newlib is used toge
Hi,
I just wanted to ask, if there was any progress on this?
Thanks
Bernd.
On 12/21/19 10:50 AM, Bernd Edlinger wrote:
> Hi David,
>
> thanks for fixing this issue.
>
> Just one comment:
>
>> +[DIAGNOSTICS_URLS_DEFAULT=DIAGNOSTICS_URL_AUTO])
>> +AC_DEFINE_UNQ
e1c16aea Mon Sep 17 00:00:00 2001
From: Bernd Edlinger
Date: Wed, 29 Jan 2020 15:31:10 +0100
Subject: [PATCH] PR 87488: Add --with-diagnostics-urls configuration option
2020-01-30 David Malcolm
Bernd Edlinger
PR 87488
* config.in (DIAGNOSTICS_URLS_DEFAULT): New define.
* configure.ac
right? I did not notice any problem from this, does this work for you
this way?
And, is it the right thing to push those changes along this patch, or do you
want to take care of this by yourself?
Thanks
Bernd.
On 1/31/20 5:58 PM, Bernd Edlinger wrote:
> Hi,
>
> this is patch is heavily
On 1/31/20 11:54 PM, Segher Boessenkool wrote:
> Hi!
>
> Thanks for working on this.
>
> On Fri, Jan 31, 2020 at 04:59:02PM +, Bernd Edlinger wrote:
>> I will try to improve the patch a bit, and hope you are gonna like
>> it. I agree that this feature is fin
Hi Segher,
On 2/1/20 2:32 AM, Segher Boessenkool wrote:
> On Fri, Jan 31, 2020 at 11:38:04PM +0000, Bernd Edlinger wrote:
>> On 1/31/20 11:54 PM, Segher Boessenkool wrote:
>>> about most, which caused me to open PR93168, is TERM=screen (which is
>>> what tmux uses), s
On 1/31/20 11:06 PM, David Malcolm wrote:
> On Fri, 2020-01-31 at 16:59 +0000, Bernd Edlinger wrote:
>> Hi,
>>
>> this is patch is heavily based on David's original patch here:
>> https://gcc.gnu.org/ml/gcc-patches/2019-12/msg01409.html
>>
>> and addr
On 2/1/20 9:55 AM, Jakub Jelinek wrote:
> On Sat, Feb 01, 2020 at 07:30:15AM +0000, Bernd Edlinger wrote:
>> @@ -239,20 +243,86 @@ colorize_init (diagnostic_color_rule_t rule)
>> }
>> }
>>
>> +/* Return URL_FORMAT_XXX which tells how we should emi
On 2/1/20 2:41 PM, David Malcolm wrote:
> On Sat, 2020-02-01 at 07:30 +0000, Bernd Edlinger wrote:
>>
>> On 1/31/20 11:06 PM, David Malcolm wrote:
>>> On Fri, 2020-01-31 at 16:59 +, Bernd Edlinger wrote:
>>>> Hi,
>>>>
>>>> t
On 2/1/20 4:54 PM, Segher Boessenkool wrote:
> Hi!
>
> On Sat, Feb 01, 2020 at 05:02:18AM +0000, Bernd Edlinger wrote:
>>>> Definitely, if the situation with tmux is like xfce4-terminal (reportedly
>>>> the 0.8 version switched to a fixed VTE, which makes the
On 2/1/20 6:12 PM, Jakub Jelinek wrote:
> On Sat, Feb 01, 2020 at 03:43:20PM +0000, Bernd Edlinger wrote:
>> I seem to remember him saying that he always has to configure with
>> --with-diagnostics-color=never, and the URLs are on top of that.
>> But there was no configure o
On 1/31/20 11:54 PM, Segher Boessenkool wrote:
> none of which use "TERM=fancy-pants-term-v42" either. (Did anyone ever
> use "dumb", anyway?)
>
It seems like emacs shell does set TERM=dumb, and it is certainly
the right thing not to emit any control codes in that environment.
Bernd.
On 2/2/20 12:05 AM, Segher Boessenkool wrote:
> On Sat, Feb 01, 2020 at 05:21:30PM +0000, Bernd Edlinger wrote:
>> On 2/1/20 6:12 PM, Jakub Jelinek wrote:
>>> On Sat, Feb 01, 2020 at 03:43:20PM +0000, Bernd Edlinger wrote:
>>>> I seem to remember him saying that h
On 2/2/20 1:28 AM, Sandra Loosemore wrote:
> On 2/1/20 8:43 AM, Bernd Edlinger wrote:
>
>> diff --git a/gcc/doc/install.texi b/gcc/doc/install.texi
>> index 6ffafac..1d3fec5 100644
>> --- a/gcc/doc/install.texi
>> +++ b/gcc/doc/install.texi
>> @@ -2097,9 +2097,
On 2/3/20 3:08 PM, Segher Boessenkool wrote:
> On Sun, Feb 02, 2020 at 08:00:44AM +0000, Bernd Edlinger wrote:
>>>> Okay, thanks. That is a strong indication that there is no need
>>>> to interfere with screen, which proves that any auto-disabling should
>>
On 2/3/20 9:26 PM, Jakub Jelinek wrote:
> On Mon, Feb 03, 2020 at 08:16:52PM +0000, Bernd Edlinger wrote:
>> Jakub, can you confirm that the COLORTERM on your working
>> gnome-terminal is set to "truecolor" ?
>
> On the box where I have display attached to yes, bu
On 2/3/20 10:05 PM, Segher Boessenkool wrote:
> On Mon, Feb 03, 2020 at 08:16:52PM +0000, Bernd Edlinger wrote:
>> So gnome terminal is a problem, since it depend heavily on the software
>> version, VTE library, and gnome-terminal.
>> Sometimes URLs are functional, some
Ping...
the latest version of this patch is here:
https://gcc.gnu.org/ml/gcc-patches/2020-02/msg00121.html
Thanks
Bernd.
On 2/3/20 11:29 PM, Bernd Edlinger wrote:
> On 2/3/20 10:05 PM, Segher Boessenkool wrote:
>> On Mon, Feb 03, 2020 at 08:16:52PM +0000, Bernd Edlinger wrote:
>
Hi,
this is the split out patch on skip.exp which fixes a pre-existing
compatibilty issue with that test case and gcc-9.2.0 (and gcc-10 from
trunk of a few weeks ago at least, likely other versions too).
Is it OK for trunk?
Thanks
Bernd.
gdb/testsuite:
2019-12-15 Bernd Edlinger
Oh, sorry, worng mailing list.
Please ignore this one.
On 12/15/19 12:25 PM, Bernd Edlinger wrote:
> Hi,
>
> this is the split out patch on skip.exp which fixes a pre-existing
> compatibilty issue with that test case and gcc-9.2.0 (and gcc-10 from
> trunk of a few weeks ago a
Hi David,
thanks for fixing this issue.
Just one comment:
> +[DIAGNOSTICS_URLS_DEFAULT=DIAGNOSTICS_URL_AUTO])
> +AC_DEFINE_UNQUOTED(DIAGNOSTICS_URLS_DEFAULT, $DIAGNOSTICS_URLS_DEFAULT,
> +[The default for -fdiagnostics-urls option])
I think for a feature as disruptive as this, w
On 5/19/21 3:22 PM, H.J. Lu wrote:
> On Wed, May 19, 2021 at 2:33 AM Richard Biener
> wrote:
>>
>> On Tue, May 18, 2021 at 9:16 PM H.J. Lu wrote:
>>>
>>> When expanding a constant constructor, don't call expand_constructor if
>>> it is more efficient to load the data from the memory via move by p
On 5/19/21 3:27 PM, Jonathan Wakely wrote:
> On 18/05/21 13:58 +0200, Bernd Edlinger wrote:
>> On 5/18/21 1:55 PM, Bernd Edlinger wrote:
>>> On 5/17/21 7:13 PM, Jonathan Wakely via Gcc-patches wrote:
>>>> libstdc++-v3/ChangeLog:
>>>>
>>>>
IL: g++.dg/modules/omp-1_c.C -std=c++2a (test for excess errors)
FAIL: g++.dg/modules/omp-1_c.C -std=c++2b dg-regexp 6 not found: "In module
imported at [^\\n]*omp-1_c.C:3:1:\\nfoo: error: module contains OpenMP, use
'-fopenmp' to enable\\n"
FAIL: g++.dg/modules/omp-1_c.C -std=c++
On 5/20/21 4:03 PM, H.J. Lu wrote:
> On Thu, May 20, 2021 at 12:51 AM Richard Biener
> wrote:
>>
>> On Wed, May 19, 2021 at 3:22 PM H.J. Lu wrote:
>>>
>>> On Wed, May 19, 2021 at 2:33 AM Richard Biener
>>> wrote:
On Tue, May 18, 2021 at 9:16 PM H.J. Lu wrote:
>
> When expandin
On 5/20/21 10:49 PM, H.J. Lu wrote:
> On Wed, May 19, 2021 at 5:55 AM H.J. Lu wrote:
>>
>> On Wed, May 19, 2021 at 2:25 AM Richard Biener
>> wrote:
>>>
>>> On Tue, May 18, 2021 at 9:16 PM H.J. Lu wrote:
Add TARGET_READ_MEMSET_VALUE and TARGET_GEN_MEMSET_VALUE to support
target ins
On 5/21/21 8:57 AM, Richard Biener wrote:
> On Thu, May 20, 2021 at 4:04 PM H.J. Lu wrote:
>>
>> On Thu, May 20, 2021 at 12:51 AM Richard Biener
>> wrote:
>>>
>>> On Wed, May 19, 2021 at 3:22 PM H.J. Lu wrote:
On Wed, May 19, 2021 at 2:33 AM Richard Biener
wrote:
>
> O
On 5/25/21 4:22 PM, Richard Biener via Gcc-patches wrote:
> On Sun, May 23, 2021 at 12:03 PM apinski--- via Gcc-patches
> wrote:
>>
>> From: Andrew Pinski
>>
>> Instead of some of the more manual optimizations inside phi-opt,
>> it would be good idea to do a lot of the heavy lifting inside match
t;>> On Wed, May 26, 2021 at 2:01 AM Andrew Pinski wrote:
>>>>>
>>>>> On Wed, May 26, 2021 at 1:43 AM Bernd Edlinger
>>>>> wrote:
>>>>>>
>>>>>> On 5/25/21 4:22 PM, Richard Biener via Gcc-patches wrote:
>>>>>
On 5/26/21 7:03 PM, Bernd Edlinger wrote:
> On 5/26/21 2:05 PM, Richard Biener wrote:
>> On Wed, May 26, 2021 at 1:37 PM Andrew Pinski wrote:
>>>
>>> On Wed, May 26, 2021 at 4:28 AM Richard Biener
>>> wrote:
>>>>
>>>> On Wed, May 26, 2
On 5/19/21 3:37 PM, Bernd Edlinger wrote:
> On 5/19/21 3:27 PM, Jonathan Wakely wrote:
>> On 18/05/21 13:58 +0200, Bernd Edlinger wrote:
>>> On 5/18/21 1:55 PM, Bernd Edlinger wrote:
>>>> On 5/17/21 7:13 PM, Jonathan Wakely via Gcc-patches wrote
:
$(ALL_HOST_OBJS) : | $(generated_files)
So this patch adds gimple-match.c generic-match.c to generated_files.
Tested on x86_64-pc-linux-gnu.
Is it OK for trunk?
Thanks
Bernd.
2021-05-28 Bernd Edlinger
* Makefile.in (generated_files): Add gimple-match.c and
generic-match.c
From
On 5/28/21 6:42 AM, Bernd Edlinger wrote:
> Hi,
>
> I was wondering, why gimple-match.c and generic-match.c
> are not built early but always last, which slows down parallel
> makes significantly.
>
> The reason seems to be that generated_files does not
> mention gi
On 5/28/21 8:41 AM, Richard Biener wrote:
> On Fri, 28 May 2021, Bernd Edlinger wrote:
>
>>
>>
>> On 5/28/21 6:42 AM, Bernd Edlinger wrote:
>>> Hi,
>>>
>>> I was wondering, why gimple-match.c and generic-match.c
>>> are not buil
On 5/28/21 9:26 AM, Andrew Pinski wrote:
> On Thu, May 27, 2021 at 10:10 PM Bernd Edlinger
> wrote:
>>
>> Hi,
>>
>> I was wondering, why gimple-match.c and generic-match.c
>> are not built early but always last, which slows down parallel
>> makes signif
stage.
From-SVN: r235804
This silences the stage compare.
Bootstrapped and reg-tested on x86_64-pc-linux-gnu.
Is it OK for trunk?
Thanks
Bernd.
2021-05-28 Bernd Edlinger
objc/
* Make-lang.in (cc1obj-checksum.c): For stage-final re-use
the checksum from the previous
.
Is it OK for trunk?
Thanks
Bernd.
2021-05-28 Bernd Edlinger
* gcc.dg/plugin/diagnostic_plugin_show_trees.c (plugin_init): Fix
caret_max_with.
* gcc.dg/plugin/diagnostic_plugin_test_inlining.c
(plugin_init): Likewise.
* gcc.dg/plugin/diagnostic_plugin_test_
On 5/29/21 9:31 PM, Jeff Law wrote:
>
>
> On 5/28/2021 6:38 AM, Bernd Edlinger wrote:
>> Hi,
>>
>> it turns out to be reproducible this way:
>>
>> COLUMNS=80 make check-gcc-c RUNTESTFLAGS="plugin.exp=diagnostic*"
>>
>> Running
Ping...
On 5/28/21 9:47 AM, Bernd Edlinger wrote:
> Hi Richard,
>
> I've replicated your PR to make the objective-c checksum compare equal
>
> commit fb2647aaf55b453b37badfd40c14c59486a74584
> Author: Richard Biener
> Date: Tue May 3 08:14:27 2016 +
>
>
c:
2021-06-08 Bernd Edlinger
* Make-lang.in (cc1-obj-checksum.c): Check previous
stage checksum exists.
gcc/objcp:
2021-06-08 Bernd Edlinger
* Make-lang.in (cc1objplus-checksum.c): Check previous
stage checksum exists.
---
gcc/objc/Make-lang.in | 3 ++-
gcc/ob
On 7/14/21 2:47 PM, Tamar Christina wrote:
> Hi,
>
> Ever since this commit
>
> commit c9114f2804b91690e030383de15a24e0b738e856
> Author: Bernd Edlinger
> Date: Fri May 28 06:27:27 2021 +0200
>
> Various tools have been having trouble with cross compilation result
rapped and reg-tested on x86_64-pc-linux-gnu.
Is it OK for trunk?
Thanks,
Bernd Edlinger (2):
Fix debug info for ignored decls at start of assembly
Ada: Remove debug line number for DECL_IGNORED_P functions
gcc/ada/gcc-interface/trans.c | 4 +++-
gcc/dwarf2out.c
, mostly for -fdwarf-4.
2021-07-24 Bernd Edlinger
PR ada/101575
* dwarf2out.c (dwarf2out_begin_prologue): Move init
of fde->ignored_debug to dwarf2out_set_ignored_loc.
(dwarf2out_set_ignored_loc): This is now also called
when no .loc statement is to
It was pointed out in PR101598 to be inappropriate, that
ignored Ada decls receive the source line number which was
recorded in the function decl's DECL_SOURCE_LOCATION.
Therefore set all front-end-generated Ada decls with
DECL_IGNORED_P to UNKNOWN_LOCATION.
2021-07-24 Bernd Edl
On 7/28/21 2:51 PM, Richard Biener wrote:
> On Mon, 26 Jul 2021, Bernd Edlinger wrote:
>
>> Ignored functions decls that are compiled at the start of
>> the assembly have bogus line numbers until the first .file
>> directive, as reported in PR101575.
>>
>>
1 - 100 of 1395 matches
Mail list logo
