https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94496
--- Comment #2 from Iain Buclaw ---
(In reply to Witold Baryluk from comment #1)
> We are close to making 'in' mean 'scope const', it is already available as a
> preview in dmd 2.092: https://dlang.org/changelog/2.092.0.html#preview-in
Indeed,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95119
Thomas Koenig changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95115
--- Comment #4 from Marc Glisse ---
(In reply to Jim Wilson from comment #3)
> The assumption here seems to be that if the user is
> dividing constants, then we don't need to worry about setting exception
> bits. If I write (4.0 / 3.0) for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95122
Bug ID: 95122
Summary: Cross-compile arm32 toolchain with hard float, but
Error in gcc final
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
There are some other cases that I cannot get right answer.
case1: interproceduure
func(int*arg)
{
return arg[0] + arg[1]
}
func2()
{
int a[10]
return func(a);
}
here func cannot tell arg is local var.
case 2: global array point to local
int *array[3]
int func(int x)
{
int sub1[10];
int sub2[10];
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95115
Jim Wilson changed:
What|Removed |Added
CC||wilson at gcc dot gnu.org
--- Comment #3
On 2020/5/13 02:24, Richard Sandiford wrote:
> luoxhu writes:
>> + /* Fold (add -1; zero_ext; add +1) operations to zero_ext. i.e:
>> +
>> + 73: r145:SI=r123:DI#0-0x1
>> + 74: r144:DI=zero_extend (r145:SI)
>> + 75: r143:DI=r144:DI+0x1
>> + ...
>> + 31: r135:CC=cmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95121
--- Comment #5 from Andrew Pinski ---
(In reply to Joseph C. Sible from comment #3)
> Also, is that documented to work that way anywhere? I didn't notice anything
> in the manual to that effect.
Register names seems not to be documented,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95121
--- Comment #4 from Andrew Pinski ---
(In reply to Joseph C. Sible from comment #2)
> Does this mean that Clang is wrong, then? Because it works the way I
> wanted/expected.
Depends, this is a GNU extension.
On Thu, May 14, 2020 at 1:46 AM Jakub Jelinek via Gcc-patches
wrote:
>
> On Wed, May 13, 2020 at 02:00:11PM +0200, Christophe Lyon via Gcc-patches
> wrote:
> > > > 2020-05-11 Bin Cheng
> > > >
> > > > PR tree-optimization/94969
> > > > * gcc.dg/tree-ssa/pr94969.c: New test.
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95121
--- Comment #3 from Joseph C. Sible ---
Also, is that documented to work that way anywhere? I didn't notice anything in
the manual to that effect.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95121
--- Comment #2 from Joseph C. Sible ---
Does this mean that Clang is wrong, then? Because it works the way I
wanted/expected.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95121
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
Thanks, I patch a version, it can give a heap variable info.
Now the curious is the patch version cannot give right answer for variable
length array. for example，
int func(int m, int n)
{
int array[m][n];
...
}
here array is allocated by alloca, obviously a local variable.
But the original
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95121
Bug ID: 95121
Summary: Wrong code generated: low-byte registers are silently
used in place of their corresponding high-byte
registers (ah, bh, ch, dh)
Product: gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95120
--- Comment #2 from Witold Baryluk ---
Created attachment 48530
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48530=edit
Minimized example
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95120
--- Comment #1 from Witold Baryluk ---
Further minimized:
==
import std.stdio;
import std.algorithm.comparison : min;
int main() {
return std.algorithm.comparison.min(3, 2);
}
==
Removing `import std.stdio;`, results in the same
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95118
--- Comment #4 from Adrien Dessemond ---
The hang also happens with "-O2 -ftree-vectorize -fopt-info-vec"
I confirm that removing "-fopt-info-vec" avoids the hang.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95120
Bug ID: 95120
Summary: [D] Incorrectly allows fqdn access to imported symbols
when doing selective imports.
Product: gcc
Version: 10.1.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94496
Witold Baryluk changed:
What|Removed |Added
CC||witold.baryluk+gcc at gmail
dot co
On Tue, 12 May 2020 16:53:14 PDT (-0700), Jim Wilson wrote:
This fixes a bug reported to the RISC-V sw-dev mailing list late last year.
https://groups.google.com/a/groups.riscv.org/forum/#!topic/sw-dev/JV5Jdh4UjVw
Keith Packard wote the obvious patch to fix it. I tested it with cross builds
On Wed, 13 May 2020, Rainer Orth wrote:
> > I'm in favour of requiring 1.5.3 or later, so 1.6 would be OK for me.
>
> If we go beyond 1.5.x, we need to go all the way up to 1.6.2: 1.6 and
> 1.6.1 have an ugly bug that can miss timeouts, causing tests to hang
> indefinitely until one manually
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95118
Sergei Trofimovich changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95119
--- Comment #1 from Bill Long ---
Appears to be a regression.
The original submitter thinks it is hanging in __lll_lock_wait inside CLOSE.
Th same hang can be observed if the references to omp_get_num_threads are
removed, but you still
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95119
Bug ID: 95119
Summary: CLOSE hangs when -fopenmp is specified in compilation
Product: gcc
Version: 9.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95053
--- Comment #19 from Bill Seurer ---
There's some stuff above this in the module but this is the part that shows the
error and I think it contains all the declarations.
subroutine Z()
real(r8) :: cld(99,99)
real(r8) cldeps
parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95118
--- Comment #2 from Sergei Trofimovich ---
Seems to be a regression since gcc-9.3.0.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95118
--- Comment #1 from Sergei Trofimovich ---
Created attachment 48528
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48528=edit
bug.c
--disable-libsanitizer --disable-libvtv
--disable-libgomp --disable-libstdcxx-pch --disable-libunwind-exceptions
CFLAGS='-O1 ' CXXFLAGS='-O1 ' --with-sysroot=/usr/x86_64-HEAD-linux-gnu
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.0.0 20200513 (experimental) (GCC)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95053
--- Comment #18 from Bill Seurer ---
I am still cutting down the code but this should answer the question about if
it really could be zero:
if (cldeps > 0) then
do k = k1,k2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81827
Luke Robison changed:
What|Removed |Added
CC||robison at arlut dot utexas.edu
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95115
--- Comment #2 from Marc Glisse ---
Or during CCP with the simpler
double f(){
double d=__builtin_inf();
return d/d;
}
and all the -frounding-math -ftrapping-math -fsignaling-nans don't seem to
help.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95115
--- Comment #1 from Marc Glisse ---
I am seeing the same thing on x86_64, happens during FRE1, so it looks like
tree-optimization.
Hi!
On Wed, May 13, 2020 at 07:50:50AM -0500, Bill Schmidt wrote:
> From: Kelvin Nilsen
>
> Add new insns vextdu[bhw]vlx, vextddvlx, vextdu[bhw]vhx, and
> vextddvhx, along with built-in access and overloaded built-in
> access to these insns.
>
> Changes from previous patch:
> * Removed the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79706
Patrick Palka changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79706
--- Comment #6 from CVS Commits ---
The master branch has been updated by Patrick Palka :
https://gcc.gnu.org/g:4924293a62ee797310dd448e545118afd5aebb3f
commit r11-373-g4924293a62ee797310dd448e545118afd5aebb3f
Author: Patrick Palka
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95117
Bug ID: 95117
Summary: Segmentation fault with static await_ready() or
await_resume()
Product: gcc
Version: 10.1.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95020
--- Comment #2 from CVS Commits ---
The master branch has been updated by Patrick Palka :
https://gcc.gnu.org/g:7e52f8b1e03776575b92574252d9b6bbed9f1af4
commit r11-372-g7e52f8b1e03776575b92574252d9b6bbed9f1af4
Author: Patrick Palka
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95116
--- Comment #2 from Owen Smith ---
Ah ok thanks, I didn't know about P0634R3 :D.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95066
--- Comment #5 from CVS Commits ---
The master branch has been updated by Marek Polacek :
https://gcc.gnu.org/g:661232da72d29f8f2385d5f588727beb74360144
commit r11-371-g661232da72d29f8f2385d5f588727beb74360144
Author: Marek Polacek
Date:
When fixing up the template specialization hasher I was confused by the
control flow through template_args_equal. This reorders the category
checking, so it is clearer as to what kind of node can reach which point.
nathan
--
Nathan Sidwell
2020-05-13 Nathan Sidwell
* pt.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95111
--- Comment #10 from Avi Kivity ---
Well, the standard is useless here.
In
[foo] () -> lazy { co_return foo; } ()
a temporary is clearly passed to the lambda body, yet the standard mandates
that we capture it by reference. As a result, a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64636
Viktor Ostashevskyi changed:
What|Removed |Added
CC||ostash at ostash dot kiev.ua
---
I discovered template typedef access checking was more expensive than it
need be. The call of get_types_needed_access_check in the
FOR_EACH_VEC_SAFE_ELT is the moral equivalent of
for (size_t pos = 0; pos != strlen (string); pos++)'
Let's not do that.
nathan
--
Nathan Sidwell
2020-05-13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95111
Iain Sandoe changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |iains at gcc dot gnu.org
---
Canonical_type_parameter shows C-like thinking. This modernizes it,
which I found simpler to understand.
pushed to master
nathan
--
Nathan Sidwell
2020-05-13 Nathan Sidwell
* pt.c (canonical_type_parameter): Simplify.
diff --git i/gcc/cp/pt.c w/gcc/cp/pt.c
index a732ced2d8d..a36f603761c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95116
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95111
--- Comment #7 from Avi Kivity ---
I have a simple reproducer. A lambda fails while a fake lambda using structs
passes. I don't think gcc is at fault, but the standard is problematic here
IMO.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95111
--- Comment #8 from Avi Kivity ---
Created attachment 48526
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48526=edit
less lame testcase
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95116
Bug ID: 95116
Summary: [C++ 20] Accepts invalid code with decltype dependent
type
Product: gcc
Version: 9.3.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95115
Bug ID: 95115
Summary: [10 Regression] RISC-V 64: inf/inf division optimized
out, invalid operation not raised
Product: gcc
Version: 10.1.0
Status: UNCONFIRMED
I've committed this set of minor cleanups from the modules branch.
nathan
--
Nathan Sidwell
2020-05-13 Nathan Sidwell
Formatting fixups & some simplifications.
* pt.c (spec_hash_table): New typedef.
(decl_specializations, type_specializations): Use it.
(retrieve_specialization):
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95111
--- Comment #6 from Iain Sandoe ---
(In reply to Avi Kivity from comment #5)
> This snippet from cppreference:
>
> If the coroutine is a non-static member function, such as task
> my_class::method1(int x) const;, its Promise type is
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95111
--- Comment #5 from Avi Kivity ---
This snippet from cppreference:
If the coroutine is a non-static member function, such as task
my_class::method1(int x) const;, its Promise type is
std::coroutine_traits, const my_class&,
On 5/11/20 6:43 PM, Patrick Palka wrote:
In the testcase below we're prematurely folding away the
requires-expression to 'true' after substituting in the function's
template arguments, but before substituting in the lambda's deduced
template arguments.
This happens because during the first
On 5/11/20 7:06 PM, Marek Polacek wrote:
I forgot to set DECL_HAS_DEPENDENT_EXPLICIT_SPEC_P when merging two
function declarations and as a sad consequence, we never tsubsted
the dependent explicit-specifier in tsubst_function_decl, leading to
disregarding the explicit-specifier altogether, and
On 5/12/20 11:36 PM, Patrick Palka wrote:
This fixes SFINAE when substitution yields an invalid delete-expression
due to the pertinent deallocation function being marked deleted or
otherwise inaccessible.
We need to check for an erroneous result from build_op_delete_call and
exit early in that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95111
--- Comment #4 from Iain Sandoe ---
(In reply to Avi Kivity from comment #3)
> The test case I uploaded only shows the failure, it won't work if gcc worked
> as I expect it. I'll try to get a better testcase, unfortunately a small
> coroutine
I'm not sure why I didn't check this in along with adding -std=c++20, since
I wrote this patch at the same time. The testsuite should support both
{ target c++2a } and { target c++20 }.
Tested x86_64-pc-linux-gnu, applying to trunk and 10.
gcc/testsuite/ChangeLog
2020-05-13 Jason Merrill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95111
--- Comment #3 from Avi Kivity ---
The test case I uploaded only shows the failure, it won't work if gcc worked as
I expect it. I'll try to get a better testcase, unfortunately a small coroutine
testcase is still some work.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95111
--- Comment #2 from Avi Kivity ---
Created attachment 48524
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48524=edit
lame testcase
Lame testcase that shows that the lambda is passed as a pointer rather than by
value, leading to a leak if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95111
--- Comment #1 from Iain Sandoe ---
There are some gotchas with coroutines and references (both regular and
rvalue).
* there could still be a bug here, so I want to double-check.
Please could you expand your snippets of code into a small
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95114
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95114
Bug ID: 95114
Summary: [9/10/11 Regression] ICE in obj_type_ref_class for
structural-equality types
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #212 from dave.anglin at bell dot net ---
On 2020-05-13 2:03 p.m., jared.martinsen at fiserv dot com wrote:
> --- Comment #211 from Jared ---
> Are these errors the same as described above?
>
> It give the following 2 errors:
> ld:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94024
Patrick Palka changed:
What|Removed |Added
CC||ppalka at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95108
Jakub Jelinek changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95061
Ian Lance Taylor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
This libgo patch builds the syscall test with -static. This avoids
problems finding libgo.so when running the test as root, which invokes
the test as a child process in various limited environments. This
fixes GCC PR 95061. Bootstrapped and ran Go tests on
x86_64-pc-linux-gnu. Committed to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95061
--- Comment #4 from CVS Commits ---
The master branch has been updated by Ian Lance Taylor :
https://gcc.gnu.org/g:0d5d880994660e231f82b7cb1dcfab744158f7e0
commit r11-364-g0d5d880994660e231f82b7cb1dcfab744158f7e0
Author: Ian Lance Taylor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95113
--- Comment #3 from Arseny Solokha ---
(In reply to Jakub Jelinek from comment #2)
> Guess dup of the other PR where the IPA opts assume DCE which doesn't really
> happen (the *p load result is never used).
Indeed, -fno-ipa-sra fixes it. So, a
Jonathan Wakely via Gcc writes:
>> I had previously approved the update to 1.5.3, but no one really wanted
>> it as no one updated the requirement. Let's have the 1.6 discussion.
>> I'm not only inclined to up to 1.6, but to actually edit it in this time.
>
> Would the tests actually refuse to
On 5/13/20 10:51 AM, Mike Stump wrote:
> So, now that ubuntu 20.04 is out and RHEL 8 is out, and they both
> contain 6, and SLES has 6 and since we've been sitting at 1.4.4 for
> so long, anyone want to not update dejagnu to require 1.6?
We do still find and fix bugs occasionally. :-) And
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95101
Thomas Koenig changed:
What|Removed |Added
Ever confirmed|0 |1
Assignee|unassigned at gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95113
Jakub Jelinek changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org,
This libbacktrace patch marks the state parameter of test_large in
ztest.c as ATTRIBUTE_UNUSED. The parameter is not used if HAVE_ZLIB
is not defined. Bootstrapped and ran libbacktrace tests on
x86_64-pc-linux-gnu. Committed to mainline.
Ian
2020-05-13 Ian Lance Taylor
* ztest.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95113
Jakub Jelinek changed:
What|Removed |Added
Last reconfirmed||2020-05-13
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
Jared changed:
What|Removed |Added
CC||jared.martinsen at fiserv dot
com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95113
Bug ID: 95113
Summary: [10/11 Regression] Wrong code w/ -O2 -fexceptions
-fnon-call-exceptions
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords:
On Wed, 13 May 2020, Martin Liška wrote:
> I'm sending the gcc-changelog relates scripts which should be added to contrib
> folder. The patch contains:
> - git_check_commit.py - checking script that verifies git message format
We need a documentation patch to contribute.html or gitwrite.html
On Wed, 13 May 2020, Martin Liška wrote:
> I'm sending the gcc-changelog relates scripts which should be added to contrib
> folder. The patch contains:
> - git_check_commit.py - checking script that verifies git message format
We need a documentation patch to contribute.html or gitwrite.html
On 12/05/2020 23:33, Jim Wilson wrote:
> On Mon, Apr 27, 2020 at 10:08 AM Craig Blackmore
> wrote:
>> Thanks for the review. I have updated the following patch with those changes.
> This looks good, and the tree is open for development work again, so I
> committed both parts 1 and 2 and pushed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95108
Jakub Jelinek changed:
What|Removed |Added
Last reconfirmed||2020-05-13
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95112
Bug ID: 95112
Summary: i386 procedures have prolog endbr32
Product: gcc
Version: 9.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
On Wed, 13 May 2020 at 18:19, Mike Stump via Gcc wrote:
>
> I've changed the subject to match the 2015, 2017 and 2018 email threads.
>
> On May 13, 2020, at 3:26 AM, Thomas Schwinge wrote:
> >
> > Comparing DejaGnu/GCC testsuite '*.sum' files between two systems ("old"
> > vs. "new") that ought
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95111
Bug ID: 95111
Summary: coroutines use-after-free with lambdas
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90320
Marek Polacek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95061
--- Comment #3 from CVS Commits ---
The master branch has been updated by Ian Lance Taylor :
https://gcc.gnu.org/g:702adbb2fff0cc043f9c4e1af890421cb238cd18
commit r11-362-g702adbb2fff0cc043f9c4e1af890421cb238cd18
Author: Ian Lance Taylor
Please find attached a patch for PR94397.
Commit message:
Fortran : "type is( real(kind(1.)) )" spurious syntax error PR94397
Based on a patch in the comments of the PR. That patch fixed this problem
but caused the test cases for PR93484 to fail. Changed to reduce
initialisation expressions
On Wed, May 13, 2020 at 02:00:11PM +0200, Christophe Lyon via Gcc-patches wrote:
> > > 2020-05-11 Bin Cheng
> > >
> > > PR tree-optimization/94969
> > > * gcc.dg/tree-ssa/pr94969.c: New test.
>
> The new test fails on arm and aarch64 and probably everywhere:
>
This patch to libbacktrace treats an EACCES error when opening a file
like an ENOENT error. This case happens when running the libgo
syscall tests as root, when testing various ways of restricting a
child process. Bootstrapped and ran libbacktrace and Go tests on
x86_64-pc-linux-gnu. Committed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95110
--- Comment #1 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:287552950d56be47adb6b6bf2eae2d612233eaec
commit r11-361-g287552950d56be47adb6b6bf2eae2d612233eaec
Author: Jakub Jelinek
Date:
GCC maintainers:
This is a resend of "[PATCH]rs6000, fix vec_first_match_index for
nulls".
Per the received comments the pr number was added to the subject line.
I also tweaked the message to make it clear that the patch fixed issues
with vectors whose elements contain zeros rather then a zero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95109
--- Comment #1 from Tobias Burnus ---
Confirmed – see PR 94690 comment 10.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95110
Bug ID: 95110
Summary: new test case in r11-345 error:
gcc.dg/tree-ssa/pr94969.c: dump file does not exist
Product: gcc
Version: 11.0
Status: UNCONFIRMED
On Wed, May 13, 2020 at 9:56 AM Mike Stump via Gcc wrote:
>
> As seen in recent bug report:
>
> CVS Commits 2020-05-12 20:40:40 UTC
>
> I guess that git thing was a bust and we're back to using cvs now. At least
> Ian did up the remote patches to make cvs work better.
In fairness, I worked
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94690
--- Comment #10 from Tobias Burnus ---
Created attachment 48522
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48522=edit
Patch to add OpenMP 5 feature (private + lastprivate permitted for 'simd')
The patch solves an independent issue,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95003
Iain Sandoe changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
As seen in recent bug report:
CVS Commits 2020-05-12 20:40:40 UTC
I guess that git thing was a bust and we're back to using cvs now. At least
Ian did up the remote patches to make cvs work better.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95109
Bug ID: 95109
Summary: [11 regression] ICE in gfortran.dg/gomp/target1.f90
after r11-349
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
1 - 100 of 242 matches
Mail list logo
