Hi:
This patch is about to do transformation like below.
Bootstrapped and regtested on x86_64-linux-gnu{-m32,}.
Ok for trunk?
from
notl%edi
vpbroadcastd%edi, %xmm0
vpand %xmm1, %xmm0, %xmm0
to
vpbroadcastd%edi, %xmm0
vpandn %xmm1,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100711
--- Comment #3 from Hongtao.liu ---
(In reply to Segher Boessenkool from comment #2)
> (In reply to Richard Biener from comment #1)
> > I suppose we're confused about the vec_duplicate. Would generally swapping
> > the duplicate and the
It isn't exposed on my platform either. Looks like a bug in
perf_data_converter (i.e., quipper). Could you try adding #include
in
third_party/perf_data_converter/src/quipper/huge_page_deducer.cc and
see if it fixes the problem? If it works, I will need to file a bug
against perf_data_converter.
That fixed the error I saw before but the build still fails. The errors start
with
eugene@eugene-Virtual-Machine:~/autofdo1/build$ ninja
[2/217] Building CXX object
CMakeFiles/quipper_perf.dir/third_party/perf_data_converter/src/quipper/huge_page_deducer.cc.o
FAILED:
Sorry, I added dependency for create_gcov but missed it for dump_gcov.
Fixed it at
https://github.com/google/autofdo/commit/6ca36cdc30986f13583a3aef3e27746ca4fc5bf6
.
Thanks,
Wei.
On Mon, May 24, 2021 at 6:39 PM Eugene Rozenfeld <
eugene.rozenf...@microsoft.com> wrote:
> Thank you Wei. Looks
Thank you Wei. Looks like something is still missing. This time perf_data.pb.h
is not found. I'm getting the error below (on Ubuntu 18.04 with cmake 3.12.1):
eugene@eugene-Virtual-Machine:~/autofdo1/build$ ninja
[1/241] Building CXX object CMakeFiles/dump_gcov_lib.dir/profile.cc.o
FAILED:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95782
--- Comment #1 from Evan Nemerson ---
This seems to also happen on s390x with -mzvector:
# s390x-linux-gnu-gcc-10 -march=z14 -mzvector -o test test.c
test.c:4:1: internal compiler error: in _cpp_pop_context, at
libcpp/macro.c:2644
4 |
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100310
--- Comment #2 from Hongtao.liu ---
w/o mask operands, v{,p}expand* are equal to mov instructions.
Hi Thomas,
I reproduced this issue manually and it turns out this is a special case.
Script takes input from https://gcc.gnu.org/pipermail/gcc-regression/ and
it matches the exact error message in the triaging process. This failure
reported on gcc regression
On 5/24/21 5:08 PM, David Malcolm via Gcc-patches wrote:
On Mon, 2021-05-24 at 16:16 -0600, Martin Sebor via Gcc-patches wrote:
The attached patch replaces TREE_NO_WARNING, gimple_get_no_warning_p
and gimple_set_no_warning with the new APIs, get_no_warning,
set_no_warning, and copy_no_warning.
On 5/24/21 5:08 PM, David Malcolm wrote:
On Mon, 2021-05-24 at 16:02 -0600, Martin Sebor wrote:
Having just one bit control whether an expression or statement should
be allowed to trigger warnings has been a source of bug reports about
false negatives for years. PR 74765 has a representative
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100748
--- Comment #3 from Jonathan Wakely ---
I'd better disable it again until I have time to figure it out.
On Mon, 2021-05-24 at 16:16 -0600, Martin Sebor via Gcc-patches wrote:
> The attached patch replaces TREE_NO_WARNING, gimple_get_no_warning_p
> and gimple_set_no_warning with the new APIs, get_no_warning,
> set_no_warning, and copy_no_warning.
Might be worth splitting this out into
(a) the
On Mon, 2021-05-24 at 16:02 -0600, Martin Sebor wrote:
> Having just one bit control whether an expression or statement should
> be allowed to trigger warnings has been a source of bug reports about
> false negatives for years. PR 74765 has a representative test case
> that shows how by setting
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100750
Bug ID: 100750
Summary: new test case gcc.target/powerpc/rop-5.c fails on BE
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=74762
Martin Sebor changed:
What|Removed |Added
Keywords||patch
Assignee|unassigned at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=74765
Martin Sebor changed:
What|Removed |Added
Keywords||patch
--- Comment #7 from Martin Sebor
The attached patch replaces TREE_NO_WARNING, gimple_get_no_warning_p
and gimple_set_no_warning with the new APIs, get_no_warning,
set_no_warning, and copy_no_warning.
Add support for per-location warning groups.
gcc/ChangeLog:
* builtins.c (warn_string_no_nul): Replace uses of TREE_NO_WARNING,
The attached patch replaces the uses of TREE_NO_WARNING in libc11.
Add support for per-location warning groups.
libcc1/ChangeLog:
* libcp1plugin.cc (record_decl_address): Replace a direct use
of TREE_NO_WARNING with set_no_warning.
diff --git a/libcc1/libcp1plugin.cc b/libcc1/libcp1plugin.cc
The attached patch replaces the uses of TREE_NO_WARNING in the rl78
back end.
Add support for per-location warning groups.
gcc/ChangeLog:
* config/rl78/rl78.c (rl78_handle_naked_attribute): Replace a direct
use of TREE_NO_WARNING with set_no_warning.
diff --git a/gcc/config/rl78/rl78.c
The attached patch replaces the uses of TREE_NO_WARNING in
the Objective-C front end.
Add support for per-location warning groups.
gcc/objc/ChangeLog:
* objc-act.c (objc_maybe_build_modify_expr): Replace direct uses
of TREE_NO_WARNING with get_no_warning, and set_no_warning.
The attached patch replaces the uses of TREE_NO_WARNING in the LTO
front end. The streaming support doesn't extend to multiple bits yet.
I plan to do that in a follow-up change.
Add support for per-location warning groups.
gcc/lto/ChangeLog:
* gimple-streamer-out.c (output_gimple_stmt): Same.
The attached patch replaces the uses of TREE_NO_WARNING in the Fortran
front end.
I don't know the Fortran front end and I made no effort to try to find
the right warning options in the calls to set/get_no_warning.
Add support for per-location warning groups.
gcc/fortran/ChangeLog:
*
The attached patch replaces the uses of TREE_NO_WARNING in the C++
front end. For the set/get_no_warning calls I tried to find the most
appropriate option to disable and query. In some cases there are
helpful comments nearby that made this easy. In other cases it was
less straightforward, and
The attached patch replaces the uses of TREE_NO_WARNING in the C
family common subset of the C and C++ front ends.
Add support for per-location warning groups.
gcc/c-family/ChangeLog:
* c-common.c (c_wrap_maybe_const): Remove TREE_NO_WARNING.
(c_common_truthvalue_conversion): Replace direct
The attached patch replaces the uses of TREE_NO_WARNING in the C
front end.
Add support for per-location warning groups.
gcc/c/ChangeLog:
* c-decl.c (pop_scope): Replace direct uses of TREE_NO_WARNING with
get_no_warning, set_no_warning, and copy_no_warning.
(diagnose_mismatched_decls):
[PATCH 2/11] use xxx_no_warning APIs in Ada.
Add support for per-location warning groups.
gcc/ada/ChangeLog:
* gcc-interface/trans.c (Handled_Sequence_Of_Statements_to_gnu):
Replace TREE_NO_WARNING with set_no_warning.
(gnat_gimplify_expr): Same.
* gcc-interface/utils.c (gnat_pushdecl):
The attached patch introduces the get_no_warning(), set_no_warning(),
and copy_no_warning() APIs without making use of them in the rest of
GCC. They are in three files:
diagnostic-spec.{h,c}: Location-centric overloads.
warning-control.cc: Tree- and gimple*-centric overloads.
The
Having just one bit control whether an expression or statement should
be allowed to trigger warnings has been a source of bug reports about
false negatives for years. PR 74765 has a representative test case
that shows how by setting the bit to avoid -Wparentheses the C++ front
end also ends up
On Tue, May 18, 2021 at 5:31 AM Iain Buclaw wrote:
>
> Excerpts from Lewis Hyatt via Gcc-patches's message of January 29, 2021 4:46
> pm:
> > Q1: What is the input charset?
> > A1:
> >
> > libcpp: Whatever was passed to -finput-charset (note, for Fortran,
> > -finput-charset is not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100085
--- Comment #8 from Segher Boessenkool ---
(In reply to luoxhu from comment #7)
> (In reply to Segher Boessenkool from comment #3)
> > The rotates in 6 and 7 are not merged, and neither are the vec_selects in
> > 8 and 9. Both should be pretty
I've committed a patch to the Go frontend that fixes this problem.
Thanks for the analysis.
Ian
On Thu, May 20, 2021 at 1:59 AM guojiufu wrote:
>
> On 2021-05-18 14:58, Richard Biener wrote:
> > On Mon, 17 May 2021, Ian Lance Taylor wrote:
> >
> >> On Mon, May 17, 2021 at 1:17 AM Richard Biener
On Mon, May 24, 2021 at 12:37:30AM +0200, Bernhard Reutner-Fischer wrote:
> On 21 May 2021 22:56:09 CEST, Bill Schmidt via Gcc-patches
> wrote:
> >>> + char *buf = (char *) malloc (lastpos - pos + 2);
> >>> + memcpy (buf, [pos], lastpos - pos + 1);
> >>> + buf[lastpos - pos + 1] = '\0';
>
On 5/24/21 1:48 PM, Patrick Palka wrote:
In the testcase below, the initializer for C::b inside C's default
constructor is encoded as a TARGET_EXPR wrapping the CALL_EXPR f() in
C++17 mode. During massaging of this constexpr constructor,
build_target_expr_with_type called from bot_manip ends up
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100748
--- Comment #2 from seurer at gcc dot gnu.org ---
I do see it failing on at least one powerpc64 LE machine. PR97944 said it used
to fail randomly.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100749
Bug ID: 100749
Summary: [12 regression] gcc.dg/pch/valid-1.c fails after
r12-949
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Hi folks,
some more suggestions for corrections in the onlinedocs:
https://gcc.gnu.org/onlinedocs/gcc-11.1.0/gfortran/GERROR.html#GERROR
RESULT "Shall of type CHARACTER and of default"
--> "Shall BE of ... default KIND."
Hi folks,
some more suggestions for corrections in the onlinedocs:
https://gcc.gnu.org/onlinedocs/gcc-11.1.0/gfortran/GERROR.html#GERROR
RESULT "Shall of type CHARACTER and of default"
--> "Shall BE of ... default KIND."
On 5/24/21 12:46 PM, Martin Sebor wrote:
Instantiating a hash_map on a number of integer types including,
for example, int or unsigned int (such as location_t), or
HOST_WIDE_INT, and using it with the garbage collector causes many
cryptic compilation errors due to incomplete support for such
On 5/21/21 4:35 PM, Patrick Palka wrote:
Here, during ahead of time access checking for the private member
EnumeratorRange::end_reached_ in the hidden friend f, we're triggering
the the assert in enforce_access that verifies we're not trying to add a
dependent access check to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100748
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2021-05-24
On 5/21/21 4:35 PM, Patrick Palka wrote:
Here, in C++17 mode, convert_nontype_argument_function is rejecting
binding a non-noexcept function reference template parameter to a
noexcept function (encoded as the template argument '*(int (&) (int)) ').
The first roadblock to making this work is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100748
Bug ID: 100748
Summary: [12 regression] 30_threads/jthread/95989.cc fails
after r12-843
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100537
Ian Lance Taylor changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100746
--- Comment #1 from Marc Glisse ---
PR 80740 ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100745
Nicolas F. changed:
What|Removed |Added
Attachment #50861|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100745
--- Comment #1 from Nicolas F. ---
I'll attach a second version of profile.c, with the vector extension code
that's actually going to be used in mpv (some cleanup has been done).
Performance is unchanged. Some absolute numbers from gcc 11.1.0:
This patch to the Go frontend marks global variables whose address is
taken. To implement this, change the backend to use flag bits for
variables. This fixes GCC PR 100537. Bootstrapped and ran Go
testsuite on x86_64-pc-linux-gnu. Committed to mainline.
Ian
PR go/100537
*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100537
--- Comment #17 from CVS Commits ---
The master branch has been updated by Ian Lance Taylor :
https://gcc.gnu.org/g:358832c46a378e5a0b8a2fa3c2739125e3e680c7
commit r12-1022-g358832c46a378e5a0b8a2fa3c2739125e3e680c7
Author: Ian Lance Taylor
On Sat, 22 May 2021, H.J. Lu via Gcc-patches wrote:
> 1. Update PUSH_ARGS to accept an argument. When the PUSH instruction
> usage is optional, pass the number of bytes to push to PUSH_ARGS so that
> the backend can decide if PUSH instructions should be generated.
> 2. Change x86 PUSH_ARGS to
On Fri, 21 May 2021, Martin Liška wrote:
> CPUs:
> aarch64, alpha, alpha64, amdgcn, arc, arceb, arm, avr, bfin, bpf, cr16, cris,
> csky, epiphany, fido, fr30, frv, ft32, h8300, hppa, hppa2.0, hppa64, i486,
> i686, ia64, iq2000, lm32, m32c, m32r, m32rle, m68k, mcore, microblaze, mips,
> mips64,
On 5/24/21 2:18 AM, Uecker, Martin wrote:
I wonder if we could get a nice short command-line option
for recommended safety/security related flags.
We have -Ox for optimization and -Wall for a useful set
of recommended warnings.
I am thinking about options such as
-ftrapv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95298
Patrick Palka changed:
What|Removed |Added
Last reconfirmed||2021-05-24
Known to fail|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100724
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Known to fail||10.3.1, 11.1.0, 12.0,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100747
Bug ID: 100747
Summary: Possibly Wrong Permissions in "liboffloadmic"
Product: gcc
Version: 11.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
One last addendum to this. I discovered that that needs a "sort"
in front of "keys %logicals_addsub" because otherwise you may get
the operators in different orders sometimes which leads to fusion.md
having the patterns in different orders which isn't helpful for
sane debugging. Segher and I
VARYING ranges are just normal ranges that span the entire domain. Such
ranges have had end-points for a few releases now, and the fact that the
legacy code was still treating all VR_VARYING the same was an oversight.
This patch fixes the oversight to match the multi-range behavior.
Tested on
On 5/21/21 5:39 AM, Aldy Hernandez via Gcc-patches wrote:
This patch converts the remaining users of get_range_info and
get_ptr_nonnull to the range_query API.
No effort was made to move passes away from VR_ANTI_RANGE, or any other
use of deprecated methods. This was a straight up conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100479
--- Comment #1 from CVS Commits ---
The master branch has been updated by Patrick Palka :
https://gcc.gnu.org/g:46ed811bcb4b86a81ef3d78ea8cfffc6cd043144
commit r12-1018-g46ed811bcb4b86a81ef3d78ea8cfffc6cd043144
Author: Patrick Palka
Date:
On 5/21/21 5:39 AM, Aldy Hernandez via Gcc-patches wrote:
This patch provides a generic API for accessing global ranges. It is
meant to replace get_range_info() and get_ptr_nonnull() with one
common interface. It uses the same API as the ranger (class
range_query), so there will now be one API
On 18/05/21 00:53 -0400, Patrick Palka via Libstdc++ wrote:
On Mon, 17 May 2021, Tim Song wrote:
On Mon, May 17, 2021 at 2:59 PM Patrick Palka wrote:
>
> + constexpr _CachedPosition&
> + operator=(_CachedPosition&& __other) noexcept
> + {
> + if
These tests rely on ADL for some functions, probably unintentionally.
The calls only work because the iterator wrappers derive from
std::iterator and so namespace std is an associated namespace.
libstdc++-v3/ChangeLog:
* testsuite/25_algorithms/inplace_merge/constrained.cc: Qualify
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100573
--- Comment #7 from Jakub Jelinek ---
Guess that is because the functions that have #pragma omp target teams
directive in it are marked declare target to.
So, either we'd need to play with macros etc. to make sure that those functions
aren't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88360
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89694
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90217
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |FIXED
Target Milestone|---
Hi Philip,
On Mon, May 24, 2021 at 02:24:13PM +0100, Philip Herron wrote:
> As some of you might know, I have been working on GCC Rust over on
> GitHub https://github.com/Rust-GCC/gccrs. As the project is moving
> forward and enforcing GCC copyright assignments for contributors, I
> would like to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100573
--- Comment #6 from Tobias Burnus ---
(In reply to Jakub Jelinek from comment #5)
> I think we want to fix both for-3.c and for-9.c similarly to
> r11-2571-g916c7a201a9a1dc94f2c056a773826a26d1daca9 i.e.
> #define DO_PRAGMA(x) _Pragma (#x)
>
Please, get serious.
=> this topic is closed for me, so STOP CC''ing ME, it is not welcome.
On Sun, 23 May 2021 at 19:03, Mike Stump wrote:
> This isn't a patch to gcc, please stop posting non-technical content to
> this list. Please review what this list is for and the rules for this list
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84862
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84187
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|1 |0
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78889
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81955
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|1 |0
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79760
Andrew Pinski changed:
What|Removed |Added
CC||vctrex at mailfence dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81612
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61238
Andrew Pinski changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
In the testcase below, the initializer for C::b inside C's default
constructor is encoded as a TARGET_EXPR wrapping the CALL_EXPR f() in
C++17 mode. During massaging of this constexpr constructor,
build_target_expr_with_type called from bot_manip ends up trying to use
B's implicitly deleted copy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100666
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
Instantiating a hash_map on a number of integer types including,
for example, int or unsigned int (such as location_t), or
HOST_WIDE_INT, and using it with the garbage collector causes many
cryptic compilation errors due to incomplete support for such types
(the PR shows a few examples). I ran
Ping https://gcc.gnu.org/pipermail/gcc-patches/2021-May/570139.html
On Tue, May 11, 2021 at 8:29 PM Fangrui Song wrote:
>
> This was introduced in 2014-12 to use local binding for external symbols
> for -fPIE. Now that we have H.J. Lu's GOTPCRELX for years which mostly
> nullify the benefit of
On Mon, 24 May 2021, Philip Herron wrote:
> remote: error: hook declined to update refs/heads/gccrs
refs/heads/gccrs doesn't match the branch naming conventions as documented
at https://gcc.gnu.org/git.html (where you'd use refs/heads/devel/* for
shared development branches), so if you hadn't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100368
Patrick Palka changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100746
Bug ID: 100746
Summary: NRVO should not introduce aliasing
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
On 5/21/21 1:39 PM, Aldy Hernandez wrote:
This patch provides a generic API for accessing global ranges. It is
meant to replace get_range_info() and get_ptr_nonnull() with one
common interface. It uses the same API as the ranger (class
range_query), so there will now be one API for
Ping patch.
| Date: Tue, 18 May 2021 16:59:12 -0400
| Subject: [PATCH 2/2] Fix tests when running on power10, PR testsuite/100166
| Message-ID: <20210518205912.gb18...@ibm-toto.the-meissners.org>
--
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email:
Ping patch. This is independent of the other patches.
| Date: Tue, 18 May 2021 16:57:59 -0400
| Subject: [PATCH 1/2] Deal with prefixed loads/stores in tests, PR
testsuite/100166
| Message-ID: <20210518205759.ga18...@ibm-toto.the-meissners.org>
--
Michael Meissner, IBM
IBM, M/S 2506R, 550
Ping patch.
| Date: Tue, 18 May 2021 16:47:58 -0400
| Subject: [PATCH 2/2] Fix xxeval predicates.
| Message-ID: <20210518204758.gb16...@ibm-toto.the-meissners.org>
This needs the following patch to have been applied:
| Date: Tue, 18 May 2021 16:46:47 -0400
| Subject: [PATCH 1/2] Move xx*
Ping patch. This patch is a set of 2 patches. The second patch will need this
patch applied. In addition, the next 3 patches that I will be submitting (to
add support for generating XXSPLTIW, XXSPLTIDP, and XXSPLTI32DX) will need this
patch applied (or else I would just have to reformulate the
Ping patch. This is independent of the other patches.
| Date: Tue, 18 May 2021 16:39:28 -0400
| Subject: [PATCH] Change rs6000_const_f32_to_i32 return type.
| Message-ID: <20210518203928.ga15...@ibm-toto.the-meissners.org>
--
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100537
--- Comment #16 from Ian Lance Taylor ---
I have a patch for this.
Ping patch. This is independent of the other patches.
| Date: Tue, 18 May 2021 16:36:32 -0400
| Subject: [PATCH] Allow __ibm128 on older PowerPC systems.
| Message-ID: <20210518203632.ga15...@ibm-toto.the-meissners.org>
--
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA
Ping patch. This is independent of the other patches.
| Date: Tue, 18 May 2021 16:32:33 -0400
| Subject: [PATCH] Fix long double tests when default long double is not IBM.
| Message-ID: <20210518203233.ga15...@ibm-toto.the-meissners.org>
--
Michael Meissner, IBM
IBM, M/S 2506R, 550 King
Ping patch.
| Subject: [PATCH 2/2] Add IEEE 128-bit fp conditional move on PowerPC.
| Message-ID: <20210518202827.gb14...@ibm-toto.the-meissners.org>
Note this patch needs the following patch before it can be applied.
| Subject: [PATCH 1/2] Add IEEE 128-bit min/max support on PowerPC.
|
Ping patch:
| Subject: [PATCH 1/2] Add IEEE 128-bit min/max support on PowerPC.
| Message-ID: <20210518202606.ga14...@ibm-toto.the-meissners.org>
--
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99519
--- Comment #1 from Tobias Burnus ---
The patch was now committed as:
commit r12-1016-g0e3b3b77e13cac764a135a7118613c47686e0a62
Author: Tobias Burnus
Date: Mon May 24 16:50:51 2021 +0200
OpenMP/Fortran: Handle polymorphic scalars in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86470
--- Comment #16 from Tobias Burnus ---
(In reply to Tobias Burnus from comment #14)
> It looks as if the committed patch handles this specific testcase correctly,
> however, there are still many issues with PRIVATE and FIRSTPRIVATE with
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86470
--- Comment #15 from CVS Commits ---
The master branch has been updated by Tobias Burnus :
https://gcc.gnu.org/g:0e3b3b77e13cac764a135a7118613c47686e0a62
commit r12-1016-g0e3b3b77e13cac764a135a7118613c47686e0a62
Author: Tobias Burnus
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100744
--- Comment #2 from Raffael Casagrande ---
Oh, I didn't notice this change. Thanks for pointing this out!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100744
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100745
Bug ID: 100745
Summary: GCC generates suboptimal assembly from vector
extensions on AArch64
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
1 - 100 of 179 matches
Mail list logo
