On Thu, Apr 18, 2024 at 5:38 PM Frank Ch. Eigler wrote:
>
> Hi -
>
> > [...] I suggest that a basic principle for such a system is that it
> > should be *easy* to obtain and maintain a local copy of the history
> > of all pull requests. That includes all versions of a pull request,
> > if it
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: matt at godbolt dot org
Target Milestone: ---
The code:
```
struct S {
std::size_t len{s.size()};
std::string s{"A rather long string"};
};
```
warn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110197
--- Comment #11 from Matt Godbolt ---
Thank you Patrick! Great news! About 1/3 of my build's output is this warning
right now :)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110197
--- Comment #8 from Matt Godbolt ---
Fantastic: thanks everyone!
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: matt at godbolt dot org
Target Milestone: ---
The following code, compiled on GCC 13.1 complains of a non-constexpr safe
array access:
```
#include
#include
struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68274
--- Comment #5 from Matt Godbolt ---
Amazing: thank you Andrew!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106020
--- Comment #13 from Matt Godbolt ---
Thanks Andrew!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109883
--- Comment #6 from Matt Borland ---
(In reply to Xi Ruoyao from comment #4)
> It seems the function
>
> __gnu_cxx::__promote_2 std::__is_integer<_Float64>::__value>::__type)(0))+((__gnu_cxx::
> __promote_2<_Float64, st
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109883
--- Comment #2 from Matt Borland ---
(In reply to Xi Ruoyao from comment #1)
> Cannot reproduce for me. Note that in this case GCC optimizes the entire
> function call away (see https://godbolt.org/z/968bPTvh9) even with -O0 so I
>
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: matt at mattborland dot com
Target Milestone: ---
The two or more argument functions in cause a stack overflow when
called with an type and any integer type. Running with ASAN yields
"AddressSani
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108732
--- Comment #7 from Matt Hellige ---
Those make sense as internal details. I don't think a typical user should be
expected to guess or learn these differences in order to use the GCC from the
command line. So, whether or not they suffice
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108732
--- Comment #5 from Matt Hellige ---
That makes sense, but it's just a strange inconsistency from a usability point
of view.
.so files are generally mmapped as well, I believe, aren't they? But I can
still generate one to /dev/null if I like
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108732
--- Comment #3 from Matt Hellige ---
As long as I'm updating builds, I'll switch to that invocation, thanks.
I still do think it's a little odd that in this case (and *only* in this case?)
output needs to be written to a mappable file
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: matt at immute dot net
Target Milestone: ---
with GCC 12, the following command fails with a fairly obscure error:
$ gcc12.2.0 -c foo.h -o /dev/null
foo.h:1: fatal error: cannot write PCH file: required memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106020
--- Comment #6 from Matt Godbolt ---
I'm afraid to say I've been unable to make a repro case in the short time I had
to try - will get back to this but about to go on vacation (!). That's to say
dumping the files from CE and using:
CXX=/opt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106020
--- Comment #5 from Matt Godbolt ---
Thanks! Understood re: cmake; I wouldn't have picked it but it was the easiest
way to repro something on compiler explorer for Howard at the time. I'm sure we
can get it down to a smaller cast and a shell
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106020
--- Comment #2 from Matt Godbolt ---
There are many hundreds of similar errors in that example; perhaps this example
is more of a clue:
/opt/compiler-explorer/gcc-12.1.0/include/c++/12.1.0/bits/move.h:205:11:
warning: writing 1 byte
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106020
--- Comment #1 from Matt Godbolt ---
Apologies for the unreduced issue, if I get a chance I'll try and shorten it,
but I hoped someone might recognise what the issue is from just this.
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: matt at godbolt dot org
CC: marxin at gcc dot gnu.org
Target Milestone: ---
When using Howard Hinnant's date library, and GCC 12.1 on x86, and then with
LTO enabled
ests? Could such a test verify the emitted assembly (like LLVM’s
FileCheck tests do)? Or would it need to execute something?
Thanks for your help!
Matt
> On Sep 26, 2021, at 11:45 PM, Matt Jacobson wrote:
>
> Fix protocol list layout for non-LP64. clang and objc4 both give the `count`
> field as `long`, not `intptr_t`. Those are the same on LP64, but not
> everywhere. For non-LP64, this fixes binary compatibility w
.
Thank you for your time.
<https://github.com/mhjacobson/gcc/commit/5ebc95dc726f0745ebdf003093f1b8d7720ce32f>
gcc/objc/ChangeLog:
2021-09-26 Matt Jacobson
* objc-next-runtime-abi-02.c (enum objc_v2_tree_index): Add new global
tree.
(static void next_runtime_02_init
925f1f428>
gcc/objc/ChangeLog:
2021-09-26 Matt Jacobson
* objc-next-runtime-abi-02.c (build_v2_class_templates): Remove explicit
padding on non-LP64.
(build_v2_class_ro_t_initializer): Remove initialization of explicit
padding on
non-LP64.
diff --git a/gcc/ob
tps://github.com/mhjacobson/gcc/commit/917dc8bb2f3265c2ca899ad750c5833b0161a11e>
I don't have commit access, so if this patch is suitable, I'd need someone else
to commit it for me. Thanks.
gcc/objc/ChangeLog:
2021-09-21 Matt Jacobson
* objc-next-runtime-abi-02.c (struct class_ro_t):
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102067
--- Comment #21 from Matt Godbolt ---
Thanks, I'd love to upgrade but in this instance I'm stuck on GCC 9.x until the
rest of my company can move to it. Nothing annoys me more than having to say
that, but ... at least we know what
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102067
--- Comment #17 from Matt Godbolt ---
This is proprietary code (that the App and Sentry files didn't really contain
anything I was concerned about), and it links with a number of other libraries
which are much more proprietary (e.g. lwave env
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102067
--- Comment #15 from Matt Godbolt ---
> Can you please try reproducing it locally with the 2 pre-processed file.
I'm not sure how to: if I don't have all the object files available in my link
line I get missing symbol errors before any l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102067
--- Comment #13 from Matt Godbolt ---
Both attached. When they're built they're built with:
```
/home/mgodbolt/dev/wave/cmake-build-release/env/bin/x86_64-conda_cos6-linux-gnu-g++
-DSPDLOG_FMT_EXTERNAL -Igenerated -I../src -I../src/wave/common
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102067
--- Comment #12 from Matt Godbolt ---
Created attachment 51361
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51361=edit
preprocessed. gzipped, Sentry.cpp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102067
--- Comment #11 from Matt Godbolt ---
Created attachment 51360
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51360=edit
preprocessed, gzipped App.cpp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102067
--- Comment #10 from Matt Godbolt ---
Thanks! Will attach!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102067
--- Comment #5 from Matt Godbolt ---
> And can you please test a more recent compiler (gcc-10 or gcc-11)?
Unfortunately not easily; we have a whole ecosystem of libraries we link in
(not attached here).
If we get any more time we'll
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102067
--- Comment #4 from Matt Godbolt ---
Interestingly, if we extract (with nm x) the files in the library, and glob
them in instead of naming the library file, everything works. We're having
difficulty constructing a reduced case, as we need
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102067
--- Comment #2 from Matt Godbolt ---
Hi Martin!
Thanks for the quick reply. We don't have an easy way to do this in our current
setup: those files are built and published as a library by a different system.
We'll give it a go though.
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: matt at godbolt dot org
Target Milestone: ---
Whillinking against a static library containing LTO objects, the `lto1` stage
crashes with a segfault
Ok! Thanks; sorry for the misunderstanding on my side.
--matt
On Sat, Aug 21, 2021 at 2:53 PM Stefan Kanthak
wrote:
> Matt Godbolt wrote:
>
> > I believe your example doesn't take into account that the values can be
> NaN
> > which compares false in all situations.
&
I believe your example doesn't take into account that the values can be NaN
which compares false in all situations. If you allow the compiler to
optimize without supporting NaN (-ffast-math), I think it generates the
code you want: https://godbolt.org/z/1ra7zcsnd
--matt
On Sat, Aug 21, 2021 at 1
ug and in the process added
-fobjc-nilcheck to the compiler invocation in objc-torture.exp. Let me know
what you think.
I’m not sure what you mean w.r.t. Objective-C++ -- can you explain?
gcc/testsuite/ChangeLog:
2021-08-14 Matt Jacobson
PR objc/101666
* lib/objc-torture.exp: T
the frontend against the example in PR101666 and inspecting
the generated code.
I don't have commit access, so if this patch is suitable, I'd need someone else
to commit it for me. Thanks.
gcc/objc/ChangeLog:
2021-08-14 Matt Jacobson
PR objc/101666
* objc-next-runtime-abi-02
> On Aug 3, 2021, at 2:39 PM, Iain Sandoe wrote:
>
>
>
>> On 2 Aug 2021, at 22:37, Matt Jacobson via Gcc-patches
>> wrote:
>>
>>> On Aug 2, 2021, at 5:09 PM, Eric Gallager wrote:
>>>
>>> On Wed, Jul 28,
> On Aug 2, 2021, at 5:09 PM, Eric Gallager wrote:
>
> On Wed, Jul 28, 2021 at 11:36 PM Matt Jacobson via Gcc-patches
> wrote:
>>
>> As is, an invocation of GCC with -fnext-runtime -fobjc-abi-version=2 crashes,
>> unless target-specific code adds an implicit -f
to commit it for me. Thanks.
gcc/objc/ChangeLog:
2021-07-28 Matt Jacobson
* objc-next-runtime-abi-02.c (objc_next_runtime_abi_02_init): Warn
about and reset flag_objc_sjlj_exceptions regardless of
flag_objc_exceptions.
gcc/c-family/ChangeLog:
2021-07-28 Matt
> On Jul 5, 2021, at 7:09 PM, Matt Jacobson wrote:
>
>> On Jun 7, 2021, at 3:30 AM, Matt Jacobson wrote:
>>
>> The AVR target builds a lot of multilib variants of target libraries by
>> default,
>> and I found myself wanting to use the --with-multi
Hi,
I Just want to confirm that did you got my last email or not.
If you find this interesting and want to know more about it , share your
details with us our experts will get in touch and share further details
with you.
I look forward to your response.
Regards,
Matt Prater
On Thu, Jul 8
> On Jun 7, 2021, at 3:30 AM, Matt Jacobson wrote:
>
> The AVR target builds a lot of multilib variants of target libraries by
> default,
> and I found myself wanting to use the --with-multilib-list argument to limit
> what I was building, to shorten build times. Thi
an AVR compiler and target libs on macOS.
I don't have commit access, so if this patch is suitable, I'd need someone else
to commit it for me. Thanks.
gcc/ChangeLog:
2020-06-07 Matt Jacobson
* config.gcc: For the AVR target, populate TM_MULTILIB_CONFIG.
* config/avr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96868
--- Comment #2 from Matt Godbolt ---
Thanks: I was confused (as I think will many folks be). The examples for
designated initialisers in C++20 on cppreference cite this behaviour as being
useful^. Of course I understand it can be misused
: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: matt at godbolt dot org
Target Milestone: ---
The following code, with -Wall -Wextra, GCC 10.x or trunk, -std=c++20:
```
struct MyObj {
MyObj();
};
struct Test {
int a{};
MyObj obj;
};
Test t() {
Test t
perand" "=r,d ,q,r")
(match_operand:ALL1 1 "nox_general_operand" "r,n Ynn,r,q"))
(clobber (const_int 0))]
"(register_operand (operands[0], mode)
|| reg_or_0_operand (operands[1], mode))
&& reload_completed"
{
return output_movqi (insn, operands, NULL);
}
[(set_attr "length" "1,1,1,1")
(set_attr "adjust_len" "mov8")])
Regards
Senthil
Happy to see someone working this. Are you starting with one CC mode?
I noticed that the current CC0 implementation seems to effectively use
several modes. For example, one for use of the t flag. I'm sure it
will be easier
to start with one mode.
Matt
++
Assignee: unassigned at gcc dot gnu.org
Reporter: matt at godbolt dot org
Target Milestone: ---
Filing on behalf of @lunasorcery (on twitter):
The following code:
```
#include
struct S {
S(char const* message) {
puts(message);
}
};
void operator,(S,S){}
int main
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94797
--- Comment #3 from Matt Godbolt ---
Thanks so much!
: other
Assignee: unassigned at gcc dot gnu.org
Reporter: matt at godbolt dot org
Target Milestone: ---
With trunk gcc and latest binutils, `c++filt` does not demangle spaceship
operator, leaving `_ZNK3FoossERKS_` mangled.
[ see, e.g. https://github.com/mattgodbolt/compiler
And this is a reference to the discussion on avrfreaks.net:
https://www.avrfreaks.net/forum/avr-gcc-and-avr-g-are-deprecated-now
Matt
On Tue, Sep 24, 2019 at 1:24 AM Kyrill Tkachov
wrote:
>
> Hi Matt,
>
> On 9/24/19 5:04 AM, Matt Turner wrote:
> > When -march=native is passed to host_detect_local_cpu to the backend,
> > it overrides all command lines after it. That means
> >
> &
When -march=native is passed to host_detect_local_cpu to the backend,
it overrides all command lines after it. That means
$ gcc -march=native -march=armv8-a
is treated as
$ gcc -march=armv8-a -march=native
Prune joined switches with Negative and RejectNegative to allow
-march=armv8-a to
When -march=native is passed to host_detect_local_cpu to the backend,
it overrides all command lines after it. That means
$ gcc -march=native -march=armv8-a
is treated as
$ gcc -march=armv8-a -march=native
Prune joined switches with Negative and RejectNegative to allow
-march=armv8-a to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89257
--- Comment #1 from Matt A ---
Apologies, I should have clarified this is on x86_64:
$ g++ -v
Using built-in specs.
COLLECT_GCC=/software/thirdparty/gcc/7.2.0-0.el7_64/bin/g++
COLLECT_LTO_WRAPPER=/software/thirdparty/gcc/7.2.0-0.el7_64/libexec
++
Assignee: unassigned at gcc dot gnu.org
Reporter: matt at ookypooky dot com
Target Milestone: ---
Code as follows:
--
#include
#include
struct Foo
{
Foo () = default;
Foo (Foo &)
: x (f.x)
, y (f.y)
{
f.y = 0;
}
int x = 123;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89220
--- Comment #1 from Matt A ---
// ... but this compiles again
auto z = ((Foo(123)))(0);
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: matt at ookypooky dot com
Target Milestone: ---
Demonstrated by the following code:
template
struct Foo
{
Foo (T) {}
auto operator () (int) { return 0; }
};
// this compiles
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: matt at godbolt dot org
Target Milestone: ---
It seems around GCC 7 an optimization was added turning multiple comparisons of
a small range into a bit-select. This optimization seems
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: matt at godbolt dot org
Target Milestone: ---
The code:
---snip
int func(int val, const int *ptr)
{
int res = val + 1234;
if (res == *ptr)
{
res = 0
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: matt at godbolt dot org
Target Milestone: ---
In the following code:
---
struct S {
char uninit;
char initialised = 11;
char variable[];
};
void
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67632
Matt Godbolt changed:
What|Removed |Added
CC||matt at godbolt dot org
--- Comment #11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81004
--- Comment #24 from Matt Godbolt ---
Thanks so much for looking in to this Jan!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81004
--- Comment #16 from Matt Godbolt ---
I see the target milestone is 7.3, but this bug is still marked NEW. Has there
been any further thought on this? I realise this is a tough one, but we've had
to either disable LTO, or roll back to c++14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80837
Matt Godbolt changed:
What|Removed |Added
CC||matt at godbolt dot org
--- Comment #7
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: matt at ookypooky dot com
Target Milestone: ---
The following code:
--
#include
#include
int main ()
{
double x = 123.456;
std::cout << std::cbrt (x) - std::cbrt (1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82299
--- Comment #7 from Matt Godbolt ---
Perfect! Thanks for clarifying, sorry for the confusion :)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82299
--- Comment #5 from Matt Godbolt ---
NB the proposed patch above has a test that compiles with -std=c++11 -- this
bug only occurs with std=c++1z, not 11. The fix may be right, but I wonder if
the test needs to be changed? Unless I've misread
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: matt at godbolt dot org
Target Milestone: ---
The follow code:
```
// compile with -Wuseless-cast -std=c++1z
enum Enum : char { A = 0, B = 1 };
struct S {
Enum e { Enum
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: matt at godbolt dot org
Target Milestone: ---
Consider the C++ code:
```
#include
#include
constexpr auto get_tokens()
{
return std::array<char, 53>{"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81021
--- Comment #34 from Matt Godbolt ---
Confirmed this fixes all the issues we were seeing. Thanks!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48227
--- Comment #5 from Matt Godbolt ---
Seems to have been fixed in 4.9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81021
--- Comment #32 from Matt Godbolt ---
Thanks! One thing, I probably misunderstand this, but you've put 7.1 in "known
to work" above: is this on purpose? 7.1 is the version the issue comes up in, I
assume it'll be fixed in an upcoming 7.2 release?
On Sun, Jun 18, 2017 at 10:56 AM, Uros Bizjak <ubiz...@gmail.com> wrote:
> On Fri, Jun 16, 2017 at 11:42 PM, Matt Turner <matts...@gmail.com> wrote:
>> Currently -march=native selects -march=broadwell on Kaby Lake systems,
>> since its model numbers are missing from the
gcc/
* config/i386/driver-i386.c (host_detect_local_cpu): Assume
skylake for unknown models with clflushopt.
---
gcc/config/i386/driver-i386.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/gcc/config/i386/driver-i386.c b/gcc/config/i386/driver-i386.c
index
Currently -march=native selects -march=broadwell on Kaby Lake systems,
since its model numbers are missing from the switch statement. It falls
back to the default case and chooses -march=broadwell because of the
presence of the ADX instruction set.
gcc/
* config/i386/driver-i386.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81004
--- Comment #14 from Matt Godbolt ---
I've just hit this same issue too (in only one of several projects I build with
7.1 and LTO). If anyone has any thoughts at a workaround I'd be very
appreciative. Thanks!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81021
--- Comment #2 from Matt Godbolt ---
Thanks Martin!
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: matt at godbolt dot org
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at
gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80629
--- Comment #1 from Matt Godbolt ---
This bug is noticeable in Compiler Explorer: https://godbolt.org/g/scFj7A for
example; the function is not colourised as CE uses the .locs to track how the
source lines map to asm. One can also see how
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: matt at godbolt dot org
Target Milestone: ---
Firstly; I appreciate how tricky it is to keep track of debug information in
the presence of optimization and inlining, but I wonder if there's something
specific happening
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80559
--- Comment #2 from Matt Godbolt ---
Thanks: it seems the command-line parameter `-std=c++1z` is needed to trigger
the segfault.
https://godbolt.org/g/6oDO6X
Apologies for not realising this in the initial report.
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: matt at godbolt dot org
Target Milestone: ---
Build: GCC v8.0.0 (built from source 20170428)
The following code:
#include
template
struct Stack_t {};
template
constexpr
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: matt at godbolt dot org
Target Milestone: ---
Consider the following (unusual) code:
--
struct Foo { static constexpr bool hasBar() { return true; } };
void test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70834
--- Comment #2 from Matt Godbolt ---
if constexpr is of course the right solution here, for certain.
I appreciate the compiler determining which if() branch to take in the
non-constexpr case is tricky.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70909
--- Comment #16 from Matt Godbolt ---
Just to be clear; I've been told GCC 6.2 is not required to compile the code I
linked; the earliest compiler it has been repro'd with is 4.9 (though we
haven't tested further back). It's also the mangled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70909
--- Comment #14 from Matt Godbolt ---
Created attachment 40101
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40101=edit
compile with gcc 6.2 -std=c++14
This reproduces the issue. Compile with g++ 6.2 and -std=c++14 to create a file
wh
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70909
--- Comment #13 from Matt Godbolt ---
We will try and get a small repro case. It comes from open source software:
it's from the compiling_tests.cpp program in trompeloeil
(https://github.com/rollbear/trompeloeil/blob/master/compiling_tests.cpp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61414
Matt Godbolt changed:
What|Removed |Added
CC||matt at godbolt dot org
--- Comment #8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70909
Matt Godbolt changed:
What|Removed |Added
CC||matt at godbolt dot org
--- Comment #4
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: matt at matthewfagan dot com
Target Milestone: ---
GCC incorrectly sizes 64-bit integer template parameters, resulting in spurious
warnings (and perhaps incorrect code generation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69188
--- Comment #15 from Matt Godbolt ---
I just tried on GCC 6.1; same issue (lto-symtab.c:119 similarly to anthony's
snapshot build).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69188
--- Comment #14 from Matt Godbolt ---
We confirm seeing the same issue (a large proprietary system, when building
optimized tests at -O3 but linking against test libraries compiled with -O2).
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: matt at godbolt dot org
Target Milestone: ---
Consider some code which tries to placement-new into an internal buffer (if the
object fits), else uses the heap:
--
#include
struct Test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70647
--- Comment #4 from Matt Godbolt ---
Agreed re: cast/FE.
I couldn't quite get your example to fail as the "o" parameter is unusued
(which would be a good clue!
#include // for std::move
struct B {
int a; int b;
B(B &am
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70647
--- Comment #2 from Matt Godbolt ---
Thanks Manuel. Interestingly this does elicit a warning:
struct B {
int a; int b;
B(B &)
: a(static_cast(a)),
b(std::move(o.b)) {}
};
but this does not:
struct B {
int a; int b;
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: matt at godbolt dot org
Target Milestone: ---
Consider the following code:
#include // for std::move
struct A {
int a; int b;
A(A &)
: a(a), // I get a warning here...
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: matt at bitbashing dot io
Target Milestone: ---
Consider the following test case:
#include
atomic_int foo;
void plusPlus(void)
{
foo++;
}
void fetchAdd(void
1 - 100 of 640 matches
Mail list logo
