public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Florian Weimer <fweimer@redhat.com>
To: Paul Eggert <eggert@cs.ucla.edu>, Joseph Myers <joseph@codesourcery.com>
Cc: gcc-patches@gcc.gnu.org
Subject: Re: Make max_align_t respect _Float128 [version 2]
Date: Wed, 07 Sep 2016 09:22:00 -0000	[thread overview]
Message-ID: <ceebdce8-a1e8-fc66-0eff-a343711ae3d4@redhat.com> (raw)
In-Reply-To: <531b9447-2f95-0714-dfc9-6b419efe1ab9@cs.ucla.edu>

On 09/06/2016 11:31 PM, Paul Eggert wrote:
> On 09/06/2016 01:40 PM, Joseph Myers wrote:
>> Sounds like a defect in C11 to me - none of the examples of flexible
>> array
>> members anticipate needing to add to the size to allow for tail padding
>> with unknown alignment requirements.
>
> Yes, I would prefer calling it a defect, as most code I've seen dealing
> with flexible array members does not align the tail size. However, GCC +
> valgrind does take advantage of this "defect" and I would not be
> surprised if other picky implementations do too.

It might be an inherent limitation of the valgrind approach. 
Speculative loads which cannot result in data races (in the C11 sense) 
due to the way the architecture behaves should be fine.  The alignment 
ensures that the load is on the same page, which is what typically 
prevent this optimization.

Some implementation techniques for C string functions result in the same 
behavior.  valgrind intercepts them or suppresses errors there, but 
that's not possible for code that GCC emits inline, obviously.

valgrind would still treat the bytes beyond the allocation boundary as 
undefined.  But I agree that false positives in this area are annoying.

Florian

  reply	other threads:[~2016-09-07  9:15 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-26 20:55 Make max_align_t respect _Float128 Joseph Myers
2016-08-26 21:10 ` Marc Glisse
2016-08-26 21:30   ` Joseph Myers
2016-08-26 21:45 ` Florian Weimer
2016-08-26 21:57   ` Paul Eggert
2016-08-26 22:25   ` Joseph Myers
2016-08-26 21:51 ` Paul Eggert
2016-08-29 13:29   ` Marek Polacek
2016-08-29 15:40     ` Joseph Myers
2016-09-01 14:18 ` Ping " Joseph Myers
2016-09-05 17:07 ` Make max_align_t respect _Float128 [version 2] Joseph Myers
2016-09-06  9:06   ` Richard Biener
2016-09-06 11:26     ` Joseph Myers
2016-09-06  9:19   ` Florian Weimer
2016-09-06  9:24     ` Richard Biener
2016-09-07  7:45       ` Florian Weimer
2016-09-07 17:53         ` Joseph Myers
2016-09-08  9:35           ` Florian Weimer
2016-09-06 11:40     ` Joseph Myers
2016-09-06 15:06       ` Florian Weimer
2016-09-06 15:20         ` Joseph Myers
2016-09-06 15:59           ` Paul Eggert
2016-09-06 20:47             ` Joseph Myers
2016-09-06 21:41               ` Paul Eggert
2016-09-07  9:22                 ` Florian Weimer [this message]
2016-09-07 11:52                   ` Mark Wielaard
2016-09-08  1:58                     ` Paul Eggert
2016-09-08 11:58                       ` Mark Wielaard
2016-09-08 12:22                         ` Florian Weimer
2016-09-08 14:59                         ` Paul Eggert
2016-09-08 12:30                       ` Bernd Schmidt
2016-09-08 12:34                         ` Florian Weimer
2016-09-07  9:15               ` Florian Weimer
2016-09-06 21:03           ` Jason Merrill
2016-09-06 21:18             ` Joseph Myers
2016-09-06 21:53               ` Jason Merrill
2016-09-06 21:56                 ` Joseph Myers
2016-09-06 12:06     ` Bernd Schmidt
2016-09-06 14:59       ` Florian Weimer
2016-09-12 18:02   ` Make max_align_t respect _Float128 [version 3] Joseph Myers
2016-09-19 16:08     ` Ping " Joseph Myers
2016-09-19 17:11       ` Paul Eggert
2016-09-26 16:35       ` Jeff Law
2016-09-06 18:14 Make max_align_t respect _Float128 [version 2] Bernd Edlinger
2016-09-06 20:58 ` Joseph Myers
2016-09-07 19:50 Bernd Edlinger
2016-09-07 20:06 ` Joseph Myers
2016-09-07 21:00   ` Bernd Edlinger
2016-09-07 21:48     ` Joseph Myers
2016-09-08 10:50 ` Florian Weimer
2016-09-09 17:24   ` Bernd Edlinger

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ceebdce8-a1e8-fc66-0eff-a343711ae3d4@redhat.com \
    --to=fweimer@redhat.com \
    --cc=eggert@cs.ucla.edu \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=joseph@codesourcery.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).