On 7/8/19 8:37 PM, Martin Sebor wrote:
> Ping: https://gcc.gnu.org/ml/gcc-patches/2019-06/msg01506.html
>
> Jeff (et al.), do you have any outstanding questions/concerns
> about the patch?
Sorry I wasn't clear. All my concerns are resolved. The patch is fine
for the trunk.
jeff
>
Ping: https://gcc.gnu.org/ml/gcc-patches/2019-06/msg01506.html
Jeff (et al.), do you have any outstanding questions/concerns
about the patch?
Martin
On 6/27/19 4:30 PM, Jeff Law wrote:
On 6/27/19 12:40 PM, Richard Biener wrote:
On June 27, 2019 7:04:32 PM GMT+02:00, Jakub Jelinek wrote:
On
On Fri, Jun 28, 2019 at 2:16 AM Jeff Law wrote:
>
> On 6/27/19 10:12 AM, Jakub Jelinek wrote:
> > On Thu, Jun 27, 2019 at 09:15:41AM -0600, Jeff Law wrote:
> >> Actually it was trivial to create with store merging.
> >>
> >> char x[20];
> >> foo()
> >> {
> >> x[0] = 0x41;
> >> x[1] = 0x42;
> >
On 6/27/19 10:12 AM, Jakub Jelinek wrote:
> On Thu, Jun 27, 2019 at 09:15:41AM -0600, Jeff Law wrote:
>> Actually it was trivial to create with store merging.
>>
>> char x[20];
>> foo()
>> {
>> x[0] = 0x41;
>> x[1] = 0x42;
>> }
>>
>> MEM [(char *)&x] = 16961;
>>
>> So clearly we can get this
On 6/27/19 12:40 PM, Richard Biener wrote:
> On June 27, 2019 7:04:32 PM GMT+02:00, Jakub Jelinek wrote:
>> On Thu, Jun 27, 2019 at 10:58:25AM -0600, Martin Sebor wrote:
>>> The LHS is unsigned short so handle_char_store would not be called
>>> because of the check in the caller. You would need s
On 6/27/19 11:04 AM, Jakub Jelinek wrote:
On Thu, Jun 27, 2019 at 10:58:25AM -0600, Martin Sebor wrote:
The LHS is unsigned short so handle_char_store would not be called
because of the check in the caller. You would need something like:
MEM [(char *)&x] = { 'a', 'b' };
This is invalid,
On June 27, 2019 7:04:32 PM GMT+02:00, Jakub Jelinek wrote:
>On Thu, Jun 27, 2019 at 10:58:25AM -0600, Martin Sebor wrote:
>> The LHS is unsigned short so handle_char_store would not be called
>> because of the check in the caller. You would need something like:
>>
>> MEM [(char *)&x] = { 'a'
On Thu, Jun 27, 2019 at 10:58:25AM -0600, Martin Sebor wrote:
> The LHS is unsigned short so handle_char_store would not be called
> because of the check in the caller. You would need something like:
>
> MEM [(char *)&x] = { 'a', 'b' };
This is invalid, because the rhs is non-empty CONSTRUCTO
On 6/27/19 9:15 AM, Jeff Law wrote:
On 6/27/19 9:00 AM, Jeff Law wrote:
On 6/26/19 8:40 PM, Martin Sebor wrote:
On 6/26/19 4:31 PM, Jeff Law wrote:
On 6/25/19 5:03 PM, Martin Sebor wrote:
The caller ensures that handle_char_store is only called for stores
to arrays (MEM_REF) or single eleme
On Thu, Jun 27, 2019 at 09:15:41AM -0600, Jeff Law wrote:
> Actually it was trivial to create with store merging.
>
> char x[20];
> foo()
> {
> x[0] = 0x41;
> x[1] = 0x42;
> }
>
> MEM [(char *)&x] = 16961;
>
> So clearly we can get this in gimple. So we need a check of some kind,
> eithe
On 6/27/19 9:00 AM, Jeff Law wrote:
> On 6/26/19 8:40 PM, Martin Sebor wrote:
>> On 6/26/19 4:31 PM, Jeff Law wrote:
>>> On 6/25/19 5:03 PM, Martin Sebor wrote:
>>>
The caller ensures that handle_char_store is only called for stores
to arrays (MEM_REF) or single elements as wide as c
On 6/26/19 8:40 PM, Martin Sebor wrote:
> On 6/26/19 4:31 PM, Jeff Law wrote:
>> On 6/25/19 5:03 PM, Martin Sebor wrote:
>>
>>>
>>> The caller ensures that handle_char_store is only called for stores
>>> to arrays (MEM_REF) or single elements as wide as char.
>> Where? I don't see it, even after f
On 6/26/19 4:31 PM, Jeff Law wrote:
On 6/25/19 5:03 PM, Martin Sebor wrote:
The caller ensures that handle_char_store is only called for stores
to arrays (MEM_REF) or single elements as wide as char.
Where? I don't see it, even after fixing the formatting in
strlen_check_and_optimize_stmt :-
On 6/25/19 5:03 PM, Martin Sebor wrote:
>
> The caller ensures that handle_char_store is only called for stores
> to arrays (MEM_REF) or single elements as wide as char.
Where? I don't see it, even after fixing the formatting in
strlen_check_and_optimize_stmt :-)
> gimple *stmt = gsi_stmt (*g
On 6/25/19 3:38 PM, Jeff Law wrote:
On 6/24/19 6:47 PM, Martin Sebor wrote:
On 6/24/19 5:59 PM, Jeff Law wrote:
On 6/24/19 5:50 PM, Martin Sebor wrote:
The strlen enhancement committed in r263018 to handle multi-character
assignments extended the handle_char_store() function to handle such
sto
On 6/24/19 6:47 PM, Martin Sebor wrote:
> On 6/24/19 5:59 PM, Jeff Law wrote:
>> On 6/24/19 5:50 PM, Martin Sebor wrote:
>>> The strlen enhancement committed in r263018 to handle multi-character
>>> assignments extended the handle_char_store() function to handle such
>>> stores via MEM_REFs. Prior
On 6/24/19 5:59 PM, Jeff Law wrote:
On 6/24/19 5:50 PM, Martin Sebor wrote:
The strlen enhancement committed in r263018 to handle multi-character
assignments extended the handle_char_store() function to handle such
stores via MEM_REFs. Prior to that the function only dealt with
single-char stor
On 6/24/19 5:50 PM, Martin Sebor wrote:
> The strlen enhancement committed in r263018 to handle multi-character
> assignments extended the handle_char_store() function to handle such
> stores via MEM_REFs. Prior to that the function only dealt with
> single-char stores. The enhancement neglected
The strlen enhancement committed in r263018 to handle multi-character
assignments extended the handle_char_store() function to handle such
stores via MEM_REFs. Prior to that the function only dealt with
single-char stores. The enhancement neglected to constrain a case
in the function that assume
19 matches
Mail list logo
