https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109577
--- Comment #9 from nightstrike ---
(In reply to David Malcolm from comment #8)
> Should be fixed for GCC 13 (for the upcoming GCC 13.3) by the above patches.
Did you miss my comment #5 highlighting the need to adjust the declaration of
malloc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110014
--- Comment #6 from nightstrike ---
(In reply to David Malcolm from comment #5)
> Should be fixed for GCC 13 (for the upcoming GCC 13.3) by the above patch.
Did you miss my comment #3 that highlighted the problem due to assuming that
size_t ==
++
Assignee: unassigned at gcc dot gnu.org
Reporter: nightstrike at gmail dot com
Target Milestone: ---
See https://gcc.gnu.org/pipermail/gcc-help/2024-March/143369.html for
reference.
The documentation at https://gcc.gnu.org/onlinedocs/gcc/Variable-Length.html
states that VLAs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108644
nightstrike changed:
What|Removed |Added
CC||nightstrike at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43613
--- Comment #10 from nightstrike ---
Patch thread started here:
https://gcc.gnu.org/pipermail/gcc-patches/2024-February/644674.html
https://inbox.sourceware.org/gcc-patches/4700e066-1b50-4e7b-92f7-d8c33a330...@gmail.com/
and ended with this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105755
--- Comment #6 from nightstrike ---
(In reply to nightstrike from comment #5)
> If I open your godbolt links, they aren't using a Windows target compiler,
> so they aren't exercising an LLP64 target.
For instance:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105755
--- Comment #5 from nightstrike ---
(In reply to David Malcolm from comment #4)
> Looks like this was fixed sometime in GCC 13; resolving as WORKSFORME.
>
> Feel free to reopen if you have a reproducer that triggers on a more recent
> GCC.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022
--- Comment #35 from nightstrike ---
(In reply to anlauf from comment #34)
> Are you sure that it finds the right new libgfortran?
Good call. I did a make install first and re-ran it, and they all pass now.
Sorry for the noise, this is an
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022
--- Comment #33 from nightstrike ---
I modified the test further to just print which ones would have called stop.
Almost, but not all, do:
stop 2
stop 3
stop 4
stop 7
stop 8
stop 9
stop 10
stop 11
stop 12
stop 13
stop 15
stop 20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022
--- Comment #32 from nightstrike ---
(In reply to anlauf from comment #31)
> (In reply to nightstrike from comment #30)
> > (In reply to GCC Commits from comment #29)
> > > * gfortran.dg/pr111022.f90: New test.
> >
> > This new
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022
nightstrike changed:
What|Removed |Added
CC||nightstrike at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113624
nightstrike changed:
What|Removed |Added
Known to fail||11.3.0, 12.2.0, 13.0, 14.0
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105755
nightstrike changed:
What|Removed |Added
CC||nightstrike at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109577
nightstrike changed:
What|Removed |Added
CC||nightstrike at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110014
nightstrike changed:
What|Removed |Added
CC||nightstrike at gmail dot com
--- Comment
: testsuite-fail
Severity: normal
Priority: P3
Component: testsuite
Assignee: unassigned at gcc dot gnu.org
Reporter: nightstrike at gmail dot com
Target Milestone: ---
This test uses an incorrect declaration for calloc():
void *calloc(long, long
, testsuite-fail
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: nightstrike at gmail dot com
CC: ktietz at gcc dot gnu.org
Target Milestone: ---
Target: *-*-mingw
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: nightstrike at gmail dot com
CC: dmalcolm at gcc dot gnu.org
Target Milestone: ---
The original PR7356 highlighted a problem where a diagnostic
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: nightstrike at gmail dot com
Target Milestone: ---
Created attachment 57235
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57235=edit
output of -freport-bug
A test from the testsuite is failing for ex
++
Assignee: unassigned at gcc dot gnu.org
Reporter: nightstrike at gmail dot com
Target Milestone: ---
See PR 67846. The original PR highlighted an ICE, and we do not ICE on
Windows, but we don't error out either. We can achieve the Linux behavior with
-fno-ms-extensions
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: nightstrike at gmail dot com
Target Milestone: ---
(Probably related to PR4)
The absolute.cc test fails this assertion:
VERIFY( absolute(p).is_absolute() );
on the second
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100058
nightstrike changed:
What|Removed |Added
CC||nightstrike at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113549
--- Comment #4 from nightstrike ---
(In reply to Andrew Pinski from comment #3)
> Either the stack size or the stack alignment issue.
>
> I am suspecting a stack alignement issue.
Possibly related: PR110273
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113548
--- Comment #3 from nightstrike ---
Seeing as how this is a testsuite issue, it seems that the crash in the same
location applies to the following:
FAIL: gcc.dg/vect/vect-ifcvt-19.c (internal compiler error: in build2, at
tree.cc:5097)
FAIL:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113549
--- Comment #2 from nightstrike ---
Test 16e uses double instead of float, which also crashes.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113549
--- Comment #1 from nightstrike ---
Created attachment 57188
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57188=edit
Failing source for easier copying
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: nightstrike at gmail dot com
Target Milestone: ---
Created attachment 57187
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57187=edit
Assembly output
The vect-simd-clone-16
: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: nightstrike at gmail dot com
Target Milestone: ---
Created attachment 57186
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57186=edit
Preprocessed source from -freport-bug
ICE during testsuite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107603
nightstrike changed:
What|Removed |Added
CC||nightstrike at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59425
nightstrike changed:
What|Removed |Added
CC||nightstrike at gmail dot com
--- Comment
Assignee: unassigned at gcc dot gnu.org
Reporter: nightstrike at gmail dot com
CC: dkm at gcc dot gnu.org
Target Milestone: ---
g:r11-4313-gd08d481912b9a2 defined POLLPRI to zero on Windows, stating in the
commit message "Define POLLPRI as zero on Wi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65257
--- Comment #2 from nightstrike ---
I should clarify that I tested this with mingw-w64, not mingw.org where the bug
was originally reported.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65257
nightstrike changed:
What|Removed |Added
CC||nightstrike at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43613
nightstrike changed:
What|Removed |Added
CC||nightstrike at gmail dot com
--- Comment
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: nightstrike at gmail dot com
Target Milestone: ---
#include
int f[262144]; auto g(void) { return std::to_array(f); }
(Thanks to Andrew for help reducing!)
Baseline run:
$ time g++ test.cc -std=gnu++20 -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69639
--- Comment #18 from nightstrike ---
(In reply to nightstrike from comment #9)
> This affects 8-trunk on x86_64 cygwin, as well. The default size of the
> stack for cc1 is:
>
> $ peflags -x /tmp/b2/gcc/cc1.exe
> /tmp/b2/gcc/cc1.exe: stack
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: nightstrike at gmail dot com
Target Milestone: ---
Created attachment 54541
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54541=edit
preprocessed source f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83286
nightstrike changed:
What|Removed |Added
CC||nightstrike at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90458
--- Comment #8 from nightstrike ---
FYI, this is the same as the failure in gcc/testsuite/gcc.dg/stack-check-16.c:
(running this under Wine)
during RTL pass: final
gcc.dg/stack-check-16.c:36:1: internal compiler error: in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108675
--- Comment #9 from nightstrike ---
I understand it's not ideal based on comment #6, but this fixes all the tests:
diff --git a/gcc/testsuite/gcc.c-torture/execute/builtins/lib/fprintf.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108709
--- Comment #1 from nightstrike ---
Perhaps these are separate bugs, but:
1) gcc.dg/analyzer/pipe-manpages.c will need similar improvements
2) gcc.dg/analyzer/pipe-void-return.c passes with an incorrect declaration for
pipe(), implying that
Assignee: dmalcolm at gcc dot gnu.org
Reporter: nightstrike at gmail dot com
Target Milestone: ---
This test fails on Windows for lack of fork. It actually fails for not having
pipe(), also, but _pipe() does the job well enough, so that fix is a simple
#define. It is not very
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: nightstrike at gmail dot com
Target Milestone: ---
The analyzer test fd-access-mode-target-headers.c fails on mingw-w64 due to the
following:
FAIL: gcc.dg/analyzer/fd-access-mode-target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107602
--- Comment #2 from nightstrike ---
Better link(In reply to nightstrike from comment #1)
> Reverting 186d43a78e945ebe9fbe217fc341847af7f95d30 fixes this problem at
> least for me
Better link: r255433
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107602
nightstrike changed:
What|Removed |Added
CC||nightstrike at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108675
--- Comment #8 from nightstrike ---
(In reply to LIU Hao from comment #7)
> (In reply to nightstrike from comment #5)
> > (In reply to LIU Hao from comment #4)
> > > Does it make any sense to remove `#include ` from
> > >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108675
--- Comment #5 from nightstrike ---
(In reply to LIU Hao from comment #4)
> Does it make any sense to remove `#include ` from
> 'gcc.c-torture/execute/builtins/lib/fprintf.c' ?
That will prevent the FILE type from existing, so the replacement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108675
--- Comment #2 from nightstrike ---
(In reply to Richard Biener from comment #1)
> These tests are known to be a bit awkwardly implemented to check for
> optimizations done ...
How would you do it if you were writing the test today?
> There
Severity: normal
Priority: P3
Component: testsuite
Assignee: unassigned at gcc dot gnu.org
Reporter: nightstrike at gmail dot com
Target Milestone: ---
Failing tests:
gcc.c-torture/execute/builtins/printf.c
gcc.c-torture/execute/builtins/fprintf.c
gcc.c-torture
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90826
nightstrike changed:
What|Removed |Added
CC||nightstrike at gmail dot com
--- Comment
: testsuite
Assignee: unassigned at gcc dot gnu.org
Reporter: nightstrike at gmail dot com
Target Milestone: ---
Both bitfield-3.m and bitfield-5.m appear to fail for the same reason on
x86_64-w64-mingw32 (cross compiled from linux, if it matters). The tests each
contain multiple
Assignee: ibuclaw at gdcproject dot org
Reporter: nightstrike at gmail dot com
Target Milestone: ---
See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99794 for reference.
This PR is tracking the state of building libphobos on cygwin using 11.3, the
last compiler that can
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108300
nightstrike changed:
What|Removed |Added
CC||nightstrike at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82028
nightstrike changed:
What|Removed |Added
CC||nightstrike at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90256
nightstrike changed:
What|Removed |Added
CC||nightstrike at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99794
--- Comment #3 from nightstrike ---
Hm, looks like it *IS* in 11. I was confused by the PR being open and the
version stating 11, thinking that it still wasn't applied. So the remaining
issues then are building on cygwin. But at least on a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99794
nightstrike changed:
What|Removed |Added
CC||nightstrike at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108204
--- Comment #4 from nightstrike ---
(In reply to Richard Biener from comment #3)
> I'd suggest to add a dg-additional-options -fno-ms-extensions to the test
> then.
We certainly can (well, Jon can :P), but shouldn't the ms extensions
,
||nightstrike at gmail dot com
--- Comment #5 from nightstrike ---
(In reply to cqwrteur from comment #4)
> (In reply to Andrew Pinski from comment #3)
> > cygwin was improved here:
> > https://sourceware.org/git/gitweb.cgi?p=newlib-cy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108192
--- Comment #3 from nightstrike ---
Created attachment 54209
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54209=edit
Patch to change printf to puts so it works everywhere
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108152
nightstrike changed:
What|Removed |Added
CC||10walls at gmail dot com
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107974
nightstrike changed:
What|Removed |Added
CC||nightstrike at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108150
nightstrike changed:
What|Removed |Added
CC||10walls at gmail dot com
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102993
nightstrike changed:
What|Removed |Added
CC||nightstrike at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103327
nightstrike changed:
What|Removed |Added
CC||nightstrike at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100427
--- Comment #11 from nightstrike ---
Possible duplicate of PR39947
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100427
nightstrike changed:
What|Removed |Added
CC||nightstrike at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106395
nightstrike changed:
What|Removed |Added
CC||nightstrike at gmail dot com
--- Comment
,
||nightstrike at gmail dot com
--- Comment #2 from nightstrike ---
Is this before or after this patch set was applied?
https://gcc.gnu.org/pipermail/gcc-patches/2022-December/609116.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108207
--- Comment #1 from nightstrike ---
Ah, Andrew, before you beat me to it... this doesn't ICE if you pass
-fno-ms-extensions, and it does ICE on Linux if you pass -fms-extensions
: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: nightstrike at gmail dot com
Target Milestone: ---
All variants of this test fail (98, 14, 17, 20)
// Target: x86_64-w64-mingw32
// Configured with: ../configure --disable-nls --with-sysroot=/tmp/rtmingw
--target=x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108204
--- Comment #2 from nightstrike ---
(In reply to Andrew Pinski from comment #1)
> Try with -fno-ms-extensions or try -fms-extension on Linux.
Hey, we have a winner! -fms-extension on Linux results in the bad error, and
-fno-ms-extensions on
++
Assignee: unassigned at gcc dot gnu.org
Reporter: nightstrike at gmail dot com
Target Milestone: ---
All of the pr84973-2.C tests fail on mingw. They give the output:
g++.dg/template/pr84973-2.C: In instantiation of 'void a()::c::b() [with int
= 0]':
g++.dg/template
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: nightstrike at gmail dot com
Target Milestone: ---
Circa v4.5, some mingw-w64 users discovered an issue with printf functions and
g++. Addressing this resulted in a kludge on the mingw-w64 headers side, but
this should
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101854
--- Comment #11 from nightstrike ---
(In reply to Martin Sebor from comment #9)
> Fixed for GCC 12. The patch is far too intrusive to backport but the
> following should fix the problem in GCC 11:
Would you mind applying it to 11? Thanks!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108192
--- Comment #2 from nightstrike ---
(In reply to H.J. Lu from comment #1)
> Since Windows doesn't support IBT, this test can be limited to Linux.
I don't know what IBT is, but if I change the two printf's to puts(), the tests
pass. So, maybe
Priority: P3
Component: testsuite
Assignee: unassigned at gcc dot gnu.org
Reporter: nightstrike at gmail dot com
Target Milestone: ---
Created attachment 54139
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54139=edit
cet-notrack-1.s
g++.dg/cet-notrack-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108190
--- Comment #5 from nightstrike ---
Created attachment 54138
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54138=edit
avx512vl-pr54700-1b.s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108190
--- Comment #4 from nightstrike ---
Created attachment 54137
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54137=edit
avx512vl-pr54700-1a.s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108190
--- Comment #3 from nightstrike ---
Created attachment 54136
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54136=edit
avx2-pr54700-1.s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108190
--- Comment #1 from nightstrike ---
Created attachment 54135
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54135=edit
avx-pr54700-1.s
Assignee: unassigned at gcc dot gnu.org
Reporter: nightstrike at gmail dot com
Target Milestone: ---
Created attachment 54134
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54134=edit
asm output 1
The following are a collection of failures from running PR54700 tests on a
li
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108152
--- Comment #2 from nightstrike ---
(In reply to Andrew Pinski from comment #1)
> { dg-options "" }
That would remove every option, no? Do others matter, like -pedantic, or
whatever else is there?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108150
--- Comment #1 from nightstrike ---
Ok, that was dumb.. WINT_MAX is wide int max... hah. So maybe test for
__CYGWIN__ || __WIN32__
Severity: normal
Priority: P3
Component: testsuite
Assignee: unassigned at gcc dot gnu.org
Reporter: nightstrike at gmail dot com
Target Milestone: ---
gcc.dg/ipa/pr96040.c assumes that size_t is unsigned long, which it isn't for
LLP64. The following definitions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108160
--- Comment #1 from nightstrike ---
It looks like the other testsuite changes (attr-8.c, the objc/c++ tests, etc.)
should be evaluated and ported over also, so this isn't a complete fix.
Alternatively, maybe this would scale better in the
Severity: normal
Priority: P3
Component: testsuite
Assignee: unassigned at gcc dot gnu.org
Reporter: nightstrike at gmail dot com
Target Milestone: ---
Created attachment 54120
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54120=edit
Sugges
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108159
--- Comment #1 from nightstrike ---
Andrew pointed out that this is the better fix, and it does indeed work:
diff --git a/gcc/testsuite/gcc.dg/format/ms-format2.c
b/gcc/testsuite/gcc.dg/format/ms-format2.c
index 5c950522a7c..9d21d108642 100644
Priority: P3
Component: testsuite
Assignee: unassigned at gcc dot gnu.org
Reporter: nightstrike at gmail dot com
Target Milestone: ---
This is presumably a regression, as the test worked when it first went in.
However, the warning message being tested for has
Assignee: unassigned at gcc dot gnu.org
Reporter: nightstrike at gmail dot com
Target Milestone: ---
gcc.dg/pr71558.c has the following lines:
__SIZE_TYPE__ strlen (const char *);
void *malloc (__SIZE_TYPE__);
__SIZE_TYPE__ b = strlen (a);
These are good in that they support
Priority: P3
Component: testsuite
Assignee: unassigned at gcc dot gnu.org
Reporter: nightstrike at gmail dot com
Target Milestone: ---
gcc/testsuite/gcc.dg/pr64536.c contains lines such as the following:
struct S { long q; } *h;
long a, b, g, j, k, *c, *d, *e, *f
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: nightstrike at gmail dot com
Target Milestone: ---
On Windows targets, the max alignment is 8192. However, this test winds up
assuming the max alignment is much larger, causing multiple
: c
Assignee: unassigned at gcc dot gnu.org
Reporter: nightstrike at gmail dot com
Target Milestone: ---
Metabug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=warray-bounds
// Compile with GCC 12.2.0 with -O2:
//warning: ‘strcpy’ offset 0 is out of the bounds [0, 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107531
--- Comment #2 from nightstrike ---
It looks like you're right. The root cause of the problem is that in my
non-reduced case, I didn't have a copy constructor, but I had a non-default
destructor that was releasing resources twice. So it's
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: nightstrike at gmail dot com
Target Milestone: ---
The following code results in a destructor being calling twice:
#include
struct S {
S() { __builtin_printf("ctor\n"); }
~S() { __builtin_prin
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: nightstrike at gmail dot com
Target Milestone: ---
struct S {
struct Config {
int x;
};
S(Config const & cfg);
};
void f() {
S s({
.y
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: nightstrike at gmail dot com
Target Milestone: ---
Related email thread:
https://gcc.gnu.org/pipermail/gcc-help/2022-January/141117.html
I recently hit this problem:
#include
void f
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: nightstrike at gmail dot com
Target Milestone: ---
We get a warning when building for windows that should be fixed, but it
highlights that the warning is slightly mistaken about where
: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: nightstrike at gmail dot com
Target Milestone: ---
Additional details here:
https://gcc.gnu.org/pipermail/gcc/2021-August/237158.html
pr98969.c:9:19: warning: cast to pointer from integer of different size
[-Wint
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: nightstrike at gmail dot com
Target Milestone: ---
See related PR97795 and PR90458
The testsuite test stack-check-8.c fails thusly:
spawn -ignore SIGHUP /tmp/_/build/gc/gcc/xgcc -B/tmp/_/build/gc/gcc/
/tmp/_/src/gcc-git
1 - 100 of 311 matches
Mail list logo
