Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c++ > #80156 > unrolled thread
| Started by | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| First post | 2021-06-05 12:53 +0200 |
| Last post | 2021-06-07 14:52 +0000 |
| Articles | 16 on this page of 156 — 33 participants |
Back to article view | Back to comp.lang.c++
Is this really necessary Bonita Montero <Bonita.Montero@gmail.com> - 2021-06-05 12:53 +0200
Re: Is this really necessary David Brown <david.brown@hesbynett.no> - 2021-06-05 14:19 +0200
Re: Is this really necessary Bonita Montero <Bonita.Montero@gmail.com> - 2021-06-05 14:27 +0200
Re: Is this really necessary David Brown <david.brown@hesbynett.no> - 2021-06-05 14:33 +0200
Re: Is this really necessary Bonita Montero <Bonita.Montero@gmail.com> - 2021-06-05 15:06 +0200
Re: Is this really necessary David Brown <david.brown@hesbynett.no> - 2021-06-05 15:29 +0200
Re: Is this really necessary Bonita Montero <Bonita.Montero@gmail.com> - 2021-06-05 17:38 +0200
Re: Is this really necessary David Brown <david.brown@hesbynett.no> - 2021-06-05 17:51 +0200
Re: Is this really necessary Richard Damon <Richard@Damon-Family.org> - 2021-06-05 11:56 -0400
Re: Is this really necessary James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-06-05 19:08 -0400
Re: Is this really necessary David Brown <david.brown@hesbynett.no> - 2021-06-06 11:24 +0200
Re: Is this really necessary Chris Vine <chris@cvine--nospam--.freeserve.co.uk> - 2021-06-06 10:33 +0100
Re: Is this really necessary Richard Damon <Richard@Damon-Family.org> - 2021-06-06 07:56 -0400
Re: Is this really necessary Chris Vine <chris@cvine--nospam--.freeserve.co.uk> - 2021-06-06 15:00 +0100
Re: Is this really necessary Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-06-06 16:20 -0700
Re: Is this really necessary Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-06-07 00:44 -0700
Re: Is this really necessary Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-06-07 12:13 -0700
Re: Is this really necessary Bo Persson <bo@bo-persson.se> - 2021-06-07 21:58 +0200
Re: Is this really necessary Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-08-07 10:25 -0700
Re: Is this really necessary Bo Persson <bo@bo-persson.se> - 2021-08-07 21:21 +0200
Re: Is this really necessary Öö Tiib <ootiib@hot.ee> - 2021-06-05 06:34 -0700
Re: Is this really necessary Richard Damon <Richard@Damon-Family.org> - 2021-06-05 20:03 -0400
Re: Is this really necessary Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-08-07 12:59 -0700
Re: Is this really necessary MrSpud_85yGi2@1ahbfz.gov - 2021-08-08 09:18 +0000
Re: Is this really necessary James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-08-08 09:23 -0400
Re: Is this really necessary Juha Nieminen <nospam@thanks.invalid> - 2021-08-08 15:04 +0000
Re: Is this really necessary Richard Damon <Richard@Damon-Family.org> - 2021-08-08 13:14 -0400
Re: Is this really necessary MrSpud_1dgrmf@dx58865qyrdw30lqllb.info - 2021-08-09 08:21 +0000
Re: Is this really necessary Juha Nieminen <nospam@thanks.invalid> - 2021-08-09 08:53 +0000
Re: Is this really necessary "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2021-08-09 19:53 +0200
Re: Is this really necessary Juha Nieminen <nospam@thanks.invalid> - 2021-08-10 05:22 +0000
Re: Is this really necessary scott@slp53.sl.home (Scott Lurndal) - 2021-08-10 14:54 +0000
Re: Is this really necessary Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-08-10 11:41 -0700
Re: Is this really necessary Juha Nieminen <nospam@thanks.invalid> - 2021-08-11 05:39 +0000
Re: Is this really necessary Chris Vine <chris@cvine--nospam--.freeserve.co.uk> - 2021-08-08 20:01 +0100
Re: Is this really necessary MrSpud_ifhov@nldls6_1kg3nl2qnwv.biz - 2021-08-09 08:19 +0000
Re: Is this really necessary Juha Nieminen <nospam@thanks.invalid> - 2021-08-09 08:55 +0000
Re: Is this really necessary James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-08-09 12:16 -0400
Re: Is this really necessary MrSpud_HG@_0b772d8ha3yjo0xb.edu - 2021-08-09 16:23 +0000
Re: Is this really necessary Vir Campestris <vir.campestris@invalid.invalid> - 2021-08-09 21:50 +0100
Re: Is this really necessary Richard Damon <Richard@Damon-Family.org> - 2021-08-09 20:57 -0400
Re: Is this really necessary scott@slp53.sl.home (Scott Lurndal) - 2021-08-10 01:12 +0000
Re: Is this really necessary Richard Damon <Richard@Damon-Family.org> - 2021-08-09 21:21 -0400
Re: Is this really necessary Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-08-10 07:13 -0700
Re: Is this really necessary Juha Nieminen <nospam@thanks.invalid> - 2021-08-10 05:29 +0000
Re: Is this really necessary MrSpud_12tus_Atff@bya886olr5o8dhu9.ac.uk - 2021-08-10 07:28 +0000
Re: Is this really necessary Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2021-08-10 15:34 +0100
Re: Is this really necessary scott@slp53.sl.home (Scott Lurndal) - 2021-08-10 14:59 +0000
Re: Is this really necessary MrSpud_wPgnov999o@vv7a6.tv - 2021-08-10 15:54 +0000
Re: Is this really necessary Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-08-10 11:29 -0700
Re: Is this really necessary mickspud@downthefarm.com - 2021-08-11 08:45 +0000
Re: Is this really necessary Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-08-11 07:05 -0700
Re: Is this really necessary mickspud@downthefarm.com - 2021-08-11 14:18 +0000
Re: Is this really necessary scott@slp53.sl.home (Scott Lurndal) - 2021-08-10 14:57 +0000
Re: Is this really necessary MrSpud_pb9bpp7Ej@6urvt16b9fax.gov.uk - 2021-08-10 07:23 +0000
Re: Is this really necessary scott@slp53.sl.home (Scott Lurndal) - 2021-08-10 15:02 +0000
Re: Is this really necessary Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-08-10 06:11 -0700
Re: Is this really necessary Bo Persson <bo@bo-persson.se> - 2021-08-10 16:13 +0200
Re: Is this really necessary Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-08-11 12:40 -0700
Re: Is this really necessary mickspud@downthefarm.com - 2021-08-12 08:20 +0000
Re: Is this really necessary Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-08-12 03:50 -0700
Re: Is this really necessary mickspud@downthefarm.com - 2021-08-12 14:58 +0000
Re: Is this really necessary Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-08-12 08:29 -0700
Re: Is this really necessary mickspud@downthefarm.com - 2021-08-12 15:39 +0000
Re: Is this really necessary Paavo Helde <myfirstname@osa.pri.ee> - 2021-08-12 20:07 +0300
Re: Is this really necessary Juha Nieminen <nospam@thanks.invalid> - 2021-08-13 07:16 +0000
Re: Is this really necessary mickspud@downthefarm.com - 2021-08-13 09:26 +0000
Re: Is this really necessary James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-08-13 10:30 -0400
Re: Is this really necessary mickspud@downthefarm.com - 2021-08-13 14:58 +0000
Re: Is this really necessary Juha Nieminen <nospam@thanks.invalid> - 2021-08-14 08:07 +0000
Re: Is this really necessary "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> - 2021-08-14 10:40 -0700
Re: Is this really necessary "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> - 2021-08-14 10:38 -0700
Re: Is this really necessary "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2021-08-13 15:30 +0200
Re: Is this really necessary Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-08-13 11:18 -0700
Re: Is this really necessary Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-08-14 03:20 -0700
Re: Is this really necessary Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-08-14 13:24 -0700
Re: Is this really necessary Juha Nieminen <nospam@thanks.invalid> - 2021-08-14 20:33 +0000
Re: Is this really necessary James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-08-15 00:40 -0400
Re: Is this really necessary Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-08-15 07:02 -0700
Re: Is this really necessary "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2021-08-15 21:19 +0200
Re: Is this really necessary Richard Damon <Richard@Damon-Family.org> - 2021-08-15 15:42 -0400
Re: Is this really necessary Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-08-21 12:38 -0700
Re: Is this really necessary Juha Nieminen <nospam@thanks.invalid> - 2021-08-14 08:13 +0000
Re: Is this really necessary Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-08-14 02:58 -0700
Re: Is this really necessary scott@slp53.sl.home (Scott Lurndal) - 2021-08-13 14:32 +0000
Re: Is this really necessary Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-08-14 02:28 -0700
Re: Is this really necessary Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-08-14 03:00 -0700
Re: Is this really necessary Bart <bc@freeuk.com> - 2021-08-14 14:03 +0100
Re: Is this really necessary mickspud@downthefarm.com - 2021-08-14 15:06 +0000
Re: Is this really necessary "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-08-12 12:06 -0700
Re: Is this really necessary mickspud@downthefarm.com - 2021-08-13 09:19 +0000
Re: Is this really necessary scott@slp53.sl.home (Scott Lurndal) - 2021-08-13 14:35 +0000
Re: Is this really necessary mickspud@downthefarm.com - 2021-08-13 14:58 +0000
Re: Is this really necessary scott@slp53.sl.home (Scott Lurndal) - 2021-08-10 15:03 +0000
Re: Is this really necessary Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-08-11 12:54 -0700
Re: Is this really necessary scott@slp53.sl.home (Scott Lurndal) - 2021-08-11 20:20 +0000
Re: Is this really necessary Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-08-12 03:42 -0700
Re: Is this really necessary Juha Nieminen <nospam@thanks.invalid> - 2021-08-11 05:45 +0000
Re: Is this really necessary Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-08-11 05:26 -0700
Re: Is this really necessary scott@slp53.sl.home (Scott Lurndal) - 2021-08-11 14:06 +0000
Re: Is this really necessary scott@slp53.sl.home (Scott Lurndal) - 2021-08-11 14:01 +0000
Re: Is this really necessary James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-08-09 23:20 -0400
Re: Is this really necessary MrSpud_m7k7yilq_8@u6w.biz - 2021-08-10 07:26 +0000
Re: Is this really necessary Juha Nieminen <nospam@thanks.invalid> - 2021-08-10 07:51 +0000
Re: Is this really necessary MrSpud_ggBp1lq0@lxz.tv - 2021-08-10 07:59 +0000
Re: Is this really necessary Juha Nieminen <nospam@thanks.invalid> - 2021-08-10 12:24 +0000
Re: Is this really necessary MrSpud_u7lm@bxuc3wy1g3cxiqu5j2x1_7iu.com - 2021-08-10 15:51 +0000
Re: Is this really necessary Juha Nieminen <nospam@thanks.invalid> - 2021-08-11 05:47 +0000
Re: Is this really necessary mickspud@downthefarm.com - 2021-08-11 08:46 +0000
Re: Is this really necessary David Brown <david.brown@hesbynett.no> - 2021-08-10 11:20 +0200
Re: Is this really necessary James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-08-10 10:27 -0400
Re: Is this really necessary David Brown <david.brown@hesbynett.no> - 2021-08-10 17:44 +0200
Re: Is this really necessary MrSpud_885p_dugji@l6zhsgj_v6t3dbj.tv - 2021-08-10 15:50 +0000
Re: Is this really necessary David Brown <david.brown@hesbynett.no> - 2021-08-11 08:31 +0200
Re: Is this really necessary James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-08-10 10:27 -0400
Re: Is this really necessary Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-08-10 11:27 -0700
Re: Is this really necessary mickspud@downthefarm.com - 2021-08-11 08:44 +0000
Re: Is this really necessary Paavo Helde <myfirstname@osa.pri.ee> - 2021-08-11 16:05 +0300
Re: Is this really necessary Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-08-10 06:41 -0700
Re: Is this really necessary Paavo Helde <myfirstname@osa.pri.ee> - 2021-06-06 18:48 +0300
Re: Is this really necessary Richard Damon <Richard@Damon-Family.org> - 2021-06-06 14:26 -0400
Re: Is this really necessary Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-06-06 16:10 -0700
Re: Is this really necessary Richard Damon <Richard@Damon-Family.org> - 2021-06-06 21:30 -0400
Re: Is this really necessary Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-06-06 18:49 -0700
Re: Is this really necessary Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-06-06 18:51 -0700
Re: Is this really necessary Richard Damon <Richard@Damon-Family.org> - 2021-06-06 22:57 -0400
Re: Is this really necessary Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-06-07 09:43 -0700
Re: Is this really necessary Öö Tiib <ootiib@hot.ee> - 2021-06-07 09:51 -0700
Re: Is this really necessary Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-08-07 10:22 -0700
Re: Is this really necessary "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> - 2021-06-07 10:13 -0700
Re: Is this really necessary Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-08-07 10:22 -0700
Re: Is this really necessary "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> - 2021-08-07 12:40 -0700
Re: Is this really necessary Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-08-07 12:54 -0700
Re: Is this really necessary Öö Tiib <ootiib@hot.ee> - 2021-06-06 23:17 -0700
Re: Is this really necessary Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-06-07 09:19 -0700
Re: Is this really necessary Paavo Helde <myfirstname@osa.pri.ee> - 2021-06-07 21:58 +0300
Re: Is this really necessary Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-06-10 11:29 -0700
Re: Is this really necessary Öö Tiib <ootiib@hot.ee> - 2021-06-05 05:38 -0700
Re: Is this really necessary David Brown <david.brown@hesbynett.no> - 2021-06-05 15:41 +0200
Re: Is this really necessary Öö Tiib <ootiib@hot.ee> - 2021-06-05 08:18 -0700
Re: Is this really necessary Richard Damon <Richard@Damon-Family.org> - 2021-06-05 11:58 -0400
Re: Is this really necessary MrSpook_rs7x@4hhtozmpj299zx.tv - 2021-06-05 16:00 +0000
Re: Is this really necessary David Brown <david.brown@hesbynett.no> - 2021-06-05 18:16 +0200
Re: Is this really necessary David Brown <david.brown@hesbynett.no> - 2021-06-06 17:34 +0200
Re: Is this really necessary MrSpook_ie@q67rq6_2ly9ut44j.org - 2021-06-06 13:55 +0000
Re: Is this really necessary Bo Persson <bo@bo-persson.se> - 2021-06-05 19:50 +0200
Re: Is this really necessary MrSpook_zn7@4tzq7j92.gov - 2021-06-06 13:59 +0000
Re: Is this really necessary James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-06-05 17:42 -0400
Re: Is this really necessary David Brown <david.brown@hesbynett.no> - 2021-06-06 11:05 +0200
Re: Is this really necessary Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-06-07 00:27 -0700
Re: Is this really necessary Vir Campestris <vir.campestris@invalid.invalid> - 2021-06-06 21:27 +0100
Re: Is this really necessary "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2021-06-07 00:22 +0200
Re: Is this really necessary scott@slp53.sl.home (Scott Lurndal) - 2021-06-07 14:53 +0000
Re: Is this really necessary Bonita Montero <Bonita.Montero@gmail.com> - 2021-06-07 18:02 +0200
Re: Is this really necessary Vir Campestris <vir.campestris@invalid.invalid> - 2021-06-16 21:38 +0100
Re: Is this really necessary scott@slp53.sl.home (Scott Lurndal) - 2021-06-07 14:52 +0000
Page 8 of 8 — ← Prev page 1 2 3 4 5 6 7 [8]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2021-06-05 11:58 -0400 |
| Message-ID | <YaNuI.72059$Mz2.23933@fx14.iad> |
| In reply to | #80165 |
On 6/5/21 11:18 AM, Öö Tiib wrote:
> On Saturday, 5 June 2021 at 16:41:35 UTC+3, David Brown wrote:
>> On 05/06/2021 14:38, Öö Tiib wrote:
>>> On Saturday, 5 June 2021 at 15:20:07 UTC+3, David Brown wrote:
>>>> On 05/06/2021 12:53, Bonita Montero wrote:
>>>>> Consider the following code:
>>>>>
>>>>>
>>>>> size_t s( int *begin, int *end )
>>>>> {
>>>>> return (end - begin) * sizeof(int);
>>>>> }
>>>>>
>>>>> This is MSVC's disassembly:
>>>>>
>>>>> sub rdx, rcx
>>>>> and rdx, -4
>>>>> mov rax, rdx
>>>>> ret 0
>>>>>
>>>>> This is gcc's disassembly:
>>>>>
>>>>> movq %rsi, %rax
>>>>> subq %rdi, %rax
>>>>> ret
>>>>>
>>>>> It the masking really necessary or just an optimizer weakness;
>>>>> it seems to me MSVC sees that two bits are shifted out and "in"
>>>>> and replaces this with a mask.
>>>>> I think that the language-standard assumes equally aligned data
>>>>> among same types for the above code and gcc is corcect, but I'm
>>>>> not sure.
>>>>>
>>>> I can't help thinking that putting a non-aligned value into an int
>>>> pointer is undefined behaviour - but I can't find a reference to that in
>>>> the C standards (and I don't know the C++ standards well enough to look
>>>> there).
>>>
>>> The C and C++ programs that use unaligned pointers are undefined (in
>>> sense of standard) regardless of the target architecture (that may allow
>>> unaligned accesses) but the implementations can extend.
>>>
>> Of course implementations can add whatever definitions they want beyond
>> the requirements of the standard.
>>
>> And while dereferencing unaligned pointers is undefined behaviour (by
>> the standards), I haven't found anything that says that merely assigning
>> an unaligned value to a pointer is undefined behaviour. But that could
>> easily be something I missed - hopefully someone can then give the
>> reference (in the C or C++ standards).
>
> When to attempt to make the pointer that is unaligned then "resulting
> pointer value is unspecified" or equal wording in couple places of
> C++ standard. I did mean usage like dereferencing of such unspecified
> pointer value is undefined (unless implementation gives some better
> guarantees).
My understanding is that the unaligned pointer has an unspecified value
that might be a trap value, so any operation that uses that value can
cause Undefined Behavior.
>
[toc] | [prev] | [next] | [standalone]
| From | MrSpook_rs7x@4hhtozmpj299zx.tv |
|---|---|
| Date | 2021-06-05 16:00 +0000 |
| Message-ID | <s9g72u$de0$1@gioia.aioe.org> |
| In reply to | #80157 |
On Sat, 5 Jun 2021 14:19:52 +0200
David Brown <david.brown@hesbynett.no> wrote:
>On 05/06/2021 12:53, Bonita Montero wrote:
>> It the masking really necessary or just an optimizer weakness;
>> it seems to me MSVC sees that two bits are shifted out and "in"
>> and replaces this with a mask.
>> I think that the language-standard assumes equally aligned data
>> among same types for the above code and gcc is corcect, but I'm
>> not sure.
>>
>
>I can't help thinking that putting a non-aligned value into an int
>pointer is undefined behaviour - but I can't find a reference to that in
Alignment only matters on certain architectures, and even then , not always.
eg this compiles and runs fine on x86 MacOS using clang, setting non aligned
ints on both the stack and the heap:
#include <stdio.h>
#include <stdint.h>
#include <stdlib.h>
int main()
{
uint32_t i;
uint32_t j;
uint32_t *p1;
uint32_t *p2;
p1 = (&j < &i ? &j : &i);
p2 = (uint32_t *)((char *)p1 + 1);
printf("p1 = %p, p2 = %p\n",p1,p2);
*p2 = (uint32_t)-1;
printf("*p2 = %u\n",*p2);
p1 = (uint32_t *)malloc(sizeof(uint32_t) * 2);
p2 = (uint32_t *)((char *)p1 + 1);
printf("p1 = %p, p2 = %p\n",p1,p2);
*p2 = (uint32_t)-1;
printf("*p2 = %u\n",*p2);
return 0;
}
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2021-06-05 18:16 +0200 |
| Message-ID | <s9g81l$s96$1@dont-email.me> |
| In reply to | #80170 |
On 05/06/2021 18:00, MrSpook_rs7x@4hhtozmpj299zx.tv wrote: > On Sat, 5 Jun 2021 14:19:52 +0200 > David Brown <david.brown@hesbynett.no> wrote: >> On 05/06/2021 12:53, Bonita Montero wrote: >>> It the masking really necessary or just an optimizer weakness; >>> it seems to me MSVC sees that two bits are shifted out and "in" >>> and replaces this with a mask. >>> I think that the language-standard assumes equally aligned data >>> among same types for the above code and gcc is corcect, but I'm >>> not sure. >>> >> >> I can't help thinking that putting a non-aligned value into an int >> pointer is undefined behaviour - but I can't find a reference to that in > > Alignment only matters on certain architectures, and even then , not always. The discussion is about behaviour that is not defined by the C and C++ standards. If you can point to /documentation/ that says clang on x86 MacOS defines the behaviour of unaligned access, that would be interesting. But other than that, a sample of "this example happens to work on this compiler with these flags on this target" is irrelevant. We all know that on many - but not all - cpu targets, unaligned accesses work as expected, albeit usually at a performance cost. But we are talking about the standards definition of C++ here (and perhaps C, in that C++ inherits such things from C), not cpus.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2021-06-06 17:34 +0200 |
| Message-ID | <s9iput$574$1@dont-email.me> |
| In reply to | #80171 |
On 06/06/2021 15:55, MrSpook_ie@q67rq6_2ly9ut44j.org wrote: > On Sat, 5 Jun 2021 18:16:52 +0200 > David Brown <david.brown@hesbynett.no> wrote: >> On 05/06/2021 18:00, MrSpook_rs7x@4hhtozmpj299zx.tv wrote: >>> On Sat, 5 Jun 2021 14:19:52 +0200 >>> David Brown <david.brown@hesbynett.no> wrote: >>>> On 05/06/2021 12:53, Bonita Montero wrote: >>>>> It the masking really necessary or just an optimizer weakness; >>>>> it seems to me MSVC sees that two bits are shifted out and "in" >>>>> and replaces this with a mask. >>>>> I think that the language-standard assumes equally aligned data >>>>> among same types for the above code and gcc is corcect, but I'm >>>>> not sure. >>>>> >>>> >>>> I can't help thinking that putting a non-aligned value into an int >>>> pointer is undefined behaviour - but I can't find a reference to that in >>> >>> Alignment only matters on certain architectures, and even then , not always. >> >> The discussion is about behaviour that is not defined by the C and C++ >> standards. If you can point to /documentation/ that says clang on x86 >> MacOS defines the behaviour of unaligned access, that would be > > Probably isn't any. I suspect most compilers just create the machine code and > the rest is up to the CPU. > In the majority of cases, that is correct. The fun comes when the compiler can see that if it assumes there is no undefined behaviour, it can make significant efficiency improvements - then it might well do so. (Optimisations vary by compiler, flags, etc.) Remember, "undefined behaviour" means compiler might generate code that does what you might expect as the "natural" behaviour on the cpu in question - it also means it might assume it doesn't happen and then you get weird effects if you break the rules. That's why "it worked when I tested it" is not something you should rely on for undefined behaviour - you might have got lucky, or maybe things will change with the next compiler version.
[toc] | [prev] | [next] | [standalone]
| From | MrSpook_ie@q67rq6_2ly9ut44j.org |
|---|---|
| Date | 2021-06-06 13:55 +0000 |
| Message-ID | <s9ik53$1g4q$1@gioia.aioe.org> |
| In reply to | #80171 |
On Sat, 5 Jun 2021 18:16:52 +0200 David Brown <david.brown@hesbynett.no> wrote: >On 05/06/2021 18:00, MrSpook_rs7x@4hhtozmpj299zx.tv wrote: >> On Sat, 5 Jun 2021 14:19:52 +0200 >> David Brown <david.brown@hesbynett.no> wrote: >>> On 05/06/2021 12:53, Bonita Montero wrote: >>>> It the masking really necessary or just an optimizer weakness; >>>> it seems to me MSVC sees that two bits are shifted out and "in" >>>> and replaces this with a mask. >>>> I think that the language-standard assumes equally aligned data >>>> among same types for the above code and gcc is corcect, but I'm >>>> not sure. >>>> >>> >>> I can't help thinking that putting a non-aligned value into an int >>> pointer is undefined behaviour - but I can't find a reference to that in >> >> Alignment only matters on certain architectures, and even then , not always. > >The discussion is about behaviour that is not defined by the C and C++ >standards. If you can point to /documentation/ that says clang on x86 >MacOS defines the behaviour of unaligned access, that would be Probably isn't any. I suspect most compilers just create the machine code and the rest is up to the CPU.
[toc] | [prev] | [next] | [standalone]
| From | Bo Persson <bo@bo-persson.se> |
|---|---|
| Date | 2021-06-05 19:50 +0200 |
| Message-ID | <ii1rr0F9q7oU1@mid.individual.net> |
| In reply to | #80170 |
On 2021-06-05 at 18:00, MrSpook_rs7x@4hhtozmpj299zx.tv wrote:
> On Sat, 5 Jun 2021 14:19:52 +0200
> David Brown <david.brown@hesbynett.no> wrote:
>> On 05/06/2021 12:53, Bonita Montero wrote:
>>> It the masking really necessary or just an optimizer weakness;
>>> it seems to me MSVC sees that two bits are shifted out and "in"
>>> and replaces this with a mask.
>>> I think that the language-standard assumes equally aligned data
>>> among same types for the above code and gcc is corcect, but I'm
>>> not sure.
>>>
>>
>> I can't help thinking that putting a non-aligned value into an int
>> pointer is undefined behaviour - but I can't find a reference to that in
>
> Alignment only matters on certain architectures, and even then , not always.
> eg this compiles and runs fine on x86 MacOS using clang, setting non aligned
> ints on both the stack and the heap:
>
> #include <stdio.h>
> #include <stdint.h>
> #include <stdlib.h>
>
> int main()
> {
> uint32_t i;
> uint32_t j;
> uint32_t *p1;
> uint32_t *p2;
>
> p1 = (&j < &i ? &j : &i);
> p2 = (uint32_t *)((char *)p1 + 1);
> printf("p1 = %p, p2 = %p\n",p1,p2);
> *p2 = (uint32_t)-1;
> printf("*p2 = %u\n",*p2);
>
> p1 = (uint32_t *)malloc(sizeof(uint32_t) * 2);
> p2 = (uint32_t *)((char *)p1 + 1);
> printf("p1 = %p, p2 = %p\n",p1,p2);
> *p2 = (uint32_t)-1;
> printf("*p2 = %u\n",*p2);
> return 0;
> }
>
You did notice (right?) that the optimiser transformed
printf("*p2 = %u\n",*p2);
into
printf("*p2 = %u\n", (uint32_t)-1);
resulting in the code
00007FF71990106D mov rcx,rsi
00007FF719901070 mov edx,0FFFFFFFFh
00007FF719901075 call printf (07FF719901090h)
[toc] | [prev] | [next] | [standalone]
| From | MrSpook_zn7@4tzq7j92.gov |
|---|---|
| Date | 2021-06-06 13:59 +0000 |
| Message-ID | <s9ikcf$1j50$1@gioia.aioe.org> |
| In reply to | #80172 |
On Sat, 5 Jun 2021 19:50:23 +0200
Bo Persson <bo@bo-persson.se> wrote:
>On 2021-06-05 at 18:00, MrSpook_rs7x@4hhtozmpj299zx.tv wrote:
>> #include <stdio.h>
>> #include <stdint.h>
>> #include <stdlib.h>
>>
>> int main()
>> {
>> uint32_t i;
>> uint32_t j;
>> uint32_t *p1;
>> uint32_t *p2;
>>
>> p1 = (&j < &i ? &j : &i);
>> p2 = (uint32_t *)((char *)p1 + 1);
>> printf("p1 = %p, p2 = %p\n",p1,p2);
>> *p2 = (uint32_t)-1;
>> printf("*p2 = %u\n",*p2);
>>
>> p1 = (uint32_t *)malloc(sizeof(uint32_t) * 2);
>> p2 = (uint32_t *)((char *)p1 + 1);
>> printf("p1 = %p, p2 = %p\n",p1,p2);
>> *p2 = (uint32_t)-1;
>> printf("*p2 = %u\n",*p2);
>> return 0;
>> }
>>
>
>You did notice (right?) that the optimiser transformed
>
>printf("*p2 = %u\n",*p2);
>
>into
>
>printf("*p2 = %u\n", (uint32_t)-1);
>
>resulting in the code
>
>00007FF71990106D mov rcx,rsi
>00007FF719901070 mov edx,0FFFFFFFFh
>00007FF719901075 call printf (07FF719901090h)
Nope, guess the compiler didn't notice either:
movq -40(%rbp), %rax ## 8-byte Reload
movq %rax, -24(%rbp)
movq -24(%rbp), %rax
addq $1, %rax
movq %rax, -32(%rbp)
movq -24(%rbp), %rsi
movq -32(%rbp), %rdx
leaq L_.str(%rip), %rdi
movb $0, %al
callq _printf
movq -32(%rbp), %rcx
movl $-1, (%rcx)
movq -32(%rbp), %rcx
movl (%rcx), %esi
leaq L_.str.1(%rip), %rdi
movl %eax, -44(%rbp) ## 4-byte Spill
movb $0, %al
callq _printf
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2021-06-05 17:42 -0400 |
| Message-ID | <s9gr4n$ui0$1@dont-email.me> |
| In reply to | #80157 |
On 6/5/21 8:19 AM, David Brown wrote: ... > I can't help thinking that putting a non-aligned value into an int > pointer is undefined behaviour - but I can't find a reference to that in > the C standards (and I don't know the C++ standards well enough to look > there). It's not something either standard says explicitly. Rather, it's something that need to be derived from what it says about other things. If you start from a pointer that is correctly aligned for it's type, most pointer operations give a result that still points to the same type, and is still correctly aligned for that type. This includes conversion to an integer type and back to the original pointer type. The only operations that could result in a mis-aligned pointer all have undefined behavior for one reason or another. For instance, conversion to a pointer to a more strictly aligned type has undefined behavior if the original pointer doesn't meet the alignment requirements of the new type. Converting a pointer to an integer, performing any kind on arithmetic on that integer to produce a different integer value, and converting back again, has undefined behavior due to the omission of any explicit definition of the behavior. So what about starting with a mis-aligned pointer? If you have a packed struct, the members of that struct might not be correctly aligned for their type. By packing a struct is not a core language feature - it's only available as an extension. On platforms with strong alignment requirements, implementations that allow struct packing will generally provide warnings about ways you should not use normal pointers to access objects that might be misaligned. You could also convert an integer that represents a memory location that is not correctly aligned for a given type, and convert it into a pointer to that type - but the behavior of such a conversion is undefined. I'm not sure that the above argument covers every possibility, but I do believe that every possible way of getting a misaligned pointer is covered, in some fashion, by both standards.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2021-06-06 11:05 +0200 |
| Message-ID | <s9i34v$fro$1@dont-email.me> |
| In reply to | #80173 |
On 05/06/2021 23:42, James Kuyper wrote: > On 6/5/21 8:19 AM, David Brown wrote: > ... >> I can't help thinking that putting a non-aligned value into an int >> pointer is undefined behaviour - but I can't find a reference to that in >> the C standards (and I don't know the C++ standards well enough to look >> there). > > It's not something either standard says explicitly. Rather, it's > something that need to be derived from what it says about other things. > If you start from a pointer that is correctly aligned for it's type, > most pointer operations give a result that still points to the same > type, and is still correctly aligned for that type. This includes > conversion to an integer type and back to the original pointer type. > The only operations that could result in a mis-aligned pointer all have > undefined behavior for one reason or another. For instance, conversion > to a pointer to a more strictly aligned type has undefined behavior if > the original pointer doesn't meet the alignment requirements of the new > type. Converting a pointer to an integer, performing any kind on > arithmetic on that integer to produce a different integer value, and > converting back again, has undefined behavior due to the omission of any > explicit definition of the behavior. > So what about starting with a mis-aligned pointer? If you have a packed > struct, the members of that struct might not be correctly aligned for > their type. By packing a struct is not a core language feature - it's > only available as an extension. On platforms with strong alignment > requirements, implementations that allow struct packing will generally > provide warnings about ways you should not use normal pointers to access > objects that might be misaligned. > You could also convert an integer that represents a memory location that > is not correctly aligned for a given type, and convert it into a pointer > to that type - but the behavior of such a conversion is undefined. > > I'm not sure that the above argument covers every possibility, but I do > believe that every possible way of getting a misaligned pointer is > covered, in some fashion, by both standards. > The only major possibility I can think of that is missing above, is type punning of various types (such as via a union in C, or by accessing the pointer via a char pointer or memcpy). But I expect they too would have to provide a valid pointer or the results would be undefined when the pointer was used. Thank you for the explanation.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2021-06-07 00:27 -0700 |
| Message-ID | <8635tudtih.fsf@linuxsc.com> |
| In reply to | #80173 |
James Kuyper <jameskuyper@alumni.caltech.edu> writes: > [...] Converting a pointer to an integer, performing any kind on > arithmetic on that integer to produce a different integer value, and > converting back again, has undefined behavior due to the omission of > any explicit definition of the behavior. Converting an arbitrary integer to a pointer is implementation-defined behavior, not undefined behavior.
[toc] | [prev] | [next] | [standalone]
| From | Vir Campestris <vir.campestris@invalid.invalid> |
|---|---|
| Date | 2021-06-06 21:27 +0100 |
| Message-ID | <s9jb4b$rs9$1@dont-email.me> |
| In reply to | #80156 |
On 05/06/2021 11:53, Bonita Montero wrote:
> Consider the following code:
>
>
> size_t s( int *begin, int *end )
> {
> return (end - begin) * sizeof(int);
> }
>
> This is MSVC's disassembly:
>
> sub rdx, rcx
> and rdx, -4
> mov rax, rdx
> ret 0
>
> This is gcc's disassembly:
>
> movq %rsi, %rax
> subq %rdi, %rax
> ret
>
> It the masking really necessary or just an optimizer weakness;
> it seems to me MSVC sees that two bits are shifted out and "in"
> and replaces this with a mask.
> I think that the language-standard assumes equally aligned data
> among same types for the above code and gcc is corcect, but I'm
> not sure.
>
I've gone through the whole thread, and nobody else has commented.
That GCC disassembly can't possibly be a correct and complete rendition
of the function.
Maybe on entry begin is in eax, and end in rdi, which would explain the
second instruction. But what's it doing with rsi?
Andy
[toc] | [prev] | [next] | [standalone]
| From | "Alf P. Steinbach" <alf.p.steinbach@gmail.com> |
|---|---|
| Date | 2021-06-07 00:22 +0200 |
| Message-ID | <s9jhr7$atc$1@dont-email.me> |
| In reply to | #80199 |
On 6 Jun 2021 22:27, Vir Campestris wrote:
> On 05/06/2021 11:53, Bonita Montero wrote:
>> Consider the following code:
>>
>>
>> size_t s( int *begin, int *end )
>> {
>> return (end - begin) * sizeof(int);
>> }
>>
>> This is MSVC's disassembly:
>>
>> sub rdx, rcx
>> and rdx, -4
>> mov rax, rdx
>> ret 0
>>
>> This is gcc's disassembly:
>>
>> movq %rsi, %rax
>> subq %rdi, %rax
>> ret
>>
>> It the masking really necessary or just an optimizer weakness;
>> it seems to me MSVC sees that two bits are shifted out and "in"
>> and replaces this with a mask.
>> I think that the language-standard assumes equally aligned data
>> among same types for the above code and gcc is corcect, but I'm
>> not sure.
>>
> I've gone through the whole thread, and nobody else has commented.
>
> That GCC disassembly can't possibly be a correct and complete rendition
> of the function.
>
> Maybe on entry begin is in eax, and end in rdi, which would explain the
> second instruction. But what's it doing with rsi?
Possibly you've assumed that the examples are expressed with the same
syntax.
The MSVC example uses Intel syntax, where e.g. `sub rdx, rcx` means `rdx
:= rdx - rcx`.
So in the MSVC example `rdx` and `rcx` hold the arguments on entry.
The gcc example uses AT&T syntax, where e.g. `movq %rsi, %rax` means
`rax := rsi`. I.e. the opposite order of the instruction arguments.
So in the gcc example `rsi` and `rdi` hold the arguments on entry.
One can tell gcc (or at least g++) to use the less noisy and more
conventional, in short more reasonable, Intel syntax via option
`-masm=intel`, unless I recall the details of that incorrectly.
Cheers,
- Alf
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2021-06-07 14:53 +0000 |
| Message-ID | <3qqvI.644877$2A5.197149@fx45.iad> |
| In reply to | #80201 |
"Alf P. Steinbach" <alf.p.steinbach@gmail.com> writes: >On 6 Jun 2021 22:27, Vir Campestris wrote: > >One can tell gcc (or at least g++) to use the less noisy and more >conventional, in short more reasonable, Intel syntax via option >`-masm=intel`, unless I recall the details of that incorrectly. Purely a matter of opinion. Probably depends on what world you came from - Unix people prefer the AT&T syntax, DOS/Windows people prefer the Intel syntax. Personally, I detest the Intel syntax with passion.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2021-06-07 18:02 +0200 |
| Message-ID | <s9lfup$mhs$1@dont-email.me> |
| In reply to | #80214 |
> Personally, I detest the Intel syntax with passion. That's a matter of habituation.
[toc] | [prev] | [next] | [standalone]
| From | Vir Campestris <vir.campestris@invalid.invalid> |
|---|---|
| Date | 2021-06-16 21:38 +0100 |
| Message-ID | <sadng1$lqq$1@dont-email.me> |
| In reply to | #80201 |
On 06/06/2021 23:22, Alf P. Steinbach wrote: > > Possibly you've assumed that the examples are expressed with the same > syntax. > > The MSVC example uses Intel syntax, where e.g. `sub rdx, rcx` means `rdx > := rdx - rcx`. > > So in the MSVC example `rdx` and `rcx` hold the arguments on entry. > > The gcc example uses AT&T syntax, where e.g. `movq %rsi, %rax` means > `rax := rsi`. I.e. the opposite order of the instruction arguments. > > So in the gcc example `rsi` and `rdi` hold the arguments on entry. > > One can tell gcc (or at least g++) to use the less noisy and more > conventional, in short more reasonable, Intel syntax via option > `-masm=intel`, unless I recall the details of that incorrectly. Ah, that explains it all. Except why the GCC/ARM disassembly I occasionally look at in my day job is in Intel order... Thanks Andy
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2021-06-07 14:52 +0000 |
| Message-ID | <UoqvI.644876$2A5.503545@fx45.iad> |
| In reply to | #80199 |
Vir Campestris <vir.campestris@invalid.invalid> writes:
>On 05/06/2021 11:53, Bonita Montero wrote:
>> Consider the following code:
>>
>>
>> size_t s( int *begin, int *end )
>> {
>> return (end - begin) * sizeof(int);
>> }
>>
>> This is MSVC's disassembly:
>>
>> sub rdx, rcx
>> and rdx, -4
>> mov rax, rdx
>> ret 0
>>
>> This is gcc's disassembly:
>>
>> movq %rsi, %rax
>> subq %rdi, %rax
>> ret
>>
>> It the masking really necessary or just an optimizer weakness;
>> it seems to me MSVC sees that two bits are shifted out and "in"
>> and replaces this with a mask.
>> I think that the language-standard assumes equally aligned data
>> among same types for the above code and gcc is corcect, but I'm
>> not sure.
>>
>I've gone through the whole thread, and nobody else has commented.
>
>That GCC disassembly can't possibly be a correct and complete rendition
>of the function.
The first input parameter is passed in %rdi, the second in %rsi and
the result is returned in %rax. That's the normal ABI on linux.
[toc] | [prev] | [standalone]
Page 8 of 8 — ← Prev page 1 2 3 4 5 6 7 [8]
Back to top | Article view | comp.lang.c++
csiph-web