https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59429
--- Comment #16 from Mathias Stearn ---
Trunk still generates different code for all cases (in some cases subtly so)
for both aarch64 and x86_64: https://www.godbolt.org/z/1s6sxrMWq. For both
arches, it seems like LE and LG generate the best
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113723
--- Comment #1 from Mathias Stearn ---
As a workaround sticking [[gnu::optimize("no-reorder-blocks-and-partition")]]
on each function that triggers this seems to work. But that is obviously not a
scalable solution.
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: redbeard0531 at gmail dot com
Target Milestone: ---
It tries to subtract labels across the function split which the assembler
rejects. At the very least it does this when
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113682
--- Comment #5 from Mathias Stearn ---
(In reply to Andrew Pinski from comment #2)
> I should note that on x86, 2 cmov in a row might be an issue and worse than
> branches. There is a cost model and the x86 backend rejects that.
>
> There are
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: redbeard0531 at gmail dot com
Target Milestone: ---
I've been trying to eliminate unpredictable branches in a hot function where
perf counters show a high mispredict percentage
: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: redbeard0531 at gmail dot com
Target Milestone: ---
https://www.godbolt.org/z/Y31xG7EeT
These two functions should be equivalent, but comp2() produces better code than
comp1() on both arm64 and x86_64
int comp1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111588
--- Comment #5 from Mathias Stearn ---
Mea culpa. The difference between boost and std was due to the code to
fast-path shared_ptrs that aren't actually shared:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111588
--- Comment #4 from Mathias Stearn ---
So even though I already knew in the back of my mind about how this can affect
benchmark results, I *still* got burned by it! I was benchmarking a simple
hazard pointer implementation against shared ptrs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111976
--- Comment #1 from Mathias Stearn ---
Just to be clear, I think we should only do this for "large" objects or
collections of objects. If you did it for small objects in general, there is a
risk that they will spread out mutable data that is
: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: redbeard0531 at gmail dot com
Target Milestone: ---
Right now constant objects always go in .rodata. This is nice because it will
give a nice loud error if you ever write
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104611
Mathias Stearn changed:
What|Removed |Added
CC||redbeard0531 at gmail dot com
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: redbeard0531 at gmail dot com
Target Milestone: ---
The atomic increment when copying a shared_ptr can be relaxed because it is
never actually used as a synchronization
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: redbeard0531 at gmail dot com
Target Milestone: ---
Right now there is a fast-path for single-threaded programs to avoid the
overhead of atomics in shared_ptr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89997
--- Comment #6 from Mathias Stearn ---
> I think this is probably not concepts-specific, and just another variant of
> PR 49152.
Perhaps the busted pretty printer is a general problem, but at least in this
case I think the fix may be in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89997
--- Comment #3 from Mathias Stearn ---
Please reopen. It still seems to be broken with -std=c++20 as the only flag:
https://godbolt.org/z/bWMq4s6xb (trunk) https://godbolt.org/z/W3xWjWaGe (12.2)
Output:
: In function 'void test()':
:16:15:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105397
Mathias Stearn changed:
What|Removed |Added
CC||redbeard0531 at gmail dot com
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: redbeard0531 at gmail dot com
Target Milestone: ---
With normal variables, gcc will generate a nice cmp/js pair when checking if
the high bit is null. When using an atomic, gcc
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: redbeard0531 at gmail dot com
Target Milestone: ---
https://godbolt.org/z/zcY11ezev
#include
#include
template
typename F::Out call(F&& fun) {
typename F:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105534
--- Comment #4 from Mathias Stearn ---
(In reply to Richard Biener from comment #2)
> Note there's
>
> _2 = value_1(D) * x_2;
>
> where _2 might be effectively uninitialized iff x_2 is not zero. When x_2
> is zero then _2 has a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105534
--- Comment #3 from Mathias Stearn ---
One slightly confusing aspect is that the wording of the flag implies that the
variable may or may not be uninitialzied (because in -Wmaybe-uninitialized
maybe binds directly to uninitialized), while
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: redbeard0531 at gmail dot com
Target Milestone: ---
The following function emits a -Wuninitialized warning on ++count with -Wall
https://godbolt.org/z/KfaMEETY1:
int test(bool cond
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: redbeard0531 at gmail dot com
Target Milestone: ---
https://godbolt.org/z/1zdYsaqEj
Consider these equivalent functions:
int test1(int x) {
if (x <= 10)
return
: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: redbeard0531 at gmail dot com
Target Milestone: ---
I'm not sure if this is an issue with the optimizer or the way that the library
code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102876
--- Comment #12 from Mathias Stearn ---
(In reply to Jakub Jelinek from comment #10)
> So we'd just punt at optimizing that, we don't know if b is read or written
> by foo (and, note, it doesn't have to be just the case of explicitly being
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102876
--- Comment #3 from Mathias Stearn ---
> Why not just make the function constexpr though?
That isn't always possible. Sometimes the initializer may call a third-party
function that is inline, but not yet marked constexpr (it may need to
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: redbeard0531 at gmail dot com
Target Milestone: ---
See: https://godbolt.org/z/KnKv9j8b9
#include
using namespace std::literals;
/*not constexpr*/ inline std
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102528
--- Comment #8 from Mathias Stearn ---
Sorry again about the confusion caused by my typo. I am not able to edit the
comment to make it clear that the comment#0 should be ignored. If that happens
again, would it be better for me to close the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102528
--- Comment #1 from Mathias Stearn ---
Sorry, there was a typo in the initial code. I forgot the trivial
implementation of await_resume(). (D'oh!)
Now I can see that test() is just a ret instruction, but there is still a lot
of dead code
++
Assignee: unassigned at gcc dot gnu.org
Reporter: redbeard0531 at gmail dot com
Target Milestone: ---
https://godbolt.org/z/aoab9W4xG
This should all compile away, and test() should just be a single ret
instruction. That is not what happens now, even with -O3.
#include
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100493
--- Comment #3 from Mathias Stearn ---
When reading https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82611, I noticed that
C++17 actually requires the warning on [=, this] from a conforming
implementation:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100493
Mathias Stearn changed:
What|Removed |Added
CC||redbeard0531 at gmail dot com
: normal
Priority: P3
Component: web
Assignee: unassigned at gcc dot gnu.org
Reporter: redbeard0531 at gmail dot com
Target Milestone: ---
https://gcc.gnu.org/onlinedocs/gcc-4.7.2/gcc/Function-Attributes.html
This would make it easier to link to the docs
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: redbeard0531 at gmail dot com
Target Milestone: ---
When a promise_type::await_transform() has
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: redbeard0531 at gmail dot com
Target Milestone: ---
https://godbolt.org/z/KTTMrEGns
Example code:
free(new (malloc(4)) int()); // Warns but shouldn't
delete new
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: redbeard0531 at gmail dot com
Target Milestone: ---
https://eel.is/c++draft/thread.condvarany.wait says "Postconditions: lock is
locked by the calling thread. […] Re
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99470
Mathias Stearn changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|INVALID
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: redbeard0531 at gmail dot com
Target Milestone: ---
These two functions do the same thing but f() is the cleaner source code
(especially when arr is a std::array) while g() generates better code:
https
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99339
--- Comment #6 from Mathias Stearn ---
> The question is how common in the wild it is and if it is worth the work.
I'm not sure how common it is, but this is my use case. The code in the bug
report is a slightly simplified example from some
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95079
--- Comment #5 from Mathias Stearn ---
@François Dumont: Sorry I didn't see your question earlier. The reason that
unordered_map perf hurts on 64-bit platforms is because it is designed to do a
size_t modulus-by-prime on every lookup, and on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99339
--- Comment #5 from Mathias Stearn ---
I filed a related bug with clang right after this one if anyone want to follow
along https://bugs.llvm.org/show_bug.cgi?id=49395.
Just because clang does worse doesn't mean gcc shouldn't do better ;)
Assignee: unassigned at gcc dot gnu.org
Reporter: redbeard0531 at gmail dot com
Target Milestone: ---
These two functions should generate the same code, but the varargs version is
much worse. And it is even worser still when you enable
-fstack-protector-strong.
https://godbolt.org/z/noEYoh
++
Assignee: unassigned at gcc dot gnu.org
Reporter: redbeard0531 at gmail dot com
Target Milestone: ---
https://godbolt.org/z/ecxEbb Code compiles on MSVC and clang, and at least on
clang produces the expected output.
#include
#include
template
struct [[nodiscard]] task
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99021
--- Comment #3 from Mathias Stearn ---
Thanks for the quick fix!
Any chance of a backport of this and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99021
--- Comment #1 from Mathias Stearn ---
clang bug for reference https://bugs.llvm.org/show_bug.cgi?id=49109
normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: redbeard0531 at gmail dot com
Target Milestone: ---
While it isn't required by the standard, it seems odd that
coroutine_handle::from_address() is noexcept while t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98639
Mathias Stearn changed:
What|Removed |Added
CC||redbeard0531 at gmail dot com
: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: redbeard0531 at gmail dot com
Target Milestone: ---
Currently insert_or_assign() and try_emplace() call find(key) and fall back to
emplace
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: redbeard0531 at gmail dot com
Target Milestone: ---
https://github.com/gcc-mirror/gcc/blob
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90295
Mathias Stearn changed:
What|Removed |Added
CC||redbeard0531 at gmail dot com
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: redbeard0531 at gmail dot com
Target Milestone: ---
namespace N {
template
struct X{ X(int); };
}
using N::X;
X(int) -> X;
This is supposed to not compile due to
http://eel.is/c++draft/temp.deduct.guid
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: redbeard0531 at gmail dot com
Target Milestone: ---
https://godbolt.org/z/30Cf6s
#include
template
constexpr inline bool isAddable = requires(const T& lhs, const U&
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: redbeard0531 at gmail dot com
Target Milestone: ---
https://godbolt.org/z/SEfFol
This is a creduce'd example that tripped a segfault in our Real World Code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: redbeard0531 at gmail dot com
Target Milestone: ---
https://godbolt.org/z/y5GQZd
struct Struct {
template
constexpr static bool use_cond = false
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: redbeard0531 at gmail dot com
Target Milestone: ---
This code compiles fine with 7 and trunk but fails
: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: redbeard0531 at gmail dot com
Target Milestone: ---
Usually -fconcepts delivers excellent error messages, but this one is pretty
bad. It looks like this goes back to 6.2, when it first started to show the
expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89781
--- Comment #3 from Mathias Stearn ---
Yeah, my point wasn't that this code should be accepted, it was that the error
messages should be improved. Ideally there would even be fixits suggesting
adding constexpr where it would be valid, otherwise
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: redbeard0531 at gmail dot com
Target Milestone: ---
The error messages make sense in a pre-c++17 world before inline variables
existed. Now they are lies!
struct X{};
struct Y
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: redbeard0531 at gmail dot com
Target Milestone: ---
https://godbolt.org/z/JA-0Gq
#include
struct Dest {
Dest() = default;
Dest(Dest&&);
Dest(co
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: redbeard0531 at gmail dot com
Target Milestone: ---
https://godbolt.org/z/8vIGZ3
using u64 = unsigned long long;
struct u128 {u64 a, b;};
inline u64 load8(void* ptr) {
u64 out
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: redbeard0531 at gmail dot com
Target Milestone: ---
https://godbolt.org/z/BAeXQB
"strncpy output truncated copying between 0 and 8 bytes from a string of len
++
Assignee: unassigned at gcc dot gnu.org
Reporter: redbeard0531 at gmail dot com
Target Milestone: ---
Also, for some reason it repeats the warning 3 times.
https://godbolt.org/z/SStUsl
// Fine
extern const char a[2] = {'1'};
auto z = __builtin_strlen(a);
// Warns
extern
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: redbeard0531 at gmail dot com
Target Milestone: ---
New in GCC9. No other compiler errors on this:
https://godbolt.org/z/480KfZ
template
class C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89640
--- Comment #4 from Mathias Stearn ---
@Jakub, This code doesn't have either mutable or noexcept, so the "wrong place
in the grammer" issue doesn't apply. That part of the fix seems correct and
useful.
While it seems correct to fix what the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89640
--- Comment #2 from Mathias Stearn ---
Unfortunately the c++ attributes syntax applies to the lambda type rather than
the function, so the warning is correct. The old style __attribute__ syntax
seems to be the only way to annotate the lambda
++
Assignee: unassigned at gcc dot gnu.org
Reporter: redbeard0531 at gmail dot com
Target Milestone: ---
Regression in gcc 9 vs 8.
https://godbolt.org/z/MGL0H4
void test() {
[]() __attribute__((noinline,cold)) {
asm volatile("");
}();
}
: In function
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: redbeard0531 at gmail dot com
Target Milestone: ---
https://godbolt.org/z/rJT5X9
struct B {};
struct A {
[[no_unique_address]] B a;
[[no_unique_address]] B b
: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: redbeard0531 at gmail dot com
Target Milestone: ---
https://godbolt.org/z/oSuiQO
// IN HEADER:
inline auto lambda = [] () -> int* {
static int foo;
return
};
inline int* func() {
static int foo;
ret
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67012
Mathias Stearn changed:
What|Removed |Added
CC||redbeard0531 at gmail dot com
++
Assignee: unassigned at gcc dot gnu.org
Reporter: redbeard0531 at gmail dot com
Target Milestone: ---
https://godbolt.org/g/aCiuAy
While I'm a bit sad that good() isn't just "ret", I think that the current
rules for allocation elision require something like that cod
Assignee: unassigned at gcc dot gnu.org
Reporter: redbeard0531 at gmail dot com
Target Milestone: ---
This was tweaked example code to demonstrate something totally unrelated, but I
noticed it was doing the constprop clone thing for functions with identical
instructions, which
: unassigned at gcc dot gnu.org
Reporter: redbeard0531 at gmail dot com
Target Milestone: ---
https://godbolt.org/g/aEFhq8
#include
std::atomic progress{-1};
void combine_writes1() {
// These should be reduced to a single store(0,release),
// At least as long as release
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86056
--- Comment #2 from Mathias Stearn ---
Oh, I agree that this optimization must be permitted. I was using this example
to prove this to someone else who didn't believe that. I only mentioned that to
explain how that weird source code came to be.
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: redbeard0531 at gmail dot com
Target Milestone: ---
This is from an example to prove that atomic_thread_fence does not prevent the
compiler from optimizing non-escaped memory.
https
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85813
--- Comment #7 from Mathias Stearn ---
> Simply returning an empty exception_ptr is what happened before the PR 64241
> change, so what we do now retains that behaviour. That might be the main
> reason for it.
Silently dropping errors always
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85813
--- Comment #3 from Mathias Stearn ---
My assumption was that if E(...) throws and it can't be caught, it should be
treated as any other case when an -fno-exceptions TU calls a throwing function.
In this case that would mean calling terminate()
: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: redbeard0531 at gmail dot com
Target Milestone: ---
It looks like nothing in that path actually needs exception support. This would
: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: redbeard0531 at gmail dot com
Target Milestone: ---
I think if this line throws the exception allocated on line 185 will leak:
https://github.com/gcc-mirror/gcc/blob
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85799
--- Comment #1 from Mathias Stearn ---
LLVM bug: https://bugs.llvm.org/show_bug.cgi?id=37476
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: redbeard0531 at gmail dot com
Target Milestone: ---
It seems like __builtin_expect doesn't propagate to conditions when inlined.
This is unfortunate because in some cases it would be nice
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83400
--- Comment #3 from Mathias Stearn ---
This is related to https://wg21.link/CWG2219
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: redbeard0531 at gmail dot com
Target Milestone: ---
It would be nice to get the benefits of those attributes on a per-constructor
basis, rather than requiring them on the whole type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85721
--- Comment #4 from Mathias Stearn ---
Marc Glisse pointed out at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85720#c3 that my I missed an
aliasing case when I created this ticket. memmove isn't a valid replacement if
out is in the range (in,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85720
--- Comment #4 from Mathias Stearn ---
(In reply to Marc Glisse from comment #3)
> Again, you are ignoring aliasing issues (just like in your other PR the
> function copy isn't equivalent to memmove). Does adding __restrict change
> the result?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85721
--- Comment #3 from Mathias Stearn ---
@Jonathan Wakely, that is because std::copy cheats and calls memmove directly.
A slight modification of the type that shouldn't matter defeats that
optimization and causes both forms to degrade to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85720
--- Comment #2 from Mathias Stearn ---
Hmm. Taking the example from the -ftree-loop-distribute-patterns documentation,
it still seems to generate poor code, this time at both -O2 and -O3:
https://godbolt.org/g/EsQDj8
Why isn't that transformed
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: redbeard0531 at gmail dot com
Target Milestone: ---
https://godbolt.org/g/Gg9fFt
Related to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85720, but filed
separately because
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: redbeard0531 at gmail dot com
Target Milestone: ---
https://godbolt.org/g/qp19Cv
using SIZE_T = decltype(sizeof(0));
void fill(char* p, SIZE_T n) {
for (SIZE_T i = 0; i < n; i++){
p[i] =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85707
--- Comment #8 from Mathias Stearn ---
> If the constructor had other side-effects (e.g., count
> the number of objects of the class) bypassing it could
> violate the invariant.
I thought one of the points of friendship was to allow friends
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85707
--- Comment #2 from Mathias Stearn ---
Here is a boiled down example of some of our code that trips this warning:
https://godbolt.org/g/ChLrch. It also shows why we do this, since the codegen
is *substantially* better for init_table_memset than
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: redbeard0531 at gmail dot com
Target Milestone: ---
I get the point of the warning and would like to be able to turn it on. However
we have some types that have been
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85680
--- Comment #3 from Mathias Stearn ---
MSVC and ICC both also handle this poorly: https://godbolt.org/g/i4wMYa
https://developercommunity.visualstudio.com/content/problem/246786/poor-codegen-for-value-init-followed-by-explicit-i.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85680
--- Comment #2 from Mathias Stearn ---
FYI, I don't think this is a signed/unsigned thing since it also repros with
unsigned long https://godbolt.org/g/LTmrpi
My initial repo actually used size_t, but I (incorrectly) changed it to long
rather
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: redbeard0531 at gmail dot com
Target Milestone: ---
https://godbolt.org/g/6yZEKf (compiled with -O3)
char* variableSize(long n) {
auto p = new char[n]();
for (int i = 0; i < n
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: redbeard0531 at gmail dot com
Target Milestone: ---
Repro code below doesn't print the "in dtor" line when compiled with -O1 or
higher. It d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77943
--- Comment #12 from Mathias Stearn ---
We were hoping to replace many places in our code that does the following with
noexcept attributes on functions:
> try {doStuffThatShouldntThrow();} catch(...) {std::terminate();}
We wanted to take
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77943
--- Comment #3 from Mathias Stearn ---
> Not being a C++ expect, but following spec:
> http://en.cppreference.com/w/cpp/language/noexcept_spec
>
> "If a search for a matching exception handler leaves a function marked
> noexcept or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77943
--- Comment #1 from Mathias Stearn ---
Created attachment 39787
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39787=edit
Reproducer
: critical
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: redbeard0531 at gmail dot com
Target Milestone: ---
When compiled with -O0 and -01 the program behaves correctly and only calls
std::terminate() when passed an argument
++
Assignee: unassigned at gcc dot gnu.org
Reporter: redbeard0531 at gmail dot com
Target Milestone: ---
Created attachment 37359
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37359=edit
Preprocessed test case
This is a reduced example from a ridiculous code contest. It compi
99 matches
Mail list logo
