target,
that is, previously the wrong bit was checked.
Regression tested successfully on arm-none-eabi with newlib-3.3.0.
Is it OK for trunk?
Thanks
Bernd.
From 9fd070407408cf10789f5e9eb5ddda2fb3798e6f Mon Sep 17 00:00:00 2001
From: Bernd Edlinger
Date: Sun, 22 Nov 2020 08:11:14 +0100
Subject
Hi,
I'd like to ping for this patch:
https://gcc.gnu.org/pipermail/gcc-patches/2020-November/559882.html
Thanks
Bernd.
On 11/22/20 9:05 AM, Bernd Edlinger wrote:
> Hi,
>
> this avoids the need to use -fno-threadsafe-statics on
> arm-none-eabi or working around that problem
On 11/24/20 11:10 PM, Jason Merrill wrote:
> On 11/22/20 3:05 AM, Bernd Edlinger wrote:
>> Hi,
>>
>> this avoids the need to use -fno-threadsafe-statics on
>> arm-none-eabi or working around that problem by supplying
>> a dummy __sync_synchronize function which
this point, and therefore those
line table entries are not helpful to the user.
2020-11-20 Bernd Edlinger
* cfgexpand.c (expand_gimple_basic_block): Remove debug_begin_stmts
following a removed debug_inline_entry.
Bootstrapped and reg-tested on x86_64-pc-linux-gnu.
Is it OK
On 12/2/20 8:50 AM, Richard Biener wrote:
> On Tue, 1 Dec 2020, Bernd Edlinger wrote:
>
>> Hi!
>>
>>
>> This removes gimple_debug stmts without block info after a
>> NULL INLINE_ENTRY.
>>
>> The line numbers from these stmts are from the inli
On 12/3/20 9:30 AM, Richard Biener wrote:
> On Wed, 2 Dec 2020, Bernd Edlinger wrote:
>
>> On 12/2/20 8:50 AM, Richard Biener wrote:
>>> On Tue, 1 Dec 2020, Bernd Edlinger wrote:
>>>
>>>> Hi!
>>>>
>>>>
>>>> Thi
On 12/2/20 7:57 PM, Jason Merrill wrote:
> On 12/1/20 1:28 PM, Bernd Edlinger wrote:
>> On 11/24/20 11:10 PM, Jason Merrill wrote:
>>> On 11/22/20 3:05 AM, Bernd Edlinger wrote:
>>>> Hi,
>>>>
>>>> this avoids the need to use -fno-threadsaf
On 12/7/20 11:50 AM, Richard Biener wrote:
>
> The ipa-param-manipulation.c hunk is OK, please commit separately.
>
Okay, this is the part I just committed.
commit 92e563d91b012f09da8fd152e934f6b964ae49cb
Author: Bernd Edlinger
Date: Mon Dec 7 16:00:00 2020 +0100
Fix locatio
On 12/7/20 4:04 PM, Jason Merrill wrote:
> On 12/5/20 7:37 AM, Bernd Edlinger wrote:
>> On 12/2/20 7:57 PM, Jason Merrill wrote:
>>> On 12/1/20 1:28 PM, Bernd Edlinger wrote:>>>> + tree type =
>>> targetm.cxx.guard_mask_bit ()
>>>&
22b2 Mon Sep 17 00:00:00 2001
> From: Bernd Edlinger
> Date: Wed, 2 Dec 2020 12:32:02 +0100
> Subject: [PATCH] Remove misleading debug line entries
>
> This removes gimple_debug_begin_stmts without block info which remain
> after a gimple block originating from an inline functio
On 12/8/20 11:35 AM, Richard Biener wrote:
>
> + {
> + /* Remove a nonbind marker when the outer scope of the
> + inline function is completely removed. */
> + if (gimple_debug_nonbind_marker_p (stmt)
> + && BLOCK_ABSTRACT_ORIGIN (b))
> +
On 12/8/20 7:57 PM, Bernd Edlinger wrote:
> On 12/8/20 11:35 AM, Richard Biener wrote:
>>
>> + {
>> + /* Remove a nonbind marker when the outer scope of the
>> + inline function is completely removed. */
>> + if (gi
As the test case shows, the outer mode may have a higher alignment
requirement than the inner mode here.
2021-04-22 Bernd Edlinger
PR target/100106
* gimplify-rtx.c (simplify_context::simplify_subreg): Check the
memory alignment for the outer mode.
* gcc.c
Aehm,
forgot to mention,
tested on arm-none-eabi (arm-sim target)
is it OK for trunk?
Thanks
Bernd.
On 4/22/21 8:37 AM, Bernd Edlinger wrote:
> As the test case shows, the outer mode may have a higher alignment
> requirement than the inner mode here.
>
> 2021-04-22 Be
Hi,
I'd like to ping for this patch here:
https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00639.html
Thanks
Bernd.
On 11/8/19 6:01 PM, Bernd Edlinger wrote:
> Hi,
>
> this fixes an unexprected fallout from my previous patch on the
> -Wshadow=complatible-local.
>
> B
Ping...
FYI this jumping into fake inline frames happens rather often
when debugging, and is especially annoying once you know how
easy it is to fix it...
Bernd.
On 11/9/19 11:20 AM, Bernd Edlinger wrote:
> Ping...
>
> On 11/2/19 7:49 AM, Bernd Edlinger wrote:
>> Ping...
>
On 11/19/19 3:01 AM, Alexandre Oliva wrote:
> Hello, Bernd,
>
> Apologies for taking so long to respond. I had not noticed your patch
> before being explicitly copied on it.
>
> IIUC you're describing a problem in GDB, that could be summed up as its
> not paying attention to is_stmt and being un
Hi,
I forgot to ping this,
is the updated patch OK?
On 9/6/19 1:27 PM, Bernd Edlinger wrote:
> On 9/6/19 12:47 PM, Richard Earnshaw (lists) wrote:
>> On 06/09/2019 11:28, Bernd Edlinger wrote:
>>> Hi!
>>>
>>> It was pointed out in the PR that the test
On 07/30/18 17:49, Joseph Myers 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
>&
trunk?
Thanks
Bernd.
2018-08-01 Bernd Edlinger
* typeck2.c (digest_init_r): Fix overlength strings.
* vtable-class-hierarchy.c (build_key_buffer_arg): Make string literal
NUL terminated.
diff -pur gcc/cp/typeck2.c gcc/cp/typeck2.c
--- gcc/cp/typeck2.c 2018-06-27 04:59:44.0 +0200
Hi,
this patch changes the Fortan FE to create NUL terminated STRING_CST
objects. This is a cleanup in preparation of a more thorough check
on the STRING_CST objects in the middle-end.
Bootstrapped and reg-tested on x86_64-pc-linux-gnu.
Is it OK for trunk?
Thanks
Bernd.
2018-08-01 Bernd
-08-01 Bernd Edlinger
* varasm.c (check_string_literal): New checking function.
(output_constant): Use it.
diff -pur gcc/varasm.c gcc/varasm.c
--- gcc/varasm.c 2018-07-17 11:19:27.0 +0200
+++ gcc/varasm.c 2018-07-31 10:16:12.058827505 +0200
@@ -4774,6 +4774,29
On 08/01/18 11:29, Richard Biener wrote:
>
> Hmm. I think it would be nice if TREE_STRING_LENGTH would
> match char[2] and TYPE_SIZE_UNIT even if that is inconvenient
> for your check above. Because the '\0' doesn't belong to the
> string. Then build_string internally appends a '\0' outside
>
On 07/31/18 05:51, Martin Sebor wrote:
> On 07/30/2018 03:11 PM, Bernd Edlinger wrote:
>> Hi,
>>
>>> @@ -621,6 +674,12 @@ c_strlen (tree src, int only_value)
>>> maxelts = maxelts / eltsize - 1;
>>> }
>>>
>>> + /* Unless
On 08/01/18 18:34, Martin Sebor wrote:
>>> If you care about detecting bugs I would expect you to be
>>> supportive rather than dismissive of this work, and helpful
>>> in bringing it to fruition rather that putting it down or
>>> questioning my priorities. Especially since the work was
>>> prompt
On 08/01/18 19:07, Martin Sebor wrote:
> On 08/01/2018 05:20 AM, Bernd Edlinger wrote:
>> On 07/30/18 17:49, Joseph Myers wrote:
>>> On Mon, 30 Jul 2018, Bernd Edlinger wrote:
>>>
>>>> Hi,
>>>>
>>>> this is how I would like to hand
On 08/01/18 18:04, Joseph Myers wrote:
> On Wed, 1 Aug 2018, Bernd Edlinger wrote:
>
>> On 07/30/18 17:49, Joseph Myers wrote:
>>> On Mon, 30 Jul 2018, Bernd Edlinger wrote:
>>>
>>>> Hi,
>>>>
>>>> this is how I would like to h
ring_p = true;
return strlen (TREE_STRING_POINTER (rhs));
Fortunately this also shows a way how to narrow strlen return value
expectations when
we are able to positively prove that a string must be zero terminated.
Bootstrapped and reg-tested on x86_64-pc-linux-gnu.
Is it OK for trunk?
Thanks
Ber
On 08/02/18 04:44, Martin Sebor wrote:
> Since the foundation of the patch is detecting and avoiding
> the overly aggressive folding of unterminated char arrays,
> besides issuing a warning for such arguments to strlen,
> the patch also fixes pr86711 - wrong folding of memchr, and
> pr86714 - tree-
wouldn't solve the warning problem below -- a separate
> computation would still be necessary to determine the tighter
> bound of the member itself.)
>
> On 08/02/2018 09:42 AM, Martin Sebor wrote:
>> On 08/02/2018 04:22 AM, Bernd Edlinger wrote:
>>> Hi,
>
On 08/02/18 15:26, Bernd Edlinger wrote:
>>
>> /* If the length can be computed at compile-time, return it. */
>> - len = c_strlen (src, 0);
>> + tree array;
>> + tree len = c_strlen (src, 0, &array);
>
> You know the c_strlen tries to compute wide c
On 08/02/18 22:34, Martin Sebor wrote:
> On 08/02/2018 12:56 PM, Bernd Edlinger wrote:
>> On 08/02/18 15:26, Bernd Edlinger wrote:
>>>>
>>>> /* If the length can be computed at compile-time, return it. */
>>>> - len = c_strlen (src, 0);
>>&g
On 08/03/18 18:50, Olivier Hainque wrote:
> Hi Bernd,
>
>> On 31 Jul 2018, at 14:07, Bernd Edlinger wrote:
>>
>> Hi!
>>
>>
>> This fixes a couple STRING_CST that are not explicitly NUL terminated.
>> These were caught in a new check in varasm.
On 08/03/18 23:15, Jeff Law wrote:
> On 07/30/2018 02:21 PM, Bernd Edlinger wrote:
>> 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/2
On 08/03/18 23:36, Jeff Law wrote:
> On 08/01/2018 05:35 AM, Bernd Edlinger wrote:
>> Hi,
>>
>> this completes the previous patches, and adds a check in varasm.c
>> that ensures that all string constants are NUL terminated,
>> And that varasm does not str
On 08/03/18 23:36, Jeff Law wrote:
> On 08/01/2018 05:35 AM, Bernd Edlinger wrote:
>> Hi,
>>
>> this completes the previous patches, and adds a check in varasm.c
>> that ensures that all string constants are NUL terminated,
>> And that varasm does not str
Hi Olivier,
I think I like your idea a lot, it should be highly useful for Fortran and GO
as well.
Would somthing something like this (untested patch) work for you on top of my
patch series.
It makes use of the zero-termination properties of STRING_CSTs, that the other
patch ensures.
I have
Hi!
This patch is inspired by Olivier's feedback to my previous patch on the
zero-termination of Ada STRING_CST.
The idea is that strings that do not have embedded nul characters _and_
do not happen to be zero-terminated in the DECL_UNIT_SIZE, are currently
not in the merge string sections. To
Again, with patch
On 08/04/18 17:43, Bernd Edlinger wrote:
> Hi!
>
>
> This patch is inspired by Olivier's feedback to my previous patch on the
> zero-termination of Ada STRING_CST.
>
> The idea is that strings that do not have embedded nul characters _and_
Aehm, I forgot the Fortran FE patch
which is also a pre-condition (at least for building with all languages):
[PATCH] Create internally nul terminated string literals in fortan FE
https://gcc.gnu.org/ml/fortran/2018-08/msg0.html
Thanks
Bernd.
On 08/04/18 17:44, Bernd Edlinger wrote
On 08/04/18 23:56, Martin Sebor wrote:
> On 08/03/2018 01:00 AM, Jeff Law wrote:
>> On 07/24/2018 05:18 PM, Bernd Edlinger wrote:
>>> On 07/24/18 23:46, Jeff Law wrote:
>>>> On 07/24/2018 01:59 AM, Bernd Edlinger wrote:
>>>>> Hi!
>>>&g
On 08/04/18 22:52, Martin Sebor wrote:
> On 08/03/2018 01:43 AM, Jakub Jelinek wrote:
>> On Thu, Aug 02, 2018 at 09:59:13PM -0600, Martin Sebor wrote:
If I call this with foo (2, 1), do you still claim it is not valid C?
>>>
>>> String functions like strlen operate on character strings stored
terals in fortan FE
https://gcc.gnu.org/ml/fortran/2018-08/msg0.html
Bootstrapped, as usual.
Is it OK for trunk?
Thanks
Bernd.
2018-08-01 Bernd Edlinger
* doc/generic.texi (STRING_CST): Update.
* varasm.c (check_string_literal): New checking function.
(output_constant): Use it.
dif
trunk?
Thanks
Bernd.
2018-08-05 Bernd Edlinger
* jit-playback.c (playback::context::context): Remove
m_char_array_type_node.
(playback::context::new_string_literal): Use
build_string_literal.
(playback::context::replay): Remove m_char_array_type_node.
* jit-playback.h (playback::context
> merging log a + log b => log a*b and
Maybe a*b could overflow, while adding the logarithms would not?
Bernd.
On 08/05/18 20:35, Marc Glisse wrote:
> On Sun, 5 Aug 2018, Bernd Edlinger wrote:
>
>>> merging log a + log b => log a*b and
>>
>> Maybe a*b could overflow, while adding the logarithms would not?
>
> Well, that's a discussion that happens every time a n
On 08/05/18 17:58, Jeff Law wrote:
> On 08/05/2018 12:08 AM, Bernd Edlinger wrote:
>> I see this from a software engineering POV.
>>
>> If we have code like this:
>>
>> void test (const char *x)
>> {
>> assert (strlen (x) < 10);
>> }
>
terminated
strings in C.
Boot-strapped and regtested on x86_64-pc-linux-gnu.
Is it OK for trunk (after pre-condition patches)?
Thanks
Bernd.
gcc:
2018-08-04 Bernd Edlinger
* varasm.c (output_constant): Add new parameter merge_strings.
Make strings properly zero term
Hi Olivier,
On 08/06/18 20:01, Olivier Hainque wrote:
> Hi Bernd,
>
> Things are moving fast so I'll answer your
> messages incrementally :-)
>
>> On 3 Aug 2018, at 20:37, Bernd Edlinger wrote:
> [...]
>> Oh, how interesting.
>>
>> My patch on
On 08/07/18 17:02, Martin Sebor wrote:
> On 08/06/2018 11:45 PM, Richard Biener wrote:
>> On August 7, 2018 5:38:59 AM GMT+02:00, Martin Sebor
>> wrote:
>>> On 08/06/2018 11:40 AM, Jeff Law wrote:
On 08/06/2018 11:15 AM, Martin Sebor wrote:
>>> These examples do not aim to be valid C, th
On 08/07/18 18:40, Olivier Hainque wrote:
> Hi Bernd,
>
> (Thanks for your interest in the Ada case as well :)
>
>> On 7 Aug 2018, at 15:07, Bernd Edlinger wrote:
>
>> When I try this example:
>>
>> $ cat array9.adb
>> -- { dg-do run }
>>
On 08/08/18 17:51, Martin Sebor wrote:
> On 08/07/2018 11:46 AM, Richard Biener wrote:
>>
>> Pointer types carry no information in GIMPLE.
>
> So what do you suggest as a solution?
>
> The strlen optimization can be decoupled from warnings and
> disabled, and the aggressive loop optimization can
instead of two.
Thanks
Bernd.
On 08/01/18 13:32, Bernd Edlinger wrote:
> Hi,
>
> this patch changes the Fortan FE to create NUL terminated STRING_CST
> objects. This is a cleanup in preparation of a more thorough check
> on the STRING_CST objects in the middle-end.
>
>
>
Hi,
I'd like to ping the following patches:
[PATCH] Check the STRING_CSTs in varasm.c
https://gcc.gnu.org/ml/gcc-patches/2018-08/msg00361.html
[PATCH] Fix not properly nul-terminated string constants in JIT
https://gcc.gnu.org/ml/gcc-patches/2018-08/msg00370.html
[PATCH] Handle overlength strin
Hi Martin,
sorry, I hope you forgive me, when I add a few comments to your patch.
> + unsigned HOST_WIDE_INT nelts = CONSTRUCTOR_NELTS (ctor);
> + tree eltype = TREE_TYPE (type);
...
> + /* Bail if the CTOR has a block of more than 256 embedded nuls
> +due to implicitly initialized
On 08/08/18 19:33, Bernd Edlinger wrote:
> Hi Martin,
>
> sorry, I hope you forgive me, when I add a few comments to your patch.
>
>> + unsigned HOST_WIDE_INT nelts = CONSTRUCTOR_NELTS (ctor);
>> + tree eltype = TREE_TYPE (type);
> ...
>> + /* Bail if the
On 08/08/18 21:50, Martin Sebor wrote:
>> Sorry, again, but could it be possible that this test case changed
>> with your patch?
>>
>> $ cat w.c
>> const char x[] = { };
>> int main()
>> {
>> __builtin_printf("%ld\n", sizeof(x));
>> return 0;
>> }
>> $ gcc w.c
>> $ ./a.out
>> 1
>>
>> withou
u want me to use XNEWVEC/XDELETEVEC.
Attached is a new version using those macros.
Is it OK for trunk?
Thanks
Bernd.
2018-08-01 Bernd Edlinger
* c-typeck.c (digest_init): Shorten overlength strings.
Index: gcc/c/c-typeck.c
===
--- gc
>> + bool one_2_one_ascii
>> += (target_to_host_charmap[0] == 1 && target_to_host ('a') ==
>> 97);
> Hmm. Is this really sufficient?I have nowhere near enough knowledge
> of the potential target character sets to know if this is sufficiently
> tight.
Shouldn't it be targ
Hi,
I'd like to ping for this patch:
https://gcc.gnu.org/ml/gcc-patches/2018-07/msg01800.html
I will add a new BZ entry for the (minor) regression this patch
introduces in gcc.dg/strlenopt-49.c and assign it to myself.
Thanks
Bernd.
On 07/29/18 12:56, Bernd Edlinger wrote:
> Hi!
&
used in gimple-ssa-sprintf.c to specify the
expected character size.
Bootstrapped and reg-tested on x86_64-pc-linux-gnu.
Is it OK for trunk?
Thanks
Bernd.2018-08-14 Bernd Edlinger
* builtins.c (c_strlen): Add new parameter eltsize.
* builtins.h (c_strlen): Adjust prototype.
* expr.c
On 08/13/18 16:27, Martin Sebor wrote:
> As I said below, the patch for PR 86552, 86711, 86714 that
> was first posted on July 19 fixes both of these issues and
> also diagnoses calls with unterminated strings:
>
> https://gcc.gnu.org/ml/gcc-patches/2018-08/msg00155.html
>
Sorry, but you you
On 08/15/18 07:12, Jeff Law wrote:
> On 08/14/2018 08:08 AM, Martin Sebor wrote:
>> On 08/14/2018 04:25 AM, Bernd Edlinger wrote:
>>> Hi,
>>>
>>> this patch is a follow-up to my patch here:
>>> https://gcc.gnu.org/ml/gcc-patches/2018-07/msg01800.html
On 08/15/18 18:25, Jeff Law wrote:
> On 08/14/2018 04:25 AM, Bernd Edlinger wrote:
>> Hi,
>>
>> this patch is a follow-up to my patch here:
>> https://gcc.gnu.org/ml/gcc-patches/2018-07/msg01800.html
>>
>> Since most calls of c_strlen and get_range_strlen
On 08/15/18 20:13, Jeff Law wrote:
> On 08/15/2018 10:38 AM, Bernd Edlinger wrote:
>> On 08/15/18 18:25, Jeff Law wrote:
>>> On 08/14/2018 04:25 AM, Bernd Edlinger wrote:
>>>> Hi,
>>>>
>>>> this patch is a follow-up to my patch here:
>>
On 08/15/18 20:18, Martin Sebor wrote:
> On 08/15/2018 10:25 AM, Jeff Law wrote:
>> On 08/14/2018 04:25 AM, Bernd Edlinger wrote:
>>> Hi,
>>>
>>> this patch is a follow-up to my patch here:
>>> https://gcc.gnu.org/ml/gcc-patches/2018-07/msg01800.
Jeff Law wrote:
> I wonder if the change to how we set up the initializers is ultimately
> changing the section those go into and ultimately causing an overflow of
> the .sdata section.
Yes, that is definitely the case.
Due to the -fmerge-all-constants option used
named arrays with brace initiali
On 08/16/18 19:35, Jeff Law wrote:
> On 08/15/2018 12:51 PM, Bernd Edlinger wrote:
> [ snip -- comment attribution is likely lost... ]
>
>>>>>
>>>>> 2018-08-14 Bernd Edlinger
>>>>>
>>>>> * builtins.c (c_strlen):
On 08/16/18 23:27, Jeff Law wrote:
> On 08/16/2018 12:47 PM, Bernd Edlinger wrote:
>
>>>>> Parameterizing the function to return either the number of
>>>>> bytes or the number of elements makes sense as an enhancement.
>>>>> It makes
le for memxxx-functions otherwise.
Bootstrapped and reg-tested on x86_64-pc-linux-gnu.
Is it OK for trunk?
Thanks
Bernd.gcc:
2018-08-17 Bernd Edlinger
PR middle-end/86711
PR middle-end/86714
* expr.c (string_constant): Don't return truncated string literals.
* fold-const.c (c_getstr): F
Richard Biener wrote:
> Note that I'm a little bit confused here given build_string
> already appends a '\0' after TREE_STRING_LENGTH. So it is safe
> to call strlen() on all STRING_CSTs. I think I raised this in
> the review of one of Bernds patches but to be honest all the
> various threads ha
Richard Biener wrote:
> +embedded @code{NUL} characters. However, the
> +@code{TREE_STRING_LENGTH} always includes a trailing @code{NUL} that
> +is not part of the language string literal but appended by the front end.
> +If the string shall not be @code{NUL}-terminated the @code{TREE_TYPE}
> +is
don't think they are
related
to the way the string constants are created, so there should be no conflict.
Bootstrapped and reg-tested on x86_64-pc-linux-gnu.
Is it OK for trunk?
Thanks
Bernd.
c-family:
2018-08-17 Bernd Edlinger
* c-common.c (braced_list_to_string): Remove eval para
On 08/17/18 06:46, Jeff Law wrote:
> On 08/05/2018 04:28 AM, Bernd Edlinger wrote:
>> Hi,
>>
>> I would like to do a minor tweak to the patch.
>> While staring at the other patch I realized that I should
>> better pass size and not thissize to the check
>>
On 08/17/18 14:19, Richard Biener wrote:
> On Fri, 17 Aug 2018, Bernd Edlinger wrote:
>
>> Richard Biener wrote:
>>> +embedded @code{NUL} characters. However, the
>>> +@code{TREE_STRING_LENGTH} always includes a trailing @code{NUL} that
>>> +is not
On 08/17/18 15:38, Richard Biener wrote:
> On Fri, 17 Aug 2018, Bernd Edlinger wrote:
>
>> On 08/17/18 14:19, Richard Biener wrote:
>>> On Fri, 17 Aug 2018, Bernd Edlinger wrote:
>>>
>>>> Richard Biener wrote:
>>>>> +embedded @code{NUL}
:
[PATCH] Call braced_list_to_string after array size is fixed
https://gcc.gnu.org/ml/gcc-patches/2018-08/msg01015.html
Thanks
Bernd.
On 08/07/18 14:55, Bernd Edlinger wrote:
> Hi,
>
> I realized that the previous version did not handle
> zero terminated Ada constants correctly
On 08/17/18 20:23, Martin Sebor wrote:
> On 08/17/2018 06:14 AM, Joseph Myers wrote:
>> On Fri, 17 Aug 2018, Jeff Law wrote:
>>
>>> On 08/16/2018 05:01 PM, Joseph Myers wrote:
On Thu, 16 Aug 2018, Jeff Law wrote:
> restores previous behavior. The sprintf bits want to count element
>>
Hi everybody,
On 08/16/18 08:36, Bernd Edlinger wrote:
> Jeff Law wrote:
>> I wonder if the change to how we set up the initializers is ultimately
>> changing the section those go into and ultimately causing an overflow of
>> the .sdata section.
>
>
> Yes, that is
On 08/17/18 22:17, Martin Sebor wrote:
> On 08/17/2018 12:44 PM, Bernd Edlinger wrote:
>> On 08/17/18 20:23, Martin Sebor wrote:
>>> On 08/17/2018 06:14 AM, Joseph Myers wrote:
>>>> On Fri, 17 Aug 2018, Jeff Law wrote:
>>>>
>>>>> On 08/16
On 08/18/18 06:01, Jeff Law wrote:
> On 08/17/2018 03:14 AM, Bernd Edlinger wrote:
>> Hi!
>>
>>
>> After the other patch has been applied, I re-based this patch accordingly.
>>
>> Except the mechanical changes, there are a few notable differenc
On 08/18/18 12:40, Richard Sandiford wrote:
> Bernd Edlinger writes:
>> Hi everybody,
>>
>> On 08/16/18 08:36, Bernd Edlinger wrote:
>>> Jeff Law wrote:
>>>> I wonder if the change to how we set up the initializers is ultimately
>>>> changi
On 08/18/18 18:46, Richard Sandiford wrote:
> Bernd Edlinger writes:
>> On 08/18/18 12:40, Richard Sandiford wrote:
>>> Bernd Edlinger writes:
>>>> Hi everybody,
>>>>
>>>> On 08/16/18 08:36, Bernd Edlinger wrote:
>>>>&g
ere designed to check the optimized
tree dump have to use the new -fassume-zero-terminated-char-arrays
option, but that is what we agreed upon.
The patch is not dependent on any other patches.
Bootstrapped and reg-tested on x86_64-pc-linux-gnu.
Is it OK for trunk?
Thanks
Ber
uld not do more than build a cross compiler and
run
make check-gcc-c RUNTESTFLAGS="alpha.exp=pr86984.c".
Bootstrapped and reg-tested on x86_64-pc-linux-gnu.
Is it OK for trunk?
Thanks
Bernd.
2018-08-19 Bernd Edlinger
PR target/86984
* expr.c (expand_assignment): Asser
On 08/20/18 12:12, Richard Biener wrote:
> On Wed, Aug 15, 2018 at 6:39 AM Jeff Law wrote:
>>
>> On 08/10/2018 10:56 AM, Martin Sebor wrote:
>>> On 08/08/2018 11:36 PM, Jeff Law wrote:
On 08/02/2018 09:42 AM, Martin Sebor wrote:
> The warning bits are definitely not okay by me. The
On 08/20/18 13:01, Richard Biener wrote:
> On Wed, Aug 1, 2018 at 3:05 PM Bernd Edlinger
> wrote:
>>
>>
>>
>> On 08/01/18 11:29, Richard Biener wrote:
>>>
>>> Hmm. I think it would be nice if TREE_STRING_LENGTH would
>>> match char[2] and
On 08/20/18 12:41, Richard Biener wrote:
> On Sun, 19 Aug 2018, Bernd Edlinger wrote:
>
>> Hi!
>>
>>
>> This fixes a wrong code issue in expand_expr_real_1 which happens because
>> a negative bitpos is actually able to reach extract_bit_field which
>> do
On 08/20/18 16:16, Jeff Law wrote:
> On 08/20/2018 07:28 AM, Richard Biener wrote:
>> On Mon, 20 Aug 2018, Bernd Edlinger wrote:
>>
>>> On 08/20/18 12:41, Richard Biener wrote:
>>>> On Sun, 19 Aug 2018, Bernd Edlinger wrote:
>>>>
>>>
On 08/20/18 16:54, Jeff Law wrote:
> On 08/20/2018 08:52 AM, Bernd Edlinger wrote:
>> On 08/20/18 16:16, Jeff Law wrote:
>>> On 08/20/2018 07:28 AM, Richard Biener wrote:
>>>> On Mon, 20 Aug 2018, Bernd Edlinger wrote:
>>>>
>>>>> On 08/20/1
On 08/20/18 16:26, Jeff Law wrote:
> On 08/20/2018 04:23 AM, Bernd Edlinger wrote:
>> On 08/20/18 12:12, Richard Biener wrote:
>>> On Wed, Aug 15, 2018 at 6:39 AM Jeff Law wrote:
>>>>
>>>> On 08/10/2018 10:56 AM, Martin Sebor wrote:
>>>>>
On 08/20/18 15:19, Richard Biener wrote:
> On Mon, 20 Aug 2018, Bernd Edlinger wrote:
>
>> On 08/20/18 13:01, Richard Biener wrote:
>>> On Wed, Aug 1, 2018 at 3:05 PM Bernd Edlinger
>>> wrote:
>>>>
>>>>
>>>>
>>>>
On 08/20/18 12:23, Richard Biener wrote:
> On Sun, 19 Aug 2018, Bernd Edlinger wrote:
>
>> Hi,
>>
>>
>> I rebased my range computation patch to current trunk,
>> and updated it according to what was discussed here.
>>
>> That means get_range_s
On 08/20/18 22:42, Martin Sebor wrote:
> On 08/20/2018 09:15 AM, Bernd Edlinger wrote:
>> On 08/20/18 16:26, Jeff Law wrote:
>>> On 08/20/2018 04:23 AM, Bernd Edlinger wrote:
>>>> On 08/20/18 12:12, Richard Biener wrote:
>>>>> On Wed, Aug 15, 2018 at 6:
On 08/21/18 00:22, Jeff Law wrote:
> On 08/20/2018 04:16 PM, Joseph Myers wrote:
>> On Fri, 17 Aug 2018, Jeff Law wrote:
>>
WCHAR_TYPE_SIZE is wrong because it doesn't account for flag_short_wchar.
As far as I can see only ada/gcc-interface/targtyps.c uses WCHAR_TYPE_SIZE
now. TYPE_
Hi,
this simplifies get_format_string in gimple-ssa-sprintf.c
to use c_getstr.
Bootstrapped and reg-tested on x86_64-pc-linux-gnu.
Is it OK for trunk?
Thanks
Bernd.
2018-08-21 Bernd Edlinger
* gimple-ssa-sprintf.c (decl_constant_value): Remove.
(get_format_string): Refer to c_getstr
On 08/21/18 00:49, Joseph Myers wrote:
> On Mon, 20 Aug 2018, Jeff Law wrote:
>
>>> If you do that, probably you want to move
>>> fortran/trans-types.c:get_typenode_from_name (which converts the strings
>>> used in target macros such as WCHAR_TYPE to the corresponding types) into
>>> generic code.
On 08/18/18 20:01, Martin Sebor wrote:
> On 08/17/2018 05:01 PM, Bernd Edlinger wrote:
>> On 08/17/18 22:17, Martin Sebor wrote:
>>> On 08/17/2018 12:44 PM, Bernd Edlinger wrote:
>>>> On 08/17/18 20:23, Martin Sebor wrote:
>>>>> On 08/17/2018 06:14
On 08/21/18 01:23, Martin Sebor wrote:
> On 08/20/2018 04:17 PM, Jeff Law wrote:
>> On 08/18/2018 11:38 AM, Martin Sebor wrote:
>>> On 08/17/2018 09:32 PM, Jeff Law wrote:
>>>> On 08/17/2018 02:17 PM, Martin Sebor wrote:
>>>>> On 08/17/2018 12:44 PM, B
On 08/20/18 17:59, Bernd Edlinger wrote:
> On 08/20/18 15:19, Richard Biener wrote:
>> On Mon, 20 Aug 2018, Bernd Edlinger wrote:
>>
>>> On 08/20/18 13:01, Richard Biener wrote:
>>>> On Wed, Aug 1, 2018 at 3:05 PM Bernd Edlinger
>>>> wrote:
&g
401 - 500 of 1395 matches
Mail list logo
