https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86153
Alexandre Oliva changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83239
Alexandre Oliva changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88146
Alexandre Oliva changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88535
--- Comment #13 from Eric Botcazou ---
> Hmm. I must be looking in the wrong place for documentation; are these
> explained somewhere?
>
> At https://gcc.gnu.org/install/configure.html I see a description of
>--target
> and a brief menti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86153
--- Comment #13 from Alexandre Oliva ---
Author: aoliva
Date: Wed Dec 19 06:51:41 2018
New Revision: 267252
URL: https://gcc.gnu.org/viewcvs?rev=267252&root=gcc&view=rev
Log:
[PR86153] simplify more overflow tests in VRP
PR 86153 was originally
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83239
--- Comment #23 from Alexandre Oliva ---
Author: aoliva
Date: Wed Dec 19 06:51:41 2018
New Revision: 267252
URL: https://gcc.gnu.org/viewcvs?rev=267252&root=gcc&view=rev
Log:
[PR86153] simplify more overflow tests in VRP
PR 86153 was originally
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87012
--- Comment #5 from Alexandre Oliva ---
Author: aoliva
Date: Wed Dec 19 06:51:30 2018
New Revision: 267251
URL: https://gcc.gnu.org/viewcvs?rev=267251&root=gcc&view=rev
Log:
[PR87012] canonicalize ref type for tmpl arg
When binding an object to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88146
--- Comment #10 from Alexandre Oliva ---
Author: aoliva
Date: Wed Dec 19 06:51:19 2018
New Revision: 267250
URL: https://gcc.gnu.org/viewcvs?rev=267250&root=gcc&view=rev
Log:
[PR c++/88146] do not crash synthesizing inherited ctor(...)
This pat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88549
--- Comment #2 from kargl at gcc dot gnu.org ---
(In reply to kargl from comment #1)
> There isn't an installed iso_c_binding.mod, and there
> never will be. It is generated and stored in memory
> when needed by gfortran.
Just noticed your error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88549
kargl at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88549
Bug ID: 88549
Summary: gcc doesn't install iso_c_binding.mod
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56703
Eric Gallager changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56954
Eric Gallager changed:
What|Removed |Added
Keywords||build
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80191
Eric Gallager changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78394
Eric Gallager changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65244
Eric Gallager changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88546
Martin Sebor changed:
What|Removed |Added
Keywords||diagnostic
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88521
--- Comment #8 from mateuszb at poczta dot onet.pl ---
My proposition is:
Index: gcc/config/i386/i386.c
===
--- gcc/config/i386/i386.c (revision 267245)
+++ gcc/config/i386/i386
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88535
--- Comment #12 from john henning ---
Summary:
Eric's advice worked as prescribed.
Detail:
On a SPARC Solaris 11.4 system, with a /usr/bin/gcc
that by default produces 64-bit objects, this worked for
an 8.2.0 bootstrap build:
export CC=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78394
--- Comment #12 from Jeffrey A. Law ---
Whether or not to fix as well as whether or not to warn at -O0 are a topic of
debate. I'm not sure I'm up for re-opening that can of worms right now.
I strongly believe -Wmaybe-uninitialized should contin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88548
Marek Polacek changed:
What|Removed |Added
Keywords||accepts-invalid
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88548
Bug ID: 88548
Summary: [9 Regression] this accepted in static member
functions
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88544
Richard Earnshaw changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88535
--- Comment #11 from john henning ---
> There are 3 different switches: --build, --host and --target.
Hmm. I must be looking in the wrong place for documentation; are these
explained somewhere?
At https://gcc.gnu.org/install/configure.html I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88547
Bug ID: 88547
Summary: missed optimization for vector comparisons
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: targ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88535
--- Comment #10 from Eric Botcazou ---
> Is that switch similar to or different from the switch '--target=something',
> which http://gcc.gnu.org/install/configure.html discourages from use?
There are 3 different switches: --build, --host and -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88533
--- Comment #9 from Harald Anlauf ---
(In reply to Richard Biener from comment #8)
> Created attachment 45252 [details]
> patch
>
> Even though the patch doesn't hoist the invariant condition the speed is
> back with it.
>
> Can you verify that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87759
--- Comment #4 from Jakub Jelinek ---
Author: jakub
Date: Tue Dec 18 21:48:59 2018
New Revision: 267245
URL: https://gcc.gnu.org/viewcvs?rev=267245&root=gcc&view=rev
Log:
PR rtl-optimization/87759
* gcc.target/i386/pr87759.c: Req
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88546
Jakub Jelinek changed:
What|Removed |Added
CC||jason at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88535
--- Comment #9 from john henning ---
Eric, thank you for the explicit advice, although I note that both your
examples say '--build=something'.
Is that switch similar to or different from the switch '--target=something',
which http://gcc.gnu.or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87759
--- Comment #3 from Vladimir Makarov ---
Author: vmakarov
Date: Tue Dec 18 21:20:16 2018
New Revision: 267244
URL: https://gcc.gnu.org/viewcvs?rev=267244&root=gcc&view=rev
Log:
2018-12-18 Vladimir Makarov
PR rtl-optimization/87759
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88535
--- Comment #8 from Eric Botcazou ---
> Yes, same for a bootstrap. You can bootstrap the latter with the former if
> you correctly configure the bootstrap, with explicit --build and CC="gcc
> -m32".
To be more explicit: if you want to bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88546
Bug ID: 88546
Summary: Copy attribute unusable for weakrefs
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
As
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88545
Bug ID: 88545
Summary: std::find compile to memchr in trivial random access
cases (patch)
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Hi,
I am following up to check if you're company is interested in acquiring
Attendees List of " The Trophex Show 2019" and the Total count will be
7,500.
We have Special discount price for Christmas & New Year.
Data Fields includes: Company name, Contact name, Title, Email address,
Webs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88541
--- Comment #2 from Jakub Jelinek ---
But looking at 319433-030.pdf there indeed is a VEX encoded insn that just
needs VPCLMULQDQ ISA and i386-builtins.def has that same requirement (avx +
vpclmulqdq). Testing a patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88535
--- Comment #7 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #6 from Eric Botcazou ---
>> I wonder if the configure or make process should defend against the
>> possibility that the host compiler and the compiler that we are building
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88477
Anders Granlund changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88535
--- Comment #6 from Eric Botcazou ---
> I wonder if the configure or make process should defend against the
> possibility that the host compiler and the compiler that we are building
> today have differing defaults for -m32 vs -m64.
The problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88526
Anders Granlund changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88544
Bug ID: 88544
Summary: ICE on ARM Cortex A7
Product: gcc
Version: 7.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88525
Anders Granlund changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88535
--- Comment #5 from john henning ---
Thank you for the response.
I wonder if the configure or make process should defend against the possibility
that the host compiler and the compiler that we are building today have
differing defaults for -m3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88464
--- Comment #18 from Jakub Jelinek ---
Author: jakub
Date: Tue Dec 18 18:41:26 2018
New Revision: 267239
URL: https://gcc.gnu.org/viewcvs?rev=267239&root=gcc&view=rev
Log:
PR target/88464
* config/i386/i386-builtin-types.def
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88542
Marc Glisse changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88541
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84080
Jakub Jelinek changed:
What|Removed |Added
CC||archivio.rp at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88543
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79524
--- Comment #6 from Dominique d'Humieres ---
*** Bug 81531 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81531
Dominique d'Humieres changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86656
Bug 86656 depends on bug 81531, which changed state.
Bug 81531 Summary: Multiple Invalid reads seen by valgrind on an invalid
test-case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81531
What|Removed |Added
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87881
--- Comment #15 from Dominique d'Humieres ---
> Does this do it for you?
Jakub's patch regtested cleanly. I'll test yours later this evening.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87881
--- Comment #14 from Jakub Jelinek ---
Comment on attachment 45258
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45258
A slightly more elaborate version of Jakub's patch
So, what will happen if there is more than one INQUIRY reference? T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87881
Paul Thomas changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84101
--- Comment #9 from Segher Boessenkool ---
But that is exactly the kind of thing lower-subreg is supposed to do?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84101
--- Comment #8 from Jakub Jelinek ---
(In reply to Segher Boessenkool from comment #6)
> I think subreg should deal with this. What do you mean "there aren't
> any half of TImode subregs"? insn 10 has it split at the start, and
> insn 18 at the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88543
Bug ID: 88543
Summary: ICE template function specialization with auto
returning tipe
Product: gcc
Version: 7.4.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88542
--- Comment #2 from Daniel Fruzynski ---
No, code with -ffast-math is the same.
BTW, fabs(NaN) is NaN, so result is the same as before (false).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84101
--- Comment #7 from Jakub Jelinek ---
#c4 has another thing:
struct S { float a, b; };
struct S
foo (float x)
{
return (struct S) { x, x };
}
where we generate bad code mainly because we have DImode as DECL_MODE of the
RESULT_DECL, even when it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88535
Eric Botcazou changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84101
--- Comment #6 from Segher Boessenkool ---
I think subreg should deal with this. What do you mean "there aren't
any half of TImode subregs"? insn 10 has it split at the start, and
insn 18 at the end wants it split, too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88542
Andrew Pinski changed:
What|Removed |Added
Keywords||missed-optimization
Component|c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87881
--- Comment #12 from Paul Thomas ---
(In reply to Jakub Jelinek from comment #11)
> Created attachment 45257 [details]
> gcc9-pr87881.patch
>
> Untested fix. simplify_const_ref is similar, but actually iterates p->ref
> and thus properly stops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88542
Bug ID: 88542
Summary: Optimize symmetric range check
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assign
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84101
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88541
Bug ID: 88541
Summary: VPCLMULQDQ 256-bit inline function unavailable with
optimization but without enabled AVX512VL support
Product: gcc
Version: 8.2.0
Status: UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88540
Bug ID: 88540
Summary: Issues with vectorization of min/max operations
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88538
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84362
--- Comment #5 from Jakub Jelinek ---
The MEM_REF is in there because we first create a _ZNK3vec4sizeEv.isra.0 clone
which takes unsigned int argument and just passes it through.
So, does LIM need to fold the MEM_EXPRs in a similar way to how PRE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71044
--- Comment #8 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #3)
> Several member functions of path construct a path from their argument, but
> could be done without any allocations, e.g. path::compare(string_view)
This is d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88213
Segher Boessenkool changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88213
--- Comment #3 from Segher Boessenkool ---
Godbolt now has the C compiler frontend as well, without -xc shenanigans, fwiw.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88534
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88537
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88534
Marek Polacek changed:
What|Removed |Added
CC||hanicka at hanicka dot net
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84362
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88535
--- Comment #3 from john henning ---
Rainer points out that a key here seems to be that the host system compiler had
been configured with sparcv9-solaris2.11 but the 8.2.0 build did not request
the same. In my case, the host system compiler was
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87881
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88536
--- Comment #7 from Manfred Schwarb ---
Thanks Jakub for the debug hint, and thanks Dominique for finding the
duplicate.
Indeed, my backtrace also points to simplify_ref_chain:
# gdb --quiet `/usr/local/gcc-trunk-32bit/bin/gcc -print-prog-name=f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88539
--- Comment #1 from Cheng Wen ---
Created attachment 45256
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45256&action=edit
POC2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88539
Bug ID: 88539
Summary: A memory leak issue was discovered in cplus-dem.c
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Componen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88536
--- Comment #6 from Jakub Jelinek ---
Indeed:
==8241== Invalid read of size 8
==8241==at 0x873E24: simplify_ref_chain(gfc_ref*, int, gfc_expr**)
(expr.c:1943)
==8241==by 0x8744C0: gfc_simplify_expr(gfc_expr*, int) (expr.c:2164)
==8241==
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88535
john henning changed:
What|Removed |Added
CC||mailboxnotfound at yahoo dot
com
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88536
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87881
Dominique d'Humieres changed:
What|Removed |Added
CC||manfred99 at gmx dot ch
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88538
Bug ID: 88538
Summary: parse error with class nontype template parameter
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88537
Bug ID: 88537
Summary: class nontype template parameter debug mode crash in
dwarf2out.c
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88533
--- Comment #8 from Richard Biener ---
Created attachment 45252
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45252&action=edit
patch
Even though the patch doesn't hoist the invariant condition the speed is back
with it.
Can you verify t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88533
--- Comment #7 from Richard Biener ---
OK, so I can add heuristic that avoids copying BBs with exit conditions based
on non-IVs/non-invariants but that doesn't fix this testcase since the
fourth condition in the loop is based on the load from 'ja
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87934
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87273
Jakub Jelinek changed:
What|Removed |Added
CC||abel at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88536
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88533
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88536
--- Comment #3 from Manfred Schwarb ---
BTW, the build logs (*README.txt) are here:
http://gfortran.meteodat.ch/download/i686/nightlies/
-linux
Configured with: ../gcc-trunk-source/gcc/configure
--enable-languages=c,c++,fortran --enable-checking=yes,extra
--disable-libstdcxx-pch --enable-libgomp --enable-lto --enable-gold
--with-plugin-ld=gold --prefix=/usr/local/gcc-trunk-32bit i686-linux
Thread model: posix
gcc version 9.0.0 20181218
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88535
--- Comment #1 from Richard Biener ---
So that means host gcc 7 when defaulting to -m64 miscompiles stage1 in a way
that it miscompiles stage2 but that miscompilation does not affect stage3.
That'll be "interesting" to track down :/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88536
Richard Biener changed:
What|Removed |Added
Target||i?86-*-*
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88533
Richard Biener changed:
What|Removed |Added
Target||x86_64-*-*
Status|UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88450
--- Comment #6 from Jakub Jelinek ---
Thus, it would be interesting to know where exactly you get the segfault under
debugger, because it is otherwise impossible to debug without access to MS Win.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88450
--- Comment #5 from Jakub Jelinek ---
The commit doesn't affect non-mingw x86, because MAX_STACK_ALIGNMENT is in that
case very large (1 << 28 bytes), but apparently for mingw if TARGET_SEH
MAX_STACK_ALIGNMENT is only 128 bits.
1 - 100 of 116 matches
Mail list logo
