https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97644
--- Comment #6 from Iain Buclaw ---
(In reply to Iain Buclaw from comment #5)
> Without doing any bisecting, r11-4572 looks very suspect for the cause of
> the segmentation fault.
Confirmed, that is the commit that caused the regression.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97659
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77691
--- Comment #44 from Jonathan Wakely ---
It looks like mingw* has the same problem:
https://sourceforge.net/p/mingw-w64/bugs/778/
mlloc returns memory aligned to 8 bytes, GCC's stddef.h says 16 is a
fundamental alignment. Even worse, mingw's own
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97659
--- Comment #2 from Paweł Bylica ---
Created attachment 49482
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49482&action=edit
Minimal test case source code
It turned out the problem is related to vector's internal instrumentation
_GLIBCXX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97659
--- Comment #1 from Jonathan Wakely ---
This looks like a bug in the sanitizer. I assume it's triggering because the
memory returned by the allocator doesn't refer to an array, so the two
addresses are not pointing to subobjects of a single objec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97658
--- Comment #1 from Jonathan Wakely ---
The compiler is telling you your code has undefined behaviour.
If you write code that conforms to the rules of the C++ language, you won't get
that warning.
Don't change your makefiles, fix your code.
I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97654
d...@adrian-ebeling.de changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCON
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97659
Bug ID: 97659
Summary: Invalid pointer subtraction in vector::insert()
(reported by pointer-subtract AddressSanitizer)
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97658
Bug ID: 97658
Summary: Tired of having to change make files on every new
version. Damnit!
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97657
Bug ID: 97657
Summary: libsanitizer/sanitizer_common/sanitizer_posix.cpp:162:
no code to deal with bad mode ?
Product: gcc
Version: unknown
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97655
--- Comment #2 from Jakub Jelinek ---
Guess the second condition should be !c->capture.
The spec says that atomic_default_mem_order(acq_rel) makes mem-order-clause
default to acquire for read, acq_rel for capture and release otherwise - write
or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97655
David Binderman changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97656
Bug ID: 97656
Summary: Specify that there is no address arithmetic on a
pointer
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: enhancement
P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97655
Bug ID: 97655
Summary: gcc/fortran/openmp.c:4133: possible cut'n'paste error
?
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Prio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81146
Artem S. Tashkinov changed:
What|Removed |Added
URL||https://bugs.winehq.org/sho
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97654
--- Comment #2 from Jonathan Wakely ---
(In reply to devl from comment #0)
> Created attachment 49480 [details]
> Full output with -v
>
> std::filesystem::copy() with copy_options = copy_symlinks |
> overwrite_existing does not overwrite existin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96504
--- Comment #3 from H.J. Lu ---
With glibc 2.31, I got
==2688647== Memcheck, a memory error detector
==2688647== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==2688647== Using Valgrind-3.16.1 and LibVEX; rerun with -h for copy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97654
--- Comment #1 from d...@adrian-ebeling.de ---
Created attachment 49481
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49481&action=edit
intermediate files
.ii and .s files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97654
Bug ID: 97654
Summary: std::filesystem::copy() can't overwrite existing
symlink
Product: gcc
Version: 9.3.0
Status: UNCONFIRMED
Severity: normal
Prior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57076
Francois-Xavier Coudert changed:
What|Removed |Added
CC||fxcoudert at gcc dot gnu.org
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96504
H.J. Lu changed:
What|Removed |Added
Last reconfirmed||2020-10-31
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96958
--- Comment #10 from Jonathan Wakely ---
There are a few other places doing unnecessary long double arithmetic, e.g.
r11-4588-60d9f254876a00260992b2f37639ef4d82d9db8f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97578
Zhendong Su changed:
What|Removed |Added
CC||su at cs dot ucdavis.edu
--- Comment #4 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96958
--- Comment #9 from Jonathan Wakely ---
N.B. the calls to __builtin_ceill and __builtin_floorl also need to be changed
to avoid implicit conversions to long double.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94200
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95519
H.J. Lu changed:
What|Removed |Added
Resolution|--- |FIXED
Status|REOPENED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96886
Paul Thomas changed:
What|Removed |Added
CC||pault at gcc dot gnu.org
--- Comment #4 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97653
--- Comment #3 from Jonathan Wakely ---
int printf(const char*, ...);
const unsigned long k = 256;
int main()
{
long double r[] = { 0.1L, 0.2L, 0.5L, 0.9L };
for (int i = 0; i < 4; ++i)
{
unsigned long j = k * r[i];
printf("%lu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97653
--- Comment #2 from Jonathan Wakely ---
Without -mabilongdouble the result is correct.
If configured with --with-long-double-format=ibm the result is correct with any
-mabi option.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97653
--- Comment #1 from Jonathan Wakely ---
Created attachment 49479
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49479&action=edit
Assembly code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97653
Bug ID: 97653
Summary: Incorrect long double calculation with
-mabi=ibmlongdouble
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Prio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97651
Andreas Schwab changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97652
--- Comment #1 from Jan Hubicka ---
Actually there is another propagation happening in ipa-cp analysis:
--- aa/pdt_14.f03.077i.cp 2020-10-31 09:00:52.809726530 +0100
+++ pdt_14.f03.077i.cp 2020-10-31 09:10:35.204755828 +0100
@@ -10,6 +10,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97652
Bug ID: 97652
Summary: New pdt14 failure after
g:617695cdc2b3d950f1e4deb5ea85d5cc302943f4
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95519
--- Comment #10 from Iain Sandoe ---
(In reply to H.J. Lu from comment #9)
> On AVX or AVX512 machines, I got
(I test on AVX and AVX512 machines without seeing this)
What version of glibc do you have?
this might be a dup of PR96504
(r11-1673 i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97651
--- Comment #1 from olha5b at gmx dot net ---
Created attachment 49478
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49478&action=edit
Preprocessing of second sample program
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97651
Bug ID: 97651
Summary: abs((int)fabs(0.0/0.0)) results negative
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
37 matches
Mail list logo
