https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105459
Kewen Lin changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at
on 2022/5/5 03:20, David Edelsohn wrote:
> I am pleased to announce that the GCC Steering Committee has
> appointed Kewen Lin as GCC PowerPC port Co-Maintainer.
>
Thanks a lot! It's a great honor for me!
> Please join me in congratulating Kewen on his new role.
> Kewen, please
Hi,
Add myself as PowerPC port co-maintainer and to DCO section. Pushed below as
r13-127.
ChangeLog:
* MAINTAINERS: Add myself as PowerPC port co-maintainer and to DCO
section.
---
MAINTAINERS | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/MAINTAINERS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105484
--- Comment #2 from Hongtao.liu ---
I'll take a look.
Optimize
_1 = *srcp_3(D);
_4 = VEC_PERM_EXPR <_1, _1, { 4, 5, 6, 7, 4, 5, 6, 7 }>;
_5 = BIT_FIELD_REF <_4, 128, 0>;
to
_1 = *srcp_3(D);
_5 = BIT_FIELD_REF <_1, 128, 128>;
the upper will finally be optimized to
_5 = BIT_FIELD_REF <*srcp_3(D), 128, 128>;
Bootstrapped and regtested on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105469
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105473
--- Comment #3 from harper at msor dot vuw.ac.nz ---
Thank you. Of course the program did not compile with -std=f95 because
there was no decimal='point' option then. But with -std=f2003 or f2008 or
f2018, and with or without n = 999 before the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105473
--- Comment #2 from Jerry DeLisle ---
I should add, I am not saying this is right or wrong. The error message refers
to F2003.
$ gfortran -std=f2003 pr105473.f90
[jerry@amdr pr105473]$ ./a.out
testinput = ";"
n= 999 ios=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105473
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle2 at gmail dot com
---
On 5/4/22 19:20, Marek Polacek wrote:
On Wed, May 04, 2022 at 05:44:45PM -0400, Jason Merrill wrote:
On 5/4/22 16:03, Marek Polacek wrote:
This patch fixes the second half of 64679. Here we issue a wrong
"redefinition of 'int x'" for the following:
struct Bar {
Bar(int, int, int);
On Wed, May 04, 2022 at 05:44:45PM -0400, Jason Merrill wrote:
> On 5/4/22 16:03, Marek Polacek wrote:
> > This patch fixes the second half of 64679. Here we issue a wrong
> > "redefinition of 'int x'" for the following:
> >
> >struct Bar {
> > Bar(int, int, int);
> >};
> >
> >
On Wed, May 4, 2022 at 1:59 AM Martin Liška wrote:
>
> Hello.
>
> I'm going to do merge from upstream.
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests. I've
> also tested
> on ppc64le-linux-gnu and verified the ABI.
>
> The only real change is a small change in
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105487
--- Comment #4 from Andrew Pinski ---
It is incorrect as that is required. Simple as that.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105487
--- Comment #3 from Paul Smith ---
There's nothing "incorrect" about a sysroot that doesn't have /usr/lib in it.
If you have a 64bit system and you don't need to run 32bit binaries, then
/usr/lib will be empty and everything will be in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105488
--- Comment #2 from Jonathan Wakely ---
See https://gcc.gnu.org/gcc-5/porting_to.html#inline
On Wed, 4 May 2022 at 12:14, Jonathan Wakely wrote:
>
> On Tue, 3 May 2022 at 11:57, Jakob Hasse via Libstdc++
> wrote:
> >
> > This is a patch for the bug 105387 reported in bugzilla: 105387
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105387. This report should
> > contain all the
Snapshot gcc-9-20220504 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/9-20220504/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 9 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105488
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105488
Bug ID: 105488
Summary: Function definition is not generated OR function is
not inlined
Product: gcc
Version: 11.1.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105387
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104470
--- Comment #7 from CVS Commits ---
The master branch has been updated by Jason Merrill :
https://gcc.gnu.org/g:a47ab705c2c9f07f08fde499d6be4682efe4b626
commit r13-124-ga47ab705c2c9f07f08fde499d6be4682efe4b626
Author: Jason Merrill
Date:
In my previous PR104470 patch I added yet another place that needs to handle
dependent member rewriting for deduction guides; this patches centralizes
rewriting into maybe_dependent_member_ref. tsubst_baselink still has its
own handling because that's simpler than teaching
On 5/4/22 16:03, Marek Polacek wrote:
This patch fixes the second half of 64679. Here we issue a wrong
"redefinition of 'int x'" for the following:
struct Bar {
Bar(int, int, int);
};
int x = 1;
Bar bar(int(x), int(x), int{x}); // #1
cp_parser_parameter_declaration_list does
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105487
--- Comment #2 from Andrew Pinski ---
I don't think there is anything GCC can do here really. If you don't have a
correct sysroot, it is not a GCC bug. Requring usr/lib is because all
directories are relative to that directory.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105487
--- Comment #1 from Paul Smith ---
Ugh, when I wrote "doesn't contain any 32bit values" I meant "doesn't contain
any 32bit files".
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105487
Bug ID: 105487
Summary: Sysroots without 32bit components cause mysterious
errors
Product: gcc
Version: 11.3.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105476
Patrick Palka changed:
What|Removed |Added
Target Milestone|--- |12.2
--- Comment #8 from Patrick Palka
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105476
--- Comment #7 from CVS Commits ---
The master branch has been updated by Patrick Palka :
https://gcc.gnu.org/g:8a98e3ff7e80bf2936f163d50309fd88d72564a0
commit r13-123-g8a98e3ff7e80bf2936f163d50309fd88d72564a0
Author: Patrick Palka
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105486
Bug ID: 105486
Summary: new test case gcc.dg/vect/bb-slp-pr104240.c from
r13-89-gb3e98eb3396e16 fails
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity:
On 2022-04-21 09:11, Kaz Kylheku wrote:
> libcpp/ChangeLog
> 2022-04-21 Kaz Kylheku
>
> This change introduces a pair of related macros
> __EXP_COUNTER__ and __UEXP_COUNTER__. These macros access
> integer values which enumerate macro expansions.
> They can be used for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100825
--- Comment #12 from Jonathan Wakely ---
At the very least, GCC should give better errors instead of just letting the
assembler complain. Clang tells you where the conflicting definitions come
from, e.g. for the code in comment 1:
1.C:7:23:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64679
--- Comment #4 from CVS Commits ---
The trunk branch has been updated by Marek Polacek :
https://gcc.gnu.org/g:a733dea9e7c39352ce9f72059938833eaa819467
commit r13-121-ga733dea9e7c39352ce9f72059938833eaa819467
Author: Marek Polacek
Date: Fri
This patch fixes the second half of 64679. Here we issue a wrong
"redefinition of 'int x'" for the following:
struct Bar {
Bar(int, int, int);
};
int x = 1;
Bar bar(int(x), int(x), int{x}); // #1
cp_parser_parameter_declaration_list does pushdecl every time it sees
a named
On Tue, May 03, 2022 at 04:43:05PM -0400, Jason Merrill via Gcc-patches wrote:
> On 5/2/22 12:18, Marek Polacek wrote:
> > Consider
> >
> >struct F {
> > F(int) {}
> > F operator()(int) const { return *this; }
> >};
> >
> > and
> >
> >F(i)(0)(0);
> >
> > where we're
isable-bootstrap
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 13.0.0 20220504 (experimental) [master r13-118-g4a206161072] (GCC)
If the index of a constructor_elt is a FIELD_DECL, the CONSTRUCTOR is
already reshaped, so we can save time and memory by returning immediately.
Tested x86_64-pc-linux-gnu, applying to trunk.
gcc/cp/ChangeLog:
* decl.cc (reshape_init): Shortcut already-reshaped init.
On 5/4/22 10:09, Patrick Palka wrote:
Here we're crashing from maybe_aggr_guide ultimately because
processing_template_decl isn't set when partially instantiating the
guide's parameter list. This causes us to prematurely force completion
of the dependent type Visitor_functior, which fails and
> On 4 May 2022, at 20:14, Martin Liška wrote:
>
> Right now, when a \$x escape sequence occures, the
> next character after $x is skipped, which is bogus.
>
> The code has very low coverage right now.
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>
> Ready to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105484
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Summary|[12/13
I am pleased to announce that the GCC Steering Committee has
appointed Kewen Lin as GCC PowerPC port Co-Maintainer.
Please join me in congratulating Kewen on his new role.
Kewen, please update your listing in the MAINTAINERS file.
Happy hacking!
David
Right now, when a \$x escape sequence occures, the
next character after $x is skipped, which is bogus.
The code has very low coverage right now.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed?
Thanks,
Martin
gcc/ChangeLog:
*
On 1/14/22 22:56, Jason Merrill wrote:
On 1/14/22 16:49, David Malcolm wrote:
On Mon, 2021-12-13 at 09:58 -0500, Jason Merrill via Gcc-patches wrote:
On 12/13/21 06:02, Jonathan Wakely wrote:
On Sun, 12 Dec 2021 at 05:39, Jason Merrill mailto:ja...@redhat.com>> wrote:
>
> In reading C++
There's no reason to call cxx_printable_name_translate here instead of using
%D in the format string.
Tested x86_64-pc-linux-gnu, applying to trunk.
gcc/cp/ChangeLog:
* error.c (cp_print_error_function): Use %qD.
(function_category): Use %qD.
---
gcc/cp/error.cc | 29
-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.0.0 20220504 (experimental) (GCC)
On 5/3/22 15:32, Joseph Myers wrote:
On Mon, 2 May 2022, David Faust via Gcc-patches wrote:
Consider the following example:
#define __typetag1 __attribute__((btf_type_tag("tag1")))
#define __typetag2 __attribute__((btf_type_tag("tag2")))
#define __typetag3
On Fri, Feb 18, 2022 at 11:13:16PM +, Hafiz Abid Qadeer wrote:
> An allocate clause in target region must specify an allocator
> unless the compilation unit has requires construct with
> dynamic_allocators clause. Current implementation of the allocate
> clause did not check for this
Hi Jakub,
On 04.05.22 14:03, Jakub Jelinek wrote:
On Wed, Apr 20, 2022 at 03:19:38PM +0200, Tobias Burnus wrote:
--- a/gcc/omp-low.cc
+++ b/gcc/omp-low.cc
@@ -13656,26 +13656,30 @@ lower_omp_target (gimple_stmt_iterator *gsi_p,
omp_context *ctx)
new_var = lookup_decl (var, ctx);
On Wed, May 04, 2022 at 06:16:14PM +0200, Tobias Burnus wrote:
> See also https://gcc.gnu.org/gcc-12/changes.html#languages and
> https://gcc.gnu.org/onlinedocs/gcc/C-Dialect-Options.html#index-foffload
>
> -foffload= was never officially documented, albeit most users will
> have encountered it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105436
--- Comment #10 from Jakub Jelinek ---
Thanks and sorry.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105476
Patrick Palka changed:
What|Removed |Added
Keywords||ice-on-valid-code
--- Comment #6 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105483
Bug ID: 105483
Summary: injected-class-name and constructors diagnostic
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105440
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0
See also https://gcc.gnu.org/gcc-12/changes.html#languages and
https://gcc.gnu.org/onlinedocs/gcc/C-Dialect-Options.html#index-foffload
-foffload= was never officially documented, albeit most users will
have encountered it. Since GCC 12 it is - but the -foffload=-
part is officially only handled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96765
Jason Merrill changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105436
Marek Polacek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105436
--- Comment #8 from CVS Commits ---
The trunk branch has been updated by Marek Polacek :
https://gcc.gnu.org/g:79a1a01cbd0e4a491d7078783131e3f88ca7158d
commit r13-115-g79a1a01cbd0e4a491d7078783131e3f88ca7158d
Author: Marek Polacek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104719
--- Comment #18 from Jonathan Wakely ---
No.
On 5/4/22 11:15, Marek Polacek wrote:
On Tue, May 03, 2022 at 04:46:11PM -0400, Jason Merrill wrote:
On 5/3/22 16:43, Jakub Jelinek wrote:
On Tue, May 03, 2022 at 04:26:51PM -0400, Jason Merrill wrote:
On 5/2/22 12:19, Marek Polacek wrote:
This patch fixes an oversight whereby we treated >=
On 04.05.22 17:12, Jakub Jelinek via Gcc-patches wrote:
Though, there is one gotcha, if we had code where we parsed some var first
and another one later and there was interdependence between the two, in
environ they can appear in any order.
I think for interdependence it depends whether in a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104719
cqwrteur changed:
What|Removed |Added
CC||unlvsur at live dot com
--- Comment #17
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104719
--- Comment #16 from CVS Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:22399ad6edcd4a2903b05196b59eec3159ceaa38
commit r13-114-g22399ad6edcd4a2903b05196b59eec3159ceaa38
Author: Jonathan Wakely
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104719
--- Comment #15 from CVS Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:ef8d5ac08b5e60f35c52087d88c0235c8ce6b65b
commit r13-113-gef8d5ac08b5e60f35c52087d88c0235c8ce6b65b
Author: Jonathan Wakely
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105470
--- Comment #12 from Jonathan Wakely ---
(In reply to Roland Hughes from comment #10)
> There is no definition of that map anywhere in the codebase where
> KeyModifiers is declared const.
That's just how std::map works.
std::map::value_type
On Tue, May 03, 2022 at 04:46:11PM -0400, Jason Merrill wrote:
> On 5/3/22 16:43, Jakub Jelinek wrote:
> > On Tue, May 03, 2022 at 04:26:51PM -0400, Jason Merrill wrote:
> > > On 5/2/22 12:19, Marek Polacek wrote:
> > > > This patch fixes an oversight whereby we treated >= as the end of
> > > > a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105436
Marek Polacek changed:
What|Removed |Added
CC||pdimov at gmail dot com
--- Comment #7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105482
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
On Tue, Jan 18, 2022 at 05:10:47PM +0100, Marcel Vollweiler wrote:
> Hi,
>
> This patch considers the environment variable syntax extension for
> device-specific variants of environment variables from OpenMP 5.1 (see
> OpenMP 5.1 specification, p. 75 and p. 639). An environment variable
> (e.g.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105482
Bug ID: 105482
Summary: Regression with `>=` in a template argument
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105410
Gaius Mulley changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
On Wed, 4 May 2022 15:31:32 +0200
Martin Liška wrote:
> On 5/4/22 15:10, Alexander Monakov wrote:
> > On Wed, 4 May 2022, Martin Liška wrote:
> >
> >> On 5/4/22 14:32, Alexander Monakov wrote:
> >>> On Wed, 4 May 2022, Martin Liška wrote:
> >>>
> The patch is a follow-up of the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105481
Marek Polacek changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105481
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Priority|P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105481
Bug ID: 105481
Summary: ICE: unexpected expression of kind template_parm_index
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'cpplib' has been submitted
by the Spanish team of translators. The file is available at:
https://translationproject.org/latest/cpplib/es.po
(This file,
cpplib-12.1-b20220213.es.po.gz
Description: Binary data
The Translation Project robot, in the
name of your translation coordinator.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105470
--- Comment #11 from Roland Hughes ---
(In reply to Marek Polacek from comment #9)
> (In reply to Roland Hughes from comment #8)
> > (In reply to Marek Polacek from comment #1)
> > > Can you please provide a stand-alone test case?
> >
> > I
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'cpplib' has been submitted
by the Spanish team of translators. The file is available at:
https://translationproject.org/latest/cpplib/es.po
(This file,
cpplib-12.1-b20220213.es.po.gz
Description: Binary data
The Translation Project robot, in the
name of your translation coordinator.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105470
--- Comment #10 from Roland Hughes ---
(In reply to Marek Polacek from comment #1)
>
> The warning is completely correct, and the code should be fixed.
>
> for ( const std::pair : someMap )
>
> This iterates over a map, with values of type:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105470
--- Comment #9 from Marek Polacek ---
(In reply to Roland Hughes from comment #8)
> (In reply to Marek Polacek from comment #1)
> > Can you please provide a stand-alone test case?
>
> I will work on this over the weekend.
Looks like that's
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105470
--- Comment #8 from Roland Hughes ---
(In reply to Marek Polacek from comment #1)
> Can you please provide a stand-alone test case?
I will work on this over the weekend.
> Yes this looks good to me (still needs maintainer approval).
Thanks again Wilco for your review.
> One minor nitpick,
> a few of the tests check for __aarch64_cas2 - this should be
> __aarch64_cas2_sync.
Fixed in the attached patch.
> Note the patch still needs an appropriate commit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105480
--- Comment #1 from seberg ---
Actually, I think I likely misanalyzed, the actual code in question where I
found this was doing something like:
while (n--) {
if (isnan(*input)) {
*out = 1;
}
else {
*out =
On 5/4/22 15:20, Andreas Schwab wrote:
> On Mai 04 2022, Martin Liška wrote:
>
>> diff --git a/gcc/gengtype-state.cc b/gcc/gengtype-state.cc
>> index ea566af3249..dfd9ea52785 100644
>> --- a/gcc/gengtype-state.cc
>> +++ b/gcc/gengtype-state.cc
>> @@ -473,43 +473,43 @@ read_a_state_token (void)
>>
Here we're crashing from maybe_aggr_guide ultimately because
processing_template_decl isn't set when partially instantiating the
guide's parameter list. This causes us to prematurely force completion
of the dependent type Visitor_functior, which fails and results in
an unexpected error_mark_node.
Jakub pointed out that cdtor_label is unnecessary, we should get all the
desired semantics with a normal return.
Tested x86_64-pc-linux-gnu and arm-eabi//arm-sim, applying to trunk.
gcc/cp/ChangeLog:
* cp-tree.h (struct language_function): Remove x_cdtor_label.
(cdtor_label,
On 04/05/2022 12:14, Richard Biener wrote:
On Wed, May 4, 2022 at 12:16 PM Richard Earnshaw via Gcc-patches
wrote:
Gimple isel already handles x CMP y ? -1 : 0 when lowering vector cond
operations, but this can be generalized further when the comparison
forms a natural mask so that we can
On 5/4/22 15:10, Alexander Monakov wrote:
> On Wed, 4 May 2022, Martin Liška wrote:
>
>> On 5/4/22 14:32, Alexander Monakov wrote:
>>> On Wed, 4 May 2022, Martin Liška wrote:
>>>
The patch is a follow-up of the discussion we've got in:
On Mai 04 2022, Martin Liška wrote:
> diff --git a/gcc/gengtype-state.cc b/gcc/gengtype-state.cc
> index ea566af3249..dfd9ea52785 100644
> --- a/gcc/gengtype-state.cc
> +++ b/gcc/gengtype-state.cc
> @@ -473,43 +473,43 @@ read_a_state_token (void)
> {
> case 'a':
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101392
--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #2 from Gaius Mulley ---
> I've just git pushed a fix to assign main_input_filename before each
> compilation. Tested on Debian/amd64 which passed with no regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104658
Richard Biener changed:
What|Removed |Added
Known to work||13.0
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105480
Bug ID: 105480
Summary: Vectorized `isnan` appears to trigger FPE on ppc64le
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103116
Richard Biener changed:
What|Removed |Added
Known to work||13.0
--- Comment #8 from Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104658
--- Comment #2 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:eca04dc8555f5fae462fbd16386da9aaf38a0711
commit r13-111-geca04dc8555f5fae462fbd16386da9aaf38a0711
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103116
--- Comment #7 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:52b7b86f8c72eb19e637f1e72ffd10f39b8cb829
commit r13-110-g52b7b86f8c72eb19e637f1e72ffd10f39b8cb829
Author: Richard Biener
Date:
On Wed, 4 May 2022, Richard Sandiford wrote:
> Richard Biener writes:
> > The testcase shows that we can end up with a contiguous access across
> > loop iterations but by means of permutations the elements accessed
> > might only cover parts of a vector. In this case we end up with
> >
On Wed, 4 May 2022, Martin Liška wrote:
> On 5/4/22 14:32, Alexander Monakov wrote:
> > On Wed, 4 May 2022, Martin Liška wrote:
> >
> >> The patch is a follow-up of the discussion we've got in:
> >> https://gcc.gnu.org/pipermail/gcc-patches/2022-May/593901.html
> >>
> >> Mold linker would
Richard Biener writes:
> The testcase shows that we can end up with a contiguous access across
> loop iterations but by means of permutations the elements accessed
> might only cover parts of a vector. In this case we end up with
> GROUP_GAP == 0 but still need to avoid accessing excess elements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103116
--- Comment #6 from rguenther at suse dot de ---
On Wed, 4 May 2022, rsandifo at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103116
>
> --- Comment #5 from rsandifo at gcc dot gnu.org
> ---
> (In reply to Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103116
--- Comment #5 from rsandifo at gcc dot gnu.org
---
(In reply to Richard Biener from comment #3)
> We could make peeling for gaps handle this by making it not a flag but
> indicate the number of vector(!?) iterations we need to peel.
I think
1 - 100 of 168 matches
Mail list logo
