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:
> Jeff Law wrote:
>> I wonder if the change to how we set up the initializer
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:
Jeff Law wrote:
> I wonder if the change to how we set up the initializers is ultimately
> changing the section those go i
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
changing the section those go into and ultimately causing an ove
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
>>> changing the section those go into and ultimately causing an overflow of
>>> the .sdata section.
>>
>>
>> Yes, tha
On 08/17/2018 04:26 PM, Bernd Edlinger wrote:
> 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 secti
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 definitely the case.
> Due to t
On 08/16/2018 09:23 AM, Martin Sebor wrote:
> On 08/15/2018 03:34 PM, Jeff Law wrote:
>> On 08/15/2018 03:02 PM, Martin Sebor wrote:
>>> On 08/15/2018 06:07 AM, Joseph Myers wrote:
On Tue, 14 Aug 2018, Martin Sebor wrote:
>> This is with Bison 3.0.4, should the version used to produce
On 08/15/2018 03:34 PM, Jeff Law wrote:
On 08/15/2018 03:02 PM, Martin Sebor wrote:
On 08/15/2018 06:07 AM, Joseph Myers wrote:
On Tue, 14 Aug 2018, Martin Sebor wrote:
This is with Bison 3.0.4, should the version used to produce
intl/plural.c
prove relevant.
Can you send me the translation
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/15/2018 03:02 PM, Martin Sebor wrote:
> On 08/15/2018 06:07 AM, Joseph Myers wrote:
>> On Tue, 14 Aug 2018, Martin Sebor wrote:
>>
This is with Bison 3.0.4, should the version used to produce
intl/plural.c
prove relevant.
>>>
>>> Can you send me the translation unit and the opt
On 08/15/2018 03:02 PM, Martin Sebor wrote:
> On 08/15/2018 06:07 AM, Joseph Myers wrote:
>> On Tue, 14 Aug 2018, Martin Sebor wrote:
>>
This is with Bison 3.0.4, should the version used to produce
intl/plural.c
prove relevant.
>>>
>>> Can you send me the translation unit and the opt
On 08/15/2018 06:07 AM, Joseph Myers wrote:
On Tue, 14 Aug 2018, Martin Sebor wrote:
This is with Bison 3.0.4, should the version used to produce intl/plural.c
prove relevant.
Can you send me the translation unit and the options it was compiled
with that triggered the errors?
I've attached
On 08/15/2018 04:28 AM, James Greenhalgh wrote:
On Tue, Aug 14, 2018 at 09:34:08PM -0500, Martin Sebor wrote:
On 08/14/2018 09:24 AM, Martin Sebor wrote:
On 08/14/2018 09:08 AM, Martin Sebor wrote:
On 08/14/2018 07:27 AM, James Greenhalgh wrote:
On Wed, Aug 08, 2018 at 07:17:07PM -0500, Marti
On August 15, 2018 12:28:55 PM GMT+02:00, James Greenhalgh
wrote:
>On Tue, Aug 14, 2018 at 09:34:08PM -0500, Martin Sebor wrote:
>> On 08/14/2018 09:24 AM, Martin Sebor wrote:
>> > On 08/14/2018 09:08 AM, Martin Sebor wrote:
>> >> On 08/14/2018 07:27 AM, James Greenhalgh wrote:
>> >>> On Wed, Aug
On Tue, Aug 14, 2018 at 09:34:08PM -0500, Martin Sebor wrote:
> On 08/14/2018 09:24 AM, Martin Sebor wrote:
> > On 08/14/2018 09:08 AM, Martin Sebor wrote:
> >> On 08/14/2018 07:27 AM, James Greenhalgh wrote:
> >>> On Wed, Aug 08, 2018 at 07:17:07PM -0500, Martin Sebor wrote:
> On 08/08/2018 0
On 08/14/2018 09:24 AM, Martin Sebor wrote:
On 08/14/2018 09:08 AM, Martin Sebor wrote:
On 08/14/2018 07:27 AM, James Greenhalgh wrote:
On Wed, Aug 08, 2018 at 07:17:07PM -0500, Martin Sebor wrote:
On 08/08/2018 05:08 AM, Jason Merrill wrote:
On Wed, Aug 8, 2018 at 9:04 AM, Martin Sebor wrot
On 08/14/2018 03:14 PM, Joseph Myers wrote:
On Tue, 14 Aug 2018, James Greenhalgh wrote:
Hi Martin,
This causes issues for the AArch64 tests (full list below).
This change (r263511) also breaks the glibc build for alpha-linux-gnu with
build-many-glibcs.py (using mainline GCC and binutils).
On Tue, 14 Aug 2018, James Greenhalgh wrote:
> Hi Martin,
>
> This causes issues for the AArch64 tests (full list below).
This change (r263511) also breaks the glibc build for alpha-linux-gnu with
build-many-glibcs.py (using mainline GCC and binutils). The error I see
is:
/scratch/jmyers/gli
On 08/14/2018 09:08 AM, Martin Sebor wrote:
On 08/14/2018 07:27 AM, James Greenhalgh wrote:
On Wed, Aug 08, 2018 at 07:17:07PM -0500, Martin Sebor wrote:
On 08/08/2018 05:08 AM, Jason Merrill wrote:
On Wed, Aug 8, 2018 at 9:04 AM, Martin Sebor wrote:
On 08/07/2018 02:57 AM, Jason Merrill wro
On 08/14/2018 07:27 AM, James Greenhalgh wrote:
On Wed, Aug 08, 2018 at 07:17:07PM -0500, Martin Sebor wrote:
On 08/08/2018 05:08 AM, Jason Merrill wrote:
On Wed, Aug 8, 2018 at 9:04 AM, Martin Sebor wrote:
On 08/07/2018 02:57 AM, Jason Merrill wrote:
On Wed, Aug 1, 2018 at 12:49 AM, Martin
On Wed, Aug 08, 2018 at 07:17:07PM -0500, Martin Sebor wrote:
> On 08/08/2018 05:08 AM, Jason Merrill wrote:
> > On Wed, Aug 8, 2018 at 9:04 AM, Martin Sebor wrote:
> >> On 08/07/2018 02:57 AM, Jason Merrill wrote:
> >>>
> >>> On Wed, Aug 1, 2018 at 12:49 AM, Martin Sebor wrote:
>
> On
On 08/09/2018 12:17 PM, Martin Sebor wrote:
Using build_string() rather than build_string_literal() needed
a tweak in digest_init_r(). It didn't break anything but since
the array type may not have a domain yet, neither will the
string. It looks like that may get adjusted later on but I've
temp
On Wed, 8 Aug 2018, Martin Sebor wrote:
> Done in the attached patch. I've also avoided dealing with
> zero-length arrays and added tests to make sure their size
> stays is regardless of the form of their initializer and
> the appropriate warnings are issued.
The C front-end changes in this patc
On Thu, 9 Aug 2018, Martin Sebor wrote:
> But for a declaration at file scope and without an initializer,
> GCC warns that the array is assumed to have one element, but
> then gives an error when sizeof is applied to it:
That's how tentative definitions (C17 6.9.2) work. There's an implicit
ini
On 08/08/2018 02:48 PM, Joseph Myers wrote:
On Wed, 8 Aug 2018, Martin Sebor wrote:
Jason/Joseph, is this meant to be accepted? It's rejected with
a hard error with -Wpedantic but I don't see any tests for it:
warning: ISO C forbids empty initializer braces [-Wpedantic]
const char x[] = {
On 08/08/2018 05:08 AM, Jason Merrill wrote:
On Wed, Aug 8, 2018 at 9:04 AM, Martin Sebor wrote:
On 08/07/2018 02:57 AM, Jason Merrill wrote:
On Wed, Aug 1, 2018 at 12:49 AM, Martin Sebor wrote:
On 07/31/2018 07:38 AM, Jason Merrill wrote:
On Tue, Jul 31, 2018 at 9:51 AM, Martin Sebor
On Wed, 8 Aug 2018, Martin Sebor wrote:
> Jason/Joseph, is this meant to be accepted? It's rejected with
> a hard error with -Wpedantic but I don't see any tests for it:
>
> warning: ISO C forbids empty initializer braces [-Wpedantic]
>const char x[] = { };
> ^
> error: z
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
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
without your patch
$ ./a.out
0
Jason/Joseph, is this meant to be accepted? It's rej
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 CTOR has a block of more than 256
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 Wed, Aug 8, 2018 at 9:04 AM, Martin Sebor wrote:
> On 08/07/2018 02:57 AM, Jason Merrill wrote:
>>
>> On Wed, Aug 1, 2018 at 12:49 AM, Martin Sebor wrote:
>>>
>>> On 07/31/2018 07:38 AM, Jason Merrill wrote:
On Tue, Jul 31, 2018 at 9:51 AM, Martin Sebor wrote:
>
>
>
On 08/07/2018 05:31 AM, Joseph Myers wrote:
On Tue, 7 Aug 2018, Martin Sebor wrote:
2) skipping embedded nuls made it possible to create a string
with fewer elements than the initializer array, which caused
arrays with unspecified bound to be smaller than they would
have been otherwise
I thin
On 08/07/2018 02:57 AM, Jason Merrill wrote:
On Wed, Aug 1, 2018 at 12:49 AM, Martin Sebor wrote:
On 07/31/2018 07:38 AM, Jason Merrill wrote:
On Tue, Jul 31, 2018 at 9:51 AM, Martin Sebor wrote:
The middle-end contains code to determine the lengths of constant
character arrays initialized
On Tue, 7 Aug 2018, Martin Sebor wrote:
> 2) skipping embedded nuls made it possible to create a string
> with fewer elements than the initializer array, which caused
> arrays with unspecified bound to be smaller than they would
> have been otherwise
I think there should be explicit tests of size
On Wed, Aug 1, 2018 at 12:49 AM, Martin Sebor wrote:
> On 07/31/2018 07:38 AM, Jason Merrill wrote:
>>
>> On Tue, Jul 31, 2018 at 9:51 AM, Martin Sebor wrote:
>>>
>>> The middle-end contains code to determine the lengths of constant
>>> character arrays initialized by string literals. The code i
On 08/06/2018 11:04 AM, Joseph Myers wrote:
On Mon, 6 Aug 2018, Martin Sebor wrote:
Ping: https://gcc.gnu.org/ml/gcc-patches/2018-07/msg01884.html
I'd expect testcases with signed char and unsigned char as well, if those
work for C, including tests for signed char where some of the initialize
On Mon, 6 Aug 2018, Martin Sebor wrote:
> Ping: https://gcc.gnu.org/ml/gcc-patches/2018-07/msg01884.html
I'd expect testcases with signed char and unsigned char as well, if those
work for C, including tests for signed char where some of the initializers
are negative. (Tests that actual array c
Ping: https://gcc.gnu.org/ml/gcc-patches/2018-07/msg01884.html
On 07/30/2018 05:51 PM, Martin Sebor wrote:
The middle-end contains code to determine the lengths of constant
character arrays initialized by string literals. The code is used
in a number of optimizations and warnings.
However, the
On 07/31/2018 07:38 AM, Jason Merrill wrote:
On Tue, Jul 31, 2018 at 9:51 AM, Martin Sebor wrote:
The middle-end contains code to determine the lengths of constant
character arrays initialized by string literals. The code is used
in a number of optimizations and warnings.
However, the code is
On Tue, Jul 31, 2018 at 9:51 AM, Martin Sebor wrote:
> The middle-end contains code to determine the lengths of constant
> character arrays initialized by string literals. The code is used
> in a number of optimizations and warnings.
>
> However, the code is unable to deal with constant arrays in
The middle-end contains code to determine the lengths of constant
character arrays initialized by string literals. The code is used
in a number of optimizations and warnings.
However, the code is unable to deal with constant arrays initialized
using the braced initializer syntax, as in
const
42 matches
Mail list logo
