[Bug libstdc++/93687] Add mcf thread model to GCC on windows for supporting C++11 std::thread?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93687 Evgeniy changed: What|Removed |Added CC||xtemp09 at gmail dot com --- Comment #3 from Evgeniy --- Another lite approach: https://github.com/meganz/mingw-std-threads
[Bug pch/91440] Precompiled headers don't work with ASLR on mingw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91440 Andrew Pinski changed: What|Removed |Added CC||malashkin.andrey at gmail dot com --- Comment #9 from Andrew Pinski --- *** Bug 105199 has been marked as a duplicate of this bug. ***
[Bug c++/105199] can't compile glslang on windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105199 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #2 from Andrew Pinski --- Fixed on the trunk for GCC 12 as PCH are now relocatable. *** This bug has been marked as a duplicate of bug 91440 ***
[Bug preprocessor/59782] libcpp does not avoid bug #48326 when compiled by older GCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59782 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #8 from Andrew Pinski --- This is a won't fix as GCC 12+ requires GCC 4.8.0+ to build which has the fix.
[Bug preprocessor/105207] Translation phase 2: splicing physical source lines to form logical source lines may not work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105207 --- Comment #3 from Andrew Pinski --- Note this only matters if you preprocessing the file yourself; that is -save-temps works correctly and errors out that there is a stray '#' in program.
gcc-11-20220409 is now available
Snapshot gcc-11-20220409 is now available on https://gcc.gnu.org/pub/gcc/snapshots/11-20220409/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 11 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch releases/gcc-11 revision b242eb2084d62b2707b93322dae2dbbffb6e1eb6 You'll find: gcc-11-20220409.tar.xz Complete GCC SHA256=97f3179a4a18f9df80075423cce3e807d009c14b797062c13031c520b3c451e6 SHA1=f52c070c651fd27ef8e948d773dd1e97ad93c742 Diffs from 11-20220402 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-11 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
[Bug analyzer/103892] -Wanalyzer-double-free false positive when compiling libpipeline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103892 David Malcolm changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from David Malcolm --- Should be fixed by the above patch on trunk for GCC 12. Backporting the fix to GCC 11 is probably not feasible. Marking as resolved. Thanks again for filing this bug.
[Bug c/105207] Translation phase 2: splicing physical source lines to form logical source lines may not work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105207 Pavel M changed: What|Removed |Added Summary|C preprocessor: splicing|Translation phase 2: |physical source lines to|splicing physical source |form logical source lines |lines to form logical |may not work|source lines may not work --- Comment #2 from Pavel M --- Actually the issue is not related to the preprocessor. It is relayed to the translation phase 2. Please
[committed] analyzer: fix folding of regions involving unknown ptrs [PR103892]
PR analyzer/103892 reports a false positive from -Wanalyzer-double-free.
The root cause is the analyzer failing to properly handle "unknown"
symbolic regions, and thus confusing two different expressions.
Specifically, the analyzer eventually hits the complexity limit for
symbolic values, and starts using an "unknown" svalue for a pointer.
The analyzer uses
symbolic_region(unknown_svalue([of ptr type]))
i.e.
(*UNKNOWN_PTR)
in a few places to mean "we have an lvalue, but we're not going to
attempt to track what it is anymore".
"Unknown" should probably be renamed to "unknowable"; in theory, any
operation on such an unknown svalue should be also an unknown svalue.
The issue is that in various places where we create child regions, we
were failing to check for the parent region being (*UNKNOWN_PTR), and so
were erroneously creating regions based on (*UNKNOWN_PTR), such as
*(UNKNOWN_PTR + OFFSET). The state-machine handling was erroneously
allowing e.g. INITIAL_VALUE (*(UNKNOWN_PTR + OFFSET)) to have state,
and thus we could record that such a value had had "free" called on it,
and thus eventually false report a double-free when a different
expression incorrectly "simplified" to the same expression.
This patch fixes things by checking when creating the various kinds of
child region for (*UNKNOWN_PTR) as the parent region, and simply
returning another (*UNKNOWN_PTR) for such child regions (using the
appropriate type).
Doing so fixes the false positive, and also fixes a state explosion on
this testcase, as the states at the program points more rapidly reach
a fixed point where everything is unknown. I checked for other cases
that no longer needed -Wno-analyzer-too-complex; the only other one
seems to be gcc.dg/analyzer/pr96841.c, but that seems to already have
become redundant at some point before this patch.
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r12-8071-g3d41408c5d2810.
gcc/analyzer/ChangeLog:
PR analyzer/103892
* region-model-manager.cc
(region_model_manager::get_unknown_symbolic_region): New,
extracted from...
(region_model_manager::get_field_region): ...here.
(region_model_manager::get_element_region): Use it here.
(region_model_manager::get_offset_region): Likewise.
(region_model_manager::get_sized_region): Likewise.
(region_model_manager::get_cast_region): Likewise.
(region_model_manager::get_bit_range): Likewise.
* region-model.h
(region_model_manager::get_unknown_symbolic_region): New decl.
* region.cc (symbolic_region::symbolic_region): Handle sval_ptr
having NULL type.
(symbolic_region::dump_to_pp): Handle having NULL type.
gcc/testsuite/ChangeLog:
PR analyzer/103892
* gcc.dg/analyzer/pr103892.c: New test.
* gcc.dg/analyzer/pr96841.c: Drop redundant
-Wno-analyzer-too-complex.
Signed-off-by: David Malcolm
---
gcc/analyzer/region-model-manager.cc | 37 ++--
gcc/analyzer/region-model.h | 2 +
gcc/analyzer/region.cc | 11 +++-
gcc/testsuite/gcc.dg/analyzer/pr103892.c | 75
gcc/testsuite/gcc.dg/analyzer/pr96841.c | 2 +-
5 files changed, 117 insertions(+), 10 deletions(-)
create mode 100644 gcc/testsuite/gcc.dg/analyzer/pr103892.c
diff --git a/gcc/analyzer/region-model-manager.cc
b/gcc/analyzer/region-model-manager.cc
index 56d60768749..4ec275ecd43 100644
--- a/gcc/analyzer/region-model-manager.cc
+++ b/gcc/analyzer/region-model-manager.cc
@@ -1362,6 +1362,19 @@ region_model_manager::get_region_for_global (tree expr)
return reg;
}
+/* Return the region for an unknown access of type REGION_TYPE,
+ creating it if necessary.
+ This is a symbolic_region, where the pointer is an unknown_svalue
+ of type _TYPE. */
+
+const region *
+region_model_manager::get_unknown_symbolic_region (tree region_type)
+{
+ tree ptr_type = region_type ? build_pointer_type (region_type) : NULL_TREE;
+ const svalue *unknown_ptr = get_or_create_unknown_svalue (ptr_type);
+ return get_symbolic_region (unknown_ptr);
+}
+
/* Return the region that describes accessing field FIELD of PARENT,
creating it if necessary. */
@@ -1372,12 +1385,7 @@ region_model_manager::get_field_region (const region
*parent, tree field)
/* (*UNKNOWN_PTR).field is (*UNKNOWN_PTR_OF__TYPE). */
if (parent->symbolic_for_unknown_ptr_p ())
-{
- tree ptr_to_field_type = build_pointer_type (TREE_TYPE (field));
- const svalue *unknown_ptr_to_field
- = get_or_create_unknown_svalue (ptr_to_field_type);
- return get_symbolic_region (unknown_ptr_to_field);
-}
+return get_unknown_symbolic_region (TREE_TYPE (field));
field_region::key_t key (parent, field);
if (field_region *reg = m_field_regions.get (key))
@@ -1397,6 +1405,10 @@ region_model_manager::get_element_region (const region
*parent,
[Bug analyzer/103892] -Wanalyzer-double-free false positive when compiling libpipeline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103892 --- Comment #3 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:3d41408c5d28105e7a3ea2eb2529431a70b96369 commit r12-8071-g3d41408c5d28105e7a3ea2eb2529431a70b96369 Author: David Malcolm Date: Sat Apr 9 18:12:57 2022 -0400 analyzer: fix folding of regions involving unknown ptrs [PR103892] PR analyzer/103892 reports a false positive from -Wanalyzer-double-free. The root cause is the analyzer failing to properly handle "unknown" symbolic regions, and thus confusing two different expressions. Specifically, the analyzer eventually hits the complexity limit for symbolic values, and starts using an "unknown" svalue for a pointer. The analyzer uses symbolic_region(unknown_svalue([of ptr type])) i.e. (*UNKNOWN_PTR) in a few places to mean "we have an lvalue, but we're not going to attempt to track what it is anymore". "Unknown" should probably be renamed to "unknowable"; in theory, any operation on such an unknown svalue should be also an unknown svalue. The issue is that in various places where we create child regions, we were failing to check for the parent region being (*UNKNOWN_PTR), and so were erroneously creating regions based on (*UNKNOWN_PTR), such as *(UNKNOWN_PTR + OFFSET). The state-machine handling was erroneously allowing e.g. INITIAL_VALUE (*(UNKNOWN_PTR + OFFSET)) to have state, and thus we could record that such a value had had "free" called on it, and thus eventually false report a double-free when a different expression incorrectly "simplified" to the same expression. This patch fixes things by checking when creating the various kinds of child region for (*UNKNOWN_PTR) as the parent region, and simply returning another (*UNKNOWN_PTR) for such child regions (using the appropriate type). Doing so fixes the false positive, and also fixes a state explosion on this testcase, as the states at the program points more rapidly reach a fixed point where everything is unknown. I checked for other cases that no longer needed -Wno-analyzer-too-complex; the only other one seems to be gcc.dg/analyzer/pr96841.c, but that seems to already have become redundant at some point before this patch. gcc/analyzer/ChangeLog: PR analyzer/103892 * region-model-manager.cc (region_model_manager::get_unknown_symbolic_region): New, extracted from... (region_model_manager::get_field_region): ...here. (region_model_manager::get_element_region): Use it here. (region_model_manager::get_offset_region): Likewise. (region_model_manager::get_sized_region): Likewise. (region_model_manager::get_cast_region): Likewise. (region_model_manager::get_bit_range): Likewise. * region-model.h (region_model_manager::get_unknown_symbolic_region): New decl. * region.cc (symbolic_region::symbolic_region): Handle sval_ptr having NULL type. (symbolic_region::dump_to_pp): Handle having NULL type. gcc/testsuite/ChangeLog: PR analyzer/103892 * gcc.dg/analyzer/pr103892.c: New test. * gcc.dg/analyzer/pr96841.c: Drop redundant -Wno-analyzer-too-complex. Signed-off-by: David Malcolm
[Bug c/105207] C preprocessor: splicing physical source lines to form logical source lines may not work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105207 --- Comment #1 from Pavel M --- The same behavior with: xxx \ error Expected: xxx error Actual: xxx error
[Bug c/105207] New: C preprocessor: splicing physical source lines to form logical source lines may not work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105207 Bug ID: 105207 Summary: C preprocessor: splicing physical source lines to form logical source lines may not work Product: gcc Version: 11.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: pavel.morozkin at gmail dot com Target Milestone: --- Sample code: xxx \ #error Invocation: $ gcc t6.c -E Actual output: xxx #error Expected output: xxx #error
Re: [PATCH] c-family: Initialize ridpointers for __int128 etc. [PR105186]
On Fri, Apr 08, 2022 at 09:29:52AM +0200, Jakub Jelinek wrote:
> Hi!
>
> The following testcase ICEs with C++ and is incorrectly rejected with C.
> The reason is that both FEs use ridpointers identifiers for CPP_KEYWORD
> and value or u.value for CPP_NAME e.g. when parsing attributes or OpenMP
> directives etc., like:
> /* Save away the identifier that indicates which attribute
> this is. */
> identifier = (token->type == CPP_KEYWORD)
>/* For keywords, use the canonical spelling, not the
> parsed identifier. */
>? ridpointers[(int) token->keyword]
>: id_token->u.value;
>
> identifier = canonicalize_attr_name (identifier);
> I've tried to change those to use ridpointers only if non-NULL and otherwise
> use the value/u.value even for CPP_KEYWORDS, but that was a large 10 hunks
> patch.
>
> The following patch instead just initializes ridpointers for the __intNN
> keywords. It can't be done earlier before we record_builtin_type as there
> are 2 different spellings and if we initialize those ridpointers early, the
> second record_builtin_type fails miserably.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
>
> 2022-04-08 Jakub Jelinek
>
> PR c++/105186
> * c-common.cc (c_common_nodes_and_builtins): After registering __int%d
> and __int%d__ builtin types, initialize corresponding ridpointers
> entry.
>
> * c-c++-common/pr105186.c: New test.
>
> --- gcc/c-family/c-common.cc.jj 2022-04-07 17:18:14.378883472 +0200
> +++ gcc/c-family/c-common.cc 2022-04-07 17:21:07.950463695 +0200
> @@ -4278,6 +4278,8 @@ c_common_nodes_and_builtins (void)
>sprintf (name, "__int%d__", int_n_data[i].bitsize);
>record_builtin_type ((enum rid)(RID_FIRST_INT_N + i), name,
> int_n_trees[i].signed_type);
> + ridpointers[RID_FIRST_INT_N + i]
> + = DECL_NAME (TYPE_NAME (int_n_trees[i].signed_type));
So this also covers the range for the unsigned variants of these types.
I think the patch is OK, thanks.
>sprintf (name, "__int%d unsigned", int_n_data[i].bitsize);
>record_builtin_type (RID_MAX, name, int_n_trees[i].unsigned_type);
> --- gcc/testsuite/c-c++-common/pr105186.c.jj 2022-04-07 17:25:32.084781386
> +0200
> +++ gcc/testsuite/c-c++-common/pr105186.c 2022-04-07 17:25:13.736037189
> +0200
> @@ -0,0 +1,5 @@
> +/* PR c++/105186 */
> +/* { dg-do compile } */
> +
> +__attribute__((__int128)) int i; /* { dg-warning "'__int128' attribute
> directive ignored" } */
> +__attribute__((__int128__)) int j; /* { dg-warning "'__int128' attribute
> directive ignored" } */
Marek
[Bug tree-optimization/103680] Jump threading and switch corrupts profile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103680 --- Comment #5 from Jan Hubicka --- The cfgcleanup logic is consistent assuming that your profile was consistent on the input (i.e. read from profile feedback). If you 1) read profile 2) do optimization and prove that given if conditional is true then you should also have 100% probability on the "true" edge so doing nothing in cfgcleanup is correct. Now of course what can happen is that you guess profile or 1) read profile 2) duplicate code 3) prove if conditonal always true in one of the copy. In this case fixing up profile locally is not possible (since it is also wrong in the other copy), so we opt doing nothing which keeps errors sort of contained and we need to live that profile is somethimes inconsistent. So cfgcleanup behaviour is by design. However if you do threading there is way to update the profile and logic for that iis n update_bb_profile_for_threading. If guessed profile was consistent with the thread, it will update profile well and it will drop message to a dump file otherwise. Now the problem is that each time profiling code is updated the interface to this function is lost. I tried to get it fixed but got lost in the new code. /* An edge originally destinating BB of COUNT has been proved to leave the block by TAKEN_EDGE. Update profile of BB such that edge E can be redirected to destination of TAKEN_EDGE. This function may leave the profile inconsistent in the case TAKEN_EDGE frequency or count is believed to be lower than COUNT respectively. */ void update_bb_profile_for_threading (basic_block bb, profile_count count, edge taken_edge) So the interface is quite simple. I have to re-read the new updating code since I no longer recall where I got lost, but perhaps if you are familiar with it, you can write in the update?
[Bug ipa/103819] [10/11/12 Regression] ICE in redirect_callee, at cgraph.c:1389 with __attribute__((flatten)) and -O2 since r11-7940-ge7fd3b783238d034
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103819 Jan Hubicka changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #4 from Jan Hubicka --- mine.
[Bug ipa/103378] [12 Regression] ICE: verify_cgraph_node failed (error: semantic interposition mismatch) since r12-5412-g458d2c689963d846
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103378 Jan Hubicka changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Jan Hubicka --- Fixed by r:4943b75e9f06f0b64ed541430bb7fbccf55fc552 Sorry for wrong PR marker :( I should have cut
[Bug ipa/103818] [12 Regression] ICE: in insert, at ipa-modref-tree.c:591 since r12-3202-gf5ff3a8ed4ca9173
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103818 --- Comment #4 from Jan Hubicka --- We have access list: Base 0: alias set 2 Ref 0: alias set 1 access: Parm 0 param offset:0 offset:-4611686018427387936 size:32 max_size:32 access: Parm 0 param offset:0 offset:352 size:32 max_size:32 access: Parm 0 param offset:0 offset:64 size:32 max_size:32 access: Parm 0 param offset:0 offset:0 size:32 max_size:32 access: Parm 0 param offset:0 offset:32800 size:32 max_size:32 access: Parm 0 param offset:0 offset:160 size:32 max_size:32 access: Parm 0 param offset:0 offset:4629700416936869888 size:32 max_size:32 access: Parm 0 param offset:0 offset:-96 size:32 max_size:32 access: Parm 0 param offset:0 offset:1376 size:32 max_size:32 access: Parm 0 param offset:0 offset:224 size:32 max_size:32 access: Parm 0 param offset:0 offset:-288 size:32 max_size:32 access: Parm 0 param offset:0 offset:448 size:32 max_size:32 access: Parm 0 param offset:0 offset:288 size:32 max_size:32 access: Parm 0 param offset:0 offset:1568 size:32 max_size:32 access: Parm 0 param offset:0 offset:640 size:32 max_size:32 access: Parm 0 param offset:0 offset:2624 size:32 max_size:32 and we want to merge Parm 0 param offset:0 offset:-4611686018427387936 size:32 max_size:32 and Parm 0 param offset:0 offset:4629700416936869888 size:32 max_size:32 into one entry since we think they have small difference. So an overflow issue: new_max_size = max_size2 + offset2 - offset1; if (known_le (new_max_size, max_size1)) new_max_size = max_size1; So we need 128bit math here. I need to look into proper way to get this right (and corresponding overflow that makes the lgoic to choose these two entries as closest to each other.
[Bug middle-end/105206] mis-optimization with -ffast-math and __builtin_powf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105206
kargl at gcc dot gnu.org changed:
What|Removed |Added
Severity|normal |minor
--- Comment #1 from kargl at gcc dot gnu.org ---
Not sure if anyone cares. I don't use -ffast-math, but this might considered a
mis-optimization with that option.
#include
float
foof(float x)
{
return (powf(10.f,x));
}
double
food(double x)
{
return (pow(10.,x));
}
-fdump-tree-original shows
;; Function foof (null)
;; enabled by -tree-original
{
return powf (1.0e+1, x);
}
;; Function food (null)
;; enabled by -tree-original
{
return pow (1.0e+1, x);
}
Compiling to assembly shows
foof:
.LFB3:
.cfi_startproc
movaps %xmm0, %xmm1
movss .LC0(%rip), %xmm0
jmp powf
.cfi_endproc
food:
.LFB4:
.cfi_startproc
mulsd .LC1(%rip), %xmm0
jmp exp
.cfi_endproc
So, the middle-end is converting pow(10.x) to exp(x*log(10.0)) where log(10.0)
is reduced, but the same transformation of powf(10.f,x) still yields a call to
powf.
[Bug middle-end/105206] New: mis-optimization with -ffast-math and __builtin_powf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105206 Bug ID: 105206 Summary: mis-optimization with -ffast-math and __builtin_powf Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: kargl at gcc dot gnu.org Target Milestone: ---
Fix ICE with -fno-semantic-interposition added via option attribut
Hi,
This patch solves problem with FE first finalizing function and then adding
-fno-semantic-interposition flag (by parsing optimization attribute).
Bootstrapped/regtested x86_64-linux, comitted.
Honza
gcc/ChangeLog:
2022-04-09 Jan Hubicka
PR ipa/103376
* cgraphunit.cc (cgraph_node::analyze): update semantic_interposition
flag.
gcc/testsuite/ChangeLog:
2022-04-09 Jan Hubicka
PR ipa/103376
* gcc.c-torture/compile/pr103376.c: New test.
diff --git a/gcc/cgraphunit.cc b/gcc/cgraphunit.cc
index 01f4e28204e..bc3dc754481 100644
--- a/gcc/cgraphunit.cc
+++ b/gcc/cgraphunit.cc
@@ -621,6 +621,7 @@ cgraph_node::analyze (void)
tree decl = this->decl;
location_t saved_loc = input_location;
input_location = DECL_SOURCE_LOCATION (decl);
+ semantic_interposition = opt_for_fn (decl, flag_semantic_interposition);
if (thunk)
{
diff --git a/gcc/testsuite/gcc.c-torture/compile/pr103376.c
b/gcc/testsuite/gcc.c-torture/compile/pr103376.c
new file mode 100644
index 000..8c14c3ded38
--- /dev/null
+++ b/gcc/testsuite/gcc.c-torture/compile/pr103376.c
@@ -0,0 +1,9 @@
+/* { dg-additional-options "-Ofast" } */
+__attribute__ ((optimize ("no-associative-math"))) double
+fn3 (double h, double l)
+{
+ return h + l;
+}
+
+double fn3 (double, double) __attribute__ ((optimize
("O2,no-associative-math")));
+
[Bug tree-optimization/103376] [12 Regression] wrong code at -Os and above on x86_64-linux-gnu since r12-5453-ga944b5dec3adb28e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103376 --- Comment #12 from CVS Commits --- The master branch has been updated by Jan Hubicka : https://gcc.gnu.org/g:4943b75e9f06f0b64ed541430bb7fbccf55fc552 commit r12-8070-g4943b75e9f06f0b64ed541430bb7fbccf55fc552 Author: Jan Hubicka Date: Sat Apr 9 21:22:58 2022 +0200 Update semantic_interposition flag at analysis time This patch solves problem with FE first finalizing function and then adding -fno-semantic-interposition flag (by parsing optimization attribute). gcc/ChangeLog: 2022-04-09 Jan Hubicka PR ipa/103376 * cgraphunit.cc (cgraph_node::analyze): update semantic_interposition flag. gcc/testsuite/ChangeLog: 2022-04-09 Jan Hubicka PR ipa/103376 * gcc.c-torture/compile/pr103376.c: New test.
[Bug fortran/105205] New: Incorrect assignment of derived type with allocatable, deferred-length character component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105205 Bug ID: 105205 Summary: Incorrect assignment of derived type with allocatable, deferred-length character component Product: gcc Version: 11.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: townsend at astro dot wisc.edu Target Milestone: --- I've run into problems with assignment of derived types containing an allocatable array of deferred-length strings. Example program: --- program alloc_char_type implicit none type mytype character(:), allocatable :: c(:) end type mytype type(mytype) :: a type(mytype) :: b integer :: i a%c = ['foo','bar','biz','buz'] b = a do i = 1, size(b%c) print *,b%c(i) end do end --- Running with gfortran 10.2.0 or 11.2.0, I get the output: >> foo << If I hard-code the length of the c component (to, say, 3), I get the expected output: >> foo bar biz buz << It seems as if only the first element of c is being copied correctly. cheers, Rich
[Bug ipa/105160] [12 regression] ipa modref marks functions with asm volatile as const or pure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105160 Jan Hubicka changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #10 from Jan Hubicka --- Fixed by r:aabb9a261ef060cf24fd626713f1d7d9df81aa57
Fix nondeterministic and side_effect propagation in ipa-modref
Hi,
this patch adds logic to propagate nondeterministic and side_effects
bits in modref when summary is updated after inlining.
Bootstrapped/regtested x86_64-linux, comitted.
gcc/ChangeLog:
2022-04-09 Jan Hubicka
* ipa-modref.cc (ipa_merge_modref_summary_after_inlining): Propagate
nondeterministic and side_effects flags.
gcc/testsuite/ChangeLog:
2022-04-09 Jan Hubicka
* gcc.dg/ipa/pr105160.c: New test.
diff --git a/gcc/ipa-modref.cc b/gcc/ipa-modref.cc
index acfd7d80ff8..556816ab429 100644
--- a/gcc/ipa-modref.cc
+++ b/gcc/ipa-modref.cc
@@ -5281,6 +5281,29 @@ ipa_merge_modref_summary_after_inlining (cgraph_edge
*edge)
if (!ignore_stores)
to_info_lto->stores->collapse ();
}
+ /* Merge side effects and non-determinism.
+ PURE/CONST flags makes functions deterministic and if there is
+ no LOOPING_CONST_OR_PURE they also have no side effects. */
+ if (!(flags & (ECF_CONST | ECF_NOVOPS | ECF_PURE))
+ || (flags & ECF_LOOPING_CONST_OR_PURE))
+{
+ if (to_info)
+ {
+ if (!callee_info || callee_info->side_effects)
+ to_info->side_effects = true;
+ if ((!callee_info || callee_info->nondeterministic)
+ && !ignore_nondeterminism_p (edge->caller->decl, flags))
+ to_info->nondeterministic = true;
+ }
+ if (to_info_lto)
+ {
+ if (!callee_info_lto || callee_info_lto->side_effects)
+ to_info_lto->side_effects = true;
+ if ((!callee_info_lto || callee_info_lto->nondeterministic)
+ && !ignore_nondeterminism_p (edge->caller->decl, flags))
+ to_info_lto->nondeterministic = true;
+ }
+ }
if (callee_info || callee_info_lto)
{
auto_vec parm_map;
diff --git a/gcc/testsuite/gcc.dg/ipa/pr105160.c
b/gcc/testsuite/gcc.dg/ipa/pr105160.c
new file mode 100644
index 000..ea80545b102
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/ipa/pr105160.c
@@ -0,0 +1,77 @@
+/* { dg-do compile } */
+/* { dg-options "-O -fdump-ipa-modref" } */
+#define sysreg_read(regname) \
+({ \
+ unsigned long __sr_val; \
+ asm volatile(""); \
+ \
+ __sr_val; \
+})
+
+#define sysreg_write(regname, __sw_val)\
+do { \
+ asm volatile(""); \
+} while (0)
+
+#define isb() \
+do { \
+ asm volatile( \
+ "isb" \
+ : \
+ : \
+ : "memory");\
+} while (0)
+
+static unsigned long sctlr_read(void)
+{
+ return sysreg_read(sctlr_el1);
+}
+
+static void sctlr_write(unsigned long val)
+{
+ sysreg_write(sctlr_el1, val);
+}
+
+static void sctlr_rmw(void)
+{
+ unsigned long val;
+
+ val = sctlr_read();
+ val |= 1UL << 7;
+ sctlr_write(val);
+}
+
+void sctlr_read_multiple(void)
+{
+ sctlr_read();
+ sctlr_read();
+ sctlr_read();
+ sctlr_read();
+}
+
+void sctlr_write_multiple(void)
+{
+ sctlr_write(0);
+ sctlr_write(0);
+ sctlr_write(0);
+ sctlr_write(0);
+ sctlr_write(0);
+}
+
+void sctlr_rmw_multiple(void)
+{
+ sctlr_rmw();
+ sctlr_rmw();
+ sctlr_rmw();
+ sctlr_rmw();
+}
+
+void function(void)
+{
+ sctlr_read_multiple();
+ sctlr_write_multiple();
+ sctlr_rmw_multiple();
+
+ isb();
+}
+/* { dg-final { scan-ipa-dump-not "Function found to be const" "modref" } } */
Re: [PATCH] libgccjit: Add support for bitcasts [PR104071]
Here's the updated patch.
On Fri, 2022-04-08 at 15:22 -0400, David Malcolm wrote:
> On Fri, 2022-01-21 at 18:41 -0500, Antoni Boucher wrote:
> > Hi.
> > Here's the updated patch.
> >
>
> Thanks. Review below:
>
> [...snip...]
>
> > diff --git a/gcc/jit/libgccjit.cc b/gcc/jit/libgccjit.cc
> > index 4c352e8c93d..6bf1e1ceee0 100644
> > --- a/gcc/jit/libgccjit.cc
> > +++ b/gcc/jit/libgccjit.cc
> > @@ -2405,6 +2405,34 @@ gcc_jit_context_new_cast (gcc_jit_context
> > *ctxt,
> > return static_cast (ctxt->new_cast (loc,
> > rvalue, type));
> > }
> >
> > +/* Public entrypoint. See description in libgccjit.h.
> > +
> > + After error-checking, the real work is done by the
> > + gcc::jit::recording::context::new_bitcast method in jit-
> > recording.c. */
> > +
> > +gcc_jit_rvalue *
> > +gcc_jit_context_new_bitcast (gcc_jit_context *ctxt,
> > + gcc_jit_location *loc,
> > + gcc_jit_rvalue *rvalue,
> > + gcc_jit_type *type)
> > +{
> > + RETURN_NULL_IF_FAIL (ctxt, NULL, loc, "NULL context");
> > + JIT_LOG_FUNC (ctxt->get_logger ());
> > + /* LOC can be NULL. */
> > + RETURN_NULL_IF_FAIL (rvalue, ctxt, loc, "NULL rvalue");
> > + RETURN_NULL_IF_FAIL (type, ctxt, loc, "NULL type");
> > + // TODO: check the sizes.
> > + /*RETURN_NULL_IF_FAIL_PRINTF3 (
> > + is_valid_cast (rvalue->get_type (), type),
> > + ctxt, loc,
> > + "cannot cast %s from type: %s to type: %s",
> > + rvalue->get_debug_string (),
> > + rvalue->get_type ()->get_debug_string (),
> > + type->get_debug_string ());*/
>
> I think we agreed that we can't check the sizes at this point, so
> this
> commented-out check would be better replaced with a comment
> explaining
> that we have to defer the check to playback time, when we have the
> trees.
>
> > +
> > + return static_cast (ctxt->new_bitcast (loc,
> > rvalue, type));
> > +}
> > +
> > /* Public entrypoint. See description in libgccjit.h.
> >
> > After error-checking, the real work is done by the
>
> [...snip...]
>
> > diff --git a/gcc/testsuite/jit.dg/test-bitcast.c
> > b/gcc/testsuite/jit.dg/test-bitcast.c
> > new file mode 100644
> > index 000..a092fa117e6
> > --- /dev/null
> > +++ b/gcc/testsuite/jit.dg/test-bitcast.c
> > @@ -0,0 +1,60 @@
> > +#include
> > +#include
> > +#include
> > +
> > +#include "libgccjit.h"
> > +
> > +#include "harness.h"
> > +
> > +void
> > +create_code (gcc_jit_context *ctxt, void *user_data)
> > +{
> > + /* Let's try to inject the equivalent of:
> > +int
> > +my_bitcast (double x)
> > +{
> > + return bitcast(x, int);
> > +}
> > + */
> > + gcc_jit_type *int_type =
> > + gcc_jit_context_get_int_type (ctxt, 4, 1);
> > + gcc_jit_type *float_type =
> > + gcc_jit_context_get_type (ctxt, GCC_JIT_TYPE_FLOAT);
>
> This uses GCC_JIT_TYPE_FLOAT for the param...
>
> > +
> > + gcc_jit_param *x =
> > + gcc_jit_context_new_param (
> > + ctxt,
> > + NULL,
> > + float_type, "x");
> > + gcc_jit_param *params[1] = {x};
> > + gcc_jit_function *func =
> > + gcc_jit_context_new_function (ctxt,
> > + NULL,
> > + GCC_JIT_FUNCTION_EXPORTED,
> > + int_type,
> > + "my_bitcast",
> > + 1, params, 0);
>
> [..snip...]
>
> > +
> > +void
> > +verify_code (gcc_jit_context *ctxt, gcc_jit_result *result)
> > +{
> > + typedef int (*my_bitcast_fn_type) (double);
>
> ...but this uses "double". Presumably these should agree, and have
> the
> same sizeof as the integer type.
>
> > + CHECK_NON_NULL (result);
> > + my_bitcast_fn_type my_bitcast =
> > + (my_bitcast_fn_type)gcc_jit_result_get_code (result,
> > "my_bitcast");
> > + CHECK_NON_NULL (my_bitcast);
> > + int val = my_bitcast (-5.1298714);
> > + note ("my_bitcast returned: %d", val);
> > + CHECK_VALUE (val, 35569201);
>
> Out of curiosity, is there any particular significance for these
> values? FWIW I rather like:
> http://evanw.github.io/float-toy/
> for directly manipulating the bits of floating point numbers.
The given float values, when bitcast to an int, gives the given int
value.
>
>
> [...snip...]
>
> > diff --git a/gcc/toplev.cc b/gcc/toplev.cc
> > index 534da1462e8..bc4921974eb 100644
> > --- a/gcc/toplev.cc
> > +++ b/gcc/toplev.cc
> > @@ -2368,6 +2368,7 @@ toplev::finalize (void)
> > gcse_c_finalize ();
> > ipa_cp_c_finalize ();
> > ira_costs_c_finalize ();
> > + tree_cc_finalize ();
> >
> > /* save_decoded_options uses opts_obstack, so these must
> > be cleaned up together. */
> > diff --git a/gcc/tree.cc b/gcc/tree.cc
> > index ae159ee20ce..fe9d9083026 100644
> > --- a/gcc/tree.cc
> > +++ b/gcc/tree.cc
> > @@ -6963,6 +6963,15 @@ build_reference_type (tree to_type)
> > (HOST_BITS_PER_WIDE_INT > 64 ? HOST_BITS_PER_WIDE_INT : 64)
> > static GTY(()) tree
Re: [PATCH] libgccjit: Add support for setting the alignment [PR104293]
Here's the updated patch.
On Fri, 2022-04-08 at 15:01 -0400, David Malcolm wrote:
> On Sun, 2022-01-30 at 20:38 -0500, Antoni Boucher via Gcc-patches
> wrote:
> > Hi.
> > This patch adds support for setting the alignment of variables in
> > libgccjit.
>
> Thanks. Sorry about the delay in reviewing it.
>
> >
> > I was wondering if I should change it so that it takes/returns
> > bytes
> > instead of bits.
> > What do you think?
>
> I'm not sure, but given that C refers to bytes for this:
> https://en.cppreference.com/w/c/language/object#Alignment
> https://en.cppreference.com/w/c/language/_Alignof
> ...I think bytes is the better choice, to maximize similarity with C.
Ok, I updated it to use bytes.
>
> Does anything support/need a fraction-of-a-byte alignment? If so,
> then
> bits would be the way to go.
>
>
> > diff --git a/gcc/jit/docs/topics/compatibility.rst
> > b/gcc/jit/docs/topics/compatibility.rst
> > index 16cebe31a10..1957399dceb 100644
> > --- a/gcc/jit/docs/topics/compatibility.rst
> > +++ b/gcc/jit/docs/topics/compatibility.rst
> > @@ -302,3 +302,13 @@ thread-local storage model of a variable:
> > section of a variable:
> >
> > * :func:`gcc_jit_lvalue_set_link_section`
> > +
> > +.. _LIBGCCJIT_ABI_24:
> > +
> > +``LIBGCCJIT_ABI_24``
> > +---
> > +``LIBGCCJIT_ABI_24`` covers the addition of functions to get and
> > set the
> > +alignement of a variable:
> > +
> > + * :func:`gcc_jit_lvalue_set_alignment`
> > + * :func:`gcc_jit_lvalue_get_alignment`
> > diff --git a/gcc/jit/docs/topics/expressions.rst
> > b/gcc/jit/docs/topics/expressions.rst
> > index 791a20398ca..0f5f5376d8c 100644
> > --- a/gcc/jit/docs/topics/expressions.rst
> > +++ b/gcc/jit/docs/topics/expressions.rst
> > @@ -738,6 +738,45 @@ where the rvalue is computed by reading from
> > the storage area.
> >
> > #ifdef LIBGCCJIT_HAVE_gcc_jit_lvalue_set_link_section
> >
> > +.. function:: void
> > + gcc_jit_lvalue_set_alignment (gcc_jit_lvalue
> > *lvalue,
> > + int alignment)
> > +
> > + Set the alignment of a variable.
> > + The parameter ``alignment`` is in bits. Analogous to:
> > +
> > + .. code-block:: c
> > +
> > + int variable __attribute__((aligned (16)));
> > +
> > + in C, but in bits instead of bytes.
>
> If we're doing it in bytes, this will need updating, of course.
>
> Maybe rename the int param from "alignment" to "bytes" to make this
> clearer.
>
> Probably should be unsigned as well.
>
> > +
> > + This entrypoint was added in :ref:`LIBGCCJIT_ABI_24`; you can
> > test for
> > + its presence using
> > +
> > + .. code-block:: c
> > +
> > + #ifdef LIBGCCJIT_HAVE_ALIGNMENT
> > +
> > +.. function:: int
> > + gcc_jit_lvalue_get_alignment (gcc_jit_lvalue
> > *lvalue)
> > +
> > + Return the alignment of a variable set by
> > ``gcc_jit_lvalue_set_alignment``, in bits.
> > + Return 0 if the alignment was not set. Analogous to:
> > +
> > + .. code-block:: c
> > +
> > + _Alignof (variable)
> > +
> > + in C, but in bits instead of bytes.
>
> Likewise this will need updating.
>
> > +
> > + This entrypoint was added in :ref:`LIBGCCJIT_ABI_24`; you can
> > test for
> > + its presence using
> > +
> > + .. code-block:: c
> > +
> > + #ifdef LIBGCCJIT_HAVE_ALIGNMENT
> > +
> > Global variables
> >
> >
>
> [...snip...]
>
> > diff --git a/gcc/jit/libgccjit.cc b/gcc/jit/libgccjit.cc
> > index 4c352e8c93d..e03f15ec9c8 100644
> > --- a/gcc/jit/libgccjit.cc
> > +++ b/gcc/jit/libgccjit.cc
> > @@ -2649,6 +2649,31 @@ gcc_jit_lvalue_set_link_section
> > (gcc_jit_lvalue *lvalue,
> > lvalue->set_link_section (section_name);
> > }
> >
> > +/* Public entrypoint. See description in libgccjit.h.
> > +
> > + After error-checking, the real work is done by the
> > + gcc::jit::recording::lvalue::get_link_section method in jit-
> > recording.cc. */
>
> Comment refers to wrong function.
>
> > +
> > +int
> > +gcc_jit_lvalue_get_alignment (gcc_jit_lvalue *lvalue)
> > +{
> > + RETURN_VAL_IF_FAIL (lvalue, 0, NULL, NULL, "NULL lvalue");
> > + return lvalue->get_alignment ();
> > +}
>
> Should this return unsigned?
>
> > +
> > +/* Public entrypoint. See description in libgccjit.h.
> > +
> > + After error-checking, the real work is done by the
> > + gcc::jit::recording::lvalue::set_alignment method in jit-
> > recording.cc. */
> > +
> > +void
> > +gcc_jit_lvalue_set_alignment (gcc_jit_lvalue *lvalue,
> > + int alignment)
> > +{
> > + RETURN_IF_FAIL (lvalue, NULL, NULL, "NULL lvalue");
>
> Should the alignment be unsigned? What if the user passes in
> negative?
>
> Does it have to be a power of two? If so, ideally we should reject
> non-power-of-two here.
>
> > + lvalue->set_alignment (alignment);
> > +}
> > +
>
> [...snip...]
>
> > diff --git a/gcc/jit/libgccjit.map b/gcc/jit/libgccjit.map
> > index
Re: [PATCH] LoongArch: Fix bug for tmpdir-g++.dg-struct-layout-1/t033.
I can confirm this patch fixes t033 failure. LGTM, except... > gcc/ChangeLog: > > * config/loongarch/loongarch.cc: Fix bug for > tmpdir-g++.dg-struct-layout-1/t033. ^^ These two whitespaces should not exist (I was taught this just several days ago :) -- Xi Ruoyao School of Aerospace Science and Technology, Xidian University
[Bug libquadmath/105101] incorrect rounding for sqrtq
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105101
--- Comment #8 from Steve Kargl ---
On Sat, Apr 09, 2022 at 10:23:39AM +, jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105101
>
> --- Comment #6 from Jakub Jelinek ---
> (In reply to Thomas Koenig from comment #5)
> > There is another, much worse, problem, reported and analyzed by "Michael S"
> > on comp.arch. The code has
> >
> > #ifdef HAVE_SQRTL
> > {
> > long double xl = (long double) x;
> > if (xl <= LDBL_MAX && xl >= LDBL_MIN)
> > {
> > /* Use long double result as starting point. */
> > y = (__float128) sqrtl (xl);
> >
> > /* One Newton iteration. */
> > y -= 0.5q * (y - x / y);
> > return y;
> > }
> > }
> > #endif
> >
> > which assumes that long double has a higher precision than
> > normal double. On x86_64, this depends o the settings of the
> > FPU flags, so a number like 0x1.06bc82f7b9d71dfcbddf2358a0eap-1024
> > is corrected with 32 ULP of error because there is only a single
> > round of Newton iterations if the FPU flags are set to normal precision.
>
> That is only a problem on OSes that do that, I think mainly BSDs, no?
> On Linux it should be fine (well, still not 0.5ulp precise, but not as bad as
> when sqrtl is just double precision precise).
>
i686-*-freebsd sets the FPU to have 53 bits of precision for
long double. It has the usual exponent range of an Intel
80-bit extended double.
[committed] wwwdocs: readings: www.cmass.com is gone, remove
I pushed this for now. Gaius, if you want to make changes to that section of readings.html, absolutely be free doing so (and I'll be happy help, too). Gerald --- htdocs/readings.html | 1 - 1 file changed, 1 deletion(-) diff --git a/htdocs/readings.html b/htdocs/readings.html index 12755d7e..8689eab8 100644 --- a/htdocs/readings.html +++ b/htdocs/readings.html @@ -569,7 +569,6 @@ names. Modula 3 information - http://www.cmass.com;>http://www.cmass.com http://www.modula3.org;>http://www.modula3.org -- 2.35.1
[committed] wwwdocs: contribute: Move validator.w3.org to https
Pushed. Gerald --- htdocs/contribute.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/htdocs/contribute.html b/htdocs/contribute.html index c0223738..c985b87d 100644 --- a/htdocs/contribute.html +++ b/htdocs/contribute.html @@ -145,7 +145,7 @@ eliminate them all. Web Site Changes Changes to the web site must -http://validator.w3.org/;>validate as HTML 5. To +https://validator.w3.org;>validate as HTML 5. To validate your changes, use the "upload file" mode of the validator. -- 2.35.1
[Bug libquadmath/105101] incorrect rounding for sqrtq
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105101
--- Comment #7 from Thomas Koenig ---
(In reply to Jakub Jelinek from comment #6)
> (In reply to Thomas Koenig from comment #5)
> > There is another, much worse, problem, reported and analyzed by "Michael S"
> > on comp.arch. The code has
> >
> > #ifdef HAVE_SQRTL
> > {
> > long double xl = (long double) x;
> > if (xl <= LDBL_MAX && xl >= LDBL_MIN)
> > {
> > /* Use long double result as starting point. */
> > y = (__float128) sqrtl (xl);
> >
> > /* One Newton iteration. */
> > y -= 0.5q * (y - x / y);
> > return y;
> > }
> > }
> > #endif
> >
> > which assumes that long double has a higher precision than
> > normal double. On x86_64, this depends o the settings of the
> > FPU flags, so a number like 0x1.06bc82f7b9d71dfcbddf2358a0eap-1024
> > is corrected with 32 ULP of error because there is only a single
> > round of Newton iterations if the FPU flags are set to normal precision.
>
> That is only a problem on OSes that do that, I think mainly BSDs, no?
Correct.
> On Linux it should be fine (well, still not 0.5ulp precise, but not as bad
> as when sqrtl is just double precision precise).
In this case, it was discovered on some version of WSL.
[Bug libquadmath/105101] incorrect rounding for sqrtq
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105101
--- Comment #6 from Jakub Jelinek ---
(In reply to Thomas Koenig from comment #5)
> There is another, much worse, problem, reported and analyzed by "Michael S"
> on comp.arch. The code has
>
> #ifdef HAVE_SQRTL
> {
> long double xl = (long double) x;
> if (xl <= LDBL_MAX && xl >= LDBL_MIN)
> {
> /* Use long double result as starting point. */
> y = (__float128) sqrtl (xl);
>
> /* One Newton iteration. */
> y -= 0.5q * (y - x / y);
> return y;
> }
> }
> #endif
>
> which assumes that long double has a higher precision than
> normal double. On x86_64, this depends o the settings of the
> FPU flags, so a number like 0x1.06bc82f7b9d71dfcbddf2358a0eap-1024
> is corrected with 32 ULP of error because there is only a single
> round of Newton iterations if the FPU flags are set to normal precision.
That is only a problem on OSes that do that, I think mainly BSDs, no?
On Linux it should be fine (well, still not 0.5ulp precise, but not as bad as
when sqrtl is just double precision precise).
[Bug libquadmath/105101] incorrect rounding for sqrtq
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105101
--- Comment #5 from Thomas Koenig ---
There is another, much worse, problem, reported and analyzed by "Michael S"
on comp.arch. The code has
#ifdef HAVE_SQRTL
{
long double xl = (long double) x;
if (xl <= LDBL_MAX && xl >= LDBL_MIN)
{
/* Use long double result as starting point. */
y = (__float128) sqrtl (xl);
/* One Newton iteration. */
y -= 0.5q * (y - x / y);
return y;
}
}
#endif
which assumes that long double has a higher precision than
normal double. On x86_64, this depends o the settings of the
FPU flags, so a number like 0x1.06bc82f7b9d71dfcbddf2358a0eap-1024
is corrected with 32 ULP of error because there is only a single
round of Newton iterations if the FPU flags are set to normal precision.
I believe we can at least fix that before the gcc 12 release, by
simply removing the code I quoted.
[Bug target/82261] x86: missing peephole for SHLD / SHRD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82261
--- Comment #4 from Peter Cordes ---
GCC will emit SHLD / SHRD as part of shifting an integer that's two registers
wide.
Hironori Bono proposed the following functions as a workaround for this missed
optimization (https://stackoverflow.com/a/71805063/224132)
#include
#ifdef __SIZEOF_INT128__
uint64_t shldq_x64(uint64_t low, uint64_t high, uint64_t count) {
return (uint64_t)(unsigned __int128)high << 64) | (unsigned __int128)low)
<< (count & 63)) >> 64);
}
uint64_t shrdq_x64(uint64_t low, uint64_t high, uint64_t count) {
return (uint64_t)unsigned __int128)high << 64) | (unsigned __int128)low)
>> (count & 63));
}
#endif
uint32_t shld_x86(uint32_t low, uint32_t high, uint32_t count) {
return (uint32_t)(uint64_t)high << 32) | (uint64_t)low) << (count & 31))
>> 32);
}
uint32_t shrd_x86(uint32_t low, uint32_t high, uint32_t count) {
return (uint32_t)uint64_t)high << 32) | (uint64_t)low) >> (count & 31));
}
---
The uint64_t functions (using __int128) compile cleanly in 64-bit mode
(https://godbolt.org/z/1j94Gcb4o) using 64-bit operand-size shld/shrd
but the uint32_t functions compile to a total mess in 32-bit mode (GCC11.2 -O3
-m32 -mregparm=3) before eventually using shld, including a totally insane
or dh, 0
GCC trunk with -O3 -mregparm=3 compiles them cleanly, but without regparm it's
also slightly different mess.
Ironically, the uint32_t functions compile to quite a few instructions in
64-bit mode, actually doing the operations as written with shifts and ORs, and
having to manually mask the shift count to &31 because it uses a 64-bit
operand-size shift which masks with &63. 32-bit operand-size SHLD would be a
win here, at least for -mtune=intel or a specific Intel uarch.
I haven't looked at whether they still compile ok after inlining into
surrounding code, or whether operations would tend to combine with other things
in preference to becoming an SHLD.
[PATCH] phiopt: Optimize (x != cst1 ? x : cst2) != cst3 [PR104639]
Hi!
Here is an attempt to resolve a P1 regression, where due to threading
changes we no longer optimize
bool foo(int i) {
while (i == 4)
i += 2;
return i;
}
to just return i != 0; by enhancing the phiopt value_replacement
optimization. Normally it will optimize x != cst1 ? x : cst1 to x.
Here we extend it to also optimize x != cst1 ? x : cst2 to x if
it (phi result) has a single immediate use which is a comparison
with some INTEGER_CST cst3 and we can prove that we don't care
whether x is cst1 or cst2 because both compare the same against cst3.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2022-04-09 Jakub Jelinek
PR tree-optimization/104639
* tree-ssa-phiopt.cc: Include tree-ssa-propagate.h.
(value_replacement): Optimize (x != cst1 ? x : cst2) != cst3
into x != cst3.
* gcc.dg/tree-ssa/pr104639-1.c: New test.
* gcc.dg/tree-ssa/pr104639-2.c: New test.
--- gcc/tree-ssa-phiopt.cc.jj 2022-04-07 17:18:14.476882106 +0200
+++ gcc/tree-ssa-phiopt.cc 2022-04-08 17:49:30.892920502 +0200
@@ -52,6 +52,7 @@ along with GCC; see the file COPYING3.
#include "gimple-range.h"
#include "gimple-match.h"
#include "dbgcnt.h"
+#include "tree-ssa-propagate.h"
static unsigned int tree_ssa_phiopt_worker (bool, bool, bool);
static bool two_value_replacement (basic_block, basic_block, edge, gphi *,
@@ -1327,7 +1328,17 @@ value_replacement (basic_block cond_bb,
We now need to verify that the two arguments in the PHI node match
the two arguments to the equality comparison. */
- if (operand_equal_for_value_replacement (arg0, arg1, , cond))
+ bool equal_p = operand_equal_for_value_replacement (arg0, arg1, , cond);
+ bool maybe_equal_p = false;
+ if (!equal_p
+ && empty_or_with_defined_p
+ && TREE_CODE (gimple_cond_rhs (cond)) == INTEGER_CST
+ && (operand_equal_for_phi_arg_p (gimple_cond_lhs (cond), arg0)
+ ? TREE_CODE (arg1) == INTEGER_CST
+ : (operand_equal_for_phi_arg_p (gimple_cond_lhs (cond), arg1)
+&& TREE_CODE (arg0) == INTEGER_CST)))
+maybe_equal_p = true;
+ if (equal_p || maybe_equal_p)
{
edge e;
tree arg;
@@ -1358,11 +1369,123 @@ value_replacement (basic_block cond_bb,
&& single_non_singleton_phi_for_edges (phi_nodes (gimple_bb (phi)),
e0, e1) == phi)
{
- replace_phi_edge_with_variable (cond_bb, e1, phi, arg);
- /* Note that we optimized this PHI. */
- return 2;
+ use_operand_p use_p;
+ gimple *use_stmt;
+
+ /* Even if arg0/arg1 isn't equal to second operand of cond, we
+can optimize away the bb if we can prove it doesn't care whether
+phi result is arg0/arg1 or second operand of cond. Consider:
+ [local count: 118111600]:
+if (i_2(D) == 4)
+ goto ; [97.00%]
+else
+ goto ; [3.00%]
+
+ [local count: 3540129]:
+
+ [local count: 118111600]:
+# i_6 = PHI
+_3 = i_6 != 0;
+Here, carg is 4, oarg is 6, crhs is 0, and because
+(4 != 0) == (6 != 0), we don't care if i_6 is 4 or 6, both
+have the same outcome. So, can can optimize this to:
+_3 = i_2(D) != 0;
+If the single imm use of phi result >, >=, < or <=, similarly
+we can check if both carg and oarg compare the same against
+crhs using ccode. */
+ if (maybe_equal_p
+ && TREE_CODE (arg) != INTEGER_CST
+ && single_imm_use (gimple_phi_result (phi), _p, _stmt))
+ {
+ enum tree_code ccode = ERROR_MARK;
+ tree clhs = NULL_TREE, crhs = NULL_TREE;
+ tree carg = gimple_cond_rhs (cond);
+ tree oarg = e0 == e ? arg1 : arg0;
+ if (is_gimple_assign (use_stmt)
+ && (TREE_CODE_CLASS (gimple_assign_rhs_code (use_stmt))
+ == tcc_comparison))
+ {
+ ccode = gimple_assign_rhs_code (use_stmt);
+ clhs = gimple_assign_rhs1 (use_stmt);
+ crhs = gimple_assign_rhs2 (use_stmt);
+ }
+ else if (gimple_code (use_stmt) == GIMPLE_COND)
+ {
+ ccode = gimple_cond_code (use_stmt);
+ clhs = gimple_cond_lhs (use_stmt);
+ crhs = gimple_cond_rhs (use_stmt);
+ }
+ if (ccode != ERROR_MARK
+ && clhs == gimple_phi_result (phi)
+ && TREE_CODE (crhs) == INTEGER_CST)
+ switch (ccode)
+ {
+ case EQ_EXPR:
+ case NE_EXPR:
+ if (!tree_int_cst_equal (crhs, carg)
+ && !tree_int_cst_equal (crhs, oarg))
+ equal_p = true;
+ break;
+
[Bug c++/105130] gcc does not warn about unused return value of last expression of statement expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105130 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #2 from Eric Gallager --- Please send your patch to the gcc-patches mailing list for review.
[Bug c/105180] K style definition does not evaluate array size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105180 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #1 from Eric Gallager --- I mean... that's some pretty suspect code right there...
[PATCH] LoongArch: Fix bug for tmpdir-g++.dg-struct-layout-1/t033.
From: chenglulu
gcc/ChangeLog:
* config/loongarch/loongarch.cc: Fix bug for
tmpdir-g++.dg-struct-layout-1/t033.
---
gcc/config/loongarch/loongarch.cc | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/gcc/config/loongarch/loongarch.cc
b/gcc/config/loongarch/loongarch.cc
index 6e24111a79d..f22150a60cc 100644
--- a/gcc/config/loongarch/loongarch.cc
+++ b/gcc/config/loongarch/loongarch.cc
@@ -473,13 +473,14 @@ loongarch_pass_aggregate_in_fpr_and_gpr_p (const_tree
type,
static rtx
loongarch_pass_fpr_single (machine_mode type_mode, unsigned regno,
- machine_mode value_mode)
+ machine_mode value_mode,
+ HOST_WIDE_INT offset)
{
rtx x = gen_rtx_REG (value_mode, regno);
if (type_mode != value_mode)
{
- x = gen_rtx_EXPR_LIST (VOIDmode, x, const0_rtx);
+ x = gen_rtx_EXPR_LIST (VOIDmode, x, GEN_INT (offset));
x = gen_rtx_PARALLEL (type_mode, gen_rtvec (1, x));
}
return x;
@@ -539,7 +540,8 @@ loongarch_get_arg_info (struct loongarch_arg_info *info,
{
case 1:
return loongarch_pass_fpr_single (mode, fregno,
- TYPE_MODE (fields[0].type));
+ TYPE_MODE (fields[0].type),
+ fields[0].offset);
case 2:
return loongarch_pass_fpr_pair (mode, fregno,
--
2.31.1
Re: [PATCH] loongarch: testsuite: adapt stack-usage-1.c for LP64
在 2022/4/9 上午5:48, Xi Ruoyao 写道: Another simple testcase change for LoongArch. Ok for trunk? --- LoongArch backend allocates two additional 8-byte stack slots for LP64, one for saving $fp and another for saving the temporary value "1". Ideally they are both unneeded, but (1) we're using -O0 so the code is suboptimized by the nature; (2) any improvement (if possible) should be deferred to GCC 13. So for now simply adjust the test to make it pass. gcc/testsuite/ * gcc.dg/stack-usage-1.c: Adjust for LoongArch LP64. --- gcc/testsuite/gcc.dg/stack-usage-1.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/gcc/testsuite/gcc.dg/stack-usage-1.c b/gcc/testsuite/gcc.dg/stack-usage-1.c index 1d7d1fee435..21cce0f440c 100644 --- a/gcc/testsuite/gcc.dg/stack-usage-1.c +++ b/gcc/testsuite/gcc.dg/stack-usage-1.c @@ -105,6 +105,8 @@ # define SIZE 252 #elif defined (__CRIS__) # define SIZE 252 +#elif defined (__loongarch_lp64) +# define SIZE 240 /* 256 - 8 bytes for $fp, and 8 bytes for a temp value */ #else # define SIZE 256 #endif OK. Thanks! Lulu Cheng
Re: [PATCH] loongarch: testsuite: skip builtin-apply2.c
在 2022/4/9 上午5:46, Xi Ruoyao 写道:
A simple testcase change, tested on loongarch64-linux-gnuabif64. Ok for trunk?
---
On LoongArch, variadic functions use different arugment passing
conventions so this test is not valid (see the section named "Variadic
argument" in the [ELF ABI][1]) and should be skipped.
[1]:
https://loongson.github.io/LoongArch-Documentation/LoongArch-ELF-ABI-EN.html
gcc/testsuite/
* gcc.dg/builtin-apply2.c (dg-skip-if): Add loongarch*-*-*.
---
gcc/testsuite/gcc.dg/builtin-apply2.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/testsuite/gcc.dg/builtin-apply2.c
b/gcc/testsuite/gcc.dg/builtin-apply2.c
index 9049af5821f..0f350f4ac16 100644
--- a/gcc/testsuite/gcc.dg/builtin-apply2.c
+++ b/gcc/testsuite/gcc.dg/builtin-apply2.c
@@ -1,7 +1,7 @@
/* { dg-do run } */
/* { dg-require-effective-target untyped_assembly } */
/* { dg-skip-if "Variadic funcs have all args on stack. Normal funcs have args in
registers." { "avr-*-* nds32*-*-* amdgcn-*-*" } } */
-/* { dg-skip-if "Variadic funcs use different argument passing from normal funcs." {
"csky*-*-* riscv*-*-* or1k*-*-* msp430-*-* pru-*-*" } } */
+/* { dg-skip-if "Variadic funcs use different argument passing from normal funcs." {
"csky*-*-* riscv*-*-* or1k*-*-* msp430-*-* pru-*-* loongarch*-*-*" } } */
/* { dg-skip-if "Variadic funcs use Base AAPCS. Normal funcs use VFP variant." {
arm*-*-* && arm_hf_eabi } } */
/* PR target/12503 */
OK.
Thanks!
LuluCheng
