Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: rcopley at gmail dot com
Target Milestone: ---
This is accepted with -std=c++17 and rejected with -std=c++20:
#include
#include
int main ()
{
std::string s = u8"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96626
R Copley changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54412
Bug #: 54412
Summary: Request for 32-byte stack alignment with -mavx on
Windows
Classification: Unclassified
Product: gcc
Version: 4.7.1
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54412
--- Comment #2 from R Copley ---
Created attachment 30793
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30793&action=edit
As before, but with explicitly 32-byte aligned variables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54412
--- Comment #3 from R Copley ---
Created attachment 30794
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30794&action=edit
Assembly-language code compiled from attachment 1
Compiled with GCC 4.7.2 from the MinGW-w64 toolchain.
Compile comman
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54412
--- Comment #4 from R Copley ---
(In reply to Kai Tietz from comment #1)
> MS' abi doesn't allow this. So I doubt we will be able to implement that
> for this target. If we want to re-align stack on function-base we will run
> into troubles with
Assignee: unassigned at gcc dot gnu.org
Reporter: rcopley at gmail dot com
Target Milestone: ---
In some circumstances, builds using precompiled headers which worked with GCC
9.1 no longer work with GCC 9.2.
Complete test case (as a bash script):
>precompiled.h echo &quo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91440
--- Comment #1 from R Copley ---
The recipe isn't as stable as I thought. The same recipe on a different machine
doesn't reproduce the issue. Apologies.
On that machine with a real project (sorry, no minimal example) I'm now seeing
this error:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91440
--- Comment #3 from R Copley ---
Yes, I'll try and bisect.
Apologies for my confusion: ASLR is enabled in the 9.2 binaries and not in the
9.1 binaries (see below).
This change isn't explicit in the MSYS2 PKGBUILD change[1] going from 9.1 to
9.2.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91440
--- Comment #5 from R Copley ---
> But is probably the reason for the failures... mingw might not implement
> the necessary relocation support for ASLR.
Yes, I think that's it. (I should have said so more explicitly.)
> You can try enable it o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91440
--- Comment #6 from R Copley ---
> Yes, I'll try and bisect.
Just to check, I rebuilt GCC 9.1 using the version of the MSYS2 package-build
from before the update to 9.2, and the binaries have ASLR enabled and do show
failures with using PCH. Loo
++
Assignee: unassigned at gcc dot gnu.org
Reporter: rcopley at gmail dot com
Target Milestone: ---
Created attachment 36481
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36481&action=edit
Preprocessed source file that demonstrates incorrect conversion from
floatin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67932
--- Comment #2 from R Copley ---
Thanks Jonathan. It's clear enough from what I wrote that:
(1) The same kind of incorrect output is produced by (a) including and
using std::printf, and (b) using iostreams and std::hexfloat;
(2) The correct ou
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67932
--- Comment #4 from R Copley ---
That's what I understood to be the case. Nevertheless, with the toolchain I am
using (see above for version; same command-line etc.), I get the results below.
Both testcases below give the correct results with g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67932
--- Comment #5 from R Copley ---
Created attachment 36489
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36489&action=edit
hexfloat-bug-2a.ii (see Comment 4)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67932
--- Comment #6 from R Copley ---
Created attachment 36490
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36490&action=edit
hexfloat-bug-2b.ii (see Comment 4)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67932
--- Comment #8 from R Copley ---
Thanks. I've emailed the mingw-w64 list at
http://sourceforge.net/p/mingw-w64/mailman/mingw-w64-public. (You expressed it
better but I hadn't seen your last comment.)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67932
--- Comment #9 from R Copley ---
For information, this has already been entered on the mingw-w64 issue tracker
(months ago) (see http://sourceforge.net/p/mingw-w64/bugs/459/).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54412
--- Comment #6 from R Copley ---
As I mentioned in the description, this request was indeed related to that bug.
The test-case no longer crashes with recent MinGW-W64 toolchains (GCC 4.9.1).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54412
--- Comment #8 from R Copley ---
No, I use the mingw-builds distro too.
gcc --version
gcc (x86_64-win32-seh-rev0, Built by MinGW-W64 project) 4.9.1
Bizarrely, the attached program exits with a random error code unless I add a
"return 0;" statem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54412
--- Comment #9 from R Copley ---
Heh, sorry. I don't really know C, I assumed it had an implicit "return 0;"
like C++. Apparently C99 has this but earlier C standards do not. So, not
bizarre at all.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54412
--- Comment #11 from R Copley ---
On 20 September 2014 07:08, roland at rschulz dot eu
wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54412
>
> --- Comment #10 from Roland Schulz ---
> Created attachment 33520
> --> https://gcc.gnu.org
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: rcopley at gmail dot com
Target Milestone: ---
Created attachment 50506
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50506&action=edit
testca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91440
R Copley changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54412
--- Comment #38 from R Copley ---
(A patch to emit unaligned instructions should probably resolve bug 49001
instead of this one, 54412.)
Could dynamic alignment be achieved, not for automatic variables and function
parameters, but for registers
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: rcopley at gmail dot com
Target Milestone: ---
The C++ program included at the end of this message causes an ICE at the last
line, in GCC versions 10.3.0, 11.1.0, 11.2.0 and on
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: rcopley at gmail dot com
Target Milestone: ---
The following program should print:
0.001914
0.630538
With "g++ -frounding-math", it prin
27 matches
Mail list logo
