[Bug c++/100986] New: internal compiler error: in finish_expr_stmt, at cp/semantics.c:681
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100986 Bug ID: 100986 Summary: internal compiler error: in finish_expr_stmt, at cp/semantics.c:681 Product: gcc Version: 10.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: brycelelbach at gmail dot com Target Milestone: --- https://godbolt.org/z/7nrdxz3ax I ran into this when doing stuff with CTAD. It appears to be fixed in GCC 11, but since it's an ICE, I figured I'd follow a bug report in case y'all want to bug fix it in the GCC 10.x series (or at least make it fail more gracefully).
[Bug tree-optimization/25290] PHI-OPT could be rewritten so that is uses match
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25290 --- Comment #23 from rguenther at suse dot de --- On Tue, 8 Jun 2021, pinskia at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25290 > > --- Comment #22 from Andrew Pinski --- > * minmax_replacement: has some handling of comparisions which might not be in > the match.pd patterns already. needs PROP_gimple_lswitch also. Yeah, this is also fold-const.c COND_EXPR simplifications using fold_cond_expr_with_comparison (to ABS/MIN/MAX) which are not yet moved to match.pd and are one reason why fold_gimple_assign still dispatches to fold_ternary_loc ... (it shouldn't).
[Bug testsuite/100407] New test cases attr-retain-*.c fail after their introduction in r11-7284
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100407 Alan Modra changed: What|Removed |Added CC||amodra at gmail dot com --- Comment #13 from Alan Modra --- All of the following result in the tests passing. make check-gcc RUNTESTFLAGS="--target_board=unix/-m32/-mno-readonly-in-sdata compile.exp=attr-retain-1.c" make check-gcc RUNTESTFLAGS="--target_board=unix/-m32/-mno-sdata compile.exp=attr-retain-1.c" make check-gcc RUNTESTFLAGS="--target_board=unix/-m32/-G0 compile.exp=attr-retain-1.c" The tests just need tweaking for ppc32 using any of the above, I'd choose -G0.
[Bug tree-optimization/100981] ICE in info_for_reduction, at tree-vect-loop.c:4897
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100981 Richard Biener changed: What|Removed |Added CC||avieira at gcc dot gnu.org --- Comment #2 from Richard Biener --- #1 0x01816089 in info_for_reduction (vinfo=0x369bf80, stmt_info=0x376e340) at ../../src/trunk/gcc/tree-vect-loop.c:4897 4897 gcc_assert (STMT_VINFO_REDUC_DEF (stmt_info)); (gdb) p debug_gimple_stmt ($1) slp_patt_96 = .COMPLEX_FMA (dsdotr.5_21, dsdotr.5_21, dsdotr.5_21); $2 = void ah, so we get a reduction stmt SLP pattern-recognized... and while the original scalar stmt_infos are preserved: t.f90:9:8: note: node 0x35cff60 (max_nunits=4, refcnt=2) t.f90:9:8: note: op template: slp_patt_96 = .COMPLEX_FMA (dsdotr.5_21, dsdotr.5_21, dsdotr.5_21); t.f90:9:8: note:stmt 0 dsdotr.5_21 = dsdotr.5_20 + _36; t.f90:9:8: note:stmt 1 dsdoti.4_19 = dsdoti.4_18 + _37; t.f90:9:8: note:children 0x35cffe8 0x35d0648 0x35d0290 the reduc-info, which is originally attached to the SLP nodes representative is no longer there (it didn't get transfered). Now, actually handling this needs some double-checking and turning the testcase into a runtime one. I'll poke on doing that. The issue is probably latent on the branch where we might want to play safer and simply refuse to pattern recog nodes with a STMT_VINFO_REDUC_DEF (vect_orig_stmt (SLP_TREE_REPRESENTATIVE (node))).
[Bug tree-optimization/100981] ICE in info_for_reduction, at tree-vect-loop.c:4897
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100981 --- Comment #3 from Richard Biener --- Created attachment 50969 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50969&action=edit patch fixing the ICE So this fixes the ICE but I'm not sure whether correct code is generated yet.
[Bug target/100936] %p and %P modifiers should not emit segment overrides
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100936
--- Comment #2 from CVS Commits ---
The master branch has been updated by Uros Bizjak :
https://gcc.gnu.org/g:267dbd42f42c52a515f49c0875d296a9cf5988fe
commit r12-1318-g267dbd42f42c52a515f49c0875d296a9cf5988fe
Author: Uros Bizjak
Date: Wed Jun 9 09:46:00 2021 +0200
i386: Do not emit segment overrides for %p and %P [PR100936]
Using %p to move the address of a symbol using LEA:
asm ("lea %p1, %0" : "=r"(addr) : "m"(var));
emits assembler warning when VAR is declared in a non-generic address
space:
Warning: segment override on `lea' is ineffectual
The problem is with %p operand modifier, which should emit raw symbol name:
p -- print raw symbol name.
Similar problem exists with %P modifier, trying to CALL or JMP to an
overridden symbol,e.g:
call %gs:zzz
jmp %gs:zzz
emits assembler warning:
Warning: skipping prefixes on `call'
Warning: skipping prefixes on `jmp'
Ensure that %p and %P never emit segment overrides.
2021-06-08 Uroš Bizjak
gcc/
PR target/100936
* config/i386/i386.c (print_operand_address_as): Rename "no_rip"
argument to "raw". Do not emit segment overrides when "raw" is
true.
gcc/testsuite/
PR target/100936
* gcc.target/i386/pr100936.c: New test.
[Bug target/100936] %p and %P modifiers should not emit segment overrides
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100936 Uroš Bizjak changed: What|Removed |Added Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |ubizjak at gmail dot com Status|UNCONFIRMED |RESOLVED Target Milestone|--- |12.0 --- Comment #3 from Uroš Bizjak --- Fixed.
[Bug tree-optimization/100981] ICE in info_for_reduction, at tree-vect-loop.c:4897
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100981 --- Comment #4 from Richard Biener --- Runtime testcase (not sure if sufficient ...). Andre - can you verify it passes runtime testing with the patch on HW that supports the complex mul? complex function cdcdot(n, cx) implicit none integer :: n, i, kx complex :: cx(*) double precision :: dsdotr, dsdoti, dt1, dt3 kx = 1 do i = 1, n dt1 = real(cx(kx)) dt3 = aimag(cx(kx)) dsdotr = dsdotr + dt1 * 2 - dt3 * 2 dsdoti = dsdoti + dt1 * 2 + dt3 * 2 kx = kx + 1 end do cdcdot = cmplx(real(dsdotr), real(dsdoti)) return end function cdcdot program test implicit none complex :: cx(100), ct, cdcdot integer :: i do i = 1, 100 cx(i) = cmplx(2*i, i) end do ct = cdcdot (100, cx) if (ct.ne.cmplx(10100.,30300.)) call abort end
[Bug sanitizer/100987] New: make distclean error "hwasan: No such file or directory"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100987 Bug ID: 100987 Summary: make distclean error "hwasan: No such file or directory" Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: antony at cosmologist dot info 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: --- Last known working trunk build was 22 Nov 2020. Since then a "make distclean" fails with this error after building C,C++, fortran (failed from weekly auto-build after that). See full dockerfile to reproduce at https://github.com/cmbant/docker-gcc-build/blob/d5eefe8bdbe0b683a7bd4ca09caf4c9bba8fc429/Dockerfile
[Bug sanitizer/100987] make distclean error "hwasan: No such file or directory"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100987 Andrew Pinski changed: What|Removed |Added Depends on||62157 --- Comment #1 from Andrew Pinski --- Similar to PR 62157. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62157 [Bug 62157] make distclean error when libsanitizer is configured not to build 'tsan'
[Bug target/100985] [9 Regression] Aarch64 acle.h "extern "C" {" mismatch "}" in 9.4.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100985
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |9.5
Target||aarch64-*-*
Component|c |target
Summary|Aarch64 acle.h "extern "C" |[9 Regression] Aarch64
|{" mismatch "}" in 9.4.0|acle.h "extern "C" {"
||mismatch "}" in 9.4.0
[Bug sanitizer/62157] make distclean error when libsanitizer is configured not to build 'tsan'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62157 --- Comment #1 from Jakub Jelinek --- Seems like automake bug to me, all this DIST_SUBDIRS vs. SUBDIRS and am__recursive_targets stuff comes from it.
[Bug sanitizer/62157] make distclean error when libsanitizer is configured not to build 'tsan'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62157 --- Comment #2 from Jakub Jelinek --- Though, of course, distclean doesn't make much sense when building in a separate build directory, just removing the whole build directory is the right distclean.
[Bug target/100985] [9 Regression] Aarch64 acle.h "extern "C" {" mismatch "}" in 9.4.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100985 Alex Coplan changed: What|Removed |Added Last reconfirmed||2021-06-09 Known to fail||9.4.0 CC||acoplan at gcc dot gnu.org, ||ktkachov at gcc dot gnu.org Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #1 from Alex Coplan --- Confirmed by inspection of the source on the head of the 9 branch.
[Bug fortran/90742] OpenACC/OpenMP target offloading: Fortran 'allocatable' scalars in 'firstprivate' clauses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90742
Tobias Burnus changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
Status|WAITING |NEW
--- Comment #3 from Tobias Burnus ---
Came up in context of my patch for PR92568 (gfortran.dg/gomp/defaultmap-8.f90)
and the following does not work neither for scalars nor for arrays:
integer, allocatable :: a, b(:)
a = 2 ! implicit allocation
b = [2] ! implicit allocation
!$omp target firstprivate(a,b)
if (a /= 2 .or. b(1) /= 1) stop 1
a = 1
b = 1
!$omp end target
if (a /= 2) stop 2
if (b(1) /= 2) stop 2
end
Namely (for a variant with only the scalar 'a'):
.omp_data_arr.2.a = a;
#pragma omp target num_teams(1) thread_limit(0) firstprivate(a) [child fn:
MAIN__._omp_fn.0 (.omp_data_arr.2, .omp_data_sizes.3, .omp_data_kinds.4)]
{
.omp_data_i = (const struct .omp_data_t.1 & restrict) &.omp_data_arr.2;
D.3963 = .omp_data_i->a;
a = D.3963;
{
D.3943 = *a;
[Bug fortran/100965] [OpenMP] ICE: Error: incorrect sharing of tree nodes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100965 --- Comment #2 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:d4d38135b3137f1d3148138340e67bdcd7ea8216 commit r12-1319-gd4d38135b3137f1d3148138340e67bdcd7ea8216 Author: Jakub Jelinek Date: Wed Jun 9 10:48:41 2021 +0200 openmp: Gimplify OMP_CLAUSE_SIZE during gfc_omp_finish_clause [PR100965] As the testcase shows, we need to gimplify OMP_CLAUSE_SIZE, so that we don't end up with SAVE_EXPR or anything similar non-gimple in it. 2021-06-08 Jakub Jelinek PR fortran/100965 * trans-openmp.c (gfc_omp_finish_clause): Gimplify OMP_CLAUSE_SIZE. * gfortran.dg/gomp/pr100965.f90: New test.
[Bug fortran/100965] [OpenMP] ICE: Error: incorrect sharing of tree nodes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100965 --- Comment #3 from Jakub Jelinek --- Fixed on the trunk, will need to check release branches if they are affected too.
[Bug fortran/100988] New: Missed optimization: RESTRICT missing for optional arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100988
Bug ID: 100988
Summary: Missed optimization: RESTRICT missing for optional
arguments
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
Target Milestone: ---
For
subroutine foo(a, b)
integer :: a, b
optional :: b
...
end subroutine
only the TREE_TYPE of 'a' has the restrict qualifier – and not 'b'.
I think that there is no good reason for this – and wonder whether the
following should be applied:
diff --git a/gcc/fortran/trans-types.c b/gcc/fortran/trans-types.c
index 5582e404df9..c4b4387c1e2 100644
--- a/gcc/fortran/trans-types.c
+++ b/gcc/fortran/trans-types.c
@@ -2338,11 +2338,9 @@ gfc_sym_type (gfc_symbol * sym)
|| (sym->ns->proc_name && sym->ns->proc_name->attr.entry_master))
type = build_pointer_type (type);
else
- {
- type = build_reference_type (type);
- if (restricted)
- type = build_qualified_type (type, TYPE_QUAL_RESTRICT);
- }
+ type = build_reference_type (type);
+ if (restricted)
+ type = build_qualified_type (type, TYPE_QUAL_RESTRICT);
}
return (type);
[Bug fortran/100989] New: Bogus internal VOLATILE attribute for ASYNCHRONOUS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100989 Bug ID: 100989 Summary: Bogus internal VOLATILE attribute for ASYNCHRONOUS Product: gcc Version: 12.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: burnus at gcc dot gnu.org CC: tkoenig at gcc dot gnu.org Target Milestone: --- For a long time, there was the believe that due to GCC's pointer-escape semantic, which follows C, no special attribute is needed for asynchronous: ... integer, asynchronous :: A call init_action(A) ! pointer escape due to by-ref and GCC's C semantic ... ! and due to 'asynchronous' due to Fortran semantic A = 5 ! (probably a bad idea if really asynchronous) ... call wait() ! arrives here, can access A due to escaped pointer ! <-- value of 'A' could have changed There might be an issue with the handling of the 'fn attr', though as the variables have to be regarded as escaping for certain function calls. In any case, VOLATILE prevents too much optimizations. The volatile was added by commit: commit 2b4c90656132abb8b8ad155d345c7d4fbf1687c9 via https://gcc.gnu.org/pipermail/gcc-patches/2018-June/499870.html https://gcc.gnu.org/pipermail/gcc-patches/2018-August/503896.html without any discussion of this point.
[Bug libstdc++/100990] New: Iterator checks for Debug Mode cannot be used with a non-common range
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100990 Bug ID: 100990 Summary: Iterator checks for Debug Mode cannot be used with a non-common range Product: gcc Version: 11.1.1 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: redi at gcc dot gnu.org Target Milestone: --- The Debug Mode iterator checks assume two iterators of the same type, so do not work with an iterator and a sentinel. It should be possible to use std::common_iterator like so: __glibcxx_require_valid_range(common_iterator<_It, _Sent>(__it), common_iterator<_It, _Sent>(__sent)); But wrapping a _Safe_iterator in common_iterator will prevent the checks from making use of the additional information present in a _Safe_iterator (and maybe prevent other checks from matching the iterator type?) It would be nice to be able to use those debug mode assertions in ranges algos and ranges::advance etc.
[Bug libstdc++/91910] Debug mode: there is a racing condition between destructors of iterator and the associated container.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91910 Jonathan Wakely changed: What|Removed |Added Status|NEW |RESOLVED Target Milestone|--- |9.3 Resolution|--- |FIXED --- Comment #9 from Jonathan Wakely --- This is fixed in all active branches.
[Bug libstdc++/90704] [LWG 3430] filesystem::path overloads for file streams are not conforming
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90704 Jonathan Wakely changed: What|Removed |Added Resolution|--- |INVALID Status|SUSPENDED |RESOLVED --- Comment #10 from Jonathan Wakely --- WG21 has just confirmed that the GCC behaviour is the desired one. The changes in https://cplusplus.github.io/LWG/issue3430 are in the C++ working draft.
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #228 from John Buddery --- Sorry it took a while, I've been away for a bit and have lots to catch up on. These patches are for 11.1.0, but should work on earlier versions too. With this I have a working gcc which I've tested on several large projects. Most of the patch is a cumulation of the patches posted earlier in this thread - unsigned pointer extension, reverting @gprel changes etc. gcov-tool.c avoids build errors from ftwbuf differences on HP, apply if you hit errors but may need tidying up. ia64.md is the patch for long calls, to avoid the 25 bit limit which prevents linking gcc. It's still a work in progress as the instruction bundling is wrong, but it does work. Note that you must apply the binutils patch (or build the current binutils master, or a release after 2.36) to get an assembler that will work with brl and the HP linker. Do not apply the ia64.md patch without building a patched gnu assembler first! Also note that you need a working C++ compiler to bootstrap. That sounds obvious, but is harder than you think - as far as I know, none of the distributed g++ versions work sufficiently. One way to get a working 4.9.2 g++ is described in my post in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64919 but there may be other solutions as well. I've never tried to bootstrap with aCC. My configure command is: ../gcc-11.1.0/configure --enable-comdat --disable-libgomp --with -as=/usr/local/binutils/bin/as --enable-languages=c,c++ --prefix=/usr/local/gcc- 11.1.0 --with-gmp=/usr/local_32 --with-mpc=/usr/local_32 --with-mpfr=/usr/local_ 32 --with-dwarf2 The --enable-comdat I think is required. I think libgomp doesn't build, I've never investigated though and disable it. I use dwarf2 as recent gdb versions won't work. The assembler I use is a patched binutils 2.36. Good luck!
[Bug c++/54835] [C++11][DR 1518] Explicit default constructors not respected during copy-list-initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54835
--- Comment #22 from David Friberg ---
(In reply to TC from comment #21)
> (In reply to David Friberg from comment #19)
> >
> > P0398R0 [1] describes the final resolution to CWG 1518, after which the
> > following example is arguably well-formed:
> >
>
> It's not. Explicitness of a constructor is not considered when forming
> implicit conversion sequences from a braced-init-list, and therefore the
> assignment is ambiguous because {} can convert to either S or tag_t, even
> though the latter is ill-formed if actually used.
TC, thanks for the clarification. Just to be sure I'm not missing something, I
was under the impression that the [**emphasis**]
> For direct-initialization or default-initialization
> **that is not in the context of copy-initialization**,
> the candidate functions are all the constructors of
> the class of the object being initialized.
part of [over.match.ctor]/1 [1], which was added in P0398R0, intended to remove
non-converting (explicit) constructors from overload resolution in this
context, particularly resolving the issue shown in the original example of LWG
issue 251 [2]:
> That turns out to be very unfortunate, consider the following:
>
> #include
> #include
>
> void f(std::array, int) {} // #1
> void f(std::allocator_arg_t, int) {} // #2
>
> int main()
> {
> f({}, 666); // #3
> }
>
> The call at #3 is ambiguous.
after which the call at #3 in the LWG example above is no longer ambiguous
(afaict). I may be missing some subtlety here, but does my example above not
fall into the same category as this one?
[1] https://timsong-cpp.github.io/cppwp/n4861/over.match.ctor#1
[2] https://cplusplus.github.io/LWG/issue2510
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #227 from John Buddery --- Created attachment 50970 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50970&action=edit Patches for gcc-11.1.0, hp-ia64 Mostly patches from this thread, apart from ia64.md which adds support for using long calls (brl).
[Bug c/100920] bogus warnings with -Wscalar-storage-order
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100920 --- Comment #11 from CVS Commits --- The releases/gcc-11 branch has been updated by Eric Botcazou : https://gcc.gnu.org/g:5be418dc591014b1773d59abca8fba5be34df618 commit r11-8533-g5be418dc591014b1773d59abca8fba5be34df618 Author: Eric Botcazou Date: Wed Jun 9 12:37:47 2021 +0200 Fix old thinko in warning on pointer for storage order purposes gcc/c PR c/100920 * c-typeck.c (convert_for_assignment): Test fndecl_built_in_p to spot built-in functions. Do not warn on pointer assignment and initialization for storage order purposes if the RHS is a call to a DECL_IS_MALLOC function. gcc/testsuite/ * gcc.dg/sso-14.c: New test.
[Bug libstdc++/100982] wrong constraint in std::optional::operator=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100982 --- Comment #1 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:b3fce1bd45f72cc9e55fb7431762e92e30fefcf1 commit r12-1327-gb3fce1bd45f72cc9e55fb7431762e92e30fefcf1 Author: Jonathan Wakely Date: Wed Jun 9 11:03:15 2021 +0100 libstdc++: Fix constraint on std::optional assignment [PR 100982] libstdc++-v3/ChangeLog: PR libstdc++/100982 * include/std/optional (optional::operator=(const optional&)): Fix value category used in is_assignable check. * testsuite/20_util/optional/assignment/100982.cc: New test.
[Bug fortran/100991] New: [OpenMP] firstprivate for optional arguments is mishandled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100991
Bug ID: 100991
Summary: [OpenMP] firstprivate for optional arguments is
mishandled
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: openmp
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
Target Milestone: ---
Split off from my defaultmap patch.
FAILING is either:
(A) FIRST TEST:
libgomp/testsuite/libgomp.fortran/optional-map.f90
for the implicitly mapped
subroutine sub2(ii, ...
integer, optional :: ii, ...
but that requires the trans-openmp.c patch shown below (otherwise, ii is mapped
fromto)
(B) SECOND TEST
program main
implicit none
integer :: ii
ii = 7
call foo(ii)
call foo()
contains
subroutine foo (ii1)
integer, optional :: ii1
!$omp target firstprivate(ii1)
if (present (ii1)) then
if (ii1 /= 7) stop 1
ii1 = 5
end if
!$omp end target
if (present (ii1)) then
if (ii1 /= 7) stop 1
end if
end
end
Patch mentioned for (A):
gfc_omp_scalar_p (tree decl, bool ptr_alloc_ok)
{
tree type = TREE_TYPE (decl);
+ if (gfc_omp_is_optional_argument (decl))
+type = TREE_TYPE (type);
if (TREE_CODE (type) == REFERENCE_TYPE)
type = TREE_TYPE (type);
if (TREE_CODE (type) == POINTER_TYPE)
* * * *
The code needed is similar to:
--- a/gcc/omp-low.c
+++ b/gcc/omp-low.c
@@ -12804,7 +12804,8 @@ lower_omp_target (gimple_stmt_iterator *gsi_p,
omp_context *ctx)
if (omp_is_reference (ovar))
type = TREE_TYPE (type);
if ((INTEGRAL_TYPE_P (type)
-&& TYPE_PRECISION (type) <= POINTER_SIZE)
+&& TYPE_PRECISION (type) <= POINTER_SIZE
+&& !omp_check_optional_argument (ovar, false))
|| TREE_CODE (type) == POINTER_TYPE)
{
tkind = GOMP_MAP_FIRSTPRIVATE_INT;
@@ -13026,13 +13027,15 @@ lower_omp_target (gimple_stmt_iterator *gsi_p,
omp_context *ctx)
|| is_gimple_reg_type (TREE_TYPE (var)))
{
tree new_var = lookup_decl (var, ctx);
+ bool is_optional = omp_check_optional_argument (var, false);
tree type;
type = TREE_TYPE (var);
if (omp_is_reference (var))
type = TREE_TYPE (type);
if ((INTEGRAL_TYPE_P (type)
&& TYPE_PRECISION (type) <= POINTER_SIZE)
- || TREE_CODE (type) == POINTER_TYPE)
+ || TREE_CODE (type) == POINTER_TYPE
+ || is_optional)
{
x = build_receiver_ref (var, false, ctx);
if (TREE_CODE (type) != POINTER_TYPE)
@@ -13040,11 +13043,14 @@ lower_omp_target (gimple_stmt_iterator *gsi_p,
omp_context *ctx)
x = fold_convert (type, x);
gimplify_expr (&x, &new_body, NULL, is_gimple_val,
fb_rvalue);
- if (omp_is_reference (var))
+ if (omp_is_reference (var) || is_optional)
{
+ tree present = (is_optional
+ ? omp_check_optional_argument (ovar,
true)
+ : NULL_TREE);
...
(Cf. other code in this file.)
Except, of course, that this does not handle all the fun stuff which is not
trivially assignable. (allocatable arrays, polymorphic ...)
[Bug c++/100974] [C++23] Implement if consteval
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100974 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- I have this roughly implemented, adding testcases now.
[Bug c++/100983] Deduction guide for member template class rejected at class scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100983 Marek Polacek changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=79501 CC||mpolacek at gcc dot gnu.org Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2021-06-09 --- Comment #1 from Marek Polacek --- Yeah, that should be valid. I think it's the same problem observed in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79501#c3
[Bug c++/100986] internal compiler error: in finish_expr_stmt, at cp/semantics.c:681
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100986 Marek Polacek changed: What|Removed |Added Keywords||ice-on-valid-code Ever confirmed|0 |1 Last reconfirmed||2021-06-09 CC||mpolacek at gcc dot gnu.org Status|UNCONFIRMED |NEW --- Comment #1 from Marek Polacek --- Fixed by r11-7044, which added a test with invalid code, so we may want to add this one, which compiles without errors now.
[Bug target/100896] --enable-initfini-array should be enabled for cross compiler to Linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100896 --- Comment #1 from CVS Commits --- The master branch has been updated by H.J. Lu : https://gcc.gnu.org/g:13a39886940331149173b25d6ebde0850668d8b9 commit r12-1328-g13a39886940331149173b25d6ebde0850668d8b9 Author: H.J. Lu Date: Tue Jun 8 16:09:24 2021 -0700 Always enable DT_INIT_ARRAY/DT_FINI_ARRAY on Linux DT_INIT_ARRAY/DT_FINI_ARRAY support was added to glibc 2.1 by commit fcf70d4114db9ff7923f5dfeb3fea6e2d623e5c2 Author: Ulrich Drepper Date: Sat Jul 24 19:45:13 1999 + Update. 1999-07-24 Ulrich Drepper * elf/dl-fini.c: Handle DT_FINI_ARRAY. * elf/link.h (struct link_map): Remove l_init_running. Add l_runcount and l_initcount. * elf/dl-init.c: Handle DT_INIT_ARRAY. ... and added to binutils 2.12 by commit e9682144c14fc809af72bd6c0b8c69731d38679c Author: H.J. Lu Date: Mon Mar 4 20:40:48 2002 + 2002-03-04 H.J. Lu * config/obj-elf.c (special_section): Add .init_array, .fini_array and .preinit_array. * config/tc-ia64.h (ELF_TC_SPECIAL_SECTIONS): Remove .init_array and .fini_array. gcc/ PR target/100896 * config.gcc (gcc_cv_initfini_array): Set to yes for Linux and GNU targets. * doc/install.texi: Require glibc 2.1 and binutils 2.12 for Linux and GNU targets.
[Bug target/100896] --enable-initfini-array should be enabled for cross compiler to Linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100896 H.J. Lu changed: What|Removed |Added Target Milestone|--- |12.0 Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #2 from H.J. Lu --- Fixed for GCC 12.
[Bug tree-optimization/100981] ICE in info_for_reduction, at tree-vect-loop.c:4897
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100981 --- Comment #5 from avieira at gcc dot gnu.org --- Yeah that works. Ran it as is, no abort, ran it with s/ne/eq/ and it aborts.
[Bug tree-optimization/97832] AoSoA complex caxpy-like loops: AVX2+FMA -Ofast 7 times slower than -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97832 --- Comment #12 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:ce670e4faafb296d1f1a7828d20f8c8ba4686797 commit r12-1329-gce670e4faafb296d1f1a7828d20f8c8ba4686797 Author: Richard Biener Date: Wed Nov 18 14:17:34 2020 +0100 tree-optimization/97832 - handle associatable chains in SLP discovery This makes SLP discovery handle associatable (including mixed plus/minus) chains better by swapping operands across the whole chain. To work this adds caching of the 'matches' lanes for failed SLP discovery attempts, thereby fixing a failed SLP discovery for the slp-pr98855.cc testcase which results in building an operand from scalars as expected. Unfortunately this makes us trip over the cost threshold so I'm XFAILing the testcase for now. For BB vectorization all this doesn't work because we have no way to distinguish good from bad associations as we eventually build operands from scalars and thus not fail in the classical sense. 2021-05-31 Richard Biener PR tree-optimization/97832 * tree-vectorizer.h (_slp_tree::failed): New. * tree-vect-slp.c (_slp_tree::_slp_tree): Initialize failed member. (_slp_tree::~_slp_tree): Free failed. (vect_build_slp_tree): Retain failed nodes and record matches in them, copying that back out when running into a cached fail. Dump start and end of discovery. (dt_sort_cmp): New. (vect_build_slp_tree_2): Handle associatable chains together doing more aggressive operand swapping. * gcc.dg/vect/pr97832-1.c: New testcase. * gcc.dg/vect/pr97832-2.c: Likewise. * gcc.dg/vect/pr97832-3.c: Likewise. * g++.dg/vect/slp-pr98855.cc: XFAIL.
[Bug tree-optimization/97832] AoSoA complex caxpy-like loops: AVX2+FMA -Ofast 7 times slower than -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97832 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED Known to work||12.0 --- Comment #13 from Richard Biener --- Fixed (hopefully), for GCC 12.
[Bug tree-optimization/53947] [meta-bug] vectorizer missed-optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947 Bug 53947 depends on bug 97832, which changed state. Bug 97832 Summary: AoSoA complex caxpy-like loops: AVX2+FMA -Ofast 7 times slower than -O3 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97832 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/99412] s352 benchmark of TSVC is vectorized by clang and not by gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99412 Bug 99412 depends on bug 97832, which changed state. Bug 97832 Summary: AoSoA complex caxpy-like loops: AVX2+FMA -Ofast 7 times slower than -O3 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97832 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c++/100992] New: Wrong result for is_constructible for const ref of tuple of tuples
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100992
Bug ID: 100992
Summary: Wrong result for is_constructible for const ref of
tuple of tuples
Product: gcc
Version: 11.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: kirshamir at gmail dot com
CC: kirshamir at gmail dot com
Target Milestone: ---
The second static_assert below fails, should pass:
#include
struct F {
F() { }
F(const std::tuple& foo) {}
};
static_assert(std::is_constructible_v&>);
static_assert(std::is_constructible_v>&>); //
fails, unjustifiably
int main() {
F f1{std::tuple{F{}}};
auto tup = std::tuple{std::tuple{f1}};
F f2{tup}; // constructible
}
https://godbolt.org/z/3KfbxfhWE
[Bug c++/100065] Conditional explicit doesn't work for deduction guide
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100065 --- Comment #4 from CVS Commits --- The releases/gcc-11 branch has been updated by Marek Polacek : https://gcc.gnu.org/g:0a9d8fd580d6afab669bae68e116e2135c2a8670 commit r11-8534-g0a9d8fd580d6afab669bae68e116e2135c2a8670 Author: Marek Polacek Date: Mon Jun 7 16:06:00 2021 -0400 c++: explicit() ignored on deduction guide [PR100065] When we have explicit() with a value-dependent argument, we can't evaluate it at parsing time, so cp_parser_function_specifier_opt stashes the argument into the decl-specifiers and grokdeclarator then stores it into explicit_specifier_map, which is then used when substituting the function decl. grokdeclarator stores it for constructors and conversion functions, but we also need to do it for deduction guides, otherwise we'll forget that we've seen an explicit-specifier as in the attached test. PR c++/100065 gcc/cp/ChangeLog: * decl.c (grokdeclarator): Store a value-dependent explicit-specifier even for deduction guides. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/explicit18.C: New test. (cherry picked from commit 1afa4facb9348cac0349ff9c30066aa25a3608f7)
[Bug c++/100065] Conditional explicit doesn't work for deduction guide
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100065 Marek Polacek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #5 from Marek Polacek --- Fixed.
[Bug c++/97375] Unexpected top-level const retainment when declaring non-type template paramter with decltype(auto)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97375 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org, ||ppalka at gcc dot gnu.org --- Comment #2 from Marek Polacek --- Fixed on trunk by r12-1224. Maybe we want to backport that to 11 too.
[Bug tree-optimization/100981] ICE in info_for_reduction, at tree-vect-loop.c:4897
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100981 --- Comment #6 from avieira at gcc dot gnu.org --- FYI Tamar asked me to make sure the instructions were being generated. I checked and they were, but not being used as it decides to inline MAIN__ and inlining seems to break (as in not apply/missed oppurtunity) the complex optimization. So for this specific test I'd use -fno-inline, it executes the fcmla instructions that way and it runs fine.
[Bug c/100993] New: ICE with -O2: Segmentation fault, cgraph_update_edges_for_call_stmt(gimple*, tree_node*, gimple*)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100993
Bug ID: 100993
Summary: ICE with -O2: Segmentation fault,
cgraph_update_edges_for_call_stmt(gimple*, tree_node*,
gimple*)
Product: gcc
Version: tree-ssa
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: cnsun at uwaterloo dot ca
Target Milestone: ---
$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/scratch/software/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/12.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /tmp/tmp.I0nMxdxnJz-gcc-builder/gcc/configure
--enable-languages=c,c++,lto --enable-checking-yes --enable-multiarch
--prefix=/scratch/software/gcc-trunk --disable-bootstrap
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.0.0 20210609 (experimental) [master revision
:c23bc3c72:87f9ac937d6cfd81cbbe0a43518ba10781888d7c] (GCC)
$ cat mutant.c
__builtin_acc_on_device(dev) { return __builtin_acc_on_device(dev); }
$ gcc-trunk -O2 mutant.c
mutant.c:1:1: warning: return type defaults to ‘int’ [-Wimplicit-int]
1 | __builtin_acc_on_device(dev) { return __builtin_acc_on_device(dev); }
| ^~~
mutant.c: In function ‘__builtin_acc_on_device’:
mutant.c:1:1: warning: type of ‘dev’ defaults to ‘int’ [-Wimplicit-int]
during IPA pass: inline
In function ‘__builtin_acc_on_device’:
cc1: internal compiler error: Segmentation fault
0xf091b3 crash_signal
/tmp/tmp.I0nMxdxnJz-gcc-builder/gcc/gcc/toplev.c:327
0xa826d0 cgraph_update_edges_for_call_stmt(gimple*, tree_node*, gimple*)
/tmp/tmp.I0nMxdxnJz-gcc-builder/gcc/gcc/cgraph.c:1729
0xf8bdcd fold_marked_statements
/tmp/tmp.I0nMxdxnJz-gcc-builder/gcc/gcc/tree-inline.c:5384
0xf9bf87 tree_function_versioning(tree_node*, tree_node*, vec*, ipa_param_adjustments*, bool, bitmap_head*,
basic_block_def*)
/tmp/tmp.I0nMxdxnJz-gcc-builder/gcc/gcc/tree-inline.c:6457
0xcc1f1b save_inline_function_body
/tmp/tmp.I0nMxdxnJz-gcc-builder/gcc/gcc/ipa-inline-transform.c:658
0xcc1f1b inline_transform(cgraph_node*)
/tmp/tmp.I0nMxdxnJz-gcc-builder/gcc/gcc/ipa-inline-transform.c:750
0xe1c8f4 execute_one_ipa_transform_pass
/tmp/tmp.I0nMxdxnJz-gcc-builder/gcc/gcc/passes.c:2290
0xe1c8f4 execute_all_ipa_transforms(bool)
/tmp/tmp.I0nMxdxnJz-gcc-builder/gcc/gcc/passes.c:2337
0xa89639 cgraph_node::expand()
/tmp/tmp.I0nMxdxnJz-gcc-builder/gcc/gcc/cgraphunit.c:1821
0xa8aa5f expand_all_functions
/tmp/tmp.I0nMxdxnJz-gcc-builder/gcc/gcc/cgraphunit.c:1992
0xa8aa5f symbol_table::compile()
/tmp/tmp.I0nMxdxnJz-gcc-builder/gcc/gcc/cgraphunit.c:2356
0xa8d95b symbol_table::compile()
/tmp/tmp.I0nMxdxnJz-gcc-builder/gcc/gcc/cgraphunit.c:2269
0xa8d95b symbol_table::finalize_compilation_unit()
/tmp/tmp.I0nMxdxnJz-gcc-builder/gcc/gcc/cgraphunit.c:2537
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
[Bug c++/96560] Substitution triggers compile-time error when it shouldn't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96560 Marek Polacek changed: What|Removed |Added Keywords||patch --- Comment #1 from Marek Polacek --- Patch: https://gcc.gnu.org/pipermail/gcc-patches/2021-April/569184.html
[Bug c++/100974] [C++23] Implement if consteval
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100974 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Created attachment 50971 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50971&action=edit gcc12-pr100974.patch Untested implementation.
[Bug ipa/100994] New: wrong code with "-O1 -finline-small-functions -fipa-cp"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100994
Bug ID: 100994
Summary: wrong code with "-O1 -finline-small-functions
-fipa-cp"
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: suochenyao at 163 dot com
CC: marxin at gcc dot gnu.org
Target Milestone: ---
***
OS and Platform:
CentOS Linux release 7.8.2003 (Core), x86_64 GNU/Linux
***
Program:
struct a {
unsigned b : 4;
unsigned c : 9;
} const d;
int e, f, g;
char h;
short i;
static int(j)() { return 0; }
static int k(const struct a l) {
for (; g; j() & l.c)
;
e = 1;
i = e + 6;
for (; e != 7; e = i)
h = f || l.b;
int m = l.c;
return 0;
}
void main() { k(d); }
***
gcc version:
$ gcc -v
Using built-in specs.
COLLECT_GCC=/data/bin/gcc-dev/bin/gcc
COLLECT_LTO_WRAPPER=/data/bin/gcc-dev/libexec/gcc/x86_64-pc-linux-gnu/12.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure --prefix=/data/bin/gcc-dev --disable-multilib
--enable-languages=c,c++
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.0.0 20210608 (experimental) (GCC)
git version: 1afa4facb9348cac0349ff9c30066aa25a3608f7
***
Command Lines:
$ gcc -O1 -finline-small-functions -fipa-cp -Wall -Wextra -fno-strict-aliasing
-fwrapv a.c -o a1.out
a.c: In function ‘k’:
a.c:10:17: warning: value computed is not used [-Wunused-value]
10 | for (; g; j() & l.c)
| ^
a.c:16:7: warning: unused variable ‘m’ [-Wunused-variable]
16 | int m = l.c;
| ^
a.c: At top level:
a.c:19:6: warning: return type of ‘main’ is not ‘int’ [-Wmain]
19 | void main() { k(d); }
| ^~~~
$ /data/bin/gcc-dev/bin/gcc a.c -o a2.out
$ ./a1.out
Segmentation fault (core dumped)
$ ./a2.out
$
[Bug tree-optimization/100981] ICE in info_for_reduction, at tree-vect-loop.c:4897
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100981 --- Comment #7 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:374f93da97fb0378453d503f3cfea4d7a923a89c commit r12-1330-g374f93da97fb0378453d503f3cfea4d7a923a89c Author: Richard Biener Date: Wed Jun 9 14:48:35 2021 +0200 tree-optimization/100981 - fix SLP patterns involving reductions The following fixes the SLP FMA patterns to preserve reduction info and the reduction vectorization to consider internal function call defs for the reduction stmt. 2021-06-09 Richard Biener PR tree-optimization/100981 gcc/ * tree-vect-loop.c (vect_create_epilog_for_reduction): Use gimple_get_lhs to also handle calls. * tree-vect-slp-patterns.c (complex_pattern::build): Transfer reduction info. gcc/testsuite/ * gfortran.dg/vect/pr100981-1.f90: New testcase. libgomp/ * testsuite/libgomp.fortran/pr100981-2.f90: New testcase.
[Bug tree-optimization/100981] [11 Regression] ICE in info_for_reduction, at tree-vect-loop.c:4897
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100981 Richard Biener changed: What|Removed |Added Summary|ICE in info_for_reduction, |[11 Regression] ICE in |at tree-vect-loop.c:4897|info_for_reduction, at ||tree-vect-loop.c:4897 Target Milestone|--- |11.2 Known to work||12.0 Priority|P3 |P2 --- Comment #8 from Richard Biener --- Fixed on trunk sofar, the issue is most likely latent on the branch.
[Bug libstdc++/100992] Wrong result for is_constructible for const ref of tuple of tuples
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100992 Jonathan Wakely changed: What|Removed |Added Ever confirmed|0 |1 Component|c++ |libstdc++ Last reconfirmed||2021-06-09 Status|UNCONFIRMED |NEW --- Comment #1 from Jonathan Wakely --- I think this is a dup
[Bug c++/100995] New: Extend std::is_constant_evaluated in if warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100995
Bug ID: 100995
Summary: Extend std::is_constant_evaluated in if warning
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: mpolacek at gcc dot gnu.org
Target Milestone: ---
Let's extend the existing warning to detect more cases, as in
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p1938r3.html#compiler-warnings
constexpr int f1() {
if constexpr (!std::is_constant_evaluated() && sizeof(int) == 4) { //
warning: always true
return 0;
}
if (std::is_constant_evaluated()) {
return 42;
} else {
if constexpr (std::is_constant_evaluated()) { // warning: always true
return 0;
}
}
return 7;
}
consteval int f2() {
if (std::is_constant_evaluated() && f1()) { // warning: always true
return 42;
}
return 7;
}
int f3() {
if (std::is_constant_evaluated() && f1()) { // warning: always false
return 42;
}
return 7;
}
[Bug c++/100995] Extend std::is_constant_evaluated in if warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100995 Marek Polacek changed: What|Removed |Added Ever confirmed|0 |1 Keywords||diagnostic Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2021-06-09
[Bug libstdc++/100992] Wrong result for is_constructible for const ref of tuple of tuples
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100992 --- Comment #2 from Amir Kirsh --- Maybe a dup of: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96592
[Bug middle-end/53267] Constant fold BUILT_IN_FMOD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53267 --- Comment #1 from CVS Commits --- The master branch has been updated by Jeff Law : https://gcc.gnu.org/g:2c17b5f8cca82d1957242055991a2c23184a1af1 commit r12-1332-g2c17b5f8cca82d1957242055991a2c23184a1af1 Author: Roger Sayle Date: Wed Jun 9 11:23:41 2021 -0400 [PATCH] PR middle-end/53267: Constant fold BUILT_IN_FMOD. gcc/ChangeLog PR middle-end/53267 * fold-const-call.c (fold_const_call_sss) [CASE_CFN_FMOD]: Support evaluation of fmod/fmodf/fmodl at compile-time. gcc/testsuite/ChangeLog * gcc.dg/builtins-70.c: New test.
[Bug target/100996] New: rs6000 p10 vector add-add fusion should work with -m32 but doesn't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100996
Bug ID: 100996
Summary: rs6000 p10 vector add-add fusion should work with -m32
but doesn't
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: acsawdey at gcc dot gnu.org
Target Milestone: ---
The fusion-p10-addadd.c test case does not get vector add-add fusion when
compiling with -m32:
/home/sawdey/work/gcc/trunk/build/gcc/xgcc
-B/home/sawdey/work/gcc/trunk/build/gcc/
/home/sawdey/work/gcc/trunk/gcc/gcc/testsuite/gcc.target/powerpc/fusion-p10-addadd.c
-m32 -fdiagnostics-plain-output -mcpu=power10 -O3 -dap -fno-ident -S
typedef vector long vlong;
vlong vaddadd(vlong a, vlong b, vlong c)
{
return a+b+c;
}
vaddadd:
.LFB3:
.cfi_startproc
vadduwm 2,2,3# 8[c=4 l=4] addv4si3
vadduwm 2,2,4# 14 [c=4 l=4] addv4si3
blr # 24 [c=4 l=4] simple_return
.cfi_endproc
[Bug target/100996] rs6000 p10 vector add-add fusion should work with -m32 but doesn't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100996 acsawdey at gcc dot gnu.org changed: What|Removed |Added Ever confirmed|0 |1 Target||powerpc-*-*-* Last reconfirmed||2021-06-09 Assignee|unassigned at gcc dot gnu.org |acsawdey at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED
[Bug middle-end/99299] Need a recoverable version of __builtin_trap()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99299 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #10 from Andrew Pinski --- Dup of bug 84595. *** This bug has been marked as a duplicate of bug 84595 ***
[Bug c/84595] Add __builtin_break() built-in for a breakpointing mechanism
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84595 Andrew Pinski changed: What|Removed |Added CC||christophe.leroy at csgroup dot eu --- Comment #10 from Andrew Pinski --- *** Bug 99299 has been marked as a duplicate of this bug. ***
[Bug middle-end/53267] Constant fold BUILT_IN_FMOD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53267 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Andrew Pinski --- Fixed.
[Bug middle-end/53267] Constant fold BUILT_IN_FMOD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53267 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |12.0
[Bug c++/100995] Extend std::is_constant_evaluated in if warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100995
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1 from Jakub Jelinek ---
namespace std {
constexpr inline bool
is_constant_evaluated () noexcept
{
return __builtin_is_constant_evaluated ();
}
}
int
foo ()
{
if (std::is_constant_evaluated ())
return 1;
return 0;
}
constexpr int
bar ()
{
if (std::is_constant_evaluated ())
return 1;
if constexpr (std::is_constant_evaluated ())
return 2;
return 0;
}
consteval int
baz ()
{
if (std::is_constant_evaluated ())
return 1;
return 0;
}
In foo, we know it will always evaluate to false, in baz always to true.
In non-constexpr functions it will not evaluate everywhere to false, so one
would need to leave out e.g. initializers of static variables and the other
spots which are manifestly constant evaluated.
But say if conditions except for statement expressions in them and if it is not
the init might be always ok and good enough for the warning.
[Bug fortran/100989] Bogus internal VOLATILE attribute for ASYNCHRONOUS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100989 Thomas Koenig changed: What|Removed |Added Last reconfirmed||2021-06-09 Ever confirmed|0 |1 Status|UNCONFIRMED |WAITING --- Comment #1 from Thomas Koenig --- F2018, 8.5.4: " An entity with the ASYNCHRONOUS attribute is a variable, and may be subject to asynchronous input/output or asynchronous communication." So, the variable can be changed without going through normal program flow. A pointer marked as escaping isn't enough, because there can also be a change during code which does not invoke any other procedures. (such as by an MPI call). If volatile isn't the right model, what is?
[Bug fortran/100989] Bogus internal VOLATILE attribute for ASYNCHRONOUS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100989 Thomas Koenig changed: What|Removed |Added Severity|normal |enhancement
[Bug other/100735] -fno-trampolines doc wrongly implies it affects C, C++ etc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100735 --- Comment #4 from CVS Commits --- The master branch has been updated by Jeff Law : https://gcc.gnu.org/g:4a0c4eaea320a418400afc4d63359ed6c4af5548 commit r12-1342-g4a0c4eaea320a418400afc4d63359ed6c4af5548 Author: Paul Eggert Date: Wed Jun 9 12:25:26 2021 -0400 Document that -fno-trampolines is for Ada only [PR100735] gcc/ PR other/100735 * doc/invoke.texi (Code Gen Options); Document that -fno-trampolines and -ftrampolines work only with Ada. * doc/tm.texi.in (Trampolines): Likewise. * doc/tm.texi: Regenerated.
[Bug fortran/100972] Missing error with "implicit none (external)"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100972 --- Comment #1 from G. Steinmetz --- Similarly, the helpful option -Wimplicit-procedure does not warn : (-Wimplicit-procedure : Warn if a procedure is called that has neither an explicit interface nor has been declared as EXTERNAL.) $ gfortran-12-20210606 -c z1.f90 -Wimplicit-procedure $ And the following error message refers to "IMPORT" : $ _g2_v12test -c z1.f90 -std=f2008 z1.f90:2:19: 2 |implicit none (external) | 1 Error: Fortran 2018: IMPORT NONE with spec list at (1)
[Bug libstdc++/100982] wrong constraint in std::optional::operator=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100982 Jonathan Wakely changed: What|Removed |Added Target Milestone|--- |9.5 Keywords||rejects-valid
[Bug c/84595] Add __builtin_break() built-in for a breakpointing mechanism
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84595
Segher Boessenkool changed:
What|Removed |Added
Ever confirmed|0 |1
CC||segher at gcc dot gnu.org
Status|UNCONFIRMED |NEW
Last reconfirmed||2021-06-09
--- Comment #11 from Segher Boessenkool ---
(In reply to Richard Biener from comment #7)
> I frequently use raise(SIGSTOP) ... (or x86 specific you can do asm ("int
> 3");
> or whatever that break thing was...
>
> Note I think that a compiler-only-side implementation might not be possible
> on all targets given it might be dependent on OS and debugger preferences
> as well?
Generating a trap instruction is not. How that then will be handled by
something else is that something else's concern, yes :-)
[Bug c/84595] Add __builtin_break() built-in for a breakpointing mechanism
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84595 --- Comment #12 from Segher Boessenkool --- (In reply to H. Peter Anvin from comment #9) > How is this different from raise(SIGTRAP);? It does an architecture-specific trap instruction, not a SIGTRAP signal. The former is useful even if you do not have an OS (or *are* the OS), for example.
[Bug c++/100825] function signature constraints are not a part of mangled name
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100825
Nickolay Merkin changed:
What|Removed |Added
CC||nickolay.merkin at gmail dot
com
--- Comment #8 from Nickolay Merkin ---
(In reply to Jonathan Wakely from comment #3)
> Clang and EDG agree with GCC here.
>
> I think your code is ill-formed due to [temp.constr.atomic] p3:
>
> "If, at different points in the program, the satisfaction result is
> different for identical atomic constraints and template arguments, the
> program is ill-formed, no diagnostic required."
Of course the constraints are different! First constraint is empty, second is
always-true.
So, these are different overloads.
Okay, let's help the compiler giving different mangled names:
https://gcc.godbolt.org/z/K8d9vv8oT
namespace a {}
namespace b {}
using namespace a;
using namespace b;
namespace a {
template void f() { std::cout << __PRETTY_FUNCTION__ << std::endl; }
}
void g() { f(); }
namespace b {
template void f() requires true { std::cout << __PRETTY_FUNCTION__ <<
std::endl; }
}
void h() { f(); }
g addresses to a::f, h addresses to b::f.
Is this still "ill-formed, no diagnostics required"?
Does it mean that a compiler may produce any corrupted binary code with any
undefined behavior? Just because we wrote same "f()" both times?
I believe, not, it does not.
The program is well-formed.
Both overloads are valid. And both are different, - it is not an ODR violation.
So, the issue is on the compiler's side: wrong rules of mangling.
[Bug c++/100997] New: [c++20] parse error when id-expression of constructor is simple-template-id
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100997
Bug ID: 100997
Summary: [c++20] parse error when id-expression of constructor
is simple-template-id
Product: gcc
Version: 11.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: felix.morgner at gmail dot com
Target Milestone: ---
Created attachment 50972
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50972&action=edit
Example source file
In C++20 mode, GCC 11.1 rejects the following code:
template
struct A;
template<>
struct A {
A() {}
};
With the following error:
:6:12: error: expected unqualified-id before ')' token
I currently don't have access to my copy of the standard, but working from both
https://wg21.link/std and https://wg21.link/std20, I am under the expression
that this code should be valid since:
According to [class.ctor], the sole id-expression of the ptr-declarator of the
ctors function declarator may be the injected-class-name. [class.pre] tells us
that the class-name of the class being declared is injected into scope of the
class, where it is called the injected-class-name. Moreover, [class.pre]
defines a class-name to be either an indentifier or a simnple-template-id. I
would argue that in the case of the explicit specialization above, A would
be a simple-template-id and thus a valid injected-class-name.
The error does not occur in C++17 mode or in GCC prior to version 11.
Tested in all cases with "-Wall -Wextra -Werror -pedantic-errors"
[Bug c++/100997] [c++20] parse error when id-expression of constructor is simple-template-id
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100997 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from Marek Polacek --- This is C++20 DR 2237, disallow simple-template-id in cdtor: see [diff.cpp17.class]p2. The diagnostic should be improved, we have bug 97202 for that. *** This bug has been marked as a duplicate of bug 97202 ***
[Bug c++/97202] GCC reports an error: expected unqualified-id before ‘short’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97202 Marek Polacek changed: What|Removed |Added CC||felix.morgner at gmail dot com --- Comment #4 from Marek Polacek --- *** Bug 100997 has been marked as a duplicate of this bug. ***
[Bug c++/100997] [c++20] parse error when id-expression of constructor is simple-template-id
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100997
--- Comment #2 from Marek Polacek ---
To make it work just remove the "" in A() {}.
[Bug c++/100997] [c++20] parse error when id-expression of constructor is simple-template-id
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100997 --- Comment #3 from Felix Morgner --- Thank you for the quick response. I will file a bug report with Boost GIL.
[Bug c++/100825] function signature constraints are not a part of mangled name
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100825 --- Comment #9 from Jonathan Wakely --- As comment 7 already said.
[Bug other/100695] Format decoder, quoting in 'dump_printf' etc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100695
Jakub Jelinek changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org,
||jakub at gcc dot gnu.org
--- Comment #1 from Jakub Jelinek ---
As an example, can be reproduced e.g. on
./cc1 -quiet -fopt-info-omp-note --param=openacc-privatization=noisy -fopenacc
-O2 .../gcc/testsuite/c-c++-common/goacc/privatization-1-routine_gang-loop.c
when that omp-low.c %<%T%> is changed to %qT.
>From what I see, the quotes for %< are emitted using:
case '<':
{
obstack_grow (&buffer->chunk_obstack,
open_quote, strlen (open_quote));
const char *colorstr
= colorize_start (pp_show_color (pp), "quote");
obstack_grow (&buffer->chunk_obstack, colorstr, strlen (colorstr));
but for %qX using:
if (quote)
pp_begin_quote (pp, pp_show_color (pp));
and similarly for the closing quote.
In the case of dump_print_*, the characters go into chunk_obstack, while e.g.
what '%T' provides goes to the stashed items or where.
[Bug c/100998] New: bug in experimental GCC12 with optimization '-O1', disappears with optimization '-O0'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100998
Bug ID: 100998
Summary: bug in experimental GCC12 with optimization '-O1',
disappears with optimization '-O0'
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: fossum at us dot ibm.com
Target Milestone: ---
(note: m, i and k are "long int", GEMM_UNROLL_M is 256, COMPSIZE is 1, and
a, c, aa, cc are of type (float *))
Here's a snippet of our code:
===
for (i = 1; i < GEMM_UNROLL_M; i *= 2){
if (m & i) {
if (((m & ~(i - 1)) - i) < 0) {
fprintf(stderr, "EEK! m = %ld, i = %ld, ((m & ~(i - 1)) - i) = %ld\n",
m, i, ((m & ~(i - 1)) - i));
fflush(stderr);
}
aa = a + ((m & ~(i - 1)) - i) * k * COMPSIZE;
cc = c + ((m & ~(i - 1)) - i) * COMPSIZE;
...
[call a function using aa and cc]
}
}
===
When we run with -O0, the printout does not occur, and all is well.
When we run with -O1, we see this printout:
EEK! m = 3, i = 1, ((m & ~(i - 1)) - i) = -2
The fact that we get a negative number ends up leading to a
segfault in the called function, when we try to access the
first element of the array "aa".
I would be DELIGHTED if you could help me understand that the tested
construction ((m & ~(i - 1)) - i) is somehow illegal, but I feel like
it should NEVER return a negative value, as long as i is a power of 2,
and (m & i) is not 0.
I'm building this code with GCC12 (a version provided by my colleague
Peter Bergner, and I'm hoping he will add a comment clarifying exactly
which version of your experimental GCC12 he is using.
[Bug d/100935] d: T.alignof ignores explicit align(N) type alignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100935 --- Comment #1 from CVS Commits --- The master branch has been updated by Iain Buclaw : https://gcc.gnu.org/g:04fea2d66bd680beb1a204e62f2f459307000813 commit r12-1344-g04fea2d66bd680beb1a204e62f2f459307000813 Author: Iain Buclaw Date: Wed Jun 9 19:37:22 2021 +0200 d: Respect explicit align(N) type alignment (PR100935) It was previously the natural type alignment, defined as the maximum of the field alignments for an aggregate. Make sure an explicit align(N) overrides it. Reviewed-on: https://github.com/dlang/dmd/pull/12646 gcc/d/ChangeLog: PR d/100935 * dmd/MERGE: Merge upstream dmd f3fdeb578.
[Bug d/100964] d: TypeInfo error when using slice copy on Structs with -fno-rtti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100964 --- Comment #1 from CVS Commits --- The master branch has been updated by Iain Buclaw : https://gcc.gnu.org/g:036e14ca44eaddf329a79d56d556862118b1f220 commit r12-1345-g036e14ca44eaddf329a79d56d556862118b1f220 Author: Iain Buclaw Date: Wed Jun 9 19:39:28 2021 +0200 d: TypeInfo error when using slice copy on Structs (PR100964) Known limitation: does not work for struct with postblit or dtor. Reviewed-on: https://github.com/dlang/dmd/pull/12648 gcc/d/ChangeLog: PR d/100964 * dmd/MERGE: Merge upstream dmd 4a4e46a6f.
[Bug d/100935] d: T.alignof ignores explicit align(N) type alignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100935 --- Comment #2 from CVS Commits --- The releases/gcc-11 branch has been updated by Iain Buclaw : https://gcc.gnu.org/g:c6c3ed60276b842114aefce54d73e30e578fdd6d commit r11-8535-gc6c3ed60276b842114aefce54d73e30e578fdd6d Author: Iain Buclaw Date: Wed Jun 9 19:37:22 2021 +0200 d: Respect explicit align(N) type alignment (PR100935) It was previously the natural type alignment, defined as the maximum of the field alignments for an aggregate. Make sure an explicit align(N) overrides it. gcc/d/ChangeLog: PR d/100935 * dmd/mtype.c (Type::getProperty): Prefer explicit alignment over natural alignment for alignof property. gcc/testsuite/ChangeLog: PR d/100935 * gdc.test/compilable/aggr_alignment.d: Add test cases. (cherry picked from commit 04fea2d66bd680beb1a204e62f2f459307000813)
[Bug d/100964] d: TypeInfo error when using slice copy on Structs with -fno-rtti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100964 --- Comment #2 from CVS Commits --- The releases/gcc-11 branch has been updated by Iain Buclaw : https://gcc.gnu.org/g:10d4f283f4177d80cec3c9e8bf447a48cab5bb47 commit r11-8536-g10d4f283f4177d80cec3c9e8bf447a48cab5bb47 Author: Iain Buclaw Date: Wed Jun 9 19:39:28 2021 +0200 d: TypeInfo error when using slice copy on Structs (PR100964) Known limitation: does not work for struct with postblit or dtor. gcc/d/ChangeLog: PR d/100964 * dmd/expression.c (Expression::checkPostblit): Don't generate TypeInfo when RTTI is disabled. gcc/testsuite/ChangeLog: PR d/100964 * gdc.test/compilable/betterCarray.d: Add test cases. (cherry picked from commit 036e14ca44eaddf329a79d56d556862118b1f220)
[Bug d/100935] d: T.alignof ignores explicit align(N) type alignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100935 --- Comment #3 from CVS Commits --- The releases/gcc-10 branch has been updated by Iain Buclaw : https://gcc.gnu.org/g:f7ece1a32000a9943f5bd5ac597d6ce3829aff8e commit r10-9898-gf7ece1a32000a9943f5bd5ac597d6ce3829aff8e Author: Iain Buclaw Date: Wed Jun 9 19:37:22 2021 +0200 d: Respect explicit align(N) type alignment (PR100935) It was previously the natural type alignment, defined as the maximum of the field alignments for an aggregate. Make sure an explicit align(N) overrides it. gcc/d/ChangeLog: PR d/100935 * dmd/mtype.c (Type::getProperty): Prefer explicit alignment over natural alignment for alignof property. gcc/testsuite/ChangeLog: PR d/100935 * gdc.test/compilable/aggr_alignment.d: Add test cases. (cherry picked from commit 3ba036dd1a752d29764ad44adca6e68bec9599fe)
[Bug d/100964] d: TypeInfo error when using slice copy on Structs with -fno-rtti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100964 --- Comment #3 from CVS Commits --- The releases/gcc-10 branch has been updated by Iain Buclaw : https://gcc.gnu.org/g:d660f34b6718c5f107fd1f1a2126aec759a6593b commit r10-9899-gd660f34b6718c5f107fd1f1a2126aec759a6593b Author: Iain Buclaw Date: Wed Jun 9 19:39:28 2021 +0200 d: TypeInfo error when using slice copy on Structs (PR100964) Known limitation: does not work for struct with postblit or dtor. gcc/d/ChangeLog: PR d/100964 * dmd/expression.c (Expression::checkPostblit): Don't generate TypeInfo when RTTI is disabled. gcc/testsuite/ChangeLog: PR d/100964 * gdc.test/compilable/betterCarray.d: Add test cases. (cherry picked from commit 10d4f283f4177d80cec3c9e8bf447a48cab5bb47)
[Bug d/100935] d: T.alignof ignores explicit align(N) type alignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100935 --- Comment #4 from CVS Commits --- The releases/gcc-9 branch has been updated by Iain Buclaw : https://gcc.gnu.org/g:fe555102dc224b4d946becc8a9db514ecec66161 commit r9-9575-gfe555102dc224b4d946becc8a9db514ecec66161 Author: Iain Buclaw Date: Wed Jun 9 19:37:22 2021 +0200 d: Respect explicit align(N) type alignment (PR100935) It was previously the natural type alignment, defined as the maximum of the field alignments for an aggregate. Make sure an explicit align(N) overrides it. gcc/d/ChangeLog: PR d/100935 * dmd/mtype.c (Type::getProperty): Prefer explicit alignment over natural alignment for alignof property. gcc/testsuite/ChangeLog: PR d/100935 * gdc.test/compilable/aggr_alignment.d: Add test cases. (cherry picked from commit 3ba036dd1a752d29764ad44adca6e68bec9599fe)
[Bug d/100964] d: TypeInfo error when using slice copy on Structs with -fno-rtti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100964 --- Comment #4 from CVS Commits --- The releases/gcc-9 branch has been updated by Iain Buclaw : https://gcc.gnu.org/g:d0ff449baf8d64819badb1883221b5b7295e7406 commit r9-9576-gd0ff449baf8d64819badb1883221b5b7295e7406 Author: Iain Buclaw Date: Wed Jun 9 19:39:28 2021 +0200 d: TypeInfo error when using slice copy on Structs (PR100964) Known limitation: does not work for struct with postblit or dtor. gcc/d/ChangeLog: PR d/100964 * dmd/expression.c (Expression::checkPostblit): Don't generate TypeInfo when RTTI is disabled. gcc/testsuite/ChangeLog: PR d/100964 * gdc.test/compilable/betterCarray.d: Add test cases. (cherry picked from commit 10d4f283f4177d80cec3c9e8bf447a48cab5bb47)
[Bug d/100935] d: T.alignof ignores explicit align(N) type alignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100935 Iain Buclaw changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #5 from Iain Buclaw --- Fix committed.
[Bug d/100964] d: TypeInfo error when using slice copy on Structs with -fno-rtti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100964 Iain Buclaw changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #5 from Iain Buclaw --- Fix committed
[Bug d/100999] New: d: foreach over a tuple doesn't work on 16-bit targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100999
Bug ID: 100999
Summary: d: foreach over a tuple doesn't work on 16-bit targets
Product: gcc
Version: 10.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: d
Assignee: ibuclaw at gdcproject dot org
Reporter: ibuclaw at gdcproject dot org
Target Milestone: ---
There is an error if the index type isn't an int or long type. This triggers
on 16-bit targets where the index would be size_t for looping over an array.
---
alias AliasSeq(TList...) = TList;
alias size_t = ushort;
void foo(int a, int b, int c)
{
// OK
foreach (size_t i, e; [0, 1, 2, 3]) { }
// Errors
static foreach (size_t i, e; [0, 1, 2, 3]) { }
foreach (size_t i, e; AliasSeq!(0, 1, 2, 3)) { }
static foreach (size_t i, e; AliasSeq!(0, 1, 2, 3)) { }
}
[Bug other/100735] -fno-trampolines doc wrongly implies it affects C, C++ etc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100735 Jeffrey A. Law changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED CC||law at gcc dot gnu.org --- Comment #5 from Jeffrey A. Law --- Fixed with Paul's documentation change on the trunk.
[Bug ipa/100994] [12 Regression] wrong code with "-O1 -finline-small-functions -fipa-cp"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100994 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Summary|wrong code with "-O1|[12 Regression] wrong code |-finline-small-functions|with "-O1 |-fipa-cp" |-finline-small-functions ||-fipa-cp" CC||ebotcazou at gcc dot gnu.org, ||jakub at gcc dot gnu.org Target Milestone|--- |12.0 Ever confirmed|0 |1 Last reconfirmed||2021-06-09 --- Comment #1 from Jakub Jelinek --- That void main should have been int main. Anyway, started with r12-434-g93f8cb4965cebee125f96376367f05e18ee5749b
[Bug ipa/100994] [12 Regression] wrong code with "-O1 -finline-small-functions -fipa-cp"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100994
--- Comment #2 from Jakub Jelinek ---
The difference after IPA between r12-433 and r12-434 is:
--- pr100994.c.092t.fixup_cfg3_ 2021-06-09 14:26:08.0 -0400
+++ pr100994.c.092t.fixup_cfg3 2021-06-09 14:26:28.0 -0400
@@ -3,7 +3,6 @@
int main ()
{
- const struct a l;
const l$c;
int g.0_4;
int f.3_5;
@@ -14,8 +13,7 @@ int main ()
int e.5_10;
[local count: 1073741824]:
- l = d;
- l$c_3 = l.c;
+ l$c_3 = 0;
[local count: 9761289362]:
g.0_4 = g;
@@ -37,8 +35,8 @@ int main ()
goto ; [50.00%]
[local count: 4343773769]:
- l.c = l$c_3;
- _6 = BIT_FIELD_REF ;
+ d.c = l$c_3;
+ _6 = 0;
_7 = _6 & 15;
if (_7 != 0)
goto ; [50.00%]
Note, d is a TREE_STATIC const variable where both members are 0,
so I guess l$c_3 = 0; is ok, but the l.c = l$c_3 to d.c = l$c_3; change is not,
that is what segfaults there.
[Bug middle-end/100998] bug in experimental GCC12 with optimization '-O1', disappears with optimization '-O0'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100998
Andrew Pinski changed:
What|Removed |Added
Component|c |middle-end
Keywords||wrong-code
Last reconfirmed||2021-06-09
Ever confirmed|0 |1
Status|UNCONFIRMED |WAITING
--- Comment #1 from Andrew Pinski ---
So the tree level looks fine for me:
_1 = (unsigned int) i_5(D);
_2 = -_1;
_9 = (unsigned int) m_6(D);
_3 = _2 & _9;
_4 = _3 - _1;
_7 = (int) _4;
CUT
This is for:
int f (long int m, long int i)
{
return ((m & ~(i - 1)) - i);
}
CUT
The assembly produced for both x86_64 and aarch64 looks correct.
What target is this on?
[Bug middle-end/100998] bug in experimental GCC12 with optimization '-O1', disappears with optimization '-O0'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100998 Andrew Pinski changed: What|Removed |Added Ever confirmed|1 |0 Status|WAITING |UNCONFIRMED Target||powerpc --- Comment #2 from Andrew Pinski --- If this is powerpc and on power10, then it is most likely caused by r12-1020.
[Bug ipa/100994] [12 Regression] wrong code with "-O1 -finline-small-functions -fipa-cp"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100994 Jakub Jelinek changed: What|Removed |Added CC||jamborm at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- The MEM[(struct a *)&l].c = l$c_24; in the function to be inlined is there since esra. Arguably it is strange that esra stores back into the parameter when it is const. In C/C++ one can cast away the const, but if the parm isn't addressable and there are no stores to it it shouldn't be modified.
[Bug target/100998] [12 Regression] bug in experimental GCC12 with optimization '-O1', disappears with optimization '-O0'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100998 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |12.0
[Bug middle-end/32667] block copy with exact overlap is expanded as memcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667 Tim Ruffing changed: What|Removed |Added CC||public at timruffing dot de --- Comment #18 from Tim Ruffing --- Is there still interest in fixing this? This still leads to spurious Valgrind warnings in the real world.
[Bug target/100998] [12 Regression] bug in experimental GCC12 with optimization '-O1', disappears with optimization '-O0'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100998 Peter Bergner changed: What|Removed |Added CC||acsawdey at gcc dot gnu.org, ||bergner at gcc dot gnu.org, ||segher at gcc dot gnu.org --- Comment #3 from Peter Bergner --- (In reply to Andrew Pinski from comment #2) > If this is powerpc and on power10, then it is most likely caused by r12-1020. Not arguing with you, but how did you pinpoint this commit?
[Bug other/100735] -fno-trampolines doc wrongly implies it affects C, C++ etc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100735 --- Comment #6 from CVS Commits --- The master branch has been updated by H.J. Lu : https://gcc.gnu.org/g:8f0d7f322172d411d271aa02024a342c72534465 commit r12-1346-g8f0d7f322172d411d271aa02024a342c72534465 Author: H.J. Lu Date: Wed Jun 9 11:56:15 2021 -0700 Update doc/tm.texi.in to fix commit 4a0c4eaea32 PR other/100735 * doc/tm.texi.in (Trampolines): Add a missing blank line.
[Bug ipa/100994] [12 Regression] wrong code with "-O1 -finline-small-functions -fipa-cp"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100994
--- Comment #4 from Jakub Jelinek ---
Though, SRA isn't really needed, consider following testcase with
-O2 -fno-early-inlining -fno-tree-sra -fno-tree-fre
struct S { unsigned b : 4; unsigned c : 9; } const d;
__attribute__((noipa)) void foo (void) {}
static int bar (const struct S l) {
((struct S *)&l)->b += 2;
((struct S *)&l)->c += 4;
foo ();
return l.b + l.c;
}
int main () { bar (d); return 0; }
This also worked fine with r12-433 and segfaults with r12-434 because it will
store to d.b and d.c (instead of modifying an automatic variable).
But even if it doesn't bind to a static .rodata variable where stores will
segfault, but binds to caller's automatic variable, this binding might change
the caller's variable.
Perhaps the tree-inline.c change is fine for Ada, but it doesn't seem to be
safe for C/C++.
[Bug target/100998] [12 Regression] bug in experimental GCC12 with optimization '-O1', disappears with optimization '-O0'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100998 --- Comment #4 from Peter Bergner --- FYI, I'll give Gordon a build without that patch to test with and see if his issue goes away with that.
