> On Aug 18, 2023, at 12:00 PM, Qing Zhao via Gcc-patches
> wrote:
>
>
>
>> On Aug 17, 2023, at 5:32 PM, Siddhesh Poyarekar wrote:
>>
>> On 2023-08-17 17:25, Qing Zhao wrote:
It's not exactly the same issue, the earlier discussion was about choosing
sizes in the same pass while
> On Aug 17, 2023, at 5:32 PM, Siddhesh Poyarekar wrote:
>
> On 2023-08-17 17:25, Qing Zhao wrote:
>>> It's not exactly the same issue, the earlier discussion was about choosing
>>> sizes in the same pass while the current one is about choosing between
>>> passes, but I agree it "rhymes".
On 2023-08-17 17:25, Qing Zhao wrote:
It's not exactly the same issue, the earlier discussion was about choosing sizes in the
same pass while the current one is about choosing between passes, but I agree it
"rhymes". This is what I was alluding to originally (for OST_MINIMUM use
MIN_EXPR if
> On Aug 17, 2023, at 4:57 PM, Siddhesh Poyarekar wrote:
>
> On 2023-08-17 16:23, Qing Zhao wrote:
Then, I think whatever MIN or MAX, the early phase has more precise
information than the later phase, we should use its result if it’s NOT
UNKNOWN?
>>>
>>> We can't be sure
On 2023-08-17 16:23, Qing Zhao wrote:
Then, I think whatever MIN or MAX, the early phase has more precise information
than the later phase, we should use its result if it’s NOT UNKNOWN?
We can't be sure about that though, can we? For example for something like
this:
struct S
{
int a;
> On Aug 17, 2023, at 3:59 PM, Siddhesh Poyarekar wrote:
>
> On 2023-08-17 15:27, Qing Zhao wrote:
>>> Yes, that's it. Maybe it's more correct if instead of MAX_EXPR if for
>>> OST_MINIMUM we stick with the early_objsz answer if it's non-zero. I'm not
>>> sure if that's the case for
On 2023-08-17 15:27, Qing Zhao wrote:
Yes, that's it. Maybe it's more correct if instead of MAX_EXPR if for
OST_MINIMUM we stick with the early_objsz answer if it's non-zero. I'm not
sure if that's the case for maximum size though, my gut says it isn't.
So, the major purpose for adding the
> On Aug 17, 2023, at 1:49 PM, Siddhesh Poyarekar wrote:
>
> On 2023-08-17 09:58, Qing Zhao wrote:
>>> So this is a (sort of) known issue, which necessitated the early_objsz pass
>>> to get an estimate before a subobject reference was optimized to a MEM_REF.
>> Do you mean that after a
On 2023-08-17 09:58, Qing Zhao wrote:
So this is a (sort of) known issue, which necessitated the early_objsz pass to
get an estimate before a subobject reference was optimized to a MEM_REF.
Do you mean that after a subobject reference was optimized to a MEM_REF, there
is no way to compute
> On Aug 17, 2023, at 7:00 AM, Siddhesh Poyarekar wrote:
>
> On 2023-08-16 11:59, Qing Zhao wrote:
>> Jakub and Sid,
>> During my study, I found an interesting behavior for the following small
>> testing case:
>> #include
>> #include
>> struct fixed {
>> size_t foo;
>> char b;
>> char
On 2023-08-16 11:59, Qing Zhao wrote:
Jakub and Sid,
During my study, I found an interesting behavior for the following small
testing case:
#include
#include
struct fixed {
size_t foo;
char b;
char array[10];
} q = {};
#define noinline __attribute__((__noinline__))
static void
FYI, I filed a new PR https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111040
to record this issue.
Qing
> On Aug 16, 2023, at 11:59 AM, Qing Zhao via Gcc-patches
> wrote:
>
> Jakub and Sid,
>
> During my study, I found an interesting behavior for the following small
> testing case:
>
>
Jakub and Sid,
During my study, I found an interesting behavior for the following small
testing case:
#include
#include
struct fixed {
size_t foo;
char b;
char array[10];
} q = {};
#define noinline __attribute__((__noinline__))
static void noinline bar ()
{
struct fixed *p =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95349
--- Comment #44 from Andrew Downing ---
(In reply to Richard Biener from comment #43)
> (In reply to Andrew Downing from comment #41)
> > > Thus for types without a non-trivial ctor/dtor you do not need to use
> > > placement new. So take your
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95349
--- Comment #43 from Richard Biener ---
(In reply to Andrew Downing from comment #41)
> > Thus for types without a non-trivial ctor/dtor you do not need to use
> > placement new. So take your example and remove the placement new.
> > Does that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95349
--- Comment #42 from Richard Biener ---
See PR101641 for an interesting case where eliding a round-trip causes
wrong-code generation. It's union related so might not apply 1:1 to C++.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95349
--- Comment #41 from Andrew Downing ---
> Thus for types without a non-trivial ctor/dtor you do not need to use
> placement new. So take your example and remove the placement new.
> Does that change its semantics?
These are C++17 rules.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95349
--- Comment #40 from rguenther at suse dot de ---
On Mon, 15 Jun 2020, richard-gccbugzilla at metafoo dot co.uk wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95349
>
> --- Comment #37 from Richard Smith
> ---
> (In reply to Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95349
--- Comment #39 from rguenther at suse dot de ---
On Tue, 16 Jun 2020, andrew2085 at gmail dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95349
>
> --- Comment #38 from Andrew Downing ---
> > int *p;
> > int x;
> > if ()
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95349
--- Comment #38 from Andrew Downing ---
> int *p;
> int x;
> if ()
>p =
> else
>p = malloc (4);
> memcpy (p, q, 4);
>
> there is a single memcpy call and the standard says that both the dynamic
> type transfers (from q) and that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95349
--- Comment #37 from Richard Smith
---
(In reply to Richard Biener from comment #36)
> The main issue I see is that this differing expectations of C and C++ are
> impossible to get correct at the same time.
That is a rather bold claim. I think
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95349
--- Comment #36 from Richard Biener ---
(In reply to Andrew Downing from comment #35)
> I agree that the new implicit object creation rules sound very difficult to
> implement correctly especially because the behavior in C is different. I'm
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95349
--- Comment #35 from Andrew Downing ---
I agree that the new implicit object creation rules sound very difficult to
implement correctly especially because the behavior in C is different. I'm
curious to see how that will all play out.
In this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95349
--- Comment #34 from Richard Biener ---
(In reply to Andrew Downing from comment #33)
> Those are all perfectly good arguments, but the problem ended up not having
> anything to do with std::launder or new implicit object creation rules or
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95349
--- Comment #33 from Andrew Downing ---
Those are all perfectly good arguments, but the problem ended up not having
anything to do with std::launder or new implicit object creation rules or
anything else introduced in the most recent standards
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95349
--- Comment #32 from rguenther at suse dot de ---
On Thu, 4 Jun 2020, andrew2085 at gmail dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95349
>
> --- Comment #31 from Andrew Downing ---
> What would you say is the solution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95349
--- Comment #31 from Andrew Downing ---
What would you say is the solution here? There's a disconnect between what the
c++ standard says should work, and what actually works.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95349
--- Comment #30 from Richard Biener ---
(In reply to Andrew Downing from comment #29)
> So I think this sort of equivalent example in C shows what's going wrong in
> the C++ example. https://godbolt.org/z/ZMz4Cp
>
> gcc knows that if the object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95349
--- Comment #29 from Andrew Downing ---
So I think this sort of equivalent example in C shows what's going wrong in the
C++ example. https://godbolt.org/z/ZMz4Cp
gcc knows that if the object mem points to is modified inside pun() its
effective
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95349
--- Comment #28 from Andrew Downing ---
Hey that's cheating, but yea the second part did it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95349
--- Comment #27 from rguenther at suse dot de ---
On June 2, 2020 6:34:12 PM GMT+02:00, andrew2085 at gmail dot com
wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95349
>
>--- Comment #25 from Andrew Downing ---
>Do you know how to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95349
--- Comment #26 from Andrew Downing ---
I mean without modifying the definition of start_lifetime_as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95349
--- Comment #25 from Andrew Downing ---
Do you know how to change that example so that gcc's knowledge is incomplete
and it not longer does the correct thing?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95349
--- Comment #24 from rguenther at suse dot de ---
On Tue, 2 Jun 2020, andrew2085 at gmail dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95349
>
> --- Comment #23 from Andrew Downing ---
> But gcc already can implement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95349
--- Comment #23 from Andrew Downing ---
But gcc already can implement std::start_lifetime_as with no overhead.
https://godbolt.org/z/YdoEcH
My intent wasn't to draw attention to std::start_lifetime_as in this bug
report, I only mentioned it as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95349
--- Comment #22 from Richard Biener ---
(In reply to Richard Smith from comment #20)
> (In reply to Andrew Downing from comment #19)
> > Not that it would make a difference in this particular situation, but is the
> > intent of P0593R6 to only
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95349
--- Comment #21 from Richard Biener ---
(In reply to Andrew Downing from comment #15)
> This is all kind of besides the point anyway though, because gcc is handling
> everything ok except for std::launder. std::launder is only supposed to be
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95349
--- Comment #20 from Richard Smith
---
(In reply to Andrew Downing from comment #19)
> Not that it would make a difference in this particular situation, but is the
> intent of P0593R6 to only allow implicitly creating an object in the
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95349
--- Comment #19 from Andrew Downing ---
Not that it would make a difference in this particular situation, but is the
intent of P0593R6 to only allow implicitly creating an object in the relevant
storage location where one hasn't already been
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95349
--- Comment #18 from Richard Smith
---
(In reply to Andrew Downing from comment #17)
> Also none of the behavior described in p0593 is required for this C++
> program to be well defined. All objects that are required to exists here are
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95349
--- Comment #17 from Andrew Downing ---
Also none of the behavior described in p0593 is required for this C++ program
to be well defined. All objects that are required to exists here are created
explicitly. It's not relying on the implicit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95349
--- Comment #16 from Richard Smith
---
Per p0593, memcpy implicitly creates objects (of any implicit lifetime type) in
the destination. It does not propagate the objects in the source memory to the
destination memory, and can therefore be used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95349
--- Comment #15 from Andrew Downing ---
(In reply to Richard Biener from comment #10)
> (In reply to Andrew Downing from comment #8)
> > From the C standard:
> > If a value is copied into an object having no declared type using memcpy or
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95349
--- Comment #14 from rguenther at suse dot de ---
On Fri, 29 May 2020, ed at catmur dot uk wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95349
>
> --- Comment #12 from Ed Catmur ---
> (In reply to Richard Biener from comment #11)
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95349
Jonathan Wakely changed:
What|Removed |Added
CC||richard-gccbugzilla@metafoo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95349
--- Comment #12 from Ed Catmur ---
(In reply to Richard Biener from comment #11)
> Note that for C++ types you can apply memcpy to the placement new is not
> needed since object re-use terminates lifetime of the previous object and
> starts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95349
--- Comment #11 from Richard Biener ---
(In reply to Ed Catmur from comment #9)
> (In reply to Jonathan Wakely from comment #4)
> > I don't know the answer, and I don't know why it's useful to try this
> > anyway.
>
> If I'm reading P0593
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95349
--- Comment #10 from Richard Biener ---
(In reply to Andrew Downing from comment #8)
> From the C standard:
> If a value is copied into an object having no declared type using memcpy or
> memmove, or is copied as an array of character type, then
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95349
--- Comment #9 from Ed Catmur ---
(In reply to Jonathan Wakely from comment #4)
> I don't know the answer, and I don't know why it's useful to try this anyway.
If I'm reading P0593 correctly (I may not be), this would be a valid
implementation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95349
--- Comment #8 from Andrew Downing ---
>From the C standard:
If a value is copied into an object having no declared type using memcpy or
memmove, or is copied as an array of character type, then the effective type of
the modified object for that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95349
--- Comment #7 from Andrew Downing ---
(In reply to Jonathan Wakely from comment #6)
> (In reply to Andrew Downing from comment #5)
> > Also, I'm not sure if operations that implicitly create
> > objects in storage are allowed to do so if an
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95349
--- Comment #6 from Jonathan Wakely ---
(In reply to Andrew Downing from comment #5)
> Also, I'm not sure if operations that implicitly create
> objects in storage are allowed to do so if an object has already explicitly
> created in that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95349
--- Comment #5 from Andrew Downing ---
(In reply to Richard Biener from comment #1)
> I think std::launder merely acts as optimization barrier here and without we
> manage to propagate the constant. We still "miscompile" things dependent on
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95349
--- Comment #4 from Jonathan Wakely ---
I don't know the answer, and I don't know why it's useful to try this anyway.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95349
--- Comment #3 from rguenther at suse dot de ---
On Wed, 27 May 2020, redi at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95349
>
> --- Comment #2 from Jonathan Wakely ---
> Using
>
> auto t = new(p)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95349
--- Comment #2 from Jonathan Wakely ---
Using
auto t = new(p) std::uint64_t;
std::memcpy(t, std::launder(storage), sizeof(storage));
return t;
also prevents GCC from propagating the dynamic type of p to t.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95349
Richard Biener changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95349
Bug ID: 95349
Summary: Using std::launder(p) produces unexpected behavior
where (p) produces expected behavior
Product: gcc
Version: 10.1.0
Status: UNCONFIRMED
Mohamed Shafi wrote:
2008/7/15 Ramana Radhakrishnan [EMAIL PROTECTED]:
snipped parts of the last mail
I agree with you, but what about when there are still caller save
register are available and there are no register restrictions for any
instructions? In my case i find that GCC has used
Hello all,
I am not sure if this the right mailing list.
I am involved in the porting of gcc 4.1.2 for a 16 bit target.
In some cases i noticed that callee save registers were getting
allocated in the body even though there isn't any function call. I
believe that callee save registers will be
Hi Mohamed,
Why not ? Callee save registers are after all registers and the split
is in the ABI's head (so to speak). So GCC is well within its right to
use callee save registers. In fact if you were in a leaf function that
did not make any function calls the first preference would be to
2008/7/15 Ramana Radhakrishnan [EMAIL PROTECTED]:
Hi Mohamed,
Why not ? Callee save registers are after all registers and the split
is in the ABI's head (so to speak). So GCC is well within its right to
use callee save registers. In fact if you were in a leaf function that
did not make any
snipped parts of the last mail
I agree with you, but what about when there are still caller save
register are available and there are no register restrictions for any
instructions? In my case i find that GCC has used only the argument
registers, stack pointer and callee saved registers. So
2008/7/15 Ramana Radhakrishnan [EMAIL PROTECTED]:
snipped parts of the last mail
I agree with you, but what about when there are still caller save
register are available and there are no register restrictions for any
instructions? In my case i find that GCC has used only the argument
Hello,
Consider the following test case:
struct A { bool g(int*, int*) __attribute__((nonnull (2))); };
bool A::g(int* a, int* b) {
if (a)
return 0;
return this;
}
G++ produces the following code for this snippet:
;; Function bool A::g(int*, int*) (_ZN1A1gEPiS0_)
bool A::g(int*,
Steven Bosscher wrote:
The documentation of the nonnull attribute says:
`nonnull (ARG-INDEX, ...)'
The `nonnull' attribute specifies that some function parameters
should be non-null pointers. For instance, the declaration:
extern void *
my_memcpy (void
Steven Bosscher wrote:
That is why I was looking at this. We have http://gcc.gnu.org/PR27336,
and part of the fix could be to make the 'this' pointer always
non-NULL. So far I haven't found anyone who can think of a situation
where 'this' can be NULL...
It can't be NULL. (There are ways to
67 matches
Mail list logo
