Richard Biener writes:
> On Thu, May 28, 2020 at 4:37 PM Jiufu Guo wrote:
>>
>> Richard Biener writes:
>>
>> > On Thu, May 28, 2020 at 10:52 AM guojiufu wrote:
>> >>
>> >> From: Jiufu Guo
>> >>
>> >> Currently GIMPLE complete unroller(cunroll) is checking
>> >> flag_unroll_loops and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95401
Bug ID: 95401
Summary: GCC produces incorrect instruction with -O3 for
skylake-avx512
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Hi Alan,
On Thu, May 28, 2020 at 7:53 PM Alan Modra via Gcc wrote:
>
> On Thu, May 28, 2020 at 10:12:04AM -0700, augustine.sterling--- via Gcc wrote:
> > After a long run as the Xtensa port maintainer, it is time for me to move
> > on.
> >
> > I nominate Max Filippov [cc'd] as the new
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95400
Bug ID: 95400
Summary: -march=native and -march=icelake-client produce
different results on icelake client
Product: gcc
Version: 9.2.1
Status: UNCONFIRMED
Segher Boessenkool writes:
> Hi!
>
> On Thu, May 28, 2020 at 04:22:16PM +0200, Richard Biener wrote:
>> For GIMPLE level transforms I don't think targets have more knowledge
>> than the middle-end.
>
> Yes, certainly.
>
>> In fact GIMPLE complete unrolling is about
>> secondary effects, removing
happen?
> >
> > This is due to define_subst magic. The generators automatically
> > create a vec_merge form of the instruction based on the information
> > in the attributes.
> >
> > AFAICT the rtl above is for the line-125 instruction, which looks ok.
> >
Hi,
Please find attached the patch that addresses PR94882.
Bootstrapped and regression tested on x86_64-pc-linux-gnu.
Thanks,
Naveen
match.pd: (x & y) - (x | y) - 1 -> ~(x ^ y) simplification [PR94882]
2029-05-04 Naveen H S
PR tree-optimization/94882
* match.pd (x & y) -
On Thu, May 28, 2020 at 10:12:04AM -0700, augustine.sterling--- via Gcc wrote:
> After a long run as the Xtensa port maintainer, it is time for me to move
> on.
>
> I nominate Max Filippov [cc'd] as the new maintainer. He has contributed
> numerous patches over the years which have required
Hi Martin,
On Thu, May 28, 2020 at 06:21:39PM -0600, Martin Sebor wrote:
> Although few tests bother with it, since you add an option for
> the existing warning where there was none before, an even more
> exhaustive test than the one you added would also verify the same
> option can be used to
On 2020-05-25, Martin Liška wrote:
On 5/22/20 6:42 AM, Fangrui Song wrote:
but I can't fix this one because joining two lines will break the 80-column
rule.
What about this:
diff --git a/gcc/collect2.c b/gcc/collect2.c
index cc57a20e08b..e5b54b080f7 100644
--- a/gcc/collect2.c
+++
When AIX added 64 bit support, it implemented what Apple MacOS Darwin
calls "FAT" libraries for its equivalent functionality -- both 32 bit
and 64 bit objects (or shared objects) are co-located in the same
archive. GCC on AIX historically has followed the GCC multilib
directory hierarchy approach
On 5/28/20 5:16 PM, Mark Wielaard wrote:
There are two warnings that might trigger when a builtin function is
used but not declared yet. Both called through implicitly_declare in
c-decl. The first in implicit_decl_warning does warn for builtins,
but does not add a fixit hint for them (only for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95399
Bug ID: 95399
Summary: [ARM, AArch64] 32/64-bit vcvtnq_* functions are
missing
Product: gcc
Version: 10.1.1
Status: UNCONFIRMED
Severity: normal
On May 28, 2020, Andrew Stubbs wrote:
> On 27/05/2020 15:46, Andrew Stubbs wrote:
>> I'm testing amdgcn-amdhsa, and I get lot of PCH test failures with
>> errors like this:
>>
>> gcc.dg/pch/common-1.c:1:22: error: one or more PCH files were found,
>> but they were invalid
>>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95090
--- Comment #8 from Manfred Schwarb ---
I even tried "char tmp[2*GFC_MAX_SYMBOL_LEN+800];" but it
still fails.
Hi,
On Mon, May 25, 2020 at 12:26:33PM -0400, Jason Merrill wrote:
> On 5/23/20 8:30 PM, Mark Wielaard wrote:
> > When reporting an error in cp_parser and we notice a string literal
> > followed by an unknown name check whether there is a known standard
> > header containing a string macro with
Barry pointed out to me that our braced-init-list as a template-argument
extension doesn't work as expected when we aggregate-initialize. Thus
fixed by calling digest_init in convert_nontype_argument so that we can
actually convert the CONSTRUCTOR.
I don't think we can call digest_init any
There are two warnings that might trigger when a builtin function is
used but not declared yet. Both called through implicitly_declare in
c-decl. The first in implicit_decl_warning does warn for builtins,
but does not add a fixit hint for them (only for non-builtins when
a header is suggested
On Thu, 7 May 2020 08:18:31 +0100
Sergei Trofimovich via Gcc-patches wrote:
> On Wed, 22 Apr 2020 23:05:38 +0100
> Sergei Trofimovich wrote:
>
> > From: Sergei Trofimovich
> >
> > On system with 'ar' and '${CHOST}-ar' the latter is preferred.
> > as it might not match default 'ar'.
> >
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94657
Sergei Trofimovich changed:
What|Removed |Added
Resolution|--- |FIXED
On Thu, May 28, 2020 at 05:01:51PM -0400, Jason Merrill wrote:
> On 5/26/20 8:25 PM, Marek Polacek wrote:
> > Since r267272, which added location wrappers, cp_fold loses
> > TREE_NO_WARNING on a MODIFY_EXPR that finish_parenthesized_expr set, and
> > that results in a bogus -Wparentheses warning.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95379
--- Comment #13 from Asher Gordon ---
Do you think that it would be possible to add something like Sparse's
-Wno-universal-initializer and use it by default? As Linus says here[1], Sparse
defaults tend to be kernel-centric, but I don't think
Snapshot gcc-8-20200528 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/8-20200528/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 8 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95328
--- Comment #3 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:3d8d5ddb539a5254c7ef83414377f4c74c7701d4
commit r11-706-g3d8d5ddb539a5254c7ef83414377f4c74c7701d4
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95398
--- Comment #1 from Steve Kargl ---
On Thu, May 28, 2020 at 09:33:08PM +, kargl at gcc dot gnu.org wrote:
>
> Code posted at
>
> https://groups.google.com/forum/#!topic/comp.lang.fortran/mW1gV6tyxXk
Here's the code
implicit none
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95381
--- Comment #3 from John Paul Adrian Glaubitz ---
(In reply to John Paul Adrian Glaubitz from comment #2)
> (In reply to Richard Biener from comment #1)
> > can we have a backtrace?
>
> Working on it.
I'm at the point now where I can invoke
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95398
Bug ID: 95398
Summary: ICE on invalid code
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95379
--- Comment #12 from Asher Gordon ---
(In reply to Luc Van Oostenryck from comment #11)
> Sparse already has this option. Also, I don't think it would help here since
> from I understand the OP want these warnings but not if they're caused by
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95397
Bug ID: 95397
Summary: [Fortran/OpenACC] Wrong results with 'loop vector'
inside 'routine'
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: openacc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95379
--- Comment #11 from Luc Van Oostenryck ---
(In reply to Andrew Pinski from comment #10)
> GCC uses -Wno-designated-init to disable the warning (this option has been
> there included for a while)? Do you think sparse could add/use the same
>
On 5/26/20 8:25 PM, Marek Polacek wrote:
Since r267272, which added location wrappers, cp_fold loses
TREE_NO_WARNING on a MODIFY_EXPR that finish_parenthesized_expr set, and
that results in a bogus -Wparentheses warning.
I.e., previously we had "b = 1" but now we have "VIEW_CONVERT_EXPR(b) = 1"
Hello gcc team,
I have sent the following proposals to the committee, but they require them to
be implemented at least into two major compilers, so I am proposing them to be
implemented into gcc. This is going to be a rather lengthy e-mail, so TL;DR:
Proposal 1: New pointer-proof keyword
On 5/27/20 4:50 AM, Jakub Jelinek wrote:
Hi!
Two years ago Paolo has added the
else if (processing_template_decl && !COMPLETE_TYPE_P (type))
pedwarn (...);
lines into cp_finish_decomp. For type dependent decl we punt much earlier,
but even for types which aren't type dependent
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95379
--- Comment #10 from Andrew Pinski ---
(In reply to Luc Van Oostenryck from comment #9)
> In fact, sparse already support the suppression of the warning via the
> option '-Wno-universal-initializer'.
>
> It's really very recent and thus only in
On Thu, 2020-05-28 at 16:51 -0300, Nicolas Bértolo wrote:
> > I'm going to have to trust your Windows expertise here; the tempdir
> > code looks convoluted to me, but perhaps that's the only way to do
> it.
> > (Microsoft's docs for "SECURITY_ATTRIBUTES" suggest to me that if
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95396
Bug ID: 95396
Summary: GCC produces incorrect code with -O3 for loops
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95369
Marek Polacek changed:
What|Removed |Added
Last reconfirmed||2020-05-28
On 5/27/20 5:15 PM, Patrick Palka wrote:
On Wed, 27 May 2020, Patrick Palka wrote:
On Wed, 27 May 2020, Patrick Palka wrote:
In the testcase below, the CONSTRUCTOR for 'field' contains a
RANGE_EXPR index:
{aggr_init_expr<...>, [1...2]={.off=1}}
but get_or_insert_ctor_field isn't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95259
H.J. Lu changed:
What|Removed |Added
URL||https://gcc.gnu.org/piperma
On 5/28/20 11:03 AM, Patrick Palka wrote:
When parsing a constraint-expression, a requires-clause or a
requires-expression, we temporarily increment processing_template_decl
so that we always obtain template trees which we later reduce via
substitution even when not inside a template.
But
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95373
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|
The obvious patch attached was already OKed in the PR by Steve Kargl.
As it is a 9/10/11 regression, I will backport it in a few days.
Thanks,
Harald
PR fortran/95373 - [9/10/11 Regression] ICE in build_reference_type, at
tree.c:7942
The use of KIND, LEN, RE, and IM inquiry references for
On 27/05/2020 15:46, Andrew Stubbs wrote:
I'm testing amdgcn-amdhsa, and I get lot of PCH test failures with
errors like this:
gcc.dg/pch/common-1.c:1:22: error: one or more PCH files were found, but
they were invalid
gcc.dg/pch/common-1.c:1:22: error: use -Winvalid-pch for more information
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95373
--- Comment #5 from CVS Commits ---
The master branch has been updated by Harald Anlauf :
https://gcc.gnu.org/g:5c715e6a2990cfb6c15acc1ee14219523534ec69
commit r11-705-g5c715e6a2990cfb6c15acc1ee14219523534ec69
Author: Harald Anlauf
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95393
--- Comment #2 from Gabriel Ravier ---
Hm, I've just done some further testing and it appears that it only occurs for
me on x86 when I have `-msse4.1` on the command line, in which case it doesn't
optimize it to `return s;`, but instead does a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95104
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95104
--- Comment #16 from CVS Commits ---
The releases/gcc-9 branch has been updated by Harald Anlauf
:
https://gcc.gnu.org/g:0d607ecbf125551513e182a181ca9c6e25dc7609
commit r9-8633-g0d607ecbf125551513e182a181ca9c6e25dc7609
Author: Harald Anlauf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95395
Rainer Orth changed:
What|Removed |Added
Target Milestone|--- |11.0
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95395
Bug ID: 95395
Summary: gcc.dg/builtin-bswap-11.c FAILs
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95353
Martin Sebor changed:
What|Removed |Added
Known to fail||10.1.0, 11.0
Summary|[10/11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95104
--- Comment #15 from CVS Commits ---
The releases/gcc-10 branch has been updated by Harald Anlauf
:
https://gcc.gnu.org/g:e1396ee72e68cc8fba99ce986f2910cd39e335b8
commit r10-8202-ge1396ee72e68cc8fba99ce986f2910cd39e335b8
Author: Harald Anlauf
Dear all,
> I think the second one is more robust - like you say, this may catch
> other cases. If we have that one, we don't need the first one.
to fix the fallout I've committed to master the following patch,
which I will backport to the affected branches (9/10):
PR fortran/95104 - Segfault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95104
--- Comment #14 from CVS Commits ---
The master branch has been updated by Harald Anlauf :
https://gcc.gnu.org/g:6ce3d791dfcba469e709935aba5743640f7d4959
commit r11-704-g6ce3d791dfcba469e709935aba5743640f7d4959
Author: Harald Anlauf
Date:
> I'm going to have to trust your Windows expertise here; the tempdir
> code looks convoluted to me, but perhaps that's the only way to do it.
> (Microsoft's docs for "SECURITY_ATTRIBUTES" suggest to me that if
> lpSecurityDescriptor is NULL, then the directory gets a default
> security
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95389
--- Comment #2 from Ulrich Teichert ---
Yes, the string "vendor/k8s.x2eio/code-generator/pkg/util" is the content of
the PkgPath() from "vendor/k8s.io/code-generator/pkg/util".
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95379
Luc Van Oostenryck changed:
What|Removed |Added
CC||luc.vanoostenryck at gmail dot
com
On Wed, 2020-05-27 at 22:27 -0300, Nicolas Bértolo wrote:
> Hi,
>
> > Do you have commit/push access to the gcc repository?
>
> No I don't.
>
> > BTW, why isn't it necessary to use --enable-host-shared in Windows?
> > Can we document that?
>
> That's because all code is position independent in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94926
Jason Merrill changed:
What|Removed |Added
Resolution|--- |FIXED
Target Milestone|9.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94926
--- Comment #2 from CVS Commits ---
The master branch has been updated by Jason Merrill :
https://gcc.gnu.org/g:7b599b9f9a1e036ff75a4daa06ac7036c6ebbe01
commit r11-703-g7b599b9f9a1e036ff75a4daa06ac7036c6ebbe01
Author: Jason Merrill
Date:
In r9-297 I was trying to be more flexible and treat static data members of
class templates more like variable templates, where the type need not be
determined until the variable is instantiated, but I suppose that in a class
the types of all the non-template members need to be determined at the
Hi Harald,
There are two possible fixes for this:
(1) guard the call to unlock_unit by:
diff --git a/libgfortran/io/transfer.c b/libgfortran/io/transfer.c
index cd51679ff46..296be0711a2 100644
--- a/libgfortran/io/transfer.c
+++ b/libgfortran/io/transfer.c
@@ -4508,7 +4508,8 @@ st_wait_async
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95322
--- Comment #12 from Daniel Krügler ---
(In reply to Daniel Krügler from comment #7)
> (In reply to Jonathan Wakely from comment #6)
> > A new LWG issue has been submitted, and there is a suggested resolution.
>
> Will take care and inform in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95090
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|RESOLVED|REOPENED
The fix for
> PR fortran/95104 - Segfault on a legal WAIT statement
>
> Referencing a unit in a WAIT statement that has not been opened before
> resulted in a NULL pointer dereference. Check for this condition.
>
> 2020-05-26 Harald Anlauf
>
> libgfortran/
> PR libfortran/95104
>
Hi!
On Thu, May 28, 2020 at 04:22:16PM +0200, Richard Biener wrote:
> For GIMPLE level transforms I don't think targets have more knowledge
> than the middle-end.
Yes, certainly.
> In fact GIMPLE complete unrolling is about
> secondary effects, removing redundancies and abstraction. So IMHO
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95252
--- Comment #7 from Jim Wilson ---
I've got 3 new g++ testsuite failures. So we might still need an exact list of
USEs. I hadn't thought about RVE. That will have to be checked also.
RV32/RV64 shouldn't matter, as the mode in the USEs
The H8/SX has some extended capabilities for bit-and, bit-ior and bit-xor
compared to earlier processors in the H8 family and thus there's some special
patterns to handle them.
THe instructions work on byte sized chunks, but GCC is exposing them in HImode
as
well. It looks like someone tried
Forgot to mention:
Bootstrapped and regtested on z13 and z14 with gas including f687f5f563
Ok for master?
On Thu, May 28, 2020 at 08:24:26PM +0200, Stefan Schulze Frielinghaus via
Gcc-patches wrote:
> Vector alignment hints are fully supported since z14. On z13 alignment
> hints have no
Vector alignment hints are fully supported since z14. On z13 alignment
hints have no effect, however, instructions with alignment hints are
still legal. Thus, emit alignment hints also for z13 targets so that if
the binary is actually run on a z14 or later it benefits from such
hints.
Note,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95391
--- Comment #1 from Bill Seurer ---
Also causes gcc.dg/vect/pr46126.c to ICE in the same spot.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95361
--- Comment #3 from CVS Commits ---
The releases/gcc-10 branch has been updated by Richard Sandiford
:
https://gcc.gnu.org/g:c082cb8a2523d8c5afe5710e265bc72dd71aa60b
commit r10-8201-gc082cb8a2523d8c5afe5710e265bc72dd71aa60b
Author: Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95389
--- Comment #1 from Ian Lance Taylor ---
To be clear, are you seeing this in the value returned by
reflect.Type.PkgPath()? Or is it showing up somewhere else? Thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95393
--- Comment #1 from Marc Glisse ---
It does optimize for me with -O2 or -O3. It could optimize earlier though, by
the end of gimple, we are still trying to return max(s,0).
Your question is inappropriate on this mailing list, and I already
answered it on the gcc-help list anyway.
On Thu, 28 May 2020 at 18:22, kiran kumar vangara via Gcc
wrote:
>
> Team,
>
> We have been compiling cpp files with g++ compiler on Redhat Linux OS
> machine and as part of this -mt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95392
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|--- |11.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95392
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95090
--- Comment #6 from anlauf at gcc dot gnu.org ---
(In reply to Manfred Schwarb from comment #5)
> gdb shows:
>
> Program received signal SIGSEGV, Segmentation fault.
> 0xf7aa5162 in __strlen_sse2_bsf () from /lib/libc.so.6
> #0 0xf7aa5162 in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95256
--- Comment #5 from Arseny Solokha ---
Is there some further work pending, or should this PR be closed now?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95211
--- Comment #8 from Arseny Solokha ---
Is there some further work pending, or should this PR be closed now?
After a long run as the Xtensa port maintainer, it is time for me to move
on.
I nominate Max Filippov [cc'd] as the new maintainer. He has contributed
numerous patches over the years which have required minimal comments from
me.
If there is anything I need to do to facilitate this, let me know.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95394
Bug ID: 95394
Summary: [11 Regression] ICE in emit_move_insn, at expr.c:3814
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95390
--- Comment #1 from Jakub Jelinek ---
Created attachment 48630
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48630=edit
gcc11-pr95390.patch
Untested fix.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95392
Bug ID: 95392
Summary: Build failure on MinGW
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95393
Bug ID: 95393
Summary: Failure to optimize loop condition arithmetic for
mismatched types
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
++ (GCC) 10.1.1 20200507 (Red Hat 10.1.1-1):
Rejects it:
test.cc:17:14: error: passing ‘const foo’ as ‘this’ argument discards
qualifiers [-fpermissive]
* gcc (GCC) 9.3.1 20200528
Rejects it:
test.cc:17:14: error: passing ‘const foo’ as ‘this’ argument discards
qualifiers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93698
Patrick Palka changed:
What|Removed |Added
Ever confirmed|0 |1
Known to fail|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92652
Patrick Palka changed:
What|Removed |Added
CC||ppalka at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95391
Bug ID: 95391
Summary: [11 regression] ICE in gcc.dg/vshift-5.c since r11-689
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
* Szabolcs Nagy:
> diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
> index cced19d2018..0fd32a22599 100644
> --- a/gcc/doc/extend.texi
> +++ b/gcc/doc/extend.texi
> On some machines it may be impossible to determine the return address of
> any function other than the current one; in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95390
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95390
Bug ID: 95390
Summary: _gfortran_{,m,s}findloc[01]_c10 not exported from
libgfortran.so.5
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
The expected semantics and valid usage of __builtin_return_address is
not clear since it exposes implementation internals that are normally
not meaningful to portable c code.
This documentation change tries to clarify the semantics in case the
return address is stored in a mangled form in memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95379
--- Comment #8 from Asher Gordon ---
(In reply to Tom Tromey from comment #7)
> The feature was added specifically to mimic what sparse does.
> If sparse changes, I think changing gcc would be appropriate.
I just report a bug to Sparse here:
Team,
We have been compiling cpp files with g++ compiler on Redhat Linux OS
machine and as part of this -mt option was given for g++ and it produced
required binary in case # 1 but produced an error in case#2 , I'm sharing
g++ version and the Redhat Linux OS version being used to compile the cpp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95389
Bug ID: 95389
Summary: Kubernetes build fails because of mangled PkgPath
Product: gcc
Version: 10.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95386
Martin Liška changed:
What|Removed |Added
Keywords||ice-on-valid-code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95181
Patrick Palka changed:
What|Removed |Added
Assignee|ppalka at gcc dot gnu.org |unassigned at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95379
--- Comment #7 from Tom Tromey ---
(In reply to Asher Gordon from comment #6)
> (In reply to Tom Tromey from comment #5)
> > Since this warning is intended to work like sparse, introducing
> > a divergence here would seem to make the feature
On Thu, May 28, 2020 at 8:00 AM Richard Sandiford
wrote:
>
> "Yangfei (Felix)" writes:
> > Thanks for reviewing this.
> > Attached please find the v5 patch.
> > Note: we also need to modify local variable "mode" once we catch one case.
> > I see test failure without this change.
>
> Looks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95379
--- Comment #6 from Asher Gordon ---
(In reply to Tom Tromey from comment #5)
> Since this warning is intended to work like sparse, introducing
> a divergence here would seem to make the feature less useful,
> in fact subverting the point of
1 - 100 of 243 matches
Mail list logo
