Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gonzalobg88 at gmail dot com
Target Milestone: ---
Example:
union __attribute__((transparent_union)) U {
int* a;
~U() {}
};
fails with:
:1:43: error: type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92287
--- Comment #9 from gnzlbg ---
> sparc is another, for example. And or1k, too.
Yeah, I was wrong. x86/x64, arm32/64, aarch64, riscv, ppc64, mips64, ... are
some of the ABIs that do not have any of these issues because they special case
"all
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92287
gnzlbg changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92287
--- Comment #4 from gnzlbg ---
Thanks for chiming in. I see the value in having a simple ABI rule. I guess
what confuses me is that the address passed in the calling convention for that
struct will never be used for anything or dereferenced.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92287
--- Comment #2 from gnzlbg ---
> I can only speak for msp430, but there's no problem with that generated
> assembly. Structures and unions are always passed by reference.
I suppose that by this you mean that the current behavior is "by
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: gonzalobg88 at gmail dot com
Target Milestone: ---
Consider this code:
struct foo {};
int id_foo(struct foo bar, int x) {
return x;
}
int id(int x) {
return x;
}
This link shows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88662
--- Comment #12 from gnzlbg ---
> I disagree. Once it's documented, people will rely on it and scream if it
> changes. Caveats about something maybe changing in future don't help. If it's
> documented to behave one way today, people will
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88662
--- Comment #10 from gnzlbg ---
> But it constrains GCC in future, which leaving it unspecified does not.
Documenting whether GCC's C _Bool has the same valid and trap representations
as the target platform's ABI specifies is a trade-off: it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88662
--- Comment #8 from gnzlbg ---
> I think it should be sufficient to either mention which types have padding
> bits,
I am not sure. An intrinsic that tells me that _Bool has 7 padding bits does
not provide me with any new information. The C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88662
--- Comment #6 from gnzlbg ---
> Why do you need more than that?
I'm reading raw data from a file which supposedly contains _Bool's and I'd like
to validate it (the _Bools could have been written to the file by a program
compiled with a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88662
--- Comment #4 from gnzlbg ---
Without that information, how does one know which values can a valid program
write to a `_Bool` via a `char*`?
AFAIK the C standard guarantees that 0x0 must be a valid representation of
_Bool, but there are no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88662
--- Comment #2 from gnzlbg ---
> Because (unsigned int)b is undefined otherwise.
AFAICT this is only undefined behavior iff `b` has a trap representation.
Assignee: unassigned at gcc dot gnu.org
Reporter: gonzalobg88 at gmail dot com
Target Milestone: ---
Compiling
unsigned int foo(unsigned int x, _Bool b) {
return x - (unsigned int)b;
}
only produces correct results if the value of `_Bool` is either `0` or `1` [0],
see https
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gonzalobg88 at gmail dot com
Target Milestone: ---
I am trying to implementing P0901r0 [0] in jemalloc. The signature of the new
memory allocation function looks like this:
typedef struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86483
gnzlbg changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86483
--- Comment #4 from gnzlbg ---
@Jonathan Wakely:
> If you tell the compiler the storage is smaller than 'usize' you're asking it
> to treat accesses past 'size' bytes as undefined behaviour (even though
> actually accesses up to usize are
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86483
--- Comment #2 from gnzlbg ---
The same applies to the alloc_align attribute.
It also does not seem possible to specify alloc_align for some flag parameter
that contains a masked alignment. For example:
smallocx_return_t je_smallocx(size_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86483
--- Comment #1 from gnzlbg ---
The same applies to the malloc attribute.
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gonzalobg88 at gmail dot com
Target Milestone: ---
I am trying to implementing P0901r0 [0] in jemalloc. The signature of the new
memory allocation function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79452
--- Comment #8 from gnzlbg ---
Eric your concerns and suggestions make sense. Changing the signature of the
functions using something like __ctfe__ and probably anything that would use
those sounds like a major ABI breaking change though. I do
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79452
--- Comment #6 from gnzlbg ---
> I wasn't replying to the part about function aliases, I was replying to the
> part about having the built-in work even when used in a non-constexpr
> function. It sounds like what you're suggesting would depend
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79452
--- Comment #3 from gnzlbg ---
I guess I should have written, "How does this feature make ODR violations more
common than the inline keyword?". Which new perils does it introduce?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79452
--- Comment #2 from gnzlbg ---
> It's already in C++17 and supported by GCC.
The following program is ill-formed in C++17:
int main() {
if constexpr() { // Error: expression missing in if condition
return 1;
}
return 0;
}
> That
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gonzalobg88 at gmail dot com
Target Milestone: ---
The run-time performance of constexpr functions is often sub-optimal, because
the optimal algorithm cannot be expressed within the capabilities of C++'s
constexpr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56400
Bug #: 56400
Summary: Lambda's this pointer are not initialized inside
template classes
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56402
Bug #: 56402
Summary: Lambda's this pointer are not initialized inside
template classes
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56401
Bug #: 56401
Summary: Lambda's this pointer are not initialized inside
template classes
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56400
--- Comment #1 from gnzlbg gonzalobg88 at gmail dot com 2013-02-19 20:50:10
UTC ---
Please delete, the report was submitted multiple times accidentaly (the right
one is http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56402).
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56401
--- Comment #1 from gnzlbg gonzalobg88 at gmail dot com 2013-02-19 20:50:19
UTC ---
Please delete, the report was submitted multiple times accidentaly (the right
one is http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56402).
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56402
--- Comment #1 from gnzlbg gonzalobg88 at gmail dot com 2013-02-19 20:52:55
UTC ---
To get the program to compile one has to comment out the second lambda which
makes the compiler crash.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47226
gnzlbg gonzalobg88 at gmail dot com changed:
What|Removed |Added
CC||gonzalobg88
31 matches
Mail list logo
