[Bug c++/101367] [coroutines] destructor for capture in lambda temporary operand to co_yield expression called twice
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101367 --- Comment #6 from CVS Commits --- The master branch has been updated by Iain D Sandoe : https://gcc.gnu.org/g:58a7b1e354530d8dfe7d8fb859c8b8b5a9140f1f commit r13-4479-g58a7b1e354530d8dfe7d8fb859c8b8b5a9140f1f Author: Iain Sandoe Date: Wed Nov 30 17:05:56 2022 + coroutines: Do not promote temporaries that will be elided. We usually need to 'promote' (i.e. save to the coroutine frame) any temporary variable that is in a target expression that must persist across an await expression. However, if the TE is just used as a direct initializer for another object it will be elided - and we should not promote it since that would lead to a DTOR call for something that is never constructed. Since we now have a mechanism to tell if TEs will be elided, use that. Although the PRs referenced initially appear to be different issues, they all stem from this. Co-Authored-By: Adrian Perl Signed-off-by: Iain Sandoe PR c++/100611 PR c++/101367 PR c++/101976 PR c++/99576 gcc/cp/ChangeLog: * coroutines.cc (find_interesting_subtree): Do not promote temporaries that are only used as direct initializers for some other object. gcc/testsuite/ChangeLog: * g++.dg/coroutines/pr100611.C: New test. * g++.dg/coroutines/pr101367.C: New test. * g++.dg/coroutines/pr101976.C: New test. * g++.dg/coroutines/pr99576_1.C: New test. * g++.dg/coroutines/pr99576_2.C: New test.
[Bug c++/100611] coroutines: destructor called too many times for coroutine lambda stored object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100611 --- Comment #6 from CVS Commits --- The master branch has been updated by Iain D Sandoe : https://gcc.gnu.org/g:58a7b1e354530d8dfe7d8fb859c8b8b5a9140f1f commit r13-4479-g58a7b1e354530d8dfe7d8fb859c8b8b5a9140f1f Author: Iain Sandoe Date: Wed Nov 30 17:05:56 2022 + coroutines: Do not promote temporaries that will be elided. We usually need to 'promote' (i.e. save to the coroutine frame) any temporary variable that is in a target expression that must persist across an await expression. However, if the TE is just used as a direct initializer for another object it will be elided - and we should not promote it since that would lead to a DTOR call for something that is never constructed. Since we now have a mechanism to tell if TEs will be elided, use that. Although the PRs referenced initially appear to be different issues, they all stem from this. Co-Authored-By: Adrian Perl Signed-off-by: Iain Sandoe PR c++/100611 PR c++/101367 PR c++/101976 PR c++/99576 gcc/cp/ChangeLog: * coroutines.cc (find_interesting_subtree): Do not promote temporaries that are only used as direct initializers for some other object. gcc/testsuite/ChangeLog: * g++.dg/coroutines/pr100611.C: New test. * g++.dg/coroutines/pr101367.C: New test. * g++.dg/coroutines/pr101976.C: New test. * g++.dg/coroutines/pr99576_1.C: New test. * g++.dg/coroutines/pr99576_2.C: New test.
[Bug c++/101976] When constructing object, calling function and performing co_await in same statement, temporary is erroneously moved trivially
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101976 --- Comment #2 from CVS Commits --- The master branch has been updated by Iain D Sandoe : https://gcc.gnu.org/g:58a7b1e354530d8dfe7d8fb859c8b8b5a9140f1f commit r13-4479-g58a7b1e354530d8dfe7d8fb859c8b8b5a9140f1f Author: Iain Sandoe Date: Wed Nov 30 17:05:56 2022 + coroutines: Do not promote temporaries that will be elided. We usually need to 'promote' (i.e. save to the coroutine frame) any temporary variable that is in a target expression that must persist across an await expression. However, if the TE is just used as a direct initializer for another object it will be elided - and we should not promote it since that would lead to a DTOR call for something that is never constructed. Since we now have a mechanism to tell if TEs will be elided, use that. Although the PRs referenced initially appear to be different issues, they all stem from this. Co-Authored-By: Adrian Perl Signed-off-by: Iain Sandoe PR c++/100611 PR c++/101367 PR c++/101976 PR c++/99576 gcc/cp/ChangeLog: * coroutines.cc (find_interesting_subtree): Do not promote temporaries that are only used as direct initializers for some other object. gcc/testsuite/ChangeLog: * g++.dg/coroutines/pr100611.C: New test. * g++.dg/coroutines/pr101367.C: New test. * g++.dg/coroutines/pr101976.C: New test. * g++.dg/coroutines/pr99576_1.C: New test. * g++.dg/coroutines/pr99576_2.C: New test.
[Bug c++/99576] [coroutines] destructor of a temporary called too early within co_await expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99576 --- Comment #16 from CVS Commits --- The master branch has been updated by Iain D Sandoe : https://gcc.gnu.org/g:58a7b1e354530d8dfe7d8fb859c8b8b5a9140f1f commit r13-4479-g58a7b1e354530d8dfe7d8fb859c8b8b5a9140f1f Author: Iain Sandoe Date: Wed Nov 30 17:05:56 2022 + coroutines: Do not promote temporaries that will be elided. We usually need to 'promote' (i.e. save to the coroutine frame) any temporary variable that is in a target expression that must persist across an await expression. However, if the TE is just used as a direct initializer for another object it will be elided - and we should not promote it since that would lead to a DTOR call for something that is never constructed. Since we now have a mechanism to tell if TEs will be elided, use that. Although the PRs referenced initially appear to be different issues, they all stem from this. Co-Authored-By: Adrian Perl Signed-off-by: Iain Sandoe PR c++/100611 PR c++/101367 PR c++/101976 PR c++/99576 gcc/cp/ChangeLog: * coroutines.cc (find_interesting_subtree): Do not promote temporaries that are only used as direct initializers for some other object. gcc/testsuite/ChangeLog: * g++.dg/coroutines/pr100611.C: New test. * g++.dg/coroutines/pr101367.C: New test. * g++.dg/coroutines/pr101976.C: New test. * g++.dg/coroutines/pr99576_1.C: New test. * g++.dg/coroutines/pr99576_2.C: New test.
[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 #17 from Jan Dubiec ---
Thanks Jonathan. I have also applied g:7b79fa930917da735f02b4f6911dfbb0a91f9714
and finally successfully built libstdc++, however there is a bunch of warnings
for review. There are no assembler errors for src/c++17/fs_dir.cc in 12.2
(binutils 2.39).
A question regarding g:75e562d2c4303d3918be9d1563284b0c580c5e45 in relation to
g:a7b97a1f6b9d4993545525fd5cb334ae640ddf45 – don't you think that
_M_blocks_per_chunk = std::min({
max_blocks,
__opts.max_blocks_per_chunk,
_M_blocks_per_chunk * 2
});
looks nicer than
_M_blocks_per_chunk = std::min({
max_blocks,
__opts.max_blocks_per_chunk,
size_t(_M_blocks_per_chunk * 2)
});
[Bug c++/105373] miscompile involving lambda coroutines and an object bitwise copied instead of via the copy constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105373 --- Comment #17 from Avi Kivity --- This was apparently fixed by 58a7b1e354530d8dfe7d8fb859c8b8b5a9140f1f. At least, I no longer observe copying of __old4 in gimple. Instead, I see addresses taken, and if I squint I can see that object properly destroyed later on. I can't test on my full-scale program due to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98056. I note that one of the duplicates is titled "When constructing object, calling function and performing co_await in same statement, temporary is erroneously moved trivially", which is exactly what this PR is about, so it can be safely marked as a duplicate as well. Please consider backporting https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99576, this is a subtle code generation bug.
[Bug libstdc++/51906] thread lock test failures on darwin11 under Xcode 4.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51906 --- Comment #57 from CVS Commits --- The master branch has been updated by Iain D Sandoe : https://gcc.gnu.org/g:a044c9d25972b22c6b4c8ec27f2de5fd622573cc commit r13-4482-ga044c9d25972b22c6b4c8ec27f2de5fd622573cc Author: Iain Sandoe Date: Sat Dec 3 17:09:35 2022 + libstdc++, Darwin: Limit recursive mutex init to OS versions needing it. The problem described in pr 51906 was fixed in the next OS release. Limit the workaround to systems that need it. Signed-off-by: Iain Sandoe libstdc++-v3/ChangeLog: * config/os/bsd/darwin/os_defines.h (_GTHREAD_USE_RECURSIVE_MUTEX_INIT_FUNC): Limit use of this macro to OS versions that need it.
[Bug c++/107417] g++ fails to recognize parameter pack in requires-expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107417 --- Comment #2 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:079add3ad39d6620d34665dd9c26c21951eb657c commit r13-4483-g079add3ad39d6620d34665dd9c26c21951eb657c Author: Patrick Palka Date: Sun Dec 4 10:47:24 2022 -0500 c++: pack in requires-expr parm list [PR107417] Here find_parameter_packs_r isn't detecting the pack T inside the requires-expr's parameter list ultimately because cp_walk_trees deliberately avoids walking the list so as to avoid false positives in the unexpanded pack checker. But it should still be fine to walk the TREE_TYPE of each parameter, which we already need to do from for_each_template_parm_r, and is sufficient to fix the testcase. PR c++/107417 gcc/cp/ChangeLog: * pt.cc (for_each_template_parm_r) : Move walking of the TREE_TYPE of each parameter to ... * tree.cc (cp_walk_subtrees) : ... here. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/concepts-requires33.C: New test.
[Bug c++/107417] g++ fails to recognize parameter pack in requires-expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107417 Patrick Palka changed: What|Removed |Added Target Milestone|--- |12.3 --- Comment #3 from Patrick Palka --- Fixed on trunk so far.
[Bug plugins/107964] New: [13] missing plugin header contracts.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107964 Bug ID: 107964 Summary: [13] missing plugin header contracts.h Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: plugins Assignee: unassigned at gcc dot gnu.org Reporter: s...@li-snyder.org Target Milestone: --- I have a gcc plugin that fails to compile against trunk because the contracts.h header, which is included by cp-tree.h, is not installed to the plugins directory. Trivially fixed thus: diff --git a/gcc/cp/Make-lang.in b/gcc/cp/Make-lang.in index af25bdc044a..e189f556955 100644 --- a/gcc/cp/Make-lang.in +++ b/gcc/cp/Make-lang.in @@ -39,7 +39,7 @@ CXX_INSTALL_NAME := $(shell echo c++|sed '$(program_transform_name)') GXX_INSTALL_NAME := $(shell echo g++|sed '$(program_transform_name)') CXX_TARGET_INSTALL_NAME := $(target_noncanonical)-$(shell echo c++|sed '$(program_transform_name)') GXX_TARGET_INSTALL_NAME := $(target_noncanonical)-$(shell echo g++|sed '$(program_transform_name)') -CP_PLUGIN_HEADERS := cp-tree.h cxx-pretty-print.h name-lookup.h type-utils.h operators.def cp-trait.def +CP_PLUGIN_HEADERS := cp-tree.h cxx-pretty-print.h name-lookup.h type-utils.h operators.def cp-trait.def contracts.h #^L # Define the names for selecting c++ in LANGUAGES. (I can send a reproducer if desired, but i didn't think that was really necessary in this case.)
[Bug fortran/106576] Finalization of temporaries from functions not occuring
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106576 --- Comment #6 from Thomas Koenig --- > I hope that you are well and that the lack of time is for a good cause? Hi Paul, yes, I'm well, and the lack of time is indeed for a good cause :-) > I have just returned to my finalizer patch. With it applied, your testcase > produces the same output as NAG. That's great! > I will attach the present version of the patch to this PR. Is there a chance that we will see this patch in gcc13? Even if it does not fix every last bug in finalizers in gfortran, it would still be a very large improvement compared to the current condition.
[Bug tree-optimization/107956] [12/13 Regression] ICE: SIGSEGV in contains_struct_check (tree.h:3641) with -fsanitize=float-cast-overflow -ftree-slp-vectorize -fexceptions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107956 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |12.3
[Bug tree-optimization/107956] [12/13 Regression] ICE: SIGSEGV in contains_struct_check (tree.h:3641) with -fsanitize=float-cast-overflow -ftree-slp-vectorize -fexceptions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107956
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
Last reconfirmed||2022-12-04
--- Comment #1 from Andrew Pinski ---
>.COND_ADD (_7, v_13(D), { 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7
> }, { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 });
[Bug tree-optimization/107956] [12/13 Regression] ICE: SIGSEGV in contains_struct_check (tree.h:3641) with -fsanitize=float-cast-overflow -ftree-slp-vectorize -fexceptions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107956
--- Comment #2 from Andrew Pinski ---
This should fix it:
diff --git a/gcc/tree-vect-patterns.cc b/gcc/tree-vect-patterns.cc
index f6c34bb3263..d9fdb24ee62 100644
--- a/gcc/tree-vect-patterns.cc
+++ b/gcc/tree-vect-patterns.cc
@@ -4964,6 +4964,8 @@ vect_recog_mask_conversion_pattern (vec_info *vinfo,
else
{
lhs = gimple_call_lhs (last_stmt);
+ if (!lhs)
+ return NULL;
vectype1 = get_vectype_for_scalar_type (vinfo, TREE_TYPE (lhs));
}
Though I think it has been a latent bug since r9-1741-g2c58d42c3ed599 really.
[Bug fortran/107870] A possible typo in the documentation of 'FLOOR'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107870 --- Comment #3 from CVS Commits --- The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:98d6e4b6f1011655da19344bc124a3013b9c0134 commit r13-4485-g98d6e4b6f1011655da19344bc124a3013b9c0134 Author: Harald Anlauf Date: Sat Dec 3 21:13:48 2022 +0100 Fortran: fix typo in documentation of intrinsic FLOOR [PR107870] gcc/fortran/ChangeLog: PR fortran/107870 * intrinsic.texi: Fix typo in documentation of intrinsic FLOOR. Describe the optional KIND argument to intrinsics as a scalar constant expression, in accordance with the current standard.
[Bug fortran/107899] ICE in resolve_deallocate_expr, at fortran/resolve.cc:7576
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107899 --- Comment #3 from CVS Commits --- The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:9123863828b2f86e7a6aafba38738e7204ed19ca commit r13-4484-g9123863828b2f86e7a6aafba38738e7204ed19ca Author: Harald Anlauf Date: Sat Dec 3 19:21:07 2022 +0100 Fortran: error recovery handling invalid CLASS variable [PR107899] gcc/fortran/ChangeLog: PR fortran/107899 * resolve.cc (resolve_deallocate_expr): Avoid NULL pointer dereference on invalid CLASS variable. gcc/testsuite/ChangeLog: PR fortran/107899 * gfortran.dg/pr107899.f90: New test.
[Bug fortran/107870] A possible typo in the documentation of 'FLOOR'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107870 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Target Milestone|--- |13.0 Resolution|--- |FIXED --- Comment #4 from anlauf at gcc dot gnu.org --- Fixed for gcc-13. Closing. Thanks for the report!
[Bug fortran/107899] ICE in resolve_deallocate_expr, at fortran/resolve.cc:7576
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107899 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED Target Milestone|--- |13.0 --- Comment #4 from anlauf at gcc dot gnu.org --- Fixed on mainline for gcc-13. Closing. Thanks for the report!
[Bug libstdc++/107965] New: libstdc++ Python Pretty-Printers: Many Exceptions From Uninitialized Structures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107965
Bug ID: 107965
Summary: libstdc++ Python Pretty-Printers: Many Exceptions From
Uninitialized Structures
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: gustaf.waldemarson at gmail dot com
Target Milestone: ---
Created attachment 54008
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54008&action=edit
Python stack-traces and memory errors
Hello,
I've been having a bit of an odd issue with Python pretty-printers
bundled together with libstdc++(-v3). Truthfully though, I'm not really
sure if this is a bug, but anyways:
Given the following simple `gdbinit` that only initializes the pretty
printers and enables Python stack-traces:
```
python
import os
import re
import sys
import os.path
import textwrap
import gdb
import gdb.types
import gdb.printing
home = os.environ.get("HOME", "~")
default_path = os.path.join(home, "git", "installs")
objects_dir = os.environ.get("objects_dir", default_path)
python_addons = os.path.join(objects_dir, "gcc", "libstdc++-v3", "python")
if os.path.isdir(python_addons):
print("Installing libstdcxx printers...")
sys.path.insert(0, python_addons)
from libstdcxx.v6.printers import register_libstdcxx_printers
register_libstdcxx_printers(None)
end
set python print-stack full
```
and this simple C++ file:
#include
#include
#include
using namespace std;
int main(void)
{
vector test{"test", "test2"};
string blabla = "hello";
int b = 2;
std::cout << blabla << " "
<< b << " "
<< test[0] << " " << test[1] << std::endl;
return 0;
}
Compile it and start debugging:
```
g++ -g3 test.cpp
gdb -q a.out
(gdb) start
(gdb) info locals
```
At `info locals` I get a lot of memory related errors, presumably
because none of the local variables have been initialized, but I
also get a large number of Python exceptions; following the Python
print-stack-trace reveals a possible error here:
```
File
"/home/xaldew/git/installs/gcc/libstdc++-v3/python/libstdcxx/v6/printers.py",
line 971, in to_string
return ptr.lazy_string (length = length)
OverflowError: int too big to convert
```
I had a look at that file but could not find any obvious errors. Is this
behavior intended for uninitialized local variables?
(The complete log-file of the error is attached)
[Bug fortran/107870] A possible typo in the documentation of 'FLOOR'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107870 --- Comment #5 from Nino Pereira --- and to you for being so courteous not to laugh me out of the room. On Sun, Dec 4, 2022 at 2:43 PM anlauf at gcc dot gnu.org < gcc-bugzi...@gcc.gnu.org> wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107870 > > anlauf at gcc dot gnu.org changed: > >What|Removed |Added > > > Status|ASSIGNED|RESOLVED >Target Milestone|--- |13.0 > Resolution|--- |FIXED > > --- Comment #4 from anlauf at gcc dot gnu.org --- > Fixed for gcc-13. Closing. > > Thanks for the report! > > -- > You are receiving this mail because: > You reported the bug.
[Bug fortran/107922] ICE in gfc_simplify_unpack, at fortran/simplify.cc:8473
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107922 --- Comment #3 from CVS Commits --- The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:24b9337d1f1b5197b6498dceb9074319be003449 commit r13-4486-g24b9337d1f1b5197b6498dceb9074319be003449 Author: Harald Anlauf Date: Thu Dec 1 21:16:46 2022 +0100 Fortran: error recovery simplifying UNPACK for insufficient FIELD [PR107922] gcc/fortran/ChangeLog: PR fortran/107922 * simplify.cc (gfc_simplify_unpack): Terminate simplification when array-valued argument FIELD does not provide enough elements. gcc/testsuite/ChangeLog: PR fortran/107922 * gfortran.dg/unpack_field_1.f90: New test.
[Bug libstdc++/107965] libstdc++ Python Pretty-Printers: Many Exceptions From Uninitialized Structures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107965 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=59170 --- Comment #1 from Andrew Pinski --- Related to PR 59170.
[Bug middle-end/107966] New: [10/11/12/13 Regression] option property Var(var) documentation seems cut off
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107966 Bug ID: 107966 Summary: [10/11/12/13 Regression] option property Var(var) documentation seems cut off Product: gcc Version: 13.0 Status: UNCONFIRMED Keywords: documentation Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: pinskia at gcc dot gnu.org Target Milestone: --- Right now it is listed as: ``` Var(var) The state of this option should be stored in variable var (actually a macro for global_options.x_var). The way that the state is stored depends on the type of option: ``` And then WarnRemoved is next. So the list is now part of Var(var,set) but it has: var is declared in the same way as for the single-argument form described above. r9-1180-g3713f2e213602f introduced Deprecated which was renamed to WarnRemoved (in r10-3083-g68a57628f482c7). r9-3637-g86f36311bccb0f tried to fix the issue by moving Var(var,set) around but messed it up still.
[Bug middle-end/107966] [10/11/12/13 Regression] option property Var(var) documentation seems cut off
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107966 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |10.5
[Bug fortran/107144] ICE in gfc_get_symbol_decl, at fortran/trans-decl.cc:1623
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107144 anlauf at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-valid-code Last reconfirmed||2022-12-04 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from anlauf at gcc dot gnu.org --- Confirmed. No ICE if bar10 has fixed character length, e.g. character(42) :: bar10
[Bug gcov-profile/107537] gcov skips throw/fallthrough annotations for 'never executed' branches
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107537 --- Comment #2 from michael.foerderer at gmx dot de --- Created attachment 54009 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54009&action=edit Patch for annotation of uncovered branches
[Bug sanitizer/107963] Support __attribute__((disable_sanitizer_instrumentation))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107963 Sam James changed: What|Removed |Added CC||sam at gentoo dot org --- Comment #2 from Sam James --- (In reply to Andrew Pinski from comment #1) > https://gcc.gnu.org/pipermail/gcc/2021-November/237787.html > > If I read this correctly, there is no reason for a new attribute for gcc. Sounds like a possible documentation issue then.
[Bug sanitizer/78204] ‘no_sanitize’ attribute directive ignored [-Wattributes]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78204
Fangrui Song changed:
What|Removed |Added
CC||i at maskray dot me
--- Comment #8 from Fangrui Song ---
Note: Clang supports
__attribute__((no_sanitize("address","undefined")))
but not
__attribute__((no_sanitize("address,undefined")))
Possibly reject `__attribute__((no_sanitize("address,undefined")))` as well to
prevent users from writing non-portable code.
[Bug sanitizer/78204] ‘no_sanitize’ attribute directive ignored [-Wattributes]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78204
--- Comment #9 from Andrew Pinski ---
(In reply to Fangrui Song from comment #8)
> Note: Clang supports
> __attribute__((no_sanitize("address","undefined")))
> but not
> __attribute__((no_sanitize("address,undefined")))
>
> Possibly reject `__attribute__((no_sanitize("address,undefined")))` as well
> to prevent users from writing non-portable code.
We document both ways already.
https://gcc.gnu.org/onlinedocs/gcc-12.2.0/gcc/Common-Function-Attributes.html#index-no_005fsanitize-function-attribute
I would have said if we don't document both ways we should reject it but since
it is documented already, maybe add to the documentation that clang does not
accept the combined string way.
[Bug sanitizer/107963] Support __attribute__((disable_sanitizer_instrumentation))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107963
--- Comment #3 from Fangrui Song ---
GCC doesn't implement -fsanitize=memory.
In the absence of it, __attribute__((disable_sanitizer_instrumentation)) is
like __attribute__((no_sanitize("all"))).
When -fsanitize=memory is implemented, the two attribute will be different.
[Bug sanitizer/107963] Support __attribute__((disable_sanitizer_instrumentation))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107963
--- Comment #4 from Andrew Pinski ---
(In reply to Fangrui Song from comment #3)
> GCC doesn't implement -fsanitize=memory.
> In the absence of it, __attribute__((disable_sanitizer_instrumentation)) is
> like __attribute__((no_sanitize("all"))).
>
> When -fsanitize=memory is implemented, the two attribute will be different.
Why do you think GCC will implement no_sanitize that way. It already didn't
implement no_sanitize that way for -fsanitize=thread too.
[Bug c/107967] New: The gcc commit 2f7f9edd28d caused the glibc make check fails.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107967 Bug ID: 107967 Summary: The gcc commit 2f7f9edd28d caused the glibc make check fails. Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: caiyinyu at loongson dot cn Target Milestone: --- The gcc commit 2f7f9edd28d caused the following glibc fails with glibc configuration on x86: ../configure \ CFLAGS="-O2 -g" CXXFLAGS="-O2 -g" \ --prefix=/usr \ --disable-werror But when we changed "-O2" to "-O1", these fails passed. FAIL: math/test-double-cosh FAIL: math/test-double-exp10 FAIL: math/test-double-expm1 FAIL: math/test-double-tgamma FAIL: math/test-float128-cosh FAIL: math/test-float128-exp10 FAIL: math/test-float128-lgamma FAIL: math/test-float128-pow FAIL: math/test-float128-tgamma FAIL: math/test-float32-cosh FAIL: math/test-float32-expm1 FAIL: math/test-float32-tgamma FAIL: math/test-float32x-cosh FAIL: math/test-float32x-exp10 FAIL: math/test-float32x-expm1 FAIL: math/test-float32x-tgamma FAIL: math/test-float64-cosh FAIL: math/test-float64-exp10 FAIL: math/test-float64-expm1 FAIL: math/test-float64-tgamma FAIL: math/test-float64x-cosh FAIL: math/test-float64x-tgamma FAIL: math/test-float-cosh FAIL: math/test-float-expm1 FAIL: math/test-float-tgamma FAIL: math/test-ldouble-cosh FAIL: math/test-ldouble-tgamma
[Bug analyzer/107943] [11/12/13 Regression] gcc -fanalyzer hangs in openssl curve25519.c since r11-3840-gaf66094d03779377
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107943 --- Comment #6 from Bernd Edlinger --- I don't know if that is relevant or not, but I was using a slighthly different criterion in bisection. I used .../configure --prefix=... --enable-languages=all and defined the bad criterion using the unreduced test case compilation took >10 minutes on Intel(R) Core(TM) i7-7700 CPU @ 3.60GHz The original test case is available as follows: $ wget https://www.openssl.org/source/openssl-1.1.1s.tar.gz $ tar xf openssl-1.1.1s.tar.gz $ ./config -fanalyzer $ make With this pointed to a different commit: r12-7615-gc5288df751f Author: Roger Sayle Date: Fri Mar 11 17:46:50 2022 + PR tree-optimization/98335: Improvements to DSE's compute_trims. This patch is the main middle-end piece of a fix for PR tree-opt/98335, which is a code-quality regression affecting mainline. The issue occurs in DSE's (dead store elimination's) compute_trims function that determines where a store to memory can be trimmed. In the testcase given in the PR, this function notices that the first byte of a DImode store is dead, and replaces the 8-byte store at (aligned) offset zero, with a 7-byte store at (unaligned) offset one. Most architectures can store a power-of-two bytes (up to a maximum) in single instruction, so writing 7 bytes requires more instructions than writing 8 bytes. This patch follows Jakub Jelinek's suggestion in comment 5, that compute_trims needs improved heuristics. beginning with this version the original test case, enters a steady state after 2 minutes (observed with top: VIRT=196296 RES=170872 SHR=21992 %CPU=100,0) and has no progress for at least 20 hours, before I killed it. The reduced test case does not exhibit this behaviour, and runs just for some seconds. But I agree that the r11-3840-gaf66094d03779377 is also special and made the compile time raise from 0 to 2-10 minutes, however I would not have opened this issue for that, since I was believing there is something expensive to check that just did not give a result in the end.
[Bug tree-optimization/107412] Miss to fold LEN_{LOAD,STORE} when the specified length equal to vector length
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107412
--- Comment #6 from CVS Commits ---
The master branch has been updated by Kewen Lin :
https://gcc.gnu.org/g:380d62c14c99d8df13b7a86660e7ee67d01ad827
commit r13-4488-g380d62c14c99d8df13b7a86660e7ee67d01ad827
Author: Kewen Lin
Date: Sun Dec 4 23:27:08 2022 -0600
gimple-fold: Refine gimple_fold_partial_load_store_mem_ref [PR107412]
Following Richard's review comments, this patch is to use
untruncated type for the length used for IFN_LEN_{LOAD,STORE}
instead of "unsigned int" for better robustness. It also
avoid to use to_constant and tree arithmetic for subtraction.
Co-authored-by: Richard Sandiford
PR tree-optimization/107412
gcc/ChangeLog:
* gimple-fold.cc (gimple_fold_partial_load_store_mem_ref): Use
untruncated type for the length, and avoid to_constant and tree
arithmetic for subtraction.
[Bug fortran/107968] New: array slicing gives wrong result for an array pointer defined in a subroutine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107968 Bug ID: 107968 Summary: array slicing gives wrong result for an array pointer defined in a subroutine Product: gcc Version: 12.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: dreier at dkrz dot de Target Milestone: --- Created attachment 54010 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54010&action=edit source code The following code show some weird behavior to me: ``` PROGRAM foo implicit none TYPE t_geographical_coordinates REAL :: lon REAL :: lat END TYPE t_geographical_coordinates TYPE t_vertices REAL, POINTER :: vlon(:) => null() REAL, POINTER :: vlat(:) => null() END TYPE t_vertices TYPE(t_vertices), POINTER :: vertices_pointer TYPE(t_vertices), TARGET :: vertices_target TYPE(t_geographical_coordinates), ALLOCATABLE, TARGET :: vertex(:) ! initialization ALLOCATE(vertex(2)) vertex%lon = 1 vertex%lat = 2 ! obtain pointer to (non-contiguous) field vertices_target%vlon => vertex%lon ! set pointer in a subroutine CALL set_vertices_pointer(vertices_target) WRITE (0,*) vertices_pointer%vlon WRITE (0,*) vertices_pointer%vlon(1:) ! It seems that setting the pointer in a subroutine does something else than ! setting it directly. Furthermore uncommenting the following line fixes the ! issue but changes the output of the lines above ?! ! vertices_pointer => vertices_target CONTAINS SUBROUTINE set_vertices_pointer(vertices) TYPE(t_vertices), POINTER, INTENT(IN) :: vertices vertices_pointer => vertices END SUBROUTINE set_vertices_pointer END PROGRAM foo ``` I expect the output to be: ``` 1. 1. 1. 1. ``` Instead, the compiled program gives me ``` 1. 1. 1. 2. ``` Compiled with gfortran 12.2 on Ubuntu 22.10. No warnings with `-Wall -Wextra`. Same behavior with `-fno-strict-aliasing -fwrapv`.
