Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: sbence92 at gmail dot com
Target Milestone: ---
Created attachment 48376
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48376&action=edit
preprocessed failing tests
Sim
++
Assignee: unassigned at gcc dot gnu.org
Reporter: sbence92 at gmail dot com
Target Milestone: ---
g++.dg/concepts/diagnostic10.C fails with gcc 10 (ead1c27a530) on mingw target
and host.
Instead of
diagnostic10.C:6:31: error: invalid use of non-static member function '
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94770
--- Comment #2 from Bence Szabó ---
Yes there's a T(30,struct{}a[1];,) in t032.
Indeed the fail happens on a variadic function (void check30va(int i, ...)).
I dig in some more and it turns out all the tests listed crash. I've attached
the format
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94770
--- Comment #3 from Bence Szabó ---
Created attachment 48379
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48379&action=edit
t032
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94770
--- Comment #4 from Bence Szabó ---
As a remark for 'same code with -std=c++14 and -std=c++17 here', I can confirm,
the example you provided also produces same assembly for me in c++14 and c++17.
Also compiling t032 with only c++14 or only c++17
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94770
--- Comment #6 from Bence Szabó ---
> Ah, then it is not c++14 vs. c++17 ABI incompatibility, but some bug in
> va_arg passing of such classes for mingw.
It seems so. In t032 I got rid of the crashing tests (30, 56, 77, 80, 89, 100,
117, 134, 16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94771
--- Comment #4 from Bence Szabó ---
Interesting, the t.f syntax is not allowed anymore even with MSVC:
https://godbolt.org/z/YCK-mv
msvc also doesn't list under extensions_
https://docs.microsoft.com/en-us/cpp/build/reference/microsoft-extension
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94770
--- Comment #14 from Bence Szabó ---
(In reply to Jakub Jelinek from comment #13)
> Completely untested WIP patch:
Results with ead1c27a530 + this patch:
The same tests fail as in the original description, t032 and t059 crash/pass
the same way a
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: sbence92 at gmail dot com
Target Milestone: ---
Host: all
Target: all
Build: all
Created attachment 47169
--> https://gcc.gnu.org/bugzi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92359
--- Comment #2 from Bence Szabó ---
Is it a subtle thing that all implementations missed or is it not specified
very well in the standard? As far as I could tell there's no specific rule for
this case. The standard is detailed about member static
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: sbence92 at gmail dot com
Target Milestone: ---
Naively adding decltype with wrong syntax in order fix "expected a type, got
'I'" results in segfault with following code:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92517
--- Comment #1 from Bence Szabó ---
started with r276764
: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: sbence92 at gmail dot com
Target Milestone: ---
Created attachment 45206
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45206&action=edit
main config.log
Bootstrap fails under Win10 at configuring li
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88450
--- Comment #1 from Bence Szabó ---
Correction: 9-21081118 works after patching with "PR bootstrap/88106" (r266309)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88450
--- Comment #2 from Bence Szabó ---
Bisected, problem starts at r266345 ([PATCH][PR84877]Dynamically align the
address for local parameter copy on the stack when required alignment is larger
than MAX_SUPPORTED_STACK_ALIGNMEN).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88450
--- Comment #7 from Bence Szabó ---
New info: when built with --enable-checking=yes, the selftests already produce
segfault in stage2 cc1 and cc1plus at the same point as the below cc1plus.
backtrace for cc1 with r266345.
Thread 1 received sign
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88450
--- Comment #10 from Bence Szabó ---
cc1:
segfault at vmovaps
2776 declspecs_add_type (loc, specs, t);
0045952e: ...kahead_kind)+1070 mov %rbp,%r8
00459531: ...kahead_kind)+1073 vmovdqa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88450
--- Comment #11 from Bence Szabó ---
Created attachment 45279
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45279&action=edit
preprocessed c-parser, gimplify
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88450
--- Comment #13 from Bence Szabó ---
ICE still occurs with current trunk (r267728) patched with gcc9-pr88331.patch
from PR88331. r266345 seems to give quite a hard time for cygwin / mingw
targets, might be worth reverting as the gcc 9 release is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88450
--- Comment #21 from Bence Szabó ---
Bootstrap succeeds with trunk + gcc9-pr88450.patch. Ran gcc testsuite, all
stackalignment tests pass and so does the test added by r266345. The CPU was an
Intel Coffee Lake so avx and avx2 is supported but avx
iority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: sbence92 at gmail dot com
Target Milestone: ---
r263551 removes the possibility to compile the below code with fpermissive.
This code has always been compiled by GCC, why remove the option now? This
break
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88951
--- Comment #4 from Bence Szabó ---
Ok, I agree with all of what you wrote. Please close the PR as you wish.
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: sbence92 at gmail dot com
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90312
--- Comment #3 from Bence Szabó ---
Thank you for the patch!
The main blocker is some msvc specific code in sanitizer_win_defs.h.
WIN_FORCE_LINK, WIN_WEAK_ALIAS, WIN_EXPORT
AFAIK the sanitizer is from LLVM (or google?) and the official llvm bui
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61592
Bence Szabó changed:
What|Removed |Added
CC||sbence92 at gmail dot com
--- Comment #2
erity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: sbence92 at gmail dot com
Target Milestone: ---
Host: x86_64-w64-mingw32, x86_64-linux-gnu
Target: x86_64-w64-mingw32, x86_64-linu
: compile-time-hog
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: sbence92 at gmail dot com
Target Milestone: ---
Host: x86_64-w64-mingw32, x86_64-linux-gnu
Target: x86_64-w64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92359
--- Comment #4 from Bence Szabó ---
>That should not matter in even in shared libraries unless you are doing some
>symbol hidding in the shared library really.
Hmm. I just run the attached example on linux (after some tuning) with -fPIC,
and i
28 matches
Mail list logo
