[Bug tree-optimization/107867] [13 Regression] ICE in init_from_control_deps, at gimple-predicate-analysis.cc:1699 since r13-2314-ga8ebd27d0ab69b08
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107867 --- Comment #2 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:0976b012d89e3d819d83cdaf0dab05925b3eb3a0 commit r13-4316-g0976b012d89e3d819d83cdaf0dab05925b3eb3a0 Author: Richard Biener Date: Fri Nov 25 13:53:14 2022 +0100 tree-optimization/107867 - failed abnormal cleanup in forwprop The following makes sure to perform abnormal cleanup when forwprop propagates into a call. PR tree-optimization/107867 * tree-ssa-forwprop.cc (pass_forwprop::execute): Handle abnormal cleanup after substitution. * g++.dg/pr107867.C: New testcase.
[Bug tree-optimization/107867] [13 Regression] ICE in init_from_control_deps, at gimple-predicate-analysis.cc:1699 since r13-2314-ga8ebd27d0ab69b08
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107867 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Richard Biener --- Fixed.
[Bug tree-optimization/107876] [13 Regression] ICE in verify_dominators, at dominance.cc:1184 (error: dominator of 4 should be 14, not 16) since r13-3749-g7314b98b1bcd382c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107876 --- Comment #4 from Richard Biener --- It's a latent issue before this rev. since clean_up_after_unswitching ends up removing all exit edges from one copy, keeping an infinite loop. The function uses remove_edge () for this, not remove_edge_and_dominated_blocks. Testing a patch.
[Bug rtl-optimization/107892] Unnecessary move between ymm registers in loop using AVX2 intrinsic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107892
--- Comment #1 from Eric Biggers ---
The reproducer I gave in my first comment doesn't reproduce the bug on
releases/gcc-11.1.0, so it must have regressed between then and trunk. I can
do a bisection if needed.
However, I actually still see the bug with gcc-11.1.0 on my original
unminimized code at
https://github.com/ebiggers/libdeflate/blob/fb0c43373f6fe600471457f4c021b8ad7e4bbabf/lib/x86/adler32_impl.h#L142.
So maybe the reproducer I gave is not the best one. Here is a slightly
different reproducer that reproduces the bug with both gcc-11.1.0 and trunk:
#include
__m256i __attribute__((target("avx2")))
f(const __m256i *p, size_t n)
{
__m256i a = _mm256_setzero_si256();
do {
a = _mm256_add_epi32(a, *p++);
} while (--n);
return _mm256_madd_epi16(a, a);
}
The assembly of the loop has the unnecessary vmovdqa:
8: c5 f5 fe 07 vpaddd (%rdi),%ymm1,%ymm0
c: 48 83 c7 20 add$0x20,%rdi
10: c5 fd 6f c8 vmovdqa %ymm0,%ymm1
14: 48 83 ee 01 sub$0x1,%rsi
18: 75 ee jne8
[Bug rtl-optimization/107892] Unnecessary move between ymm registers in loop using AVX2 intrinsic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107892 --- Comment #2 from Eric Biggers --- This is also reproducible with SSE2.
[Bug c/107890] UB on integer overflow impacts code flow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107890 --- Comment #4 from Andrew Pinski --- There is always a trade off here. We made the decision that signed integer overflow is undefined because we want to do optimizations. Gcc does provide an option which makes them behave well defined at runtime, -fwrapv . This is similar to strict aliasing with respect to optimizations in the sense it is hard to decide if the optimizations is being done will break what people assumptions are. This is part of the reason why there is a specifications (standard) so people can write to it. There are other undefined behavior that gcc has started to take advantage of (e.g. in c++ if there is no return with a value in a function with that returns non-void). The question is where do you draw the line with respect to undefined behaviors, the answer is complex sometimes, especially if you are optimizing. In this example the range of x is known to be positive so multiplying by another positive # gives a positive result and then dividing by a positive value still is positive. The check for negative result is optimized away.
[Bug tree-optimization/107413] Perf loss ~14% on 519.lbm_r SPEC cpu2017 benchmark with r8-7132-gb5b33e113434be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107413 --- Comment #13 from Rama Malladi --- (In reply to CVS Commits from comment #12) > The master branch has been updated by Wilco Dijkstra : > > https://gcc.gnu.org/g:0c1b0a23f1fe7db6a2e391b7cb78cff90032 > > commit r13-4291-g0c1b0a23f1fe7db6a2e391b7cb78cff90032 > Author: Wilco Dijkstra > Date: Wed Nov 23 17:27:19 2022 + > > AArch64: Add fma_reassoc_width [PR107413] > > Add a reassocation width for FMA in per-CPU tuning structures. Keep > the existing setting of 1 for cores with 2 FMA pipes (this disables > reassociation), and use 4 for cores with 4 FMA pipes. This improves > SPECFP2017 on Neoverse V1 by ~1.5%. > > gcc/ > PR tree-optimization/107413 > * config/aarch64/aarch64.cc (struct tune_params): Add > fma_reassoc_width to all CPU tuning structures. > (aarch64_reassociation_width): Use fma_reassoc_width. > * config/aarch64/aarch64-protos.h (struct tune_params): Add > fma_reassoc_width. Thank you for this code change/ fix. I will attempt a run with this change.
[Bug sanitizer/107893] New: gcc trunk at -O0 (UBSan) misses a Null-pointer-dereference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107893
Bug ID: 107893
Summary: gcc trunk at -O0 (UBSan) misses a
Null-pointer-dereference
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: shaohua.li at inf dot ethz.ch
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, marxin at
gcc dot gnu.org
Target Milestone: ---
For the following code, `gcc-trunk -O0 -fsanitize=undefined
-fno-sanitize-recover=all` misses the NULL-pointer-dereference, while
`gcc-trunk -Ox -fsanitize=address -fno-sanitize-recover=all` (x=1, 2, 3, or s)
can detect it.
I checked gcc8/9/10/11/12 and they all have this issue.
clang can detect it at all optimization levels.
Compiler explorer: https://godbolt.org/z/85qfdccse
% cat a.c
int main() {
int *a = 0;
(a[1] | a[0]) >> 056;
}
%
% gcc-tk -O0 -fsanitize=undefined -fno-sanitize-recover=all -w a.c &&./a.out
Segmentation fault
% gcc-tk -O1 -fsanitize=undefined -fno-sanitize-recover=all -w a.c &&./a.out
a.c:3:13: runtime error: load of null pointer of type 'int'
%
[Bug libstdc++/107886] Problem witch std::latch, std::binary_semaphores in C++20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107886
--- Comment #8 from Jamaika ---
First lesson on the page https://www.modernescpp.com/index.php/latches-in-c-20
I use GCC from 11.3.1 to 13.0.0 20221124
```
// workers.cpp
#include
#include
#include
#include
std::latch workDone(6);
std::mutex coutMutex;
void synchronizedOut(const std::string& s) {
std::lock_guard lo(coutMutex);
std::cout << s;
}
class Worker {
public:
Worker(std::string n): name(n) { };
void operator() () {
synchronizedOut(name + ": " + "Work done!\n");
workDone.arrive_and_wait(); // wait until all work is done (1)
synchronizedOut(name + ": " + "See you tomorrow!\n");
}
private:
std::string name;
};
int main() {
std::cout << '\n';
Worker herb(" Herb");
std::thread herbWork(herb);
Worker scott("Scott");
std::thread scottWork(scott);
Worker bjarne(" Bjarne");
std::thread bjarneWork(bjarne);
Worker andrei("Andrei");
std::thread andreiWork(andrei);
Worker andrew(" Andrew");
std::thread andrewWork(andrew);
Worker david("David");
std::thread davidWork(david);
herbWork.join();
scottWork.join();
bjarneWork.join();
andreiWork.join();
andrewWork.join();
davidWork.join();
}
```
I have error.
workers.cpp:8:6: error: 'latch' in namespace 'std' does not name a type
8 | std::latch workDone(6);
| ^
When I use 'latch.h' gcc 11.3.0 and above hasn't problem.
https://github.com/luncliff/latch/blob/master/latch.h
I have not error.
[Bug rtl-optimization/107892] Unnecessary move between ymm registers in loop using AVX2 intrinsic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107892 --- Comment #3 from Hongtao.liu --- > In the bad version, I noticed that the RTL initially has two separate insns > for 'a += *p': one to do the addition and write the result to a new pseudo > register, and one to convert the value from mode V8SI to V4DI and assign it Because we're defining __m256i as __v4di, and rtl use subreg to bitcast __v8si reg to __v4di one. > to the original pseudo register. These two separate insns never get > combined. (That sort of explains why the bug isn't seen with the __v8si and > += method; gcc doesn't do a type conversion with that method.) So, I'm Combine failed to combine them because the __v8si reg is also used outside of the loop. > wondering if the bug is in the instruction combining pass. Or perhaps the > RTL should never have had two separate insns in the first place?
[Bug sanitizer/107893] gcc trunk at -O0 (UBSan) misses a Null-pointer-dereference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107893 --- Comment #1 from Jakub Jelinek --- You don't store the shift result anywhere and there are no side-effects in the expression, so nothing prevents the compiler from optimizing out the whole expression.
[Bug c++/84469] structured binding inside for all loop thinks it is type depedent when it is not (inside a template)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84469
--- Comment #7 from Jakub Jelinek ---
The patch unfortunately regresses the OpenMP g++.dg/gomp/for-21.C test:
template
void
f6 (S (&a)[10])
{
#pragma omp for collapse (2)
for (auto [i, j, k] : a) // { dg-error "use of 'i'
before deduction of 'auto'" "" { target *-*-* } .-1 }
for (int l = i; l < j; l += k) // { dg-error "use of 'j'
before deduction of 'auto'" }
; // { dg-error "use of 'k'
before deduction of 'auto'" "" { target *-*-* } .-3 }
}
...
S c[10] {};
f6 <0> (c);
where the bug is no longer diagnosed. When not in a template or when the
range for decl is type dependent, it works because the invalid uses are
diagnosed by finish_id_expression -> mark_used and complain about uses of auto
before it is deduced, but in the above case a is not type dependent, mark_used
doesn't complain about uses of auto when processing_template_decl and the new
code deduces a and i/j/k before finish_id_expression is called on it again
during instantiation.
So, I'll need to add further code to handle this right.
[Bug sanitizer/107893] gcc trunk at -O0 (UBSan) misses a Null-pointer-dereference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107893 --- Comment #2 from Richard Biener --- Well, it first performs the a[1] access which segfaults, isn't that expected?
[Bug sanitizer/107893] gcc trunk at -O0 (UBSan) misses a Null-pointer-dereference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107893
--- Comment #3 from Richard Biener ---
That is,
int main() {
int *a = 0;
(a[0] | a[1]) >> 056;
}
works at -O0:
t.c:3:6: runtime error: load of null pointer of type 'int'
[Bug tree-optimization/107876] [13 Regression] ICE in verify_dominators, at dominance.cc:1184 (error: dominator of 4 should be 14, not 16) since r13-3749-g7314b98b1bcd382c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107876 --- Comment #5 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:238cf114de16518c6569f0cdd2c4d6211ac98a74 commit r13-4317-g238cf114de16518c6569f0cdd2c4d6211ac98a74 Author: Richard Biener Date: Mon Nov 28 09:19:33 2022 +0100 tree-optimization/107876 - unswitching of switch The following shows a missed update of dominators when unswitching removes unreachable edges from switch stmts it unswitches. Fixed by wiping dominator info in that case. PR tree-optimization/107876 * tree-ssa-loop-unswitch.cc (clean_up_after_unswitching): Wipe dominator info if we removed an edge. * g++.dg/tree-ssa/pr107876.C: New testcase.
[Bug tree-optimization/107876] [13 Regression] ICE in verify_dominators, at dominance.cc:1184 (error: dominator of 4 should be 14, not 16) since r13-3749-g7314b98b1bcd382c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107876 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #6 from Richard Biener --- Fixed.
[Bug sanitizer/107893] gcc trunk at -O0 (UBSan) misses a Null-pointer-dereference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107893
--- Comment #4 from Li Shaohua ---
(In reply to Richard Biener from comment #3)
> That is,
>
> int main() {
> int *a = 0;
>(a[0] | a[1]) >> 056;
> }
>
> works at -O0:
>
> t.c:3:6: runtime error: load of null pointer of type 'int'
Yes, the a[1] access caused the segfault. For clang's UBsan, it emits an error
message for a[1]:
a.c:3:5: runtime error: applying non-zero offset 4 to null pointer
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior a.c:3:5 in
Is there a way for gcc's UBsan to warn such errors?
[Bug target/96795] MVE: issue with polymorphism and integer promotion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96795 --- Comment #4 from CVS Commits --- The trunk branch has been updated by Andrea Corallo : https://gcc.gnu.org/g:e0dd75fe90ef4cda94f431747d239d6cfcf5656f commit r13-4330-ge0dd75fe90ef4cda94f431747d239d6cfcf5656f Author: Stam Markianos-Wright Date: Thu Nov 10 15:02:47 2022 + arm: further fix overloading of MVE vaddq[_m]_n intrinsic It was observed that in tests `vaddq_m_n_[s/u][8/16/32].c`, the _Generic resolution would fall back to the `__ARM_undef` failure state. This is a regression since `dc39db873670bea8d8e655444387ceaa53a01a79` and `6bd4ce64eb48a72eca300cb52773e6101d646004`, but it previously wasn't identified, because the tests were not checking for this kind of failure. The above commits changed the definitions of the intrinsics from using `[u]int[8/16/32]_t` types for the scalar argument to using `int`. This allowed `int` to be supported in user code through the overloaded `#defines`, but seems to have broken the `[u]int[8/16/32]_t` types The solution implemented by this patch is to explicitly use a new _Generic mapping from all the `[u]int[8/16/32]_t` types for int. With this change, both `int` and `[u]int[8/16/32]_t` parameters are supported from user code and are handled by the overloading mechanism correctly. Note that in these scalar cases it is safe to pass the raw p, rather than the typeof-ed __p, because we are not at risk of the _Generics being exponentially expanded on the `n` scalar argument to an `_n` intrinsic. Using p instead will give a more accurate error message to the user, should something be wrong with that argument. gcc/ChangeLog: PR target/96795 * config/arm/arm_mve.h (__arm_vaddq_m_n_s8): Change types. (__arm_vaddq_m_n_s32): Likewise. (__arm_vaddq_m_n_s16): Likewise. (__arm_vaddq_m_n_u8): Likewise. (__arm_vaddq_m_n_u32): Likewise. (__arm_vaddq_m_n_u16): Likewise. (__arm_vaddq_m): Fix Overloading. (__ARM_mve_coerce3): New.
[Bug target/96795] MVE: issue with polymorphism and integer promotion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96795 --- Comment #5 from CVS Commits --- The trunk branch has been updated by Andrea Corallo : https://gcc.gnu.org/g:31df339a50c30712c1e071d2b18f304b148a3165 commit r13-4331-g31df339a50c30712c1e071d2b18f304b148a3165 Author: Stam Markianos-Wright Date: Thu Nov 10 15:02:52 2022 + arm: propagate fixed overloading of MVE intrinsic scalar parameters This is a mechanical patch that propagates the change proposed in my previous patch for vaddq[_m]_n across all other polymorphic MVE intrinsic overloads of scalar types. The find and Replace patterns used were: s/__ARM_mve_coerce\(__p(\d+), [u]?int(8|16|32|64)_t\) /__ARM_mve_coerce3(p$1, int)/g s/__ARM_mve_coerce2\(__p(\d+), double\) /__ARM_mve_coerce2(p$1, double)/g gcc/ChangeLog: PR target/96795 * config/arm/arm_mve.h (__arm_vaddq): Fix Overloading. (__arm_vmulq): Likewise. (__arm_vcmpeqq): Likewise. (__arm_vcmpneq): Likewise. (__arm_vmaxnmavq): Likewise. (__arm_vmaxnmvq): Likewise. (__arm_vminnmavq): Likewise. (__arm_vsubq): Likewise. (__arm_vminnmvq): Likewise. (__arm_vrshlq): Likewise. (__arm_vqsubq): Likewise. (__arm_vqdmulltq): Likewise. (__arm_vqdmullbq): Likewise. (__arm_vqdmulhq): Likewise. (__arm_vqaddq): Likewise. (__arm_vhaddq): Likewise. (__arm_vhsubq): Likewise. (__arm_vqdmlashq): Likewise. (__arm_vqrdmlahq): Likewise. (__arm_vmlasq): Likewise. (__arm_vqdmlahq): Likewise. (__arm_vmaxnmavq_p): Likewise. (__arm_vmaxnmvq_p): Likewise. (__arm_vminnmavq_p): Likewise. (__arm_vminnmvq_p): Likewise. (__arm_vfmasq_m): Likewise. (__arm_vsetq_lane): Likewise. (__arm_vcmpneq_m): Likewise. (__arm_vhaddq_x): Likewise. (__arm_vhsubq_x): Likewise. (__arm_vqrdmlashq_m): Likewise. (__arm_vqdmlashq_m): Likewise. (__arm_vmlaldavaxq_p): Likewise. (__arm_vmlasq_m): Likewise. (__arm_vqdmulhq_m): Likewise. (__arm_vqdmulltq_m): Likewise. (__arm_viwdupq_m): Likewise. (__arm_viwdupq_u16): Likewise. (__arm_viwdupq_u32): Likewise. (__arm_viwdupq_u8): Likewise. (__arm_vdwdupq_m): Likewise. (__arm_vdwdupq_u16): Likewise. (__arm_vdwdupq_u32): Likewise. (__arm_vdwdupq_u8): Likewise. (__arm_vaddlvaq): Likewise. (__arm_vaddlvaq_p): Likewise. (__arm_vaddvaq): Likewise. (__arm_vaddvaq_p): Likewise. (__arm_vcmphiq_m): Likewise. (__arm_vmladavaq_p): Likewise. (__arm_vmladavaxq): Likewise. (__arm_vmlaldavaxq): Likewise. (__arm_vrmlaldavhaq_p): Likewise.
[Bug target/107515] MVE: Generic functions do not accept _Float16 scalars
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107515 --- Comment #5 from CVS Commits --- The trunk branch has been updated by Andrea Corallo : https://gcc.gnu.org/g:2fefb8931d566cc8a4cbba81601972b0d2002f95 commit r13-4332-g2fefb8931d566cc8a4cbba81601972b0d2002f95 Author: Stam Markianos-Wright Date: Thu Nov 10 15:06:47 2022 + arm: Explicitly specify other float types for _Generic overloading [PR107515] This patch adds explicit references to other float types to __ARM_mve_typeid in arm_mve.h. Resolves PR 107515: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107515 gcc/ChangeLog: PR target/107515 * config/arm/arm_mve.h (__ARM_mve_typeid): Add float types.
[Bug libstdc++/107815] 20_util/to_chars/float128_c++23.cc FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107815
--- Comment #17 from Jakub Jelinek ---
(In reply to dave.anglin from comment #16)
> This is what the test prints:
> 6.47518e-4966 6e-4966
> xxx.cc:79: void test(std::chars_format): Assertion 'ec4 == std::errc() &&
> ptr4 == ptr1' failed.
> ABORT instruction (core dumped)
Ah, ok, so it is a different case, the
std::numeric_limits::denorm_min(),
one.
6e-4966 is I believe the correct shortest scientific string representation of
the value, because nexttoward{l,f128} of that value in one direction is 0 (in
fixed or 0e+00 in scientific) and in the other direction is 12.95036e-4966
(1e-4965
in shortest scientific) and one further step 19.42554e-4966 (2e-4965 in
shortest scientific).
What fails is the from_chars for you, and from_chars when not hexadecimal
always
uses strto* functions, so I presume what HP-UX mishandles is:
#include
int
main ()
{
char *end;
const char *p = "6e-4966";
long double l = strtold (p, &end);
if (l != __LDBL_DENORM_MIN__ || end != p + 7)
abort ();
p = "1e-4965";
l = strtold (p, &end);
if (l != 2.0L * __LDBL_DENORM_MIN__ || end != p + 7)
abort ();
p = "2e-4965";
l = strtold (p, &end);
if (l != 3.0L * __LDBL_DENORM_MIN__ || end != p + 7)
abort ();
return 0;
}
Is that the case?
If yes, is denorm_min the only thing that doesn't work? We can then #ifdef it
out for HP-UX with a comment.
[Bug demangler/107884] H8/300: cp-demangle.c fix warning related demangle.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107884 --- Comment #4 from Jonathan Wakely --- (In reply to Richard Biener from comment #3) > Supposedly C defines literal suffixes for int32_t? Otherwise using (1L << > 17) might work as well here. Yes, it could be: INT32_C(1) << 17 That expands to int_least32_t not int32_t but that's fine for this purpose.
[Bug target/106875] [11/12/13 Regression] ICE in ix86_emit_outlined_ms2sysv_save with -mabi=ms -mcall-ms2sysv-xlogues and "#pragma GCC target" since r11-3183-gba948b37768c99cd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106875
--- Comment #3 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:ee629d242d9f93a38e49bed904bb334bbe15dde1
commit r13-4353-gee629d242d9f93a38e49bed904bb334bbe15dde1
Author: Jakub Jelinek
Date: Mon Nov 28 10:13:43 2022 +0100
i386: Fix up ix86_abi handling [PR106875]
The following testcase fails since my changes to make also
opts_set saved/restored upon function target/optimization changes
(before it has been acting as "has this option be ever explicit
anywhere?").
The problem is that for ix86_abi we depend on the opts_set
value for it in ix86_option_override_internal:
SET_OPTION_IF_UNSET (opts, opts_set, ix86_abi, DEFAULT_ABI);
but as it is a TargetSave, the backend code is required to
save/restore it manually (it does that) and since gcc 11 also
to save/restore the opts_set bit for it (which isn't done).
We don't do that for various other TargetSave which
ix86_function_specific_{save,restore} saves/restores, but as long
as we never test opts_set for it, it doesn't really matter.
One possible fix would be to introduce some new TargetSave into
which ix86_function_specific_{save,restore} would save/restore a bitmask
of the opts_set bits. The following patch uses an easier fix, by
making it a TargetVariable instead the saving/restoring is handled
by the generated code.
The differences in options.h are just slight movements on where
*ix86_abi stuff appears in it, ditto for options.cc, the real
differences are just in options-save.cc, where cl_target_option_save
gets:
+ ptr->x_ix86_abi = opts->x_ix86_abi;
...
+ if (opts_set->x_ix86_abi) mask |= HOST_WIDE_INT_1U << 3;
(plus adjustments of following TargetVariables mask related stuff),
cl_target_option_restore gets:
+ opts->x_ix86_abi = ptr->x_ix86_abi;
...
+ opts_set->x_ix86_abi = static_cast((mask & 1) != 0);
+ mask >>= 1;
plus the movements in other functions too. So, by it being a
TargetVariable, the only thing that changed is that we don't need to
handle it manually in ix86_function_specific_{save,restore} because it
is handled automatically including the opts_set stuff.
2022-11-28 Jakub Jelinek
PR target/106875
* config/i386/i386.opt (x_ix86_abi): Remove TargetSave.
(ix86_abi): Replace it with TargetVariable.
* config/i386/i386-options.cc (ix86_function_specific_save,
ix86_function_specific_restore): Don't save and restore x_ix86_abi.
* g++.target/i386/pr106875.C: New test.
[Bug libstdc++/107886] Problem witch std::latch, std::binary_semaphores in C++20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107886 --- Comment #9 from Jonathan Wakely --- Please read https://gcc.gnu.org/bugs/ and provide the requested info! It asks for several things which are still missing and should not be difficult, e.g. the output of `gcc -v` It works fine for me with x86_64-w64-mingw32 so this seems to be a problem with the mingw config, not with upstream GCC. Probably you don't have a threading library that GCC can use, such as pthreads-win32. But we can't tell how your GCC has been configured because you won't provide the requested information.
[Bug target/106875] [11/12 Regression] ICE in ix86_emit_outlined_ms2sysv_save with -mabi=ms -mcall-ms2sysv-xlogues and "#pragma GCC target" since r11-3183-gba948b37768c99cd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106875 Jakub Jelinek changed: What|Removed |Added Summary|[11/12/13 Regression] ICE |[11/12 Regression] ICE in |in |ix86_emit_outlined_ms2sysv_ |ix86_emit_outlined_ms2sysv_ |save with -mabi=ms |save with -mabi=ms |-mcall-ms2sysv-xlogues and |-mcall-ms2sysv-xlogues and |"#pragma GCC target" since |"#pragma GCC target" since |r11-3183-gba948b37768c99cd |r11-3183-gba948b37768c99cd | --- Comment #4 from Jakub Jelinek --- Fixed on the trunk for now.
[Bug c++/107889] Incorrect parsing of qualified friend function returning decltype(auto)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107889 --- Comment #2 from Jonathan Wakely --- I think this is https://wg21.link/cwg1828 which was resolved by https://wg21.link/p1787 which GCC does not implement yet.
[Bug c++/107889] Incorrect parsing of qualified friend function returning decltype(auto)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107889 --- Comment #3 from Jonathan Wakely --- (In reply to David Mazières from comment #0) > A similar problem was reported in bug #59766 for friend functions returning > auto. That's unrelated. The problem here is that decltype(auto)::f is a nested-name-specifier for a member 'f' so is parsed as part of the return type, not the function name. This is what C++20 (and all earlier standards) said. The ambiguity has been resolved as a DR against earlier standards, but GCC doesn't implement that change yet, as shown at https://gcc.gnu.org/projects/cxx-status.html#cxx23
[Bug libstdc++/107815] 20_util/to_chars/float128_c++23.cc FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107815
--- Comment #18 from Jakub Jelinek ---
Or better yet
#include
#include
int
main ()
{
char *end;
const char *p = "6e-4966";
long double l = strtold (p, &end);
if (l != __LDBL_DENORM_MIN__ || end != p + 7)
printf ("%Le %s\n", l, end);
p = "1e-4965";
l = strtold (p, &end);
if (l != 2.0L * __LDBL_DENORM_MIN__ || end != p + 7)
printf ("%Le %s\n", l, end);
p = "2e-4965";
l = strtold (p, &end);
if (l != 3.0L * __LDBL_DENORM_MIN__ || end != p + 7)
printf ("%Le %s\n", l, end);
return 0;
}
so that we know if it is just the denorm_min() case or also other denormals.
[Bug sanitizer/106558] ASan failed to detect a global-buffer-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106558 --- Comment #19 from CVS Commits --- The master branch has been updated by Martin Liska : https://gcc.gnu.org/g:5dd4d2e93e3de60d4ef1068b6dfd06b6b9fff16e commit r13-4354-g5dd4d2e93e3de60d4ef1068b6dfd06b6b9fff16e Author: Yuri Gribov Date: Sun Aug 14 08:42:44 2022 +0300 asan: fix unsafe optimization of Asan checks. PR sanitizer/106558 gcc/ * sanopt.cc: Do not optimize out checks for non-SSA addresses. gcc/testsuite/ * c-c++-common/asan/pr106558.c: New test.
[Bug sanitizer/106558] ASan failed to detect a global-buffer-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106558 --- Comment #20 from Martin Liška --- Fixed on master. Do we want to do a backport?
[Bug fortran/107872] ICE on recursive DT with DTIO since r7-4096-gbf9f15ee55f5b291
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107872
--- Comment #3 from Paul Thomas ---
Created attachment 53975
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53975&action=edit
Fix for this PR
This is a trivial bug. The ICE is occurring in resolve.cc(derived_inaccessible)
because derived types with recursive allocatable components have not been
allowed for.
With the patch, the test below does the right thing.
I am tied up with my finalization work at present. If somebody else wishes to
commit the patch, be my guest.
With a pointer component, the test runs correctly back to gfortran 7.4.1
20191027.
Cheers
Paul
! { dg-do run }
!
! Test the fix for PR107872, where an ICE occurred in
resolve.cc(derived_inaccessible)
! because derived types with recursive allocatable components were not catered
for.
!
module mod1
type t
integer :: data
type(t), allocatable :: next
contains
procedure, private :: write_t
generic :: write(formatted) => write_t
end type
contains
recursive subroutine write_t(this, unit, iotype, v_list, iostat, iomsg)
class(t), intent(in) :: this
integer, intent(in) :: unit
character(*), intent(in) :: iotype
integer, intent(in) :: v_list(:)
integer, intent(out) :: iostat
character(*), intent(inout) :: iomsg
if (ALLOCATED(this%next)) &
write (unit, '(dt)') this%next
write (unit, '(i2)') this%data
end subroutine
end module
use mod1
type(t) :: a
character (8) :: buffer
a%data = 1
allocate (a%next)
a%next%data = 2
allocate (a%next%next)
a%next%next%data = 3
write (buffer, '(dt)')a
deallocate (a%next)
if (trim (buffer) .ne. ' 3 2 1') stop 1
end
[Bug tree-optimization/107608] [13 Regression] Failure on fold-overflow-1.c and pr95115.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107608 Richard Biener changed: What|Removed |Added Keywords||missed-optimization --- Comment #6 from Richard Biener --- (In reply to Jakub Jelinek from comment #0) > ... but then > comes dom2 and happily replaces > _1 = 3.4028234663852885981170418348451692544e+38 * 2.0e+0; > return _1; > with > _1 = 3.4028234663852885981170418348451692544e+38 * 2.0e+0; > return Inf; > (I think this is still correct) Note this is also a pessimization code-generation wise since if we preserve the multiplication the result is readily available in a register but as optimized we have another constant pool entry and load. So we might want to consider not propagating constants generated by operations we cannot eliminate. If the only consumer is a compare-and-branch we can of course still end up with a seemingly dead stmt, so this would be only for the missed optimization.
[Bug tree-optimization/107493] [13 Regression] Wrong code at -Os on x86_64-linux-gnu since r13-3486-g4c5b116077638277
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107493 --- Comment #6 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:2b293a949c0fbe21e47c4bc99f807dc941c02bb6 commit r13-4357-g2b293a949c0fbe21e47c4bc99f807dc941c02bb6 Author: Richard Biener Date: Mon Nov 28 10:25:44 2022 +0100 tree-optimization/107493 - SCEV analysis with conversions This shows another case where trying to validate conversions during the CHREC SCC analysis fails because said analysis assumes we are converting a complete SCC. Like the constraint on the initial conversion seen restrict all conversions handled to sign-changes. PR tree-optimization/107493 * tree-scalar-evolution.cc (scev_dfs::follow_ssa_edge_expr): Only handle no-op and sign-changing conversions. * gcc.dg/torture/pr107493.c: New testcase.
[Bug tree-optimization/107493] [13 Regression] Wrong code at -Os on x86_64-linux-gnu since r13-3486-g4c5b116077638277
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107493 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #7 from Richard Biener --- Fixed.
[Bug tree-optimization/107176] [10/11/12 Regression] Wrong code at -Os on x86_64-pc-linux-gnu since r7-2012-g43aabfcfd4139e4c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107176 Bug 107176 depends on bug 107493, which changed state. Bug 107493 Summary: [13 Regression] Wrong code at -Os on x86_64-linux-gnu since r13-3486-g4c5b116077638277 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107493 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug libstdc++/107894] New: [feature request] _GLIBCXX_ASSERTIONS for std::optional
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107894 Bug ID: 107894 Summary: [feature request] _GLIBCXX_ASSERTIONS for std::optional Product: gcc Version: 12.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: tim at klingt dot org Target Milestone: --- `_GLIBCXX_ASSERTIONS` does not enable any API validation for std::optional. e.g. `operator->` translates to `address_to`: https://github.com/gcc-mirror/gcc/blob/master/libstdc%2B%2B-v3/include/std/optional#L969-L970 libc++ on the other hand has assertions that can detect invalid uses: https://github.com/llvm/llvm-project/blob/main/libcxx/include/optional#L930-L937 it would be great if libstdc++ could perform the same validation
[Bug tree-optimization/107895] New: mt19937 bad performance on LP64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107895
Bug ID: 107895
Summary: mt19937 bad performance on LP64
Product: gcc
Version: 12.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: jengelh at inai dot de
Target Milestone: ---
Input
=
#include
#include
static std::mt19937 rng;
int main() {
for (size_t j = 0; j < 0x8000; ++j) {
uint32_t numbers[65536];
for (size_t i = 0; i < std::size(numbers); ++i)
numbers[i] = rng();
// ensure number generation is not all optimized away
write(STDOUT_FILENO, numbers, sizeof(numbers));
}
}
Observed
Target: x86_64-suse-linux
gcc version 12.2.1 20221020 [revision 0aaef83351473e8f4eb774f8f999bbe87a4866d7]
(SUSE Linux)
$ g++ x.cpp -O2 && time ./a.out >/dev/zero
-m32-m64
=== = ==
std::mt19937 3.9s 11.5s
std::mt19937_64 14.0s 11.6s
=== = ==
error ±0.1s
With -ftree-loop-if-convert [Bug #80520], but still not at -m32 levels:
+-ftree- -m32-m64
=== = ==
std::mt19937 3.9s5.2s
std::mt19937_64 14.0s5.4s
=== = ==
error ±0.1s
Expected
Expected to see <= 4.7s on -m64 at all times. (3.9 + ~20% margin for wider
transfers CPU<->caches/RAM)
The -m64 versions should have somewhat equal runtime or faster runtime (because
more registers, more opportunities); concerns like https://gmplib.org/32vs64
apply to old CPUs, but I do not think it's indicative of how contemporary
x86_64 systems perform.
Additional information
==
CPUs:
"11th Gen Intel(R) Core(TM) i5-1135G7 @ 2.40GHz"
[fam 6 model 140 stepping 1 microcode 0xa4] and
"AMD Ryzen 7 3700X 8-Core Processor"
[fam 23 model 113 stepping 0 microcode 0x8701013]
(about 3.0 and 10.2 seconds runtime, respectively)
[Bug libstdc++/107885] H8/300: libsupc++/hash_bytes.cc fix shift-count-overflow warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107885 Jonathan Wakely changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug tree-optimization/107879] [13 Regression] ffmpeg-4 test suite fails on FPU arithmetics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107879 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- I will have a look.
[Bug libstdc++/107894] [feature request] _GLIBCXX_ASSERTIONS for std::optional
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107894
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|--- |DUPLICATE
--- Comment #1 from Jonathan Wakely ---
(In reply to tim blechmann from comment #0)
> `_GLIBCXX_ASSERTIONS` does not enable any API validation for std::optional.
I don't know why people keep claiming this, but it's nonsense.
tmp$ cat opt.cc
#include
int main()
{
std::optional o;
return *o.operator->();
}
tmp$ g++ -D_GLIBCXX_ASSERTIONS opt.cc
tmp$ ./a.out
/usr/include/c++/12/optional:477: constexpr _Tp& std::_Optional_base_impl<_Tp,
_Dp>::_M_get() [with _Tp = int; _Dp = std::_Optional_base]:
Assertion 'this->_M_is_engaged()' failed.
Aborted (core dumped)
> it would be great if libstdc++ could perform the same validation
It already does, please try it instead of just skimming the code.
*** This bug has been marked as a duplicate of bug 102712 ***
[Bug libstdc++/102712] std::optional::operator* should assert on unset value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102712 Jonathan Wakely changed: What|Removed |Added CC||tim at klingt dot org --- Comment #4 from Jonathan Wakely --- *** Bug 107894 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/107895] mt19937 bad performance on LP64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107895 --- Comment #1 from Jan Engelhardt --- clang-15.0.5+gnustdlibc timing distribution. -m32 -m64 mt19937 6.0 4.7 mt19937_64 9.2 4.7
[Bug demangler/107884] H8/300: cp-demangle.c fix warning related demangle.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107884 --- Comment #5 from Jonathan Wakely --- Oh, except that we pass it to cplus_demangle(const char*, int) and so anything above the first 16 bits is lost anyway. Should that function use int32_t instead?
[Bug tree-optimization/107617] SCC-VN with len_store and big endian
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107617
--- Comment #3 from Richard Biener ---
I suppose it's the
+ MEM [(integer(kind=4) *)_13] = { -1, 1, -1, 1 };
...
+ .LEN_STORE (vectp.75_247, 64B, 11, { 255, 255, 255, 255, 0, 0, 0, 1, 255,
255, 255, 255, 0, 0, 0, 1 }, -1);
..
+ MEM [(integer(kind=8) *)&a] = { -1, 1 };
+ MEM [(integer(kind=8) *)&a + 16B] = { -1, 1 };
+ a[4] = 1;
+ a[5] = -1;
+ a[6] = 1;
you are talking about where we elide the scalar loads from _13 stored into
a[].
A gimple testcase would be something like
typedef unsigned char v16qi __attribute__((vector_size(16)));
int a[4];
void __GIMPLE (ssa)
foo (void *p)
{
int v;
__BB(2):
.LEN_STORE (p_1(D), _Literal (int *) 64, 11, _Literal (v16qi) { _Literal
(unsigned char) 255, _Literal (unsigned char) 255, _Literal (unsigned char)
255, _Literal (unsigned char) 255, _Literal (unsigned char) 0, _Literal
(unsigned char) 0, _Literal (unsigned char) 0, _Literal (unsigned char) 1,
_Literal (unsigned char) 255, _Literal (unsigned char) 255, _Literal (unsigned
char) 255, _Literal (unsigned char) 255, _Literal (unsigned char) 0, _Literal
(unsigned char) 0, _Literal (unsigned char) 0, _Literal (unsigned char) 1 },
_Literal (signed char) -1);
v_2 = __MEM ((int *)p_1(D));
v_3 = __MEM ((int *)p_1(D) + 4);
v_4 = __MEM ((int *)p_1(D) + 8);
v_5 = __MEM ((int *)p_1(D) + 12);
a[0] = v_2;
a[1] = v_3;
a[2] = v_4;
a[3] = v_5;
return;
}
which produces
a[0] = 1;
a[1] = _Literal (int) -1;
a[2] = 1;
a[3] = v_5;
changing the len to 15 and thus folding the .LEN_STORE to a full store changes
that to
a[0] = _Literal (int) -1;
a[1] = 1;
a[2] = _Literal (int) -1;
a[3] = 1;
which I assume is correct? I think we'd need to feed a negative pd.rhs_off
into native_encode_expr but that's not supported there (and it treats -1
special).
Still .LEN_STORE covers bytes p + [0..11] here, correct? But the stored
value is interpreted wrongly here and the new rhs_off assumes little-endian
adjustment.
[Bug tree-optimization/107617] SCC-VN with len_store and big endian
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107617 --- Comment #4 from Richard Biener --- Created attachment 53976 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53976&action=edit patch Can you please test this patch? Visually inspecting the fortran testcase and the GIMPLE testcase shows it fixes this case.
[Bug tree-optimization/107895] mt19937 bad performance on LP64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107895
Richard Biener changed:
What|Removed |Added
Keywords||missed-optimization
Target||x86_64-*-*
--- Comment #2 from Richard Biener ---
Sounds like an if-conversion issue, thus RTL? Btw, we inline a wrapper
doing
if (..->_M_p > 623)
mersenne_twister_engine ();
else
{
some inlined stuff, incrementing _M_p
}
but the inlined stuff is already fully if-converted and thus not the
timing critical part?
[Bug libstdc++/107886] Problem witch std::latch, std::binary_semaphores in C++20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107886
--- Comment #10 from Jamaika ---
```
Using built-in specs.
COLLECT_GCC=g++.exe
Target: x86_64-w64-mingw32
Configured with: /home/ma/m/source/gcc-g/configure --host=x86_64-w64-mingw32
--target=x86_64-w64-mingw32 --disable-nls --enable-languages=c,c++,objc,obj-c++
--with-gmp=/home/ma/m/build/for_target --with-mpfr=/home/ma/m/build/for_target
--with-mpc=/home/ma/m/build/for_target --with-isl=/home/ma/m/build/for_target
--enable-twoprocess --disable-libstdcxx-pch --disable-win32-registry
--disable-shared --enable-fully-dynamic-string --enable-libssp
--prefix=/home/ma/m/target --with-sysroot=/home/ma/m/target
Thread model: win32
Supported LTO compression algorithms: zlib
gcc version 13.0.0 20221124 (experimental) (GCC)
COLLECT_GCC_OPTIONS='-v' '-std=gnu++20' '-ftree-vectorize' '-D' 'WINVER=0x0602'
'-D' '_WIN32_WINNT=0x0602' '-g0' '-O3' '-c' '-o' 'latch_windows.o'
'-mtune=generic' '-march=x86-64'
c:/gcc1300/bin/../libexec/gcc/x86_64-w64-mingw32/13.0.0/cc1plus.exe -quiet -v
-iprefix c:\gcc1300\bin\../lib/gcc/x86_64-w64-mingw32/13.0.0/ -U_REENTRANT -D
WINVER=0x0602 -D _WIN32_WINNT=0x0602 latch_windows.cpp -quiet -dumpbase
latch_windows.cpp -dumpbase-ext .cpp -mtune=generic -march=x86-64 -g0 -O3
-std=gnu++20 -version -ftree-vectorize -o
C:\Users\KOMPUT~1\AppData\Local\Temp\ccI5bDpg.s
GNU C++20 (GCC) version 13.0.0 20221124 (experimental) (x86_64-w64-mingw32)
compiled by GNU C version 13.0.0 20221124 (experimental), GMP version
6.2.1, MPFR version 4.1.1, MPC version 1.2.1, isl version isl-0.24-GMP
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
ignoring duplicate directory
"c:/gcc1300/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/13.0.0/../../../../include/c++/13.0.0"
ignoring duplicate directory
"c:/gcc1300/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/13.0.0/../../../../include/c++/13.0.0/x86_64-w64-mingw32"
ignoring duplicate directory
"c:/gcc1300/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/13.0.0/../../../../include/c++/13.0.0/backward"
ignoring duplicate directory
"c:/gcc1300/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/13.0.0/include"
ignoring nonexistent directory
"/home/ma/m/target/home/ma/m/target/lib/gcc/x86_64-w64-mingw32/13.0.0/../../../../include"
ignoring duplicate directory
"c:/gcc1300/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/13.0.0/include-fixed"
ignoring duplicate directory
"c:/gcc1300/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/13.0.0/../../../../x86_64-w64-mingw32/include"
ignoring nonexistent directory "/home/ma/m/target/mingw/include"
#include "..." search starts here:
#include <...> search starts here:
c:\gcc1300\bin\../lib/gcc/x86_64-w64-mingw32/13.0.0/../../../../include/c++/13.0.0
c:\gcc1300\bin\../lib/gcc/x86_64-w64-mingw32/13.0.0/../../../../include/c++/13.0.0/x86_64-w64-mingw32
c:\gcc1300\bin\../lib/gcc/x86_64-w64-mingw32/13.0.0/../../../../include/c++/13.0.0/backward
c:\gcc1300\bin\../lib/gcc/x86_64-w64-mingw32/13.0.0/include
c:\gcc1300\bin\../lib/gcc/x86_64-w64-mingw32/13.0.0/include-fixed
c:\gcc1300\bin\../lib/gcc/x86_64-w64-mingw32/13.0.0/../../../../x86_64-w64-mingw32/include
End of search list.
GNU C++20 (GCC) version 13.0.0 20221124 (experimental) (x86_64-w64-mingw32)
compiled by GNU C version 13.0.0 20221124 (experimental), GMP version
6.2.1, MPFR version 4.1.1, MPC version 1.2.1, isl version isl-0.24-GMP
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: 2b6c2fb9839dec486c0793745b5cdfdc
In file included from c:\gcc1300\include\c++\13.0.0\latch:38,
from latch_windows.cpp:5:
c:\gcc1300\include\c++\13.0.0\bits\atomic_base.h: In member function 'void
std::atomic_flag::wait(bool, std::memory_order) const':
c:\gcc1300\include\c++\13.0.0\bits\atomic_base.h:264:12: error:
'__atomic_wait_address_v' is not a member of 'std'
264 | std::__atomic_wait_address_v(&_M_i, __v,
|^~~
c:\gcc1300\include\c++\13.0.0\bits\atomic_base.h: In member function 'void
std::atomic_flag::notify_one()':
c:\gcc1300\include\c++\13.0.0\bits\atomic_base.h:272:12: error:
'__atomic_notify_address' is not a member of 'std'
272 | { std::__atomic_notify_address(&_M_i, false); }
|^~~
c:\gcc1300\include\c++\13.0.0\bits\atomic_base.h: In member function 'void
std::atomic_flag::notify_all()':
c:\gcc1300\include\c++\13.0.0\bits\atomic_base.h:278:12: error:
'__atomic_notify_address' is not a member of 'std'
278 | { std::__atomic_notify_address(&_M_i, true); }
|^~~
c:\gcc1300\include\c++\13.0.0\bits\atomic_base.h: In member function 'void
std::__atomic_base<_IntTp>::wait(__int_type, std::memory_order) const':
c:\gcc1300\include\c++\13.0.0\bits\atomic_base.h:613:14: error:
'__atomic_wait_address_v' is not a member of 'std'
613 | std::__atomic_wait_address_v(&_M_i, __old,
| ^~~
c:\gcc1300\include\c++\1
[Bug libstdc++/107886] Problem witch std::latch, std::binary_semaphores in C++20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107886 --- Comment #11 from Jamaika --- without #define __cpp_lib_atomic_wait 201907L ``` Using built-in specs. COLLECT_GCC=g++.exe Target: x86_64-w64-mingw32 Configured with: /home/ma/m/source/gcc-g/configure --host=x86_64-w64-mingw32 --target=x86_64-w64-mingw32 --disable-nls --enable-languages=c,c++,objc,obj-c++ --with-gmp=/home/ma/m/build/for_target --with-mpfr=/home/ma/m/build/for_target --with-mpc=/home/ma/m/build/for_target --with-isl=/home/ma/m/build/for_target --enable-twoprocess --disable-libstdcxx-pch --disable-win32-registry --disable-shared --enable-fully-dynamic-string --enable-libssp --prefix=/home/ma/m/target --with-sysroot=/home/ma/m/target Thread model: win32 Supported LTO compression algorithms: zlib gcc version 13.0.0 20221124 (experimental) (GCC) COLLECT_GCC_OPTIONS='-v' '-std=gnu++20' '-ftree-vectorize' '-D' 'WINVER=0x0602' '-D' '_WIN32_WINNT=0x0602' '-g0' '-O3' '-c' '-o' 'latch_windows.o' '-mtune=generic' '-march=x86-64' c:/gcc1300/bin/../libexec/gcc/x86_64-w64-mingw32/13.0.0/cc1plus.exe -quiet -v -iprefix c:\gcc1300\bin\../lib/gcc/x86_64-w64-mingw32/13.0.0/ -U_REENTRANT -D WINVER=0x0602 -D _WIN32_WINNT=0x0602 latch_windows.cpp -quiet -dumpbase latch_windows.cpp -dumpbase-ext .cpp -mtune=generic -march=x86-64 -g0 -O3 -std=gnu++20 -version -ftree-vectorize -o C:\Users\KOMPUT~1\AppData\Local\Temp\ccVi63tF.s GNU C++20 (GCC) version 13.0.0 20221124 (experimental) (x86_64-w64-mingw32) compiled by GNU C version 13.0.0 20221124 (experimental), GMP version 6.2.1, MPFR version 4.1.1, MPC version 1.2.1, isl version isl-0.24-GMP GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 ignoring duplicate directory "c:/gcc1300/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/13.0.0/../../../../include/c++/13.0.0" ignoring duplicate directory "c:/gcc1300/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/13.0.0/../../../../include/c++/13.0.0/x86_64-w64-mingw32" ignoring duplicate directory "c:/gcc1300/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/13.0.0/../../../../include/c++/13.0.0/backward" ignoring duplicate directory "c:/gcc1300/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/13.0.0/include" ignoring nonexistent directory "/home/ma/m/target/home/ma/m/target/lib/gcc/x86_64-w64-mingw32/13.0.0/../../../../include" ignoring duplicate directory "c:/gcc1300/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/13.0.0/include-fixed" ignoring duplicate directory "c:/gcc1300/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/13.0.0/../../../../x86_64-w64-mingw32/include" ignoring nonexistent directory "/home/ma/m/target/mingw/include" #include "..." search starts here: #include <...> search starts here: c:\gcc1300\bin\../lib/gcc/x86_64-w64-mingw32/13.0.0/../../../../include/c++/13.0.0 c:\gcc1300\bin\../lib/gcc/x86_64-w64-mingw32/13.0.0/../../../../include/c++/13.0.0/x86_64-w64-mingw32 c:\gcc1300\bin\../lib/gcc/x86_64-w64-mingw32/13.0.0/../../../../include/c++/13.0.0/backward c:\gcc1300\bin\../lib/gcc/x86_64-w64-mingw32/13.0.0/include c:\gcc1300\bin\../lib/gcc/x86_64-w64-mingw32/13.0.0/include-fixed c:\gcc1300\bin\../lib/gcc/x86_64-w64-mingw32/13.0.0/../../../../x86_64-w64-mingw32/include End of search list. GNU C++20 (GCC) version 13.0.0 20221124 (experimental) (x86_64-w64-mingw32) compiled by GNU C version 13.0.0 20221124 (experimental), GMP version 6.2.1, MPFR version 4.1.1, MPC version 1.2.1, isl version isl-0.24-GMP GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Compiler executable checksum: 2b6c2fb9839dec486c0793745b5cdfdc latch_windows.cpp:9:6: error: 'latch' in namespace 'std' does not name a type 9 | std::latch workDone(6); | ^ latch_windows.cpp: In member function 'void Worker::operator()()': latch_windows.cpp:23:9: error: 'workDone' was not declared in this scope 23 | workDone.arrive_and_wait(); // wait until all work is done (1) | ^~~~ ```
[Bug libstdc++/107886] Problem witch std::latch, std::binary_semaphores in C++20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107886 --- Comment #12 from Jamaika --- with 'latch.h' ``` Using built-in specs. COLLECT_GCC=g++.exe Target: x86_64-w64-mingw32 Configured with: /home/ma/m/source/gcc-g/configure --host=x86_64-w64-mingw32 --target=x86_64-w64-mingw32 --disable-nls --enable-languages=c,c++,objc,obj-c++ --with-gmp=/home/ma/m/build/for_target --with-mpfr=/home/ma/m/build/for_target --with-mpc=/home/ma/m/build/for_target --with-isl=/home/ma/m/build/for_target --enable-twoprocess --disable-libstdcxx-pch --disable-win32-registry --disable-shared --enable-fully-dynamic-string --enable-libssp --prefix=/home/ma/m/target --with-sysroot=/home/ma/m/target Thread model: win32 Supported LTO compression algorithms: zlib gcc version 13.0.0 20221124 (experimental) (GCC) COLLECT_GCC_OPTIONS='-v' '-std=gnu++20' '-ftree-vectorize' '-D' 'WINVER=0x0602' '-D' '_WIN32_WINNT=0x0602' '-g0' '-O3' '-c' '-o' 'latch_windows.o' '-mtune=generic' '-march=x86-64' c:/gcc1300/bin/../libexec/gcc/x86_64-w64-mingw32/13.0.0/cc1plus.exe -quiet -v -iprefix c:\gcc1300\bin\../lib/gcc/x86_64-w64-mingw32/13.0.0/ -U_REENTRANT -D WINVER=0x0602 -D _WIN32_WINNT=0x0602 latch_windows.cpp -quiet -dumpbase latch_windows.cpp -dumpbase-ext .cpp -mtune=generic -march=x86-64 -g0 -O3 -std=gnu++20 -version -ftree-vectorize -o C:\Users\KOMPUT~1\AppData\Local\Temp\cc7P0VYd.s GNU C++20 (GCC) version 13.0.0 20221124 (experimental) (x86_64-w64-mingw32) compiled by GNU C version 13.0.0 20221124 (experimental), GMP version 6.2.1, MPFR version 4.1.1, MPC version 1.2.1, isl version isl-0.24-GMP GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 ignoring duplicate directory "c:/gcc1300/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/13.0.0/../../../../include/c++/13.0.0" ignoring duplicate directory "c:/gcc1300/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/13.0.0/../../../../include/c++/13.0.0/x86_64-w64-mingw32" ignoring duplicate directory "c:/gcc1300/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/13.0.0/../../../../include/c++/13.0.0/backward" ignoring duplicate directory "c:/gcc1300/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/13.0.0/include" ignoring nonexistent directory "/home/ma/m/target/home/ma/m/target/lib/gcc/x86_64-w64-mingw32/13.0.0/../../../../include" ignoring duplicate directory "c:/gcc1300/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/13.0.0/include-fixed" ignoring duplicate directory "c:/gcc1300/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/13.0.0/../../../../x86_64-w64-mingw32/include" ignoring nonexistent directory "/home/ma/m/target/mingw/include" #include "..." search starts here: #include <...> search starts here: c:\gcc1300\bin\../lib/gcc/x86_64-w64-mingw32/13.0.0/../../../../include/c++/13.0.0 c:\gcc1300\bin\../lib/gcc/x86_64-w64-mingw32/13.0.0/../../../../include/c++/13.0.0/x86_64-w64-mingw32 c:\gcc1300\bin\../lib/gcc/x86_64-w64-mingw32/13.0.0/../../../../include/c++/13.0.0/backward c:\gcc1300\bin\../lib/gcc/x86_64-w64-mingw32/13.0.0/include c:\gcc1300\bin\../lib/gcc/x86_64-w64-mingw32/13.0.0/include-fixed c:\gcc1300\bin\../lib/gcc/x86_64-w64-mingw32/13.0.0/../../../../x86_64-w64-mingw32/include End of search list. GNU C++20 (GCC) version 13.0.0 20221124 (experimental) (x86_64-w64-mingw32) compiled by GNU C version 13.0.0 20221124 (experimental), GMP version 6.2.1, MPFR version 4.1.1, MPC version 1.2.1, isl version isl-0.24-GMP GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Compiler executable checksum: 2b6c2fb9839dec486c0793745b5cdfdc COLLECT_GCC_OPTIONS='-v' '-std=gnu++20' '-ftree-vectorize' '-D' 'WINVER=0x0602' '-D' '_WIN32_WINNT=0x0602' '-g0' '-O3' '-c' '-o' 'latch_windows.o' '-mtune=generic' '-march=x86-64' c:/gcc1300/bin/../lib/gcc/x86_64-w64-mingw32/13.0.0/../../../../x86_64-w64-mingw32/bin/as.exe -v -o latch_windows.o C:\Users\KOMPUT~1\AppData\Local\Temp\cc7P0VYd.s GNU assembler version 2.39 (x86_64-w64-mingw32) using BFD version (GNU Binutils) 2.39 COMPILER_PATH=c:/gcc1300/bin/../libexec/gcc/x86_64-w64-mingw32/13.0.0/;c:/gcc1300/bin/../libexec/gcc/;c:/gcc1300/bin/../lib/gcc/x86_64-w64-mingw32/13.0.0/../../../../x86_64-w64-mingw32/bin/ LIBRARY_PATH=c:/gcc1300/bin/../lib/gcc/x86_64-w64-mingw32/13.0.0/;c:/gcc1300/bin/../lib/gcc/;c:/gcc1300/bin/../lib/gcc/x86_64-w64-mingw32/13.0.0/../../../../x86_64-w64-mingw32/lib/../lib/;c:/gcc1300/bin/../lib/gcc/x86_64-w64-mingw32/13.0.0/../../../../lib/;c:/gcc1300/bin/../lib/gcc/x86_64-w64-mingw32/13.0.0/../../../../x86_64-w64-mingw32/lib/;c:/gcc1300/bin/../lib/gcc/x86_64-w64-mingw32/13.0.0/../../../ COLLECT_GCC_OPTIONS='-v' '-std=gnu++20' '-ftree-vectorize' '-D' 'WINVER=0x0602' '-D' '_WIN32_WINNT=0x0602' '-g0' '-O3' '-c' '-o' 'latch_windows.o' '-mtune=generic' '-march=x86-64' '-dumpdir' 'latch_windows.' ```
[Bug libstdc++/107801] Building cross compiler for H8 family fails in libstdc++ (c++17/memory_resource.cc)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107801 --- Comment #11 from Jonathan Wakely --- I don't think we want to build (parts of) the library with non-default options like that. It might affect the ABI of the library, and all users would have to use the same options for their own code. I think we can just use bitset::size_type for the _M_bytes member. We don't need to use uint32_t there if size_t only has 16 bits. We can't allocate that much memory anyway. --- a/libstdc++-v3/src/c++17/memory_resource.cc +++ b/libstdc++-v3/src/c++17/memory_resource.cc @@ -505,7 +505,7 @@ namespace pmr } // Allocated size of chunk: -uint32_t _M_bytes = 0; +bitset::size_type _M_bytes = 0; // Start of allocated chunk: std::byte* _M_p = nullptr; @@ -579,7 +579,7 @@ namespace pmr // For 16-bit pointers it's five pointers (10 bytes). // TODO pad 64-bit to 4*sizeof(void*) to avoid splitting across cache lines? static_assert(sizeof(chunk) - == sizeof(bitset::size_type) + sizeof(uint32_t) + 2 * sizeof(void*)); + == 2 * sizeof(bitset::size_type) + 2 * sizeof(void*)); // An oversized allocation that doesn't fit in a pool. struct big_block With that change, I get failures for fs_dir.cc instead: libtool: compile: /home/jwakely/src/gcc/build-h8/./gcc/xgcc -shared-libgcc -B/home/jwakely/src/gcc/build-h8/./gcc -nostdinc++ -L/home/jwakely/src/gcc/build-h8/h8300-elf/normal/libstdc++-v3/src -L/home/jwakely/src/gcc/build-h8/h8300-elf/normal/libstdc++-v3/src/.libs -L/home/jwakely/src/gcc/build-h8/h8300-elf/normal/libstdc++-v3/libsupc++/.libs -nostdinc -B/home/jwakely/src/gcc/build-h8/h8300-elf/normal/newlib/ -isystem /home/jwakely/src/gcc/build-h8/h8300-elf/normal/newlib/targ-include -isystem /home/jwakely/src/gcc/gcc/newlib/libc/include -B/home/jwakely/gcc/h8300-elf/h8300-elf/bin/ -B/home/jwakely/gcc/h8300-elf/h8300-elf/lib/ -isystem /home/jwakely/gcc/h8300-elf/h8300-elf/include -isystem /home/jwakely/gcc/h8300-elf/h8300-elf/sys-include -mn -I/home/jwakely/src/gcc/gcc/libstdc++-v3/../libgcc -I/home/jwakely/src/gcc/build-h8/h8300-elf/normal/libstdc++-v3/include/h8300-elf -I/home/jwakely/src/gcc/build-h8/h8300-elf/normal/libstdc++-v3/include -I/home/jwakely/src/gcc/gcc/libstdc++-v3/libsupc++ -std=gnu++17 -nostdinc++ -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi=2 -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -frandom-seed=fs_dir.lo -fimplicit-templates -g -O2 -c /home/jwakely/src/gcc/gcc/libstdc++-v3/src/c++17/fs_dir.cc -o fs_dir.o In file included from /home/jwakely/src/gcc/gcc/libstdc++-v3/src/c++17/fs_dir.cc:37: /home/jwakely/src/gcc/gcc/libstdc++-v3/src/c++17/../filesystem/dir-common.h: In static member function ‘static std::filesystem::__gnu_posix::DIR* std::filesystem::_Dir_base::openat(const _At_path&, bool)’: /home/jwakely/src/gcc/gcc/libstdc++-v3/src/c++17/../filesystem/dir-common.h:210:36: warning: unused parameter ‘nofollow’ [-Wunused-parameter] 210 | openat(const _At_path& atp, bool nofollow) | ~^~~~ /home/jwakely/src/gcc/gcc/libstdc++-v3/src/c++17/fs_dir.cc: In member function ‘bool std::filesystem::__cxx11::_Dir::do_unlink(bool, std::error_code&) const’: /home/jwakely/src/gcc/gcc/libstdc++-v3/src/c++17/fs_dir.cc:147:18: warning: unused parameter ‘is_directory’ [-Wunused-parameter] 147 | do_unlink(bool is_directory, error_code& ec) const noexcept | ~^~~~ /tmp/ccsGgjxM.s: Assembler messages: /tmp/ccsGgjxM.s:14980: Error: value of 000169ff too large for field of 2 bytes at 0010 /tmp/ccsGgjxM.s:14990: Error: value of 00025a7b too large for field of 2 bytes at 002a /tmp/ccsGgjxM.s:15018: Error: value of 0002e814 too large for field of 2 bytes at 0065 /tmp/ccsGgjxM.s:15024: Error: value of 0002e805 too large for field of 2 bytes at 0073 /tmp/ccsGgjxM.s:15033: Error: value of 00030c1c too large for field of 2 bytes at 0083 (and hundreds more assembler errors like that)
[Bug libstdc++/107815] 20_util/to_chars/float128_c++23.cc FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107815
--- Comment #19 from dave.anglin at bell dot net ---
On 2022-11-28 4:39 a.m., jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107815
>
> --- Comment #18 from Jakub Jelinek ---
> Or better yet
> #include
> #include
>
> int
> main ()
> {
>char *end;
>const char *p = "6e-4966";
>long double l = strtold (p, &end);
>if (l != __LDBL_DENORM_MIN__ || end != p + 7)
> printf ("%Le %s\n", l, end);
>p = "1e-4965";
>l = strtold (p, &end);
>if (l != 2.0L * __LDBL_DENORM_MIN__ || end != p + 7)
> printf ("%Le %s\n", l, end);
>p = "2e-4965";
>l = strtold (p, &end);
>if (l != 3.0L * __LDBL_DENORM_MIN__ || end != p + 7)
> printf ("%Le %s\n", l, end);
>return 0;
> }
> so that we know if it is just the denorm_min() case or also other denormals.
I tried both test cases with a recent build of gcc-12. Neither failed at O0 or
O2. Nothing was printed.
[Bug libstdc++/107801] Building cross compiler for H8 family fails in libstdc++ (c++17/memory_resource.cc)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107801 --- Comment #12 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #11) > I think we can just use bitset::size_type for the _M_bytes member. This compiles for all multilibs of x86_64, h8300-elf, and msp430-elf.
[Bug tree-optimization/107895] mt19937 bad performance on LP64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107895 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW CC||marxin at gcc dot gnu.org Ever confirmed|0 |1 Last reconfirmed||2022-11-28 --- Comment #3 from Martin Liška --- Btw. the benchmark was sped up by r13-739-g793f847ba7dbe763 from 8.4 -> 5.3s on AMD Ryzen 9 5950X 16-Core Processor with -O2 options.
[Bug tree-optimization/107879] [13 Regression] ffmpeg-4 test suite fails on FPU arithmetics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107879
--- Comment #5 from Jakub Jelinek ---
It is the foperator_mult::op{1,2}_range and can be seen even on:
double
foo (double x, double y)
{
double z = x * y;
if (z == 0.0)
return x;
return 42.0;
}
testcase.
2->3 (T) x_2(D) : [frange] double [-0.0 (-0x0.0p+0), 0.0 (0x0.0p+0)]
2->3 (T) y_3(D) : [frange] double [-0.0 (-0x0.0p+0), 0.0 (0x0.0p+0)]
2->3 (T) z_4 : [frange] double [-0.0 (-0x0.0p+0), 0.0 (0x0.0p+0)]
On the true edge of z == 0.0, we have [-0., 0.] range for z_4, that is correct,
but getting from lhs [-0., 0.] and op2 range VARYING to [-0., 0.] is wrong.
We get that because we compute the range in that case as [-0., 0.] / VARYING,
and for division it is actually correct, [-0., 0.] divided by anything non-NAN
non-zero is still [-0., 0.], and [-0., 0.] divided by [-0., 0.] is NAN.
Plus we have the (IMHO still correct) implication that if a result is not NAN,
then neither operand could be NAN.
So I'm afraid back to the drawing board on when we can use division for
multiplication reverse ranges and when we can use multiplication for division
reverse ranges (and whether it is ok to use minus/plus for plus/minus reverse
operations).
[Bug fortran/106576] Finalization of temporaries from functions not occuring
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106576 --- Comment #4 from Paul Thomas --- Created attachment 53977 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53977&action=edit Ongoing patch for PR37336 Fixes this PR, so testcase will be added to the collection. Paul
[Bug fortran/106576] Finalization of temporaries from functions not occuring
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106576 --- Comment #5 from Paul Thomas --- Hi Thomas, I hope that you are well and that the lack of time is for a good cause? I have just returned to my finalizer patch. With it applied, your testcase produces the same output as NAG. I will attach the present version of the patch to this PR. Cheers Paul
[Bug libstdc++/107466] [12/13 Regression] invalid -Wnarrowing error with std::subtract_with_carry_engine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107466 --- Comment #6 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:a64775a0edd46980036b757041f0c065ed9f8d22 commit r13-4364-ga64775a0edd46980036b757041f0c065ed9f8d22 Author: Jonathan Wakely Date: Mon Nov 28 09:44:52 2022 + libstdc++: Make 16-bit std::subtract_with_carry_engine work [PR107466] This implements the proposed resolution of LWG 3809, so that std::subtract_with_carry_engine can be used with a 16-bit result_type. Currently this produces a narrowing error when instantiating the std::linear_congruential_engine to create the initial state. It also truncates the default_seed constant when passing it as a result_type argument. Change the type of the constant to uint_least32_t and pass 0u when the default_seed should be used. libstdc++-v3/ChangeLog: PR libstdc++/107466 * include/bits/random.h (subtract_with_carry_engine): Use 32-bit type for default seed. Use 0u as default argument for subtract_with_carry_engine(result_type) constructor and seed(result_type) member function. * include/bits/random.tcc (subtract_with_carry_engine): Use 32-bit type for default seed and engine used for initial state. * testsuite/26_numerics/random/subtract_with_carry_engine/cons/lwg3809.cc: New test.
[Bug fortran/104382] Finalization of parent components not compliant with standard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104382 --- Comment #6 from Paul Thomas --- (In reply to Thomas Koenig from comment #4) > To add some variety to the tests, nagfor gives > > destructor4(complicated) 2.000 2.000 > destructor5 (simple2) 5 > destructor5 (simple2) 6 > destructor2(simple) 1 1 > final_count after assignment = 4 > destructor4(complicated) 4.000 5.000 > destructor5 (simple2) -1 > destructor5 (simple2) -2 > destructor2(simple) 3 4 > final_count after deallocation = 8 The current version of the finalizer patch gives the same result as nagfor. Cheers Paul
[Bug libstdc++/107886] Problem witch std::latch, std::binary_semaphores in C++20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107886 --- Comment #13 from Jonathan Wakely --- (In reply to Jamaika from comment #6) > I don't understand something. Why _GLIBCXX_HAS_GTHREADS works for > std::jthread but not for std::latch std::jthread doesn't depend on _GLIBCXX_HAS_GTHREADS, it's always available. But you might not be able to create a new thread using std::jthread if your platform doesn't provide what's needed for it to work. (In reply to Jamaika from comment #10) > ``` > Using built-in specs. > COLLECT_GCC=g++.exe > Target: x86_64-w64-mingw32 > Configured with: /home/ma/m/source/gcc-g/configure --host=x86_64-w64-mingw32 > --target=x86_64-w64-mingw32 --disable-nls > --enable-languages=c,c++,objc,obj-c++ --with-gmp=/home/ma/m/build/for_target > --with-mpfr=/home/ma/m/build/for_target > --with-mpc=/home/ma/m/build/for_target > --with-isl=/home/ma/m/build/for_target --enable-twoprocess > --disable-libstdcxx-pch --disable-win32-registry --disable-shared > --enable-fully-dynamic-string --enable-libssp --prefix=/home/ma/m/target > --with-sysroot=/home/ma/m/target > Thread model: win32 This is the problem. You need a thread model that provides the support needed for C++.
[Bug libstdc++/107886] Problem witch std::latch, std::binary_semaphores in C++20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107886 --- Comment #14 from Jonathan Wakely --- (In reply to Jamaika from comment #11) > without #define __cpp_lib_atomic_wait 201907L You should not be defining this anyway, it's defined by the library when the feature is supported. You can't change that. Don't ever define these __cpp_* macros. (In reply to Jamaika from comment #12) > with 'latch.h' This is a third-party header that defines its own std::latch, it has nothing to do with GCC.
[Bug tree-optimization/107896] New: ICE in supportable_widening_operation, at tree-vect-stmts.cc:12199 breaking arm bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107896
Bug ID: 107896
Summary: ICE in supportable_widening_operation, at
tree-vect-stmts.cc:12199 breaking arm bootstrap
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: acoplan at gcc dot gnu.org
Target Milestone: ---
The following fails (reduced from arm bootstrap):
$ cat t.cc
struct gcc_options {
int x_flag_tree_phiprop;
int x_flag_tree_pre;
int x_flag_tree_pta;
int x_flag_tree_reassoc;
int x_flag_tree_scev_cprop;
int x_flag_tree_sink;
int x_flag_tree_slp_vectorize;
int x_flag_web;
} cl_optimization_restore_opts;
signed char cl_optimization_restore_ptr_1, cl_optimization_restore_ptr_0;
void cl_optimization_restore() {
cl_optimization_restore_opts
.x_flag_tree_phiprop = cl_optimization_restore_opts.x_flag_tree_pre =
cl_optimization_restore_opts.x_flag_tree_pta =
cl_optimization_restore_opts.x_flag_tree_reassoc =
cl_optimization_restore_opts.x_flag_tree_scev_cprop =
cl_optimization_restore_opts.x_flag_tree_sink =
cl_optimization_restore_opts.x_flag_tree_slp_vectorize =
cl_optimization_restore_ptr_0;
cl_optimization_restore_opts.x_flag_web = cl_optimization_restore_ptr_1;
}
$ gcc/xgcc -B gcc -c t.cc -O2 -march=armv8-a+crypto
during GIMPLE pass: slp
t.cc: In function ‘void cl_optimization_restore()’:
t.cc:12:6: internal compiler error: in supportable_widening_operation, at
tree-vect-stmts.cc:12199
12 | void cl_optimization_restore() {
| ^~~
0x1dd0b13 supportable_widening_operation(vec_info*, tree_code, _stmt_vec_info*,
tree_node*, tree_node*, tree_code*, tree_code*, int*, vec*)
/home/alecop01/toolchain/src/gcc/gcc/tree-vect-stmts.cc:12199
0x1dd5ef5 vectorizable_conversion
/home/alecop01/toolchain/src/gcc/gcc/tree-vect-stmts.cc:5064
0x1df36c6 vect_analyze_stmt(vec_info*, _stmt_vec_info*, bool*, _slp_tree*,
_slp_instance*, vec*)
/home/alecop01/toolchain/src/gcc/gcc/tree-vect-stmts.cc:11256
0x13a164d vect_slp_analyze_node_operations_1
/home/alecop01/toolchain/src/gcc/gcc/tree-vect-slp.cc:5957
0x13a164d vect_slp_analyze_node_operations
/home/alecop01/toolchain/src/gcc/gcc/tree-vect-slp.cc:6147
0x13a1556 vect_slp_analyze_node_operations
/home/alecop01/toolchain/src/gcc/gcc/tree-vect-slp.cc:6126
0x13a3b37 vect_slp_analyze_operations(vec_info*)
/home/alecop01/toolchain/src/gcc/gcc/tree-vect-slp.cc:6387
0x13a8ce8 vect_slp_analyze_bb_1
/home/alecop01/toolchain/src/gcc/gcc/tree-vect-slp.cc:7372
0x13a8ce8 vect_slp_region
/home/alecop01/toolchain/src/gcc/gcc/tree-vect-slp.cc:7419
0x13a9b9d vect_slp_bbs
/home/alecop01/toolchain/src/gcc/gcc/tree-vect-slp.cc:7610
0x13aa1c1 vect_slp_function(function*)
/home/alecop01/toolchain/src/gcc/gcc/tree-vect-slp.cc:7698
0x13b3ec6 execute
/home/alecop01/toolchain/src/gcc/gcc/tree-vectorizer.cc:1532
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
$ gcc/xgcc -B gcc -v
Reading specs from gcc/specs
COLLECT_GCC=gcc/xgcc
COLLECT_LTO_WRAPPER=gcc/lto-wrapper
Target: arm-linux-gnueabihf
Configured with: /home/alecop01/toolchain/src/gcc/configure
--prefix=/data_sdb/toolchain/cc1s/arm-lin --enable-languages=c,c++
--disable-bootstrap --target=arm-linux-gnueabihf
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 13.0.0 20221128 (experimental) (GCC)
[Bug analyzer/107807] gcc.dg/analyzer/errno-1.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107807 David Malcolm changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #8 from David Malcolm --- Thanks; marking this as resolved.
[Bug libstdc++/107886] Problem witch std::latch, std::binary_semaphores in C++20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107886 Jonathan Wakely changed: What|Removed |Added Status|WAITING |NEW --- Comment #15 from Jonathan Wakely --- Confirming, as we might be able to support some subset of C++20 concurrency primitives for the Win32 model. As https://github.com/luncliff/latch/blob/master/latch_windows.cpp shows all that's needed are atomic decrements and WaitOnAddress/WakeByAddressAll. If our std::__atomic_wait_address and __atomic_impl::notify_all used those, we could provide std::latch, and maybe others.
[Bug tree-optimization/107896] [13 Regression] ICE in supportable_widening_operation, at tree-vect-stmts.cc:12199 breaking arm bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107896 Andrew Pinski changed: What|Removed |Added Summary|ICE in |[13 Regression] ICE in |supportable_widening_operat |supportable_widening_operat |ion, at |ion, at |tree-vect-stmts.cc:12199|tree-vect-stmts.cc:12199 |breaking arm bootstrap |breaking arm bootstrap Version|12.0|13.0 Target Milestone|--- |13.0 Keywords||build
[Bug tree-optimization/107868] [10 regression] Wrong code on AArch64 at -O1 with new/delete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107868 --- Comment #3 from Richard Biener --- a backport depends on r11-3610-gb6158faacbfb7d Your reduced testcase doesn't compile since it references undeclared 'pobj'.
[Bug tree-optimization/107896] [13 Regression] ICE in supportable_widening_operation, at tree-vect-stmts.cc:12199 breaking arm bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107896 --- Comment #1 from Andrew Pinski --- Going backwards: gcc_assert (VECTOR_MODE_P (intermediate_mode)); .. intermediate_mode = insn_data[icode1].operand[0].mode; ... if ((icode1 = optab_handler (optab1, vec_mode)) == CODE_FOR_nothing || (icode2 = optab_handler (optab2, vec_mode)) == CODE_FOR_nothing) return false;
[Bug c++/107864] [10/11/12/13 Regression] ICE (seg fault) in check_return_expr or instantiate_body with concepts and specialized version
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107864 Patrick Palka changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org Status|NEW |ASSIGNED CC||ppalka at gcc dot gnu.org
[Bug tree-optimization/107896] [13 Regression] ICE in supportable_widening_operation, at tree-vect-stmts.cc:12199 breaking arm bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107896 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Ever confirmed|0 |1 Last reconfirmed||2022-11-28 --- Comment #2 from Richard Biener --- OK, so we have vec_unpacks_lo_v2si unpacking V2Si to DImode. I can fix that easily.
[Bug tree-optimization/107868] [10 regression] Wrong code on AArch64 at -O1 with new/delete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107868 --- Comment #4 from Richard Biener --- I can confirm backporting the two revs fixes the -O1 execute FAIL of 20_util/allocator/1.cc on the branch. Fully testing that now.
[Bug libstdc++/107886] Problem witch std::latch, std::binary_semaphores in C++20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107886
--- Comment #16 from Jonathan Wakely ---
Something like ...
--- include/bits/atomic_wait.h 2022-11-07 15:38:32.551751184 +
+++ /tmp/inc/bits/atomic_wait.h 2022-11-28 16:27:51.352489618 +
@@ -33,7 +33,7 @@
#pragma GCC system_header
#include
-#if defined _GLIBCXX_HAS_GTHREADS || defined _GLIBCXX_HAVE_LINUX_FUTEX
+#if defined _GLIBCXX_HAS_GTHREADS || defined _GLIBCXX_HAVE_LINUX_FUTEX ||
_WIN32
#include
#include
#include
@@ -59,6 +59,10 @@
#define _GLIBCXX_HAVE_PLATFORM_WAIT 1
using __platform_wait_t = int;
inline constexpr size_t __platform_wait_alignment = 4;
+#elif _WIN32
+using __platform_wait_t = __UINTPTR_TYPE__;
+inline constexpr size_t __platform_wait_alignment
+ = alignof(__platform_wait_t);
#else
// define _GLIBCX_HAVE_PLATFORM_WAIT and implement __platform_wait()
// and __platform_notify() if there is a more efficient primitive supported
@@ -122,6 +126,30 @@
static_cast(__futex_wait_flags::__wake_private),
__all ? INT_MAX : 1);
}
+#elif _WIN32
+extern "C" int __glibcxx_get_last_error() __asm("GetLastError");
+
+template
+ void
+ __platform_wait(const _Tp* __addr, __platform_wait_t __val) noexcept
+ {
+const long __timeout = 0x;
+ if (WaitOnAddress(__addr, &__val, sizeof(__platform_wait_t),
__timeout))
+ return;
+_GLIBCXX_THROW_OR_ABORT(std::system_error(__glibcxx_get_last_error(),
+ std::system_category(),
+ "WaitOnAddress"));
+ }
+
+template
+ void
+ __platform_notify(const _Tp* __addr, bool __all) noexcept
+ {
+ if (__all)
+ WakeByAddressAll(__addr);
+ else
+ WakeByAddressOne(__addr);
+ }
#endif
inline void
[Bug c++/107773] Class members do not hide inherited types inside requires
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107773
Patrick Palka changed:
What|Removed |Added
CC||ppalka at gcc dot gnu.org
--- Comment #2 from Patrick Palka ---
accepts-invalid c++98 testcase (not a regression):
struct a {
typedef void get;
};
struct b : a {
int get(int i) const;
};
template
void f() {
typedef typename T::get type;
}
template void f();
[Bug libstdc++/107885] H8/300: libsupc++/hash_bytes.cc fix shift-count-overflow warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107885 --- Comment #1 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:7b79fa930917da735f02b4f6911dfbb0a91f9714 commit r13-4369-g7b79fa930917da735f02b4f6911dfbb0a91f9714 Author: Jonathan Wakely Date: Mon Nov 28 10:52:23 2022 + libstdc++: Fix _Hash_bytes for I16LP32 targets [PR107885] For H8/300 size_t is 32 bits wide, but (unsigned char)buf[2] << 16 promotes to int which is only 16 bits wide. The shift is then undefined. This fixes it by converting to size_t before shifting. libstdc++-v3/ChangeLog: PR libstdc++/107885 * libsupc++/hash_bytes.cc (_Hash_bytes): Convert to size_t instead of implicit integer promotion to 16 bits.
[Bug libstdc++/107801] Building cross compiler for H8 family fails in libstdc++ (c++17/memory_resource.cc)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107801 --- Comment #13 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:75e562d2c4303d3918be9d1563284b0c580c5e45 commit r13-4371-g75e562d2c4303d3918be9d1563284b0c580c5e45 Author: Jonathan Wakely Date: Mon Nov 28 13:28:53 2022 + libstdc++: Fix src/c++17/memory_resource for H8 targets [PR107801] This fixes compilation failures for H8 multilibs. For the normal multilib (ILP16L32?), the chunk struct does not have the expected size, because uint32_t is type long and has alignment 4 (by default). This forces sizeof(chunk) to be 12 instead of the expected 10. We can fix that by using bitset::size_type instead of uint32_t, so that we only use a 16-bit size when size_t and pointers are 16-bit types. For the I32LP16 multilibs that use -mint32 int is wider than size_t and so arithmetic expressions involving size_t promote to int. This means we need some explicit casts back to size_t. libstdc++-v3/ChangeLog: PR libstdc++/107801 * src/c++17/memory_resource.cc (chunk::_M_bytes): Change type from uint32_t to bitset::size_type. Adjust static assertion. (__pool_resource::_Pool::replenish): Cast to size_t after multiplication instead of before. (__pool_resource::_M_alloc_pools): Ensure both arguments to std::max have type size_t.
[Bug libstdc++/107801] Building cross compiler for H8 family fails in libstdc++ (c++17/memory_resource.cc)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107801 --- Comment #14 from Jonathan Wakely --- src/c++17/memory_resource.cc builds now with trunk, but I still get the assembler errors for src/c++17/fs_dir.cc
[Bug libstdc++/107885] H8/300: libsupc++/hash_bytes.cc fix shift-count-overflow warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107885 --- Comment #2 from Jonathan Wakely --- Fixed on trunk.
[Bug tree-optimization/107888] [12/13 Regression] Missed min/max transformation in phiopt due to VRP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107888 --- Comment #2 from Andrew Pinski --- (In reply to Richard Biener from comment #1) > which means we fail to optimize a > b ? 1 : b as well, no? Yes that is correct. Even for max, "a >= b ? a : 6;" would need to be "reverted" 6 back to b. [local count: 1073741824]: if (ab_2(D) >= bb_3(D)) goto ; [65.00%] else goto ; [35.00%] [local count: 697932184]: [local count: 1073741824]: # c_1 = PHI The min/max patterns inside match needs to handle CST if the ranges of the two operands overlap with one/two values. Even though this is a regression, I don't know if this shows up in real code and is a small optimization really so I would suspect a P4 for this really as it requires a bigger change that most likely won't be backported. I filed it as it was showing up while I was working on the patch for PR 101805 (which won't be submitted until GCC 14 anyways).
[Bug tree-optimization/105129] missing -Wformat-overflow for %b and %B directives in C2X standard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105129 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |13.0 Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #1 from Andrew Pinski --- Fixed for GCC 13 by r13-4372-gaa353bd9a03b0d5ba9 . Sorry for not confirming this bug before, I just happened on to this bug report (via my mail inbox) just a few minutes after the patch was merged in.
[Bug c++/105127] Search Path not working on Cygwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105127 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2022-11-28 Ever confirmed|0 |1 Status|UNCONFIRMED |WAITING --- Comment #1 from Andrew Pinski --- >Appveyor's Visual Studio 2017 image was ok. The problem appears on 2019 and >2022. I get the feeling the issue is more inside cygwin library if it works with 2017 image. Have you reported this problem to the cygwin folks?
[Bug c++/107897] New: [13 Regression] ICE in verify_curr_properties, at passes.cc:2201
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107897
Bug ID: 107897
Summary: [13 Regression] ICE in verify_curr_properties, at
passes.cc:2201
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
Started between 20221030 and 20221106,
with file g++.dg/cpp2a/concepts-lambda3.C :
$ gcc-13-20221127 -c concepts-lambda3.C -std=c++20 -flto -fno-inline
concepts-lambda3.C:40:13: error: mangling of 'main(int,
char**):: [with auto:5 = int]' as
'_ZZ4mainENKUlT_E1_clIiEEDaS_' conflicts with a previous mangle
40 | auto a0 = [](IsNotLarge auto a) { return [](auto b){ return b; }; };
| ^
concepts-lambda3.C:37:3: note: previous mangling 'int main(int,
char**)_ZZ4mainENKUlT_E1_clIiEEDaS_(int) const'
37 | [](auto t) requires true { return t; }(5);
| ^
concepts-lambda3.C:40:13: note: a later '-fabi-version=' (or =0) avoids this
error with a change in mangling
40 | auto a0 = [](IsNotLarge auto a) { return [](auto b){ return b; }; };
| ^
during IPA pass: targetclone
concepts-lambda3.C:63:1: internal compiler error: in verify_curr_properties, at
passes.cc:2201
63 | }
| ^
0x10c1cb5 verify_curr_properties
../../gcc/passes.cc:2201
0x10c23dd do_per_function
../../gcc/passes.cc:1701
[Bug c/107898] New: [11/12/13 Regression] ICE in irange_intersect, at value-range.cc:1640
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107898 Bug ID: 107898 Summary: [11/12/13 Regression] ICE in irange_intersect, at value-range.cc:1640 Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Started between 20220403 and 20220410, with file gcc.dg/Walloca-larger-than-2.c : (and started between 20201018 and 20201108 with -O1+) $ gcc-13-20221127 -c Walloca-larger-than-2.c -fsanitize=address -fsanitize=pointer-subtract -fpreprocessed -Walloca-larger-than=5000 Walloca-larger-than-2.c:7:1: warning: parameter names (without types) in function declaration 7 | extern void* alloca (__SIZE_TYPE__); | ^~ Walloca-larger-than-2.c: In function 'test_alloca': Walloca-larger-than-2.c:17:5: warning: implicit declaration of function 'T' [-Wimplicit-function-declaration] 17 | T (alloca (0)); | ^ Walloca-larger-than-2.c:17:16: warning: 'alloca' argument 1 type is 'int' where 'long unsigned int' is expected in a call to built-in function declared without prototype [-Wbuiltin-declaration-mismatch] 17 | T (alloca (0)); |^ Walloca-larger-than-2.c:7:14: note: built-in 'alloca' declared here 7 | extern void* alloca (__SIZE_TYPE__); | ^~ Walloca-larger-than-2.c:21:16: warning: 'alloca' argument 1 type is 'int' where 'long unsigned int' is expected in a call to built-in function declared without prototype [-Wbuiltin-declaration-mismatch] 21 | T (alloca (1)); |^ Walloca-larger-than-2.c:7:14: note: built-in 'alloca' declared here 7 | extern void* alloca (__SIZE_TYPE__); | ^~ Walloca-larger-than-2.c:24:16: warning: 'alloca' argument 1 type is 'unsigned int' where 'long unsigned int' is expected in a call to built-in function declared without prototype [-Wbuiltin-declaration-mismatch] 24 | T (alloca (n)); |^ Walloca-larger-than-2.c:7:14: note: built-in 'alloca' declared here 7 | extern void* alloca (__SIZE_TYPE__); | ^~ Walloca-larger-than-2.c:17:5: warning: argument to 'alloca' is zero [-Walloca-larger-than=] 17 | T (alloca (0)); | ^~ Walloca-larger-than-2.c:21:5: warning: use of 'alloca' within a loop [-Walloca-larger-than=] 21 | T (alloca (1)); | ^~ during GIMPLE pass: walloca Walloca-larger-than-2.c:25:1: internal compiler error: in irange_intersect, at value-range.cc:2560 25 | } | ^ 0x12550c8 irange::irange_intersect(irange const&) ../../gcc/value-range.cc:2559 0x1251a81 irange::legacy_verbose_intersect(irange const*) ../../gcc/value-range.cc:2324 0x1cc78dc irange::intersect(vrange const&) ../../gcc/value-range.h:969 0x1cc78dc alloca_call_type ../../gcc/gimple-ssa-warn-alloca.cc:228 0x1cc8243 pass_walloca::execute(function*) ../../gcc/gimple-ssa-warn-alloca.cc:292
[Bug tree-optimization/107868] [10 regression] Wrong code on AArch64 at -O1 with new/delete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107868
--- Comment #5 from Victor Do Nascimento
---
(In reply to Richard Biener from comment #3)
> a backport depends on r11-3610-gb6158faacbfb7d
>
> Your reduced testcase doesn't compile since it references undeclared 'pobj'.
How embarassing. Accidentally deleted a line of code when clearing up
unnecessary comments.
If it is of any use, the working testcase is:
#include
struct gnu { };
bool check_new = false;
bool check_delete = false;
void*
operator new(std::size_t n) noexcept(false)
{
check_new = true;
return NULL;
}
void operator delete(void *v) noexcept
{
check_delete = true;
return;
}
void operator delete(void *v, std::size_t) noexcept
{
::operator delete(v);
}
void test01()
{
std::allocator obj;
gnu* pobj = obj.allocate(256);
if (!check_new)
__builtin_abort();
obj.deallocate(pobj, 256);
if (!check_delete)
__builtin_abort();
}
int main()
{
test01();
return 0;
}
[Bug fortran/107899] New: ICE in resolve_deallocate_expr, at fortran/resolve.cc:7576
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107899 Bug ID: 107899 Summary: ICE in resolve_deallocate_expr, at fortran/resolve.cc:7576 Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Affects versions down to at least r5 : (target instead of allocatable) $ cat z1.f90 program p type t end type class(t), target :: x[:] if (allocated(x)) deallocate (x) end $ cat z2.f90 program p type t end type class(t), target :: x[:] deallocate(x) end $ gfortran-13-20221127 -c z1.f90 -fcoarray=lib z1.f90:4:27: 4 |class(t), target :: x[:] | 1 Error: Coarray variable 'x' at (1) shall not have codimensions with deferred shape z1.f90:5:17: 5 |if (allocated(x)) deallocate (x) | 1 Error: 'array' argument of 'allocated' intrinsic at (1) must be ALLOCATABLE f951: internal compiler error: Segmentation fault 0xf36d0f crash_signal ../../gcc/toplev.cc:314 0x87a956 resolve_deallocate_expr ../../gcc/fortran/resolve.cc:7576 0x87a956 resolve_allocate_deallocate ../../gcc/fortran/resolve.cc:8461 0x87cfac gfc_resolve_code(gfc_code*, gfc_namespace*) ../../gcc/fortran/resolve.cc:12291 0x87b2ff gfc_resolve_blocks(gfc_code*, gfc_namespace*) ../../gcc/fortran/resolve.cc:10979 0x87b658 gfc_resolve_code(gfc_code*, gfc_namespace*) ../../gcc/fortran/resolve.cc:11971 0x87e407 resolve_codes ../../gcc/fortran/resolve.cc:17628 0x87e4ce gfc_resolve(gfc_namespace*) ../../gcc/fortran/resolve.cc:17663 0x866294 resolve_all_program_units ../../gcc/fortran/parse.cc:6631 0x866294 gfc_parse_file() ../../gcc/fortran/parse.cc:6887 0x8b4d3f gfc_be_parse_file ../../gcc/fortran/f95-lang.cc:229
[Bug libstdc++/107886] Problem witch std::latch, std::binary_semaphores in C++20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107886 --- Comment #17 from Jamaika --- Testing atomic_wait, errors are still there. Thanks for taking up the topic. ``` In file included from c:\gcc1300\include\c++\13.0.0\mutex:60, from c:\gcc1300\include\c++\13.0.0\bits\atomic_wait.h:49, from c:\gcc1300\include\c++\13.0.0\bits\atomic_base.h:42, from c:\gcc1300\include\c++\13.0.0\latch:38, from latch_windows.cpp:4: c:\gcc1300\include\c++\13.0.0\atomic:67:5: error: '__atomic_base' does not name a type 67 | __atomic_base _M_base; | ^ c:\gcc1300\include\c++\13.0.0\atomic:103:21: error: 'memory_order' has not been declared 103 | store(bool __i, memory_order __m = memory_order_seq_cst) noexcept | ^~~~ c:\gcc1300\include\c++\13.0.0\atomic:107:21: error: 'memory_order' has not been declared 107 | store(bool __i, memory_order __m = memory_order_seq_cst) volatile noexcept | ^~~~ c:\gcc1300\include\c++\13.0.0\atomic:111:10: error: 'memory_order' has not been declared 111 | load(memory_order __m = memory_order_seq_cst) const noexcept | ^~~~ c:\gcc1300\include\c++\13.0.0\atomic:115:10: error: 'memory_order' has not been declared 115 | load(memory_order __m = memory_order_seq_cst) const volatile noexcept | ^~~~ c:\gcc1300\include\c++\13.0.0\atomic:119:24: error: 'memory_order' has not been declared 119 | exchange(bool __i, memory_order __m = memory_order_seq_cst) noexcept |^~~~ c:\gcc1300\include\c++\13.0.0\atomic:124:14: error: 'memory_order' has not been declared 124 | memory_order __m = memory_order_seq_cst) volatile noexcept | ^~~~ ```
[Bug c++/107897] [13 Regression] ICE in verify_curr_properties, at passes.cc:2201
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107897 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |13.0 Keywords||ABI, c++-lambda
[Bug rtl-optimization/107772] function prologue generated even though it's only needed in an unlikely path
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107772 --- Comment #2 from Avi Kivity --- I expect something like this: f(int*, int*): cmp rdi, rsi je .L10 .L4: cmp DWORD PTR [rsi], 0 jne .L14 .L3 add rsi, 4 cmp rsi, rdi jne .L4 .L10 ret .section .text.cold .L14: pushrsi pushrdi mov rax, DWORD PTR [rsi] callg(int) pop rdi pop rsi mov DWORD PTR [rsi], eax jmp .L3
[Bug rtl-optimization/107772] function prologue generated even though it's only needed in an unlikely path
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107772 --- Comment #3 from Andrew Pinski --- (In reply to Avi Kivity from comment #2) > I expect something like this: Right doing shrink wrapping like that is "hard" really and someone would need to add a full infrastructure for this. I doubt it will be implemented any time soon really.
[Bug tree-optimization/107898] [11/12/13 Regression] ICE in irange_intersect, at value-range.cc:1640
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107898 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |11.4
[Bug middle-end/105126] [10/11/12/13 Regression] Optimization regression gcc inserts not needed movsx when using switch statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105126 --- Comment #5 from Andrew Pinski --- Note for aarch64, is_bin_1 produces better code on the trunk than is_bin_0. There is an extra zero extent for is_bin_0 there. So I suspect this is we get a promotion/demotion pass, it will definitely need to check some target specific hooks/macros to get the best code generation. x86_64 might be one of the few targets (left) that demotion makes a difference while most other targets want promotions really.
[Bug c++/105130] gcc does not warn about unused return value of last expression of statement expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105130 --- Comment #3 from Andrew Pinski --- I would have thought this was by design. a statement expression last statement is "used" there.
[Bug c++/105130] gcc does not warn about unused return value of last expression of statement expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105130 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=39808 --- Comment #4 from Andrew Pinski --- PR 39808 is the C version.
[Bug rtl-optimization/107772] function prologue generated even though it's only needed in an unlikely path
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107772
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Comment #4 from Alexander Monakov ---
You'll get better results from outlining a rare path manually: the
prologue/epilogue won't be re-executed for each invocation of 'g':
int g(int);
__attribute__((noinline,cold))
static void f_slowpath(int* b, int* e)
{
switch (0)
do {
if (*b != 0)
default: *b = g(*b);
} while (++b != e);
}
void f(int* b, int* e)
{
for (; b != e; b++)
if (*b != 0) {
f_slowpath(b, e);
return;
}
}
[Bug target/104688] gcc and libatomic can use SSE for 128-bit atomic loads on Intel and AMD CPUs with AVX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104688 Peter Cordes changed: What|Removed |Added CC||peter at cordes dot ca --- Comment #23 from Peter Cordes --- (In reply to Xi Ruoyao from comment #20) > "On Zhaoxin CPUs with AVX, the VMOVDQA instruction is atomic if the accessed > memory is Write Back, but it's not guaranteed for other memory types." VMOVDQA is still fine, I think WB is the only memory type that's relevant for atomics, at least on the mainstream OSes we compile for. It's not normally possible for user-space to allocate memory of other types. Kernels normally use WB memory for their shared data, too. You're correct that WT and WP are the other two cacheable memory types, and Zhaoxin's statement doesn't explicitly guarantee atomicity for those, unlike Intel and AMD. But at least on Linux, I don't think there's a way for user-space to even ask for a page of WT or WP memory (or UC or WC). Only WB memory is easily available without hacking the kernel. As far as I know, this is true on other existing OSes. WT = write-through: read caching, no write-allocate. Write hits update the line and memory. WP = write-protect: read caching, no write-allocate. Writes go around the cache, evicting even on hit. (https://stackoverflow.com/questions/65953033/whats-the-usecase-of-write-protected-pat-memory-type quotes the Intel definitions.) Until recently, the main work on formalizing the x86 TSO memory model had only looked at WB memory. A 2022 paper looked at WT, UC, and WC memory types: https://dl.acm.org/doi/pdf/10.1145/3498683 - Extending Intel-x86 Consistency and Persistency Formalising the Semantics of Intel-x86 Memory Types and Non-temporal Stores (The intro part describing memory types is quite readable, in plain English not full of formal symbols. They only mention WP once, but tested some litmus tests with readers and writers using any combination of the other memory types.) Some commenters on my answer on when WT is ever used or useful confirmed that mainstream OSes don't give easy access to it. https://stackoverflow.com/questions/61129142/when-use-write-through-cache-policy-for-pages/61130838#61130838 * Linux has never merged a patch to let user-space allocate WT pages. * The Windows kernel reportedly doesn't have a mechanism to keep track of pages that should be WT or WP, so you won't find any. I don't know about *BSD making it plausible for user-space to point an _Atomic int * at a page of WT or WP memory. I'd guess not. I don't know if there's anywhere we can document that _Atomic objects need to be in memory that's allocated in a "normal" way. Probably hard to word without accidentally disallowing something that's fine.
[Bug tree-optimization/107868] [10 regression] Wrong code on AArch64 at -O1 with new/delete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107868 Richard Biener changed: What|Removed |Added Status|ASSIGNED|NEW Assignee|rguenth at gcc dot gnu.org |unassigned at gcc dot gnu.org --- Comment #6 from Richard Biener --- It also depends on r11-3386-g9e64f17d044767 for a testsuite adjustment and also r11-3612-g4f4ced28826ece to further fix the C++ frontend side and avoid regressing g++.dg/pr94314.C but that doesn't apply cleanly. So there's definitely too much to backport for this last GCC 10 release. At least I'm now going to stop chasing all related commits ...
[Bug tree-optimization/107896] [13 Regression] ICE in supportable_widening_operation, at tree-vect-stmts.cc:12199 breaking arm bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107896 --- Comment #3 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:2200b7054638bbf157192a4dca23886dd420becb commit r13-4374-g2200b7054638bbf157192a4dca23886dd420becb Author: Richard Biener Date: Mon Nov 28 17:26:15 2022 +0100 tree-optimization/107896 - allow v2si to dimode unpacks The following avoids ICEing for V2SI -> DImode vec_unpacks_lo. PR tree-optimization/107896 * tree-vect-stmts.cc (supportable_widening_operation): Handle non-vector mode intermediate mode.
[Bug tree-optimization/107896] [13 Regression] ICE in supportable_widening_operation, at tree-vect-stmts.cc:12199 breaking arm bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107896 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from Richard Biener --- Should be fixed.
[Bug target/104688] gcc and libatomic can use SSE for 128-bit atomic loads on Intel and AMD CPUs with AVX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104688 --- Comment #24 from Alexander Monakov --- (In reply to Peter Cordes from comment #23) > But at least on Linux, I don't think there's a way for user-space to even > ask for a page of WT or WP memory (or UC or WC). Only WB memory is easily > available without hacking the kernel. As far as I know, this is true on > other existing OSes. I think it's possible to get UC/WC mappings via a graphics/compute API (e.g. OpenGL, Vulkan, OpenCL, CUDA) on any OS if you get a mapping to device memory (and then CPU vendor cannot guarantee that 128b access won't tear because it might depend on downstream devices).
[Bug fortran/107819] ICE in gfc_check_argument_var_dependency, at fortran/dependency.cc:978
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107819 --- Comment #14 from CVS Commits --- The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:07b9bcc1d1484f8f1c850ff14db678fb6b1e4d36 commit r13-4375-g07b9bcc1d1484f8f1c850ff14db678fb6b1e4d36 Author: Harald Anlauf Date: Sun Nov 27 21:10:18 2022 +0100 Fortran: ICE with elemental and dummy argument with VALUE attribute [PR107819] gcc/fortran/ChangeLog: PR fortran/107819 * trans-stmt.cc (gfc_conv_elemental_dependencies): In checking for elemental dependencies, treat dummy argument with VALUE attribute as implicitly having intent(in). gcc/testsuite/ChangeLog: PR fortran/107819 * gfortran.dg/elemental_dependency_7.f90: New test.
[Bug c++/105127] Search Path not working on Cygwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105127 --- Comment #2 from Sam Darwin --- yes, reported: https://cygwin.com/pipermail/cygwin/2022-January/250693.html I don't know where the bug originates, in gcc or cygwin. If an expert in gcc could submit a fix to cygwin or vice versa.
[Bug target/104688] gcc and libatomic can use SSE for 128-bit atomic loads on Intel and AMD CPUs with AVX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104688 --- Comment #25 from Peter Cordes --- (In reply to Alexander Monakov from comment #24) > > I think it's possible to get UC/WC mappings via a graphics/compute API (e.g. > OpenGL, Vulkan, OpenCL, CUDA) on any OS if you get a mapping to device > memory (and then CPU vendor cannot guarantee that 128b access won't tear > because it might depend on downstream devices). Even atomic_int doesn't work properly if you deref a pointer to WC memory. WC doesn't have the same ordering guarantees, so it would break acquire/release semantics. So we already don't support WC for this. We do at least de-facto support atomics on UC memory because the ordering guarantees are a superset of cacheable memory, and 8-byte atomicity for aligned load/store is guaranteed even for non-cacheable memory types since P5 Pentium (and on AMD). (And lock cmpxchg16b is always atomic even on UC memory.) But you're right that only Intel guarantees that 16-byte VMOVDQA loads/stores would be atomic on UC memory. So this change could break that very unwise corner-case on AMD which only guarantees that for cacheable loads/stores, and Zhaoxin only for WB. But was anyone previously using 16-byte atomics on UC device memory? Do we actually care about supporting that? I'd guess no and no, so it's just a matter of documenting that somewhere. Since GCC7 we've reported 16-byte atomics as being non-lock-free, so I *hope* people weren't using __atomic_store_n on device memory. The underlying implementation was never guaranteed.
[Bug tree-optimization/107879] [13 Regression] ffmpeg-4 test suite fails on FPU arithmetics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107879 Jakub Jelinek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #6 from Jakub Jelinek --- Created attachment 53978 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53978&action=edit gcc13-pr107879.patch Untested fix.
