[Bug libstdc++/69879] New: Create a pointer to the default operator new and delete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69879
Bug ID: 69879
Summary: Create a pointer to the default operator new and
delete
Product: gcc
Version: 5.2.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: daniel.gutson at tallertechnologies dot com
Target Milestone: ---
This issue comes from the following discussion:
https://gcc.gnu.org/ml/libstdc++/2015-11/msg9.html
In short: Pedro Alves suggested as a solution the addition of a pointer to the
original (default) operator new and another for the operator delete, e.g.
__default_operator_new and __default_operator_delete.
This will allow users to override the global operators new and delete, and yet
call the original implementations, for example to alter the behavior when there
is no memory and the nothrow new should not iterate calling the new_handler.
// Example 1:
void* operator new ( std::size_t count, const std::nothrow_t& tag)
noexcept(true)
{
const auto old_handler = std::set_new_handler(nullptr);
const auto ret = __default_operator_new(count, tag);
std::set_new_handler(old_handler);
return ret;
}
// Slightly different example:
void* operator new ( std::size_t count, const std::nothrow_t& tag)
noexcept(true)
{
const auto old_handler = std::set_new_handler(nullptr);
const auto ret = __default_operator_new(count, tag);
std::set_new_handler(old_handler);
if (ret == nullptr && old_handler != nullptr)
old_handler();
return ret;
}
Please assign this to aurelio.remo...@tallertechnologies.com
[Bug libstdc++/69879] Create a pointer to the default operator new and delete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69879 --- Comment #1 from Daniel Gutson --- Remind to consider all the overloads (throwing, nothrow, etc.) which will require different names.
[Bug middle-end/69976] New: Zero the local stack on function exit; don't optimize out memset before return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69976 Bug ID: 69976 Summary: Zero the local stack on function exit; don't optimize out memset before return Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: daniel.gutson at tallertechnologies dot com Target Milestone: --- Existing security practices recommend to the arrays of automatic storage duration (e.g. by zeroing them) upon function exit. This could be done by calling memset; however, gcc seems to optimize out the call to memset before the return statement (or when the memset call is the last statement). This forces secure-sensitive applications to implement their own memset, usually a copy of it. I suggest the following enhancement: -provide two new attributes: 'clear_stack' and 'allow_ending_memset' -provide two new flags: -fclear-stack and -Wdirty-stack -logic: by using -fclear-stack, the following modes can be specified: -fclear-stack=none: current behavior, memset is optimized out -fclear-stack=attribute: user controls the behavior per function basis by using the attributes; 'clear_stack' causes gcc to add the memset call at the end of the function (no control flow analysis recommended), whereas 'allow_ending_memset' prevents gcc to optimize out the call to memset enabling the user to call it. Specifying both attributes in the same function should not be allowed. -fclear-stack=auto: instructs gcc to emit a call to memset at the end of functions having arrays of automatic storage duration (zeroing those arrays only). The 'clear_stack' attribute can be used in this mode to force the stack zeroing on particular functions overriding the decision logic -fclear-stack=always: instructs gcc to emit a call to memset at the end of every function having a nonempty stack. -Wdirty-stack: only to be used with -fclear-stack=attribute, causes gcc to emit a warning message when a function has at least an array of static storage duration but is not zeroed at the end (either because 'clear_stack' wasn't specified or because there is no memset call statement; control flow analysis similar to the one used by detecting paths with no return statement on non void-return functions could be used). Please assign this to andres.tirabos...@tallertechnologies.com
[Bug middle-end/69976] Zero the local stack on function exit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69976 --- Comment #3 from Daniel Gutson --- Those are very good ideas but fell into the land of the backend. The red zone IIUC is a x86_64 only ABI concept. What do you think about adding also a -m counterpart option with the same semantic but for the backend? Our plan is to address separately the middle end part and the backend part (initially for x86_64) and subdivide the latter in clobbered registers and red zone cleaning, so 3 sets of patches.
[Bug libstdc++/69879] Create a pointer to the default operator new and delete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69879 --- Comment #4 from Daniel Gutson --- BTW, please reassign this to gabriel.iba...@tallertechnologies.com since Aurelio is still working on qemu. Sorry for the inconveniences.
[Bug c++/70201] New: Dump C++ template instantiations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70201 Bug ID: 70201 Summary: Dump C++ template instantiations Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: daniel.gutson at tallertechnologies dot com Target Milestone: --- Add a -fdump-template-instantiations option in order to dump the C++ template instantiations. Please assign this to andres.tirabos...@tallertechnologies.com .
[Bug c++/70201] Dump C++ template instantiations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70201 --- Comment #2 from Daniel Gutson --- (In reply to Jonathan Wakely from comment #1) > What do you plan to implement? It would be better to produce output > compatible with Templight (http://plc.inf.elte.hu/templight/) rather than a > GCC-specific dump. Actually I planned to implement the human-friendly format that gcc currently outputs when an instantiation fails [with T=...], which I think it will be useful for most users; however I admit that hving templight support is interesting. So I propose to implement -fdump-template-instantations=human or alike, leaving the code cleanly ready to add other dump formats (such as =templight) or =plugin to enable user-defined dump formats (so templight could be implemented as one). What do you think?
[Bug c++/70584] New: constexpr variables cannot be used as intrinsic arguments where an immediate is expected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70584
Bug ID: 70584
Summary: constexpr variables cannot be used as intrinsic
arguments where an immediate is expected
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: daniel.gutson at tallertechnologies dot com
Target Milestone: ---
Created attachment 38216
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38216&action=edit
test case
The following code causes gcc to complain that the last argument should be an
8-bit immediate value:
#include
int main()
{
__m128i r;
constexpr auto index = 1;
r = _mm_aeskeygenassist_si128(r, index);
}
This fails with -O0 but not with -O3.
The arguments to reproduce the issue are:
g++ -std=c++14 -msse -msse2 -maes -O0 tst.cpp -o tst
I attached the code anyway.
FWIW, this works in clang both for -O0 and for -O3. I think that constexpr
variables should be valid immediate arguments.
This bug affects the development of template metaprograms.
If there is agreement that this should be fixed, feel free to assign this to
andres.tirabos...@tallertechnologies.com .
[Bug c++/70584] constexpr variables cannot be used as intrinsic arguments where an immediate is expected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70584
--- Comment #1 from Daniel Gutson
---
Additional data: an enumerator works:
int main()
{
__m128i r;
//constexpr auto index = 1;
enum { index = 1 };
r = _mm_aeskeygenassist_si128(r, index);
}
[Bug c++/70606] New: new warning for unicode quotes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70606 Bug ID: 70606 Summary: new warning for unicode quotes Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: daniel.gutson at tallertechnologies dot com Target Milestone: --- This issue is created from the discussion here: https://gcc.gnu.org/ml/gcc/2016-03/msg00260.html (please note that the thread continues in April). Basically, we want gcc to emit a specific message when unicode quotes are used. Somebody of us will solve this issue during next week, once we decide who, I will add a comment so the assignee can be updated.
[Bug c++/70584] constexpr variables cannot be used as intrinsic arguments where an immediate is expected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70584 --- Comment #4 from Daniel Gutson --- Thanks Martin. Andres is finishing 70210 soon next week, and he can address this after solving it. Feel free to assign this issue to him (andres.tirabos...@tallertechnologies.com).
[Bug c++/70584] constexpr variables cannot be used as intrinsic arguments where an immediate is expected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70584 --- Comment #5 from Daniel Gutson --- (In reply to Daniel Gutson from comment #4) > Thanks Martin. > > Andres is finishing 70210 soon next week, and he can address this after s/70210/70201/ > solving it. Feel free to assign this issue to him > (andres.tirabos...@tallertechnologies.com).
[Bug target/70612] New: -mtune=native -maes does not detect that AES is not present
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70612 Bug ID: 70612 Summary: -mtune=native -maes does not detect that AES is not present Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: daniel.gutson at tallertechnologies dot com Target Milestone: --- I didn't investigate this, but despite /proc/cpuinfo does not list aes as a capability, I think that the combination -mtune=native -maes should fail.
[Bug target/70612] -mtune=native -maes does not detect that AES is not present
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70612 Daniel Gutson changed: What|Removed |Added Severity|normal |enhancement --- Comment #2 from Daniel Gutson --- My bad, I meant -march. But in case this is not a bug, I still think we could do better at least with a warning.
[Bug c/70742] New: Add a builtin for obtaining a quotient and remainder of an integer division
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70742 Bug ID: 70742 Summary: Add a builtin for obtaining a quotient and remainder of an integer division Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: daniel.gutson at tallertechnologies dot com Target Milestone: --- Created attachment 38318 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38318&action=edit example with disassembly listing This idea has been originated here https://sourceware.org/ml/libc-alpha/2016-04/msg00503.html and later from here https://sourceware.org/bugzilla/show_bug.cgi?id=19974 Due to suggestions in both the libc-alpha mailing list and in the glibc issue tracker, I created this issue here as a compiler enhencement. Basically the idea is to create the __builtin_div builtins family, so they finally get translated to a single asm insn (if available) that calculates both the quotient and the remainder. I attach the same file that is attached in the glibc's bug tracker. The goal is that std::div and cstdlib's div can be reimplemented as calling this builtin.
[Bug c/70742] Support div as a builtin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70742 --- Comment #2 from Daniel Gutson --- (In reply to Andrew Pinski from comment #1) > Let me reword the summary. what you want is div and ldiv and imaxdiv to be > supported as a builtin, in that it expands correctly to do the div/mod > inlined. > > >The goal is that std::div and cstdlib's div can be reimplemented as calling > >this builtin. > > Or rather they stay the way they are and GCC rewrites it to be correct. AKA > no reimplementing at all. That's correct, my bad: the goal is actually not touching the library at all.
[Bug c/70742] Support div as a builtin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70742 --- Comment #3 from Daniel Gutson --- (In reply to Andrew Pinski from comment #1) > Let me reword the summary. what you want is div and ldiv and imaxdiv to be and lldiv > supported as a builtin, in that it expands correctly to do the div/mod > inlined. > > >The goal is that std::div and cstdlib's div can be reimplemented as calling > >this builtin. > > Or rather they stay the way they are and GCC rewrites it to be correct. AKA > no reimplementing at all.
[Bug c/70742] Support div as a builtin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70742 --- Comment #4 from Daniel Gutson --- Please assign this to andres.tirabos...@tallertechnologies.com
[Bug c/70742] Support div as a builtin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70742
--- Comment #6 from Daniel Gutson
---
(In reply to Marc Glisse from comment #5)
> It seems to me that the reason we don't already have div as a builtin is
> that we need to know the layout of div_t.
>
> In a header, you don't really need inline asm:
> inline div_t div(int a, int b){ div_t q; q.quot=a/b; q.rem=a%b; return q; }
:) that was the whole discussion with the glibc maintainers: they don't want
inline functions. Please look at the discussions there, and consider to join.
[Bug c/70742] Support div as a builtin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70742 --- Comment #9 from Daniel Gutson --- Created attachment 38323 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38323&action=edit sample script to be called from the build system
[Bug c/70742] Support div as a builtin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70742 --- Comment #10 from Daniel Gutson --- (In reply to Marc Glisse from comment #8) > "The div, ldiv, and lldiv functions return a structure of type div_t, > ldiv_t, and lldiv_t, respectively, comprising both the quotient and the > remainder. The structures shall contain (in either order) the members quot > (the quotient) and rem (the remainder), each of which has the same type as > the arguments numer and denom." > > So while we know the names and types of the fields, we don't know their > order (unless stdlib.h was included). IIUC, this is a new situation that has never occurred before regarding builtins. If so, maybe a new mechanism should be developed, that we add a couple of offsetof(div_t) sometime during the building of gcc so the offsets are known by the builtins. IOW, some kind of script invoked by the build system that generates a header file containing the offsets of the members of the structure... Maybe something like the attachment (https://gcc.gnu.org/bugzilla/attachment.cgi?id=38323) Then, we include the generated header file (which contains the offsets) from the source file that implements the builtin. Would this be acceptable? I'm not sure what about the first time when bootstrapping, or when building a cross-compiler.
[Bug c++/60850] New: pedantic warning behavior when casting void* to ptr-to-func
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60850 Bug ID: 60850 Summary: pedantic warning behavior when casting void* to ptr-to-func Product: gcc Version: 4.8.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: daniel.gutson at tallertechnologies dot com Created attachment 32606 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32606&action=edit proposed fix #pragma GCC diagnostic ignore "-pedantic" doesn't work in cases such as: void* p = 0; #pragma GCC diagnostic ignored "-pedantic" F* f2 = reinterpret_cast(p); I tested the attached patch, and all passes plus the test case I added. Please consider to add the fix in 4.8.3. I don't have write access. Changelog: 2014-03-31 Daniel Gutson gcc/cp/ * typeck.c (build_reinterpret_cast_1): Pass proper argument to warn() in pedantic. gcc/testsuite/g++.dg/ * diagnostic/pedantic.C: New test case.
[Bug c++/60850] pedantic warning behavior when casting void* to ptr-to-func
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60850 --- Comment #2 from Daniel Gutson --- It went, but I got no answer. FWIW: http://gcc.gnu.org/ml/gcc-patches/2014-04/msg00026.html
[Bug c++/60850] pedantic warning behavior when casting void* to ptr-to-func
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60850 --- Comment #6 from Daniel Gutson --- Thanks Manuel. 1) I didn't see a warning regarding the old use of -pedantic rather than -Wpedantic 2) I'll change that, after the C++ FE maintainer sees the patch in order to not pollute the thread with more patches. I didn't know about the deprecation of -pedantic, thanks! And thanks for your encouraging words!
[Bug c++/61066] [4.8 Regression] Many testcase failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61066 --- Comment #5 from Daniel Gutson --- It seems some tests didn't run when I tested the patch, sorry about that. I'll try to run all the tests and update them as needed. I will post the new patch as soon as possible. Sorry for the inconveniences.
[Bug c++/61066] [4.8 Regression] Many testcase failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61066 --- Comment #7 from Daniel Gutson --- Sorry my lack of time. Thanks Jason.
[Bug libstdc++/58962] Pretty printers use obsolete Python syntax
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58962 --- Comment #3 from Daniel Gutson --- Please do not close this issue.(In reply to Bruce Merry from comment #1) > I've now realised that this is actually just the tip of the iceberg - I > suspect that libstdc++'s pretty printers aren't Python 3 ready, while Ubuntu > is shipping a gdb linked to libython 3.3. Feel free to close if this is as > expected. Please don't close this issue, it is completely relevant since not only for ubuntu but for other distros too. Syntax should work both with python versions 2 and 3 at ever possible.
[Bug tree-optimization/57742] memset(malloc(n),0,n) -> calloc(n,1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57742 Daniel Gutson changed: What|Removed |Added CC||daniel.gutson@tallertechnol ||ogies.com --- Comment #24 from Daniel Gutson --- This optimization breaks code, please see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67618
[Bug c/67618] New: malloc+memset optimization breaks code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67618
Bug ID: 67618
Summary: malloc+memset optimization breaks code
Product: gcc
Version: 5.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: daniel.gutson at tallertechnologies dot com
Target Milestone: ---
compiling the following code with -O2
#include
#include
char* function(size_t x)
{
void* ret = malloc(x);
if (x > 12)
memset(ret, 0, x);
return (char*)ret;
}
int main(void)
{
return 0;
}
causes gcc to wrongly replace function's content by a call to calloc.
This comes from https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57742
Additionally, in the case for RTEMS for example, if the function itself
(caller) is calloc, causes a recursive call. (Maybe this could be addressed in
two separate issues).
[Bug c/67618] malloc+memset optimization breaks code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67618 --- Comment #2 from Daniel Gutson --- (In reply to Marc Glisse from comment #1) > Why do you call it wrong? It is always legal to replace malloc with calloc, Have you seen the 'if' condition? The optimization ignores it completely. > and if we do it, the memset becomes useless. It may not be optimal from a > performance POV, but I don't see where it breaks anything. > > As for the infinite loop, that's a know problem not specific to this > function and there are already several PRs/emails about it. When you compile > the C library itself, you are supposed to pass some options to gcc so it > knows not to do that.
[Bug c/67618] malloc+memset optimization breaks code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67618 --- Comment #4 from Daniel Gutson --- (In reply to Andreas Schwab from comment #3) > Trying to read the (uninitialized) contents of the allocated memory for x <= > 12 would be undefined behaviour, so calling calloc instead does not change > the defined behaviour. Why do you assert that the program will read the memory? The optimization ignores the 'if' statement (just comment that line and see), so if malloc() returns NULL, memset is called unconditionally and will try to write to address NULL. The "x > 12" was just an example that this is arbitrary. Replace it with something else. The 'if' shall not be ignored.
[Bug middle-end/67618] malloc+memset optimization breaks code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67618 --- Comment #6 from Daniel Gutson --- (In reply to Andrew Pinski from comment #5) > (In reply to Daniel Gutson from comment #4) > > (In reply to Andreas Schwab from comment #3) > > > Trying to read the (uninitialized) contents of the allocated memory for x > > > <= > > > 12 would be undefined behaviour, so calling calloc instead does not change > > > the defined behaviour. > > > > Why do you assert that the program will read the memory? > > It does not. It just optimizes the code. I meant: how do you know what the program will do next? Maybe it will write memory. See below please. > > > The optimization ignores the 'if' statement (just comment that line and > > see), so if malloc() returns NULL, memset is called unconditionally and will > > try to write to address NULL. The "x > 12" was just an example that this is > > arbitrary. Replace it with something else. The 'if' shall not be ignored. > > yes that just undefined behavior when invoking memset with a NULL value, so > replacing it is still fine. That's why the 'if (ptr != NULL)' should not be ignored, which currently is. The 'if' prevents the UB. > > Also calloc is sometimes faster than a malloc/memset due to knowing if the > kernel will zero out the memory, etc. This is not under discussion.
[Bug tree-optimization/67618] malloc+memset optimization breaks code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67618
--- Comment #9 from Daniel Gutson
---
(In reply to Marc Glisse from comment #8)
> (bugzilla bug that reset the component...)
>
> (In reply to Daniel Gutson from comment #6)
> > That's why the 'if (ptr != NULL)' should not be ignored, which currently is.
> > The 'if' prevents the UB.
>
> Uh, if you consider it UB, I don't understand the problem. At runtime,
> either malloc succeeded and the transformation is fine, or x<=12 and the
> transformation is fine, or the call to memset is undefined behavior so
> anything is fine (including the transformation). Unless you explicitly want
> to catch the trap, I don't understand what you are saying. Could you detail
> step by step where a well-defined behavior in the original program is turned
> into a different behavior in the optimization?
See this example: ('function' is same as above)
void caller(void)
{
void* ptr = function(1);
*(char*)ptr = 1;
}
In this case, calloc was called instead of (only) malloc because the 'if' was
ignored, resulting in a suboptimized code (since calloc is usually slower than
malloc alone).
The resulting steps are:
calloc(1)
*ptr = 1;
whereas I just wanted
malloc(1)
*ptr = 1;
IMHO, the optimization should take the 'if' into account and only apply if it
is the usual 'if (ptr != NULL)' pattern.
(Additionally, it should check that the context caller function is not 'calloc'
itself).
[Bug tree-optimization/67618] malloc+memset optimization breaks code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67618
--- Comment #11 from Daniel Gutson ---
(In reply to Andrew Pinski from comment #10)
> (In reply to Daniel Gutson from comment #9)
> > (In reply to Marc Glisse from comment #8)
> > > (bugzilla bug that reset the component...)
> > >
> > > (In reply to Daniel Gutson from comment #6)
> > > > That's why the 'if (ptr != NULL)' should not be ignored, which
> > > > currently is.
> > > > The 'if' prevents the UB.
> > >
> > > Uh, if you consider it UB, I don't understand the problem. At runtime,
> > > either malloc succeeded and the transformation is fine, or x<=12 and the
> > > transformation is fine, or the call to memset is undefined behavior so
> > > anything is fine (including the transformation). Unless you explicitly
> > > want
> > > to catch the trap, I don't understand what you are saying. Could you
> > > detail
> > > step by step where a well-defined behavior in the original program is
> > > turned
> > > into a different behavior in the optimization?
> >
> > See this example: ('function' is same as above)
> >
> > void caller(void)
> > {
> > void* ptr = function(1);
> > *(char*)ptr = 1;
> > }
>
> Maybe file another bug which does the opposite transformation for the cases
> where memcpy happens after the calloc. There is not enough information to
> know if the value is going to be <=15 most of the time or not so we just
> guess.
Can't we use this one?
>
> Anyways there is no breaking of code.
OK, my bad.
> If you don't want this transformation
> inside a function which is called calloc, then you need to use
> -fno-builtin-malloc to disable finding of the malloc call.
Shouldn't be -fno-builtin-calloc the flag to prevent this optimization? I don't
want to disable malloc's builtin flavor everywhere else.
[Bug c++/67064] Register asm variable broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67064 --- Comment #30 from Daniel Gutson --- May I ask what's wrong with Andres Tiraboschi's solution approach?
[Bug c++/64875] New: -Winline does not report C++ methods
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64875
Bug ID: 64875
Summary: -Winline does not report C++ methods
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: daniel.gutson at tallertechnologies dot com
The following code misses the warning:
#include
struct PP
{
inline void m();
};
int main()
{
PP pp;
pp.m();
}
inline void PP::m()
{
std::cout << "hola" << std::endl;
}
Invoke:
g++ -Wall -Wextra -pedantic -ggdb3 -std=c++11 -Winline winline.cpp
No warnings emitted.
However:
objdump -dC ./a.out |grep "PP"
40086c:e8 59 00 00 00 callq 4008ca
004008ca :
If no one is available, assign this to me (though I'm not sure when I will have
time to address this).
[Bug c++/64875] -Winline does not report C++ methods
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64875 --- Comment #2 from Daniel Gutson --- inline is as useful in c++ as in C regardless of ODR or any other reason but its original purpose: performance.I want to know when my hint is not honored which is the exact intent of this warning.
[Bug c++/60850] pedantic warning behavior when casting void* to ptr-to-func
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60850 --- Comment #8 from Daniel Gutson --- Could you please detail *exactly* what the problem is, what the output error is and what does autotools do in its probe? Thanks.
[Bug c++/67064] Register asm variable broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67064
Daniel Gutson changed:
What|Removed |Added
CC||daniel.gutson@tallertechnol
||ogies.com
--- Comment #5 from Daniel Gutson
---
FWIW, g++ 4.8.4 and clang 3.5 do not complain in the following code:
struct s {
int i;
};
//register struct s *reg __asm__( "1" );
s* reg;
int f(void)
{
int i;
i = reg->i;
i = (reg)->i;
return i;
}
As from the same paragraphs of the standard, I don't think that a adding
parenthesis should alter the "valueness type" outside a decltype, meaning that
this could be an error lately introduced. I'll ask for a Committee member help
here.
[Bug c++/67064] Register asm variable broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67064 --- Comment #6 from Daniel Gutson --- Please discard my previous comment, I read too fast. I'll do some debugging and get back with some analysis. It seems that cxx_mark_addressable() is wrongly called.
[Bug c++/67064] Register asm variable broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67064 --- Comment #9 from Daniel Gutson --- Thanks Ville and Jens for looking into this. I'll be able to fix this during next week, so if nobody is available to solve this sooner, then please assign it to me. Regarding the global register variables, it's a GNU C extension (see https://gcc.gnu.org/onlinedocs/gcc/Explicit-Reg-Vars.html), but I think it should be rejected when compiling in strict mode (e.g. -ansi or -std=c++14). I think this should be filed as a separate issue.
[Bug c++/67064] Register asm variable broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67064 --- Comment #12 from Daniel Gutson --- I tried them all, and none of those flags reject a global variable declared as register. I still think a separate issue should be filed.
[Bug c++/67064] Register asm variable broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67064 --- Comment #15 from Daniel Gutson --- (In reply to Jason Merrill from comment #14) > (In reply to Ville Voutilainen from comment #13) > > It is correct that currently none of the pedantic-flags diagnose the use of > > this extension; perhaps that should be fixed while fixing this bug... > > '-Wpedantic' does not cause warning messages for use of the > alternate keywords whose names begin and end with '__'. Pedantic > warnings are also disabled in the expression that follows > '__extension__'. However, only system header files should use > these escape routes; application programs should avoid them. Do you refer to the __asm__? If not, do you think this is a bug too or not?
[Bug c++/67105] New: use of global register variables should emit a pedwarn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67105
Bug ID: 67105
Summary: use of global register variables should emit a pedwarn
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: daniel.gutson at tallertechnologies dot com
Target Milestone: ---
This is a spinoff of https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67064
specially comment https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67064#c16
So basically:
struct s {
int i;
};
register struct s *reg asm( "si" );
should pedwarn.
[Bug c++/67064] Register asm variable broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67064 --- Comment #18 from Daniel Gutson --- I created https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67105 to treat that bug separately. 67064 (this bug) interferes with RTEMS in real life thus has a much higher priority, so I will address this bug first. Please assign this to me. Thanks.
[Bug c++/67064] Register asm variable broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67064 --- Comment #20 from Daniel Gutson --- (In reply to Manuel López-Ibáñez from comment #19) > (In reply to Daniel Gutson from comment #18) > > Please assign this to me. Thanks. > > You need to login with your @gcc.gnu.org account to be able to assign bugs > (and do other Bugzilla operations). I don't have a @gcc.gnu.org account. Should I simply send the attachment? Otherwise please assign this to me for me if it is still possible. FWIW, I've been listed in the MAINTAINER list in the past while working for CodeSourcery but my name no longer is in that list.
[Bug c++/67064] Register asm variable broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67064 --- Comment #22 from Daniel Gutson --- (In reply to Jason Merrill from comment #21) > (In reply to Daniel Gutson from comment #20) > > I don't have a @gcc.gnu.org account. Should I simply send the attachment? > > Sure. > > > Otherwise please assign this to me for me if it is still possible. > > Done. Thanks. > > > FWIW, I've been listed in the MAINTAINER list in the past while working for > > CodeSourcery but my name no longer is in that list. > > Hmm, how were you in that list without a gcc.gnu.org account? I don't know/remember (maybe I did have such account? Where can I check that?) It was 2008/2009 where I mostly fixed backend erratas. In any case, how can apply for one? (Sorry for the spam to the other CC'ed people, I will continue this by private mailing).
