https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119644
--- Comment #3 from Geoff Wozniak ---
> This should be an error while expanding into RTL and it is the backend
> responsibility for that.
Sorry. Wasn't exactly sure where to put it.
> So don't use -mgeneral-regs-only if you need to use FP at
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: gcc-bugzilla at geoff dot wozniak.ca
Target Milestone: ---
The following function built with current mainline code (commit
5b9fd65726afef37ed6a6e39f0ceb7f47160ba07
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: campbell+gcc-bugzilla at mumble dot net
Target Milestone: ---
std::ios::sync_with_stdio(false) creates a stdio_filebuf over stdin with mode
in:
182 new
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gcc-bugzilla at mkarcher dot dialup.fu-berlin.de
Target Milestone: ---
This example program compiles without any kind of warning in gcc:
static char x = 0xD8;
int main
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113244
--- Comment #2 from Marcus Holland-Moritz ---
(In reply to Andrew Pinski from comment #1)
> I suspect this is because libstdc++.so is NOT instrumented for TSAN.
This is certainly possible.
Is there documentation available on how to build a sui
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: gcc-bugzilla at mhxnet dot de
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86030
--- Comment #20 from John Soo ---
I think that in order to really rid gcc of the E2BIG problem on linux,
COLLECT_*_OPTIONS will have to be deprecated and removed. This is particularly
a problem when executing spec files, it seems.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86030
--- Comment #19 from John Soo ---
I verified the proposed patch sent argv through @file, but COLLECT_GCC_OPTIONS
still caused E2BIG. In the failing execve, COLLECT_GCC_OPTIONS was 134227
characters long.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86030
--- Comment #18 from John Soo ---
And actually the proposed patch is not conservative enough, because the size of
the strings in argv/env also matter.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86030
--- Comment #17 from John Soo ---
Created attachment 55910
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55910&action=edit
libiberty, Unix: pass argv over ARG_MAX through an @file
This does not handle environ being too large, but it is an
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86030
--- Comment #16 from John Soo ---
It is actually somewhat likely that ARG_MAX will be hit when running on linux
because it is hit when the stack can't contain enough pointers to contain argv
and environ (see exec.c in the kernel
https://github.co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86030
--- Comment #15 from John Soo ---
Just for some context on what limit is hit: under man sysconf you will find a
description of ARG_MAX
(https://www.man7.org/linux/man-pages/man3/sysconf.3.html)
> ARG_MAX - _SC_ARG_MAX
> The maximum length of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86030
--- Comment #14 from John Soo ---
> Here though it seems that you are dealing with another sort of limit which is
> much larger (I have seen 128K being mentioned on the GH page).If this
> somehow corrupts the command line, it wouldn't help
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86030
--- Comment #12 from John Soo ---
I think the general problem in that issue is that ARG_MAX is not respected when
the driver (or any subprocess) execs things on linux. I think that it is not
the same as the original issue here, though.
> I don't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86030
--- Comment #10 from John Soo ---
I'm also not sure
https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=180ebb8a24d24fc5b105f2257d6216f6dfde62df
fixes the collect bug because collect uses collect_execute instead of the pex_*
exec functions.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86030
--- Comment #9 from John Soo ---
Would a patch for unix doing something similar to
https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=180ebb8a24d24fc5b105f2257d6216f6dfde62df
be accepted? I am happy to start working on something like it but I have
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86030
--- Comment #8 from John Soo ---
> Also, it is typically Windows that suffers from this limitation of command
> line length.
Ok that may be true but I am effected by this on linux as are quite a few
others in this issue https://github.com/NixOS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86030
John Soo changed:
What|Removed |Added
CC||john.soo+gcc-bugzilla@arist
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110970
--- Comment #2 from gcc-bugzilla at zulan dot net ---
Yes, apologies for the missing information
clang version 15.0.7
g++ (GCC) 13.2.1 20230801
(Arch)
According to https://clang.llvm.org/cxx_status.html
P0634R3 / "Down with typename
13.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: gcc-bugzilla at zulan dot net
Target Milestone: ---
Using clang with the current libstdc++ and c++23 (2b) fails:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110878
--- Comment #3 from Taylor R Campbell
---
(In reply to Andrew Pinski from comment #1)
> There is another bug report dealing with this. But IIRC this is an expected
> warning as foo is being passed an array which is size 16 but then passed to
>
: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: campbell+gcc-bugzilla at mumble dot net
Target Milestone: ---
Isolated from code passing a pointer into an array and the length of the array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110592
--- Comment #10 from Taylor R Campbell ---
(In reply to Eric Botcazou from comment #9)
> > I don't understand, how would that help? As I understand it, whenever
> > `-mcpu=v7', the memory model is just ignored -- even if we set it to TSO --
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110592
--- Comment #7 from Taylor R Campbell
---
> Sorry, no, NetBSD/sparc is too obscure a platform to justify changing the
> default for the entire compiler. But you can do like Linux & Solaris and
> add sparc/tso.h to the tm_file list of sparc-*-n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110592
Taylor R Campbell changed:
What|Removed |Added
CC||campbell+gcc-bugzilla@mumbl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110441
Matt Cross changed:
What|Removed |Added
CC||matt.cross+gcc-bugzilla@gma
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gcc-bugzilla at richardebeling dot de
Target Milestone: ---
This code snippet does not compile with GCC 13.1 and the current "trunk"
version on godbolt (see https://god
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107532
--- Comment #29 from Andrey Alekseenko ---
> it seems like we should treat *any* class with a reference member as a
> reference wrapper.
And any class with a pointer, I suspect.
This is a reduced/simplified example from our codebase still tr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108483
--- Comment #3 from Michael Karcher ---
Thanks for the pointer to #4210. Note that 4210 is slightly different, though.
In that report, the condition and the warnable expression are in different
statements, and https://gcc.gnu.org/bugzilla/show_b
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gcc-bugzilla at mkarcher dot dialup.fu-berlin.de
Target Milestone: ---
Created attachment 54318
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54318&action=edit
minimal exa
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gcc-bugzilla at al42and dot me
Target Milestone: ---
The following code compiles fine with Clang 15 and GCC 12 and outputs "3" when
run.
With GCC 13, it produces
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107732
--- Comment #2 from Andrey Alekseenko ---
@Aldy Hernandez, thank you. Can confirm that your patch fully resolves the
issue for me.
++
Assignee: unassigned at gcc dot gnu.org
Reporter: gcc-bugzilla at al42and dot me
Target Milestone: ---
Created attachment 53916
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53916&action=edit
Preprocessed source (-freport-bug)
The following code (reduced
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107466
--- Comment #3 from Mara Sophie Grosch ---
Standard explicitly allows using unsigned short though:
https://en.cppreference.com/w/cpp/numeric/random/subtract_with_carry_engine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103081
--- Comment #9 from Chris MacGregor
---
With the testcase I just attached, using 13.0.0 20221030 via Godbolt:
https://godbolt.org/z/8Y4cr6MxY
: In instantiation of 'Event::Event(EventCat, auto:1) [with auto:1 =
int]':
:38:32: required from h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103081
Chris MacGregor changed:
What|Removed |Added
CC||chris-gcc-bugzilla@cybermat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107460
--- Comment #4 from Chris MacGregor
---
@Andrew, how did you get the output in comment #2, with "tree check: expected
enumeral_type, have record_type in tsubst_copy" in it?
Also, should this be marked as directly a dup of 103081, rather than a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107466
Bug ID: 107466
Summary: [12 Regression] invalid -Wnarrowing error
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107460
--- Comment #1 from Chris MacGregor
---
Created attachment 53794
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53794&action=edit
preprocessed source
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: chris-gcc-bugzilla at cybermato dot com
Target Milestone: ---
Created attachment 53793
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53793&action=edit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106713
Pablo Busse changed:
What|Removed |Added
CC||gcc-bugzilla at decltype dot
org
Version: 11.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gcc-bugzilla at decltype dot org
Target Milestone: ---
Created attachment 53257
--> ht
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: jeremy-gcc-bugzilla at sawicki dot us
Target Milestone: ---
Created attachment 51391
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51391&action=edit
Reproducib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95048
--- Comment #11 from Christian Fersch ---
Would you accept a patch that implements my solution from comment 6? It seems
to me like that would be an improvement over the current situation.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99157
kratenko changed:
What|Removed |Added
CC||gcc-bugzilla at garstig dot org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96555
Eelis changed:
What|Removed |Added
CC||gcc-bugzilla at contacts dot
eelis
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96299
henrik changed:
What|Removed |Added
CC||gcc-bugzilla at mysko dot org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95048
--- Comment #9 from Christian Fersch ---
But is it possible to query the value of -fwide-exec-charset? I had quick look
and couldn't find anything.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95048
Christian Fersch changed:
What|Removed |Added
CC||gcc-bugzilla at m dot
chronial.de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96606
RyuaNerin changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96606
--- Comment #1 from RyuaNerin ---
Created attachment 49059
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49059&action=edit
msvc vs gcc
Assignee: unassigned at gcc dot gnu.org
Reporter: gcc-bugzilla at ryuar dot in
Target Milestone: ---
Created attachment 49058
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49058&action=edit
source code.
Hello.
The shift operator doesn't work correctly in som
Version: 10.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gcc-bugzilla at mysko dot org
Target Milestone: ---
The following sample fails to compile with GCC 10.1
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: pieter+gcc-bugzilla at plexis dot eu
Target Milestone: ---
Created attachment 48545
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48545&action=edit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94504
--- Comment #5 from Michael Karcher ---
I got the command line of gcc wrong. "-pie" just sets the linker flags for PIE
linking, but it does *not* compile source code as PIE. If I use "-fpie",
garbage collection does what it is supposed to do.
As
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94504
--- Comment #3 from Michael Karcher ---
(In reply to Richard Biener from comment #2)
> Huh, looking at the assembly & the object file this seems to be fully a linker
> issue who seems to be responsible for building the GOT. I suggest to move
> t
: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: gcc-bugzilla at mkarcher dot dialup.fu-berlin.de
Target Milestone: ---
I try to compile the following test program using
gcc -ffunction-sections
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94409
--- Comment #4 from gcc-bugzilla at vlasiu dot net ---
That's really bad news for us. Well, we'll wait for a patch and maybe we are
going to backport-it. If it's going to be too complicated we are probably going
to switch to one o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94409
--- Comment #2 from gcc-bugzilla at vlasiu dot net ---
(In reply to Jonathan Wakely from comment #1)
> N.B. GCC 7 is no longer supported and will not be fixed (but the bug is also
> present in supported releases).
We are going to switch s
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gcc-bugzilla at vlasiu dot net
Target Milestone: ---
std::regexp constructor fail on AIX (Japanese). Works fine for English,
Spanish, Italian, French and German languages.
$ gcc -v
Using
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92143
--- Comment #8 from Daryl Haresign ---
(In reply to Jonathan Wakely from comment #5)
> C11 6.2.8 says "Valid alignments
> include only those values returned by an _Alignof expression for fundamental
> types, plus an additional implementation-defi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92143
--- Comment #4 from Daryl Haresign ---
As for conformance, the latest C draft says:
The aligned_alloc function allocates space for an object whose alignment is
specified by alignment, whose size is specified by size, and whose value is
indetermi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92143
--- Comment #3 from Daryl Haresign ---
$ g++-9 -E -dM test.cc | grep ALIGNED
#define _GLIBCXX_HAVE_ALIGNED_ALLOC 1
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gcc-bugzilla at daryl dot haresign.com
Target Milestone: ---
The following code throws a std::bad_alloc on macOS (seen via GCC 9.2 installed
with Homebrew, on macOS Catalina 10.15):
#include
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91988
--- Comment #1 from Tobias Gödderz
---
Happens with GCC 9.1.0 as well.
Assignee: unassigned at gcc dot gnu.org
Reporter: gcc-bugzilla at tobias dot goedderz.info
CC: marxin at gcc dot gnu.org
Target Milestone: ---
Inlining fails with LTO when there is an argument with a destructor. This seems
unintentional to me, given the following behaviour
: unassigned at gcc dot gnu.org
Reporter: gcc-bugzilla at tobias dot goedderz.info
Target Milestone: ---
Created attachment 46684
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46684&action=edit
Preprocessed source code
Hi,
I'm experiencing g++ segfaults during compilatio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89635
Lucas Werkmeister changed:
What|Removed |Added
CC||gcc-bugzilla@lucaswerkmeist
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: gcc-bugzilla at mkarcher dot dialup.fu-berlin.de
Target Milestone: ---
As noted while filing a bug on rustc because rustc does not correctly implement
the Sparc64 ABI regarding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85696
--- Comment #2 from gcc-bugzilla at zulan dot net ---
Created attachment 44087
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44087&action=edit
minimal example
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85696
gcc-bugzilla at zulan dot net changed:
What|Removed |Added
Attachment #44085|0 |1
is obsolete
ormal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gcc-bugzilla at zulan dot net
Target Milestone: ---
Created attachment 44085
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44085&action=edit
gcc -v (Archlinux)
The follo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84222
--- Comment #2 from Daryl Haresign ---
See also bug 79817.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84222
--- Comment #1 from Daryl Haresign ---
Additionally, any external use of a static method of a deprecated class should
probably (but does not currently) emit a warning (Clang emits a warning).
class [[deprecated]] C {
public:
void fn() {}
}
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gcc-bugzilla at daryl dot haresign.com
Target Milestone: ---
If I mark a class with the [[deprecated]] annotation, it complains when the
class uses its own name in the implementation:
class
: preprocessor
Assignee: unassigned at gcc dot gnu.org
Reporter: tim+gcc-bugzilla at centricular dot com
Target Milestone: ---
gcc (Debian 6.3.0-4) 6.3.0 20170121
cpp (Debian 6.3.0-4) 6.3.0 20170121
Also happens with latest gcc7 snapshot on https://gcc.godbolt.org/
Linux 4.9.0-1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79254
--- Comment #7 from Daryl Haresign ---
I would also be inclined to reverse your Guard: have it take 'this', have an
'activate' method which swaps in the new values, have a 'deactivate' method
which releases the memory, and have its destructor swa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79254
--- Comment #6 from Daryl Haresign ---
I guess you don't want _M_copy_assign to be public, either.
onent: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: gcc-bugzilla at daryl dot haresign.com
Target Milestone: ---
Assigning one string to another, where they have non-equal
propagate-on-copy-assignment allocators, does a `_M_destroy()`, followed by an
`assign()`.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79037
--- Comment #10 from Michael Karcher ---
OK, I got it. I retract my last comment.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79037
--- Comment #8 from Michael Karcher ---
The patch looks like it should work fine, I guess John Paul Adrian Glaubitz is
going to test it soon. But I wonder whether the determination of alignment is
in types.cc really needed, as user-specified alig
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79037
--- Comment #5 from Michael Karcher ---
The root issue now is that the ABI gcc implements on m68k is incompatible with
the Go runtime shipped with gcc.
The Go runtime uses the lowest two bits in the type information pointer as
flags (called PREC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78966
Eelis changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78966
--- Comment #2 from Eelis ---
The testcase was a minimized version of the (imho innocuous looking):
#include
#include
template
std::ostream & operator<<(std::ostream &, std::variant const &);
int main() { std::cout << std::endl; }
++
Assignee: unassigned at gcc dot gnu.org
Reporter: gcc-bugzilla at contacts dot eelis.net
Target Milestone: ---
Consider:
template
struct vari
{
static_assert(sizeof...(TT) != 0, "bleh");
};
template struct X {};
void f(void(*)(X));
template v
iority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gcc-bugzilla at minijackson dot 33mail.com
Target Milestone: ---
GCC version and system:
gcc (Gentoo 6.2.0-r1 p1.1) 6.2.0
Compilation options:
-altivec -awt -cilk cxx -debug -doc -fixed-point fortr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42490
Eelis changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=10619
Eelis changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: gcc-bugzilla at contacts dot eelis.net
Target Milestone: ---
Both the reservoir sampling and the selection sampling implementations use a
uniform_int_distribution<_Size> to generate integers distributed ov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33952
--- Comment #5 from Eelis ---
(In reply to David Malcolm from comment #4)
> Eelis: FWIW, gcc has a -fmax-errors=n option; I wonder if setting that to 1
> might be a better fit for geordi? (just thinking aloud here).
It also truncates the error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77436
--- Comment #3 from Lucas Werkmeister
---
Sorry, I wasn’t aware that wrapping is defined but overflow isn’t. The bug also
happens if the summand type is changed to long (or, precisely, int64_t), where
overflow shouldn’t happen (we’re adding at m
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gcc-bugzilla at lucaswerkmeister dot de
Target Milestone: ---
Created attachment 39529
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39529&action=edit
Preprocessed version of a small C program that sums
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: gcc-bugzilla at chwress dot at
Target Milestone: ---
Created attachment 38942
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38942&action=edit
A small program demonstrating the issue
We (Fabian Ya
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71173
--- Comment #6 from gcc-bugzilla at zulan dot net ---
As far as I can tell it is fixed. Tested with Archlinux "6.1.1" which seems to
be git/1bbd3999).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59832
gcc-bugzilla at zulan dot net changed:
What|Removed |Added
CC||gcc-bugzilla at zulan dot
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: gcc-bugzilla at mkarcher dot dialup.fu-berlin.de
Target Milestone: ---
Created attachment 36537
--> https://gcc.gnu.org/bugzi
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gcc-bugzilla at contacts dot eelis.net
Target Milestone: ---
Consider:
#include
#include
struct X
{
bool alive = true;
~X() { alive = false; }
explicit operator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67002
--- Comment #16 from Michael Karcher ---
The bug seems to be quite similar to the infamous "sloth that was dropped on
the head as a baby"-bug Linus discovered (https://lkml.org/lkml/2014/7/24/584 ,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=619
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67002
Michael Karcher changed:
What|Removed |Added
CC||gcc-bugzilla at mkarcher dot
dialu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65371
--- Comment #4 from Stuart ---
The assembly generated from Comment #1 looks good.
However, the assembly generated from Comment #3 hasn't improved, it still
contains the unnecessary mov instruction on line 2 (mov r2, r3).
The first instruction m
1 - 100 of 481 matches
Mail list logo
