[Bug ipa/92553] OpenMP offload static linking error, ICE in inline_read_section, at ipa-fnsummary.c:3332
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92553 --- Comment #2 from Ye Luo --- PR92357 mentioned that you backported a fix to the gcc 9 branch and how I'm getting the following error /home/yeluo/opt/gcc-9-branch/bin/g++ -fopenmp -foffload=nvptx-none -foffload=-lm -fomit-frame-pointer -finline-limit=1000 -fstrict-aliasing -funroll-all-loops -D__forceinline=inline -Wno-deprecated -march=native -O3 -DNDEBUG -ffast-math CMakeFiles/check_spo_batched.dir/check_spo_batched.cpp.o -o ../../bin/check_spo_batched -Wl,-rpath,/opt/math-libraries/OpenBLAS/current/lib ../../lib/libqmcwfs.a ../../lib/libqmcbase.a ../../lib/libqmcutil.a /opt/math-libraries/OpenBLAS/current/lib/libopenblas.so /opt/math-libraries/OpenBLAS/current/lib/libopenblas.so lto1: fatal error: CMakeFiles/check_spo_batched.dir/check_spo_batched.cpp.o: section _ZN11qmcplusplus17einspline_spo_ompIdE17evaluateDetRatiosERKNS_18VirtualParticleSetERNS_6VectorIdSaIdEEERKS7_RSt6vectorIdS6_E$_omp_fn$1 is missing compilation terminated. mkoffload: fatal error: /home/yeluo/opt/gcc-9-branch/bin/x86_64-pc-linux-gnu-accel-nvptx-none-gcc returned 1 exit status compilation terminated. lto-wrapper: fatal error: /home/yeluo/opt/gcc-9-branch/libexec/gcc/x86_64-pc-linux-gnu/9.2.1//accel/nvptx-none/mkoffload returned 1 exit status compilation terminated. /usr/bin/ld: error: lto-wrapper failed collect2: error: ld returned 1 exit status
[Bug target/92769] Powerpc: No way to set CR0[SO] on function return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92769 --- Comment #4 from Andrew Pinski --- >Linux system calls and Linux VDSO calls System calls, I can understand But why is it required by VDSO calls too? That seems backwards and also means VDSO functions are not the same ABI as normal functions.
[Bug testsuite/92941] Test failure when no C++ compiler built
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92941 --- Comment #1 from Andrew Pinski --- The reason why this has not been seen as much as building without the C++ front-end is not something 99% people do, even cross compiler folks
[Bug c++/93048] [10 Regression] ICE in verify_gimple
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93048 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |10.0 Summary|ICE in verify_gimple|[10 Regression] ICE in ||verify_gimple --- Comment #6 from Andrew Pinski --- This might already been fixed.
[Bug target/93135] [10 Regression] g++.dg/cpp0x/initlist118.C fails on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93135 Andrew Pinski changed: What|Removed |Added Depends on||93221 --- Comment #1 from Andrew Pinski --- Maybe the same as bug 93221. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93221 [Bug 93221] [10 Regression] ICE maximum number of generated reload insns per insn achieved (90) on aarch64
[Bug target/93133] __builtin_isgreater emits trapping compare instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93133 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-01-12 Ever confirmed|0 |1 --- Comment #2 from Andrew Pinski --- Confirmed.
[Bug target/93235] [AArch64] ICE with __fp16 in a struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93235
--- Comment #3 from Andrew Pinski ---
aarch64 is one of the few targets that has a floating point type which is less
than SImode :).
A simple workaround for this bug is to change the code slightly:
struct sfp16 {
__fp16 f;
};
struct sfp16 get(short x) {
union {
__fp16 f;
short w;
} u;
u.w = x;
return (struct sfp16){u.f};
}
[Bug target/93235] [AArch64] ICE with __fp16 in a struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93235
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2020-01-12
Summary|[AArch64] ICE with __fp16 |[AArch64] ICE with __fp16
|and union |in a struct
Ever confirmed|0 |1
--- Comment #2 from Andrew Pinski ---
This one also ICEs in the same way:
struct sfp16 {
__fp16 f;
};
struct sfp16 get(short x) {
struct sfp16 a;
*(short*)&(a.f) = x;
return a;
}
[Bug target/93235] [AArch64] ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93235 --- Comment #1 from Andrew Pinski --- *** Bug 93236 has been marked as a duplicate of this bug. ***
[Bug c/93236] [AArch64] ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93236 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Andrew Pinski --- Dup, I can only assume it was accidently filed twice. *** This bug has been marked as a duplicate of bug 93235 ***
[Bug c/93236] [AArch64] ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93236 --- Comment #1 from Jim Rees --- Created attachment 47639 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47639=edit sample code
[Bug c/93236] New: [AArch64] ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93236 Bug ID: 93236 Summary: [AArch64] ICE Product: gcc Version: 9.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: jimreesma at gmail dot com Target Milestone: --- On aarch64-linux-gnu, ubuntu@ubuntu:~$ gcc -O -c gcc9_ice.c during RTL pass: expand gcc9_ice.c: In function ‘get’: gcc9_ice.c:13:11: internal compiler error: in gen_rtx_SUBREG, at emit-rtl.c:1010 13 | return u.s; | ~^~ With the -O, or with -O0, no ice, and the emitted code works correctly.
[Bug c/93235] New: [AArch64] ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93235 Bug ID: 93235 Summary: [AArch64] ICE Product: gcc Version: 9.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: jimreesma at gmail dot com Target Milestone: --- Created attachment 47638 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47638=edit compile with gcc -O1 -S gcc9_ice.c on aarch64-linux-gnu On aarch64-linux-gnu, ubuntu@ubuntu:~$ gcc -O -c gcc9_ice.c during RTL pass: expand gcc9_ice.c: In function ‘get’: gcc9_ice.c:13:11: internal compiler error: in gen_rtx_SUBREG, at emit-rtl.c:1010 13 | return u.s; | ~^~ With the -O, or with -O0, no ice, and the emitted code works correctly.
[Bug tree-optimization/93080] insert of an extraction on the same location is not optimized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93080
--- Comment #4 from Andrew Pinski ---
Note the patch also does not handle the following (or something a little more
complex):
/* { dg-do compile } */
/* { dg-options "-O2 -fdump-tree-optimized" } */
#define vector __attribute__((__vector_size__(4*sizeof(int)) ))
vector int g(vector int a, int c)
{
int b = a[2];
a[1] = c;
a[2] = b;
return a;
}
/* { dg-final { scan-tree-dump-times "BIT_INSERT_EXPR" 1 "optimized" } } */
/* { dg-final { scan-tree-dump-times "BIT_FIELD_REF" 0 "optimized" } } */
[Bug tree-optimization/93081] insertation followed by another inseration to the same location is not optimized away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93081
--- Comment #4 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #3)
> (In reply to Richard Biener from comment #2)
> > OK for trunk.
>
> Except it is wrong if the size(@1) != size(@3). I Noticed that after I
> created this bug report. I have a better fix; though I combined it with
> something which really belongs in reassociate rather than in match.pd so I
> am working towards that first to remove the reassociate part. I am going to
> submit it when stage 1 starts. I have many BIT_INSERT_EXPR/BIT_FIELD_REF
> improves which I want to submit together.
Note this might be better in reassociate pass anyways. There we don't need to
have them right next to each other to remove them
That is take:
/* { dg-do compile } */
/* { dg-options "-O2 -fdump-tree-optimized" } */
#define vector __attribute__((__vector_size__(4*sizeof(int)) ))
vector int f(vector int a, int b, int c)
{
a[0] = b;
a[1] = b;
a[0] = c;
return a;
}
/* { dg-final { scan-tree-dump-times "BIT_INSERT_EXPR" 2 "optimized" } } */
--- CUT ---
[Bug tree-optimization/93080] insert of an extraction on the same location is not optimized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93080 --- Comment #3 from Andrew Pinski --- (In reply to Richard Biener from comment #2) > It's a bugfix so applicable for stage3... pre-approved with a testcase. Except it causes a regression on x86_64: FAIL: gcc.target/i386/pr54855-8.c scan-assembler-not movsd FAIL: gcc.target/i386/pr54855-8.c scan-assembler-times maxsd 1 FAIL: gcc.target/i386/pr54855-9.c scan-assembler-not movss FAIL: gcc.target/i386/pr54855-9.c scan-assembler-times minss 1 I have not looked into how to fix these regressions though.
[Bug tree-optimization/93044] extra cast is not removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93044 --- Comment #4 from Andrew Pinski --- (In reply to Richard Biener from comment #3) > Indeed that seems to disallow this case. The condition is complicated > enough to warrant extra care fiddling with it though ;) The main reason why I filed this bug when I saw instead of fixing it is because the condition was complicated and I did not understand why all of the conditions were there.
[Bug tree-optimization/93081] insertation followed by another inseration to the same location is not optimized away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93081 --- Comment #3 from Andrew Pinski --- (In reply to Richard Biener from comment #2) > OK for trunk. Except it is wrong if the size(@1) != size(@3). I Noticed that after I created this bug report. I have a better fix; though I combined it with something which really belongs in reassociate rather than in match.pd so I am working towards that first to remove the reassociate part. I am going to submit it when stage 1 starts. I have many BIT_INSERT_EXPR/BIT_FIELD_REF improves which I want to submit together.
[Bug driver/93196] GCC compiles c code, provides no executable output with option -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93196 Andrew Pinski changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |WORKSFORME --- Comment #18 from Andrew Pinski --- Maybe you have a buggy kernel in use on the machine which does not work. Anyways this is not a GCC issue as strace shows GCC is doing the correct thing so closing.
[Bug middle-end/93232] std::array warning: writing 1 byte into a region of size 0 [ttps://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wstringop-overflow=-Wstringop-overflow=m]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93232 --- Comment #3 from Andrew Pinski --- (In reply to fdlbxtqi from comment #2) > Is that a method to dump the entire processed source? Please read https://gcc.gnu.org/bugs/ under the "Detailed bug reporting instructions" section.
[Bug c++/91318] [C++][PATCH] warnings about unused internal macros with -Wunused-macros and #pragma GCC optimize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91318 --- Comment #5 from Piotr Henryk Dabrowski --- Ping.
[Bug fortran/93234] New: INQUIRE on pre-assigned files of ROUND and SIGN properties fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93234 Bug ID: 93234 Summary: INQUIRE on pre-assigned files of ROUND and SIGN properties fails Product: gcc Version: 8.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: urbanjost at comcast dot net Target Milestone: --- Cannot call INQUIRE() on pre-assigned files for properties ROUND and SIGN fails with an internal error. The simplest case is program showit implicit none character(len=20) :: round character(len=20) :: sign inquire(unit=5,round=round) inquire(unit=5,sign=sign) ! Internal Error: inquire_via_unit(): Bad sign write(*,*)'UNITS=',units(i),' ROUND=',round,' sign=',sign end program showit If you do an open on the units and specify the round and sign values it is then OK.
[Bug web/93185] Support git commits as a link in bugzilla entries
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93185
Frédéric Buclin changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|--- |FIXED
--- Comment #10 from Frédéric Buclin ---
(In reply to Jakub Jelinek from comment #9)
> This was just trying to document what clearly is already implemented, e.g.
> for
> PR tree-optimization/90838 bugzilla already creates URL to
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90838
> There is no need to change anything.
Fun, I forgot I implemented this part already. :)
> But, while r10-5824-g42950b74c9b could be mapped directly to
> https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=42950b74c9b
> and the last one to
> https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;
> h=42950b74c9b103676f99dc9f1a27859e3f7be436
> by bugzilla, the first one can't, as it needs to run a few shell commands to
> determine the hash, so I'd like to r10-5824 to point to e.g.
> https://gcc.gnu.org/cgi-bin/gcc-gitref.cgi?r=r10-5824
> and let the cgi script perform redirection.
OK, I patched Bugzilla to point to
https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=\1 for the last two forms and to
gcc-gitref.cgi for the first form.
> In https://gcc.gnu.org/ml/gcc-patches/2019-08/msg01015.html Jason was
> suggesting that g: could take not just the hashes, but other ways git can
> use to describe the commit, so e.g. some tag name, or commit_hash~1,
> commit_hash^^ etc.
> For the redirects, I have tentatively used g:[0-9a-zA-Z._{}~^-]+ , but maybe
> / and @ should be accepted there too.
I always considered / and @ as evil in such URLs, because / has historically
been used to change directories in some security vulnerabilities and @ could be
used in URLs like user:password@host:port (remember FTP?). So I generally
prefer to be too restrictive with such regexps. For now, I kept the regexp
unchanged to match [0-9a-f] (hexadecimal) only. Let me know if you really want
me to let this regexp be more persmissive.
> https://git-scm.com/docs/gitrevisions says also HEAD@{5 minutes ago} , but
> guess
> we do not want to allow spaces in there in bugzilla
Sure, else we will match pretty much everything in long comments as the
probability is high to match {...}. :)
All done. Closing!
[Bug middle-end/93232] std::array warning: writing 1 byte into a region of size 0 [ttps://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wstringop-overflow=-Wstringop-overflow=m]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93232 --- Comment #2 from fdlbxtqi --- (In reply to Andrew Pinski from comment #1) > Can you attach the preprocessed source? > > This might be a dup of bug 92955. The source is here: https://bitbucket.org/ejsvifq_mabmip/fast_io/src/master/examples/0021.benchmark/output_10M_size_t.cc I cannot find out why. Is that a method to dump the entire processed source?
[Bug web/93185] Support git commits as a link in bugzilla entries
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93185
Jakub Jelinek changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment #9 from Jakub Jelinek ---
(In reply to Frédéric Buclin from comment #8)
> (In reply to Jakub Jelinek from comment #7)
> > r([0-9]{1,6}) to http://gcc.gnu.org/viewcvs/gcc?view=revision=\1
> > (what we have already, should be https? and perhaps we'll switch to some
> > redirector instead, so maybe https://gcc.gnu.org/r\1 instead?)
>
> I have updated Bugzilla to point to https instead of http.
Thanks.
> Which URL do you
> prefer: the current link to viewcvs/gcc?view=revision=\1 or the
> link to the redirector https://gcc.gnu.org/r\1 ? The advantage of the link
> to viewcvs is that you have one less redirection.
I agree, so let's change it when we decide what to do with SVN revisions.
The viewcvs will work for now.
> > pr([0-9]{1,6}) etc. to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=\1 (also
> > implemented, similar PR [a-z-]+/([0-9]{1,6}) )
>
> What's the point of [a-z]+/ in front of the bug ID if this part is useless
> to identify the bug report? I haven't implemented that part till I
> understand what this part is used for.
This was just trying to document what clearly is already implemented, e.g. for
PR tree-optimization/90838 bugzilla already creates URL to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90838
There is no need to change anything.
> > (r[0-9]{1,2}-[0-9]{1,6}) to https://gcc.gnu.org/\1 (redirector to be
> > implemented)
>
> Waiting for the redirector to be implemented. Could meanwhile someone paste
> a valid example here so that I can use it for testing?
In https://gcc.gnu.org/ml/gcc/2020-01/msg00160.html I have posted a tentative
patch for the redirects, but as I said there, the gcc-gitref.cgi is not
implemented yet, hope it can be done say on Monday.
The aim is that e.g. 42950b74c9b103676f99dc9f1a27859e3f7be436 hash (but in the
testing reposurgeon repository, can't have something final because the current
conversion hasn't been finished yet) can be also written as
r10-5824
r10-5824-g42950b74c9b
r10-5824-g42950b74c9b103676f99dc9f1a27859e3f7be436
and all of those would in the end redirect to the same
https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=42950b74c9b103676f99dc9f1a27859e3f7be436
(note, as this hash is from test repo, it won't really work as is).
But, while r10-5824-g42950b74c9b could be mapped directly to
https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=42950b74c9b
and the last one to
https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=42950b74c9b103676f99dc9f1a27859e3f7be436
by bugzilla, the first one can't, as it needs to run a few shell commands to
determine the hash, so I'd like to r10-5824 to point to e.g.
https://gcc.gnu.org/cgi-bin/gcc-gitref.cgi?r=r10-5824
and let the cgi script perform redirection.
r10-5824 stands for 5824's commit after the first one on trunk after branching
gcc 9, r10-0 stands for the first commit on trunk after branching gcc 9,
its parent commit is r9-7160 (in the test repo) and r9-7161 is the first gcc 9
branch commit after branching gcc 9.
> > g:([0-9a-zA-Z_-]+) to https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=\1
>
> Done, but I have restricted the regexp to ([0-9a-f]{7,40}) as the hash is in
> hexadecimal form, so we don't need (nor want) g-z A-Z _ and -.
In https://gcc.gnu.org/ml/gcc-patches/2019-08/msg01015.html Jason was
suggesting that g: could take not just the hashes, but other ways git can use
to describe the commit, so e.g. some tag name, or commit_hash~1, commit_hash^^
etc.
For the redirects, I have tentatively used g:[0-9a-zA-Z._{}~^-]+ , but maybe
/ and @ should be accepted there too.
https://git-scm.com/docs/gitrevisions says also HEAD@{5 minutes ago} , but
guess
we do not want to allow spaces in there in bugzilla and after all, stuff like
g:master@{yesterday} is really meaningless in bugzilla comments.
But sure, accepting hashes is the most common need, thinking about it even
g:master isn't very useful because it is a moving target. CCing Jason on this.
Perhaps those make only sense for the redirects and not the bugzilla comments.
> > r[0-9]{1,2}-[0-9]{1,6}-g([0-9a-f]{7,40}) to
> > https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=\1
> > ?
>
> Could someone paste a valid example here so that I can test it too?
See above, that is the:
r10-5824-g42950b74c9b
r10-5824-g42950b74c9b103676f99dc9f1a27859e3f7be436
[Bug web/93185] Support git commits as a link in bugzilla entries
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93185
Frédéric Buclin changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |LpSolit at gmail dot com
--- Comment #8 from Frédéric Buclin ---
(In reply to Jakub Jelinek from comment #7)
> r([0-9]{1,6}) to http://gcc.gnu.org/viewcvs/gcc?view=revision=\1
> (what we have already, should be https? and perhaps we'll switch to some
> redirector instead, so maybe https://gcc.gnu.org/r\1 instead?)
I have updated Bugzilla to point to https instead of http. Which URL do you
prefer: the current link to viewcvs/gcc?view=revision=\1 or the link
to the redirector https://gcc.gnu.org/r\1 ? The advantage of the link to
viewcvs is that you have one less redirection.
> pr([0-9]{1,6}) etc. to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=\1 (also
> implemented, similar PR [a-z-]+/([0-9]{1,6}) )
What's the point of [a-z]+/ in front of the bug ID if this part is useless to
identify the bug report? I haven't implemented that part till I understand what
this part is used for.
> (r[0-9]{1,2}-[0-9]{1,6}) to https://gcc.gnu.org/\1 (redirector to be
> implemented)
Waiting for the redirector to be implemented. Could meanwhile someone paste a
valid example here so that I can use it for testing?
> g:([0-9a-zA-Z_-]+) to https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=\1
Done, but I have restricted the regexp to ([0-9a-f]{7,40}) as the hash is in
hexadecimal form, so we don't need (nor want) g-z A-Z _ and -.
For testing purposes: g:d3cf980217ce13b1eda01d4c42a7e3afd2bf3217 g:d3cf9802
g:01invalid234hash567
> r[0-9]{1,2}-[0-9]{1,6}-g([0-9a-f]{7,40}) to
> https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=\1
> ?
Could someone paste a valid example here so that I can test it too?
[Bug ada/93233] No warning for possibly uninitialised return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93233 --- Comment #1 from Chris Sykes --- I noticed that g++ also fails to warn about this with a similar test case written in c++, and found this old bug report: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=18501 Perhaps this is easier to fix (without generating false positives, or adversely affecting code generation) in the Ada front-end?
[Bug ada/93233] New: No warning for possibly uninitialised return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93233
Bug ID: 93233
Summary: No warning for possibly uninitialised return
Product: gcc
Version: 9.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ada
Assignee: unassigned at gcc dot gnu.org
Reporter: chris at amtiskaw dot net
Target Milestone: ---
Created attachment 47637
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47637=edit
Test case using normal and extended return syntax.
Hi,
I'm learning Ada and was surprised to find that the compiler
failed to issue a warning when a variable used as the return
value of a (simple) function was only conditionally initialised.
I discovered this while investigating a bug in a function that
used the extended return syntax, so I constructed the following
test case which tries both normal and extended returns:
with Ada.Text_IO; use Ada.Text_IO;
procedure Returns is
function Normal(X: in Integer) return Boolean is
Result: Boolean;
begin
if X < 0 then
Result := true;
end if;
return Result;
end Normal;
function Extended(X: in Integer) return Boolean is
begin
return Result : Boolean do
if X < 0 then
Result := true;
end if;
end return;
end Extended;
begin
Put_Line("Normal(0): " & Normal(0)'Image);
Put_Line("Normal(-1): " & Normal(-1)'Image);
Put_Line("Extended(0): " & Extended(0)'Image);
Put_Line("Extended(-1): " & Extended(-1)'Image);
end Returns;
Compiling using gnatmake succeeds with no warnings about the
potentially uninitialised `Result` from the compiler:
$ gnatmake -v -Wall -gnatwa returns.adb
GNATMAKE 9.2.1 20190827 (Red Hat 9.2.1-1)
Copyright (C) 1992-2019, Free Software Foundation, Inc.
"returns.ali" being checked ...
-> "returns.ali" missing.
gcc -c -Wall -gnatwa returns.adb
End of compilation
gnatbind -x returns.ali
gnatlink returns.ali
Running the generated executable gives unpredictable results:
$ ./returns
Normal(0): TRUE
Normal(-1): TRUE
Extended(0): FALSE
Extended(-1): TRUE
$ ./returns
Normal(0): FALSE
Normal(-1): TRUE
Extended(0): FALSE
Extended(-1): TRUE
I've tried both gcc-gnat 9.2.1 from Fedora 31, and the latest GNAT CE from
Adacore with the same results (no warnings).
Platform details - up-to-date Fedora 31, x86_64:
GNAT 9.2.1 20190827 (Red Hat 9.2.1-1)
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/9/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-redhat-linux
Configured with: ../configure --enable-bootstrap
--enable-languages=c,c++,fortran,objc,obj-c++,ada,go,d,lto --prefix=/usr
--mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared
--enable-threads=posix --enable-checking=release --enable-multilib
--with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions
--enable-gnu-unique-object --enable-linker-build-id
--with-gcc-major-version-only --with-linker-hash-style=gnu --enable-plugin
--enable-initfini-array --with-isl --enable-offload-targets=nvptx-none
--without-cuda-driver --enable-gnu-indirect-function --enable-cet
--with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux
Thread model: posix
gcc version 9.2.1 20190827 (Red Hat 9.2.1-1) (GCC)
[Bug target/93177] PPC: Missing many useful platform intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93177
--- Comment #7 from Segher Boessenkool ---
(In reply to Andrew Pinski from comment #5)
> >the cntlz ones are not, for example
>
> :) It has been a long time since I touched this but I would not doubt I
> messed up this too.
It's nastiness in the generic builtins. builtin_clz(0) is undefined, even
if it *is* defined for the machine pattern. This is so that code using the
builtin can be portable. Unfortunately there is no good way (or I don't know
it, anyway) to do something like
int f(int x) { return x ? __builtin_clz(x) : 32; }
so that it compiles to just a cntlzw insn (instead, it currently does a branch
and stuff :-( ).
> __mulh* intrinsics are better implemented these days using either 64bit or
> 128bit multiples.
Yup.
> __l[hwd]brx/__st[hwd]brx intrinsics are better implemented as
> __builtin_bswap* followed by load/stored these days (the bswap builtins did
> not exist back then or optimized)
Yup.
> Many of the other intrinsics should be implemented as non inline-asm too,
> even fma, should be done using __builtin_fma :).
Yup :-)
GCC has come a long way, since Cell :-) You can reliably write many things
just as high-level C code now, and trust that well-optimised machine code
falls out.
[Bug target/93177] PPC: Missing many useful platform intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93177 --- Comment #6 from Segher Boessenkool --- (In reply to Matt Emmerton from comment #4) > The intrinsics that we would find useful, having used them as provided by > the IBM XL C/C++ compiler, are the following: > > __sync() > __isync() > __lwsync() The sync intrinsics need to be tied to some other code. A volatile asm with a "memory" clobber is not good enough, in many cases. > __dcbt() > __dcbtst() Those are builtin_prefetch(). > __lwarx() > __ldarx() > __stwcx() > __stdcx() The compiler can always insert memory accesses in between those two, if you have them as separate intrinsics (and it will, simply stack accesses for temporaries will do, already). If those accesses hit the same reservation granule as the larx/stcx. uses, you lose. You need to write the whole sequence in one piece of assembler code. > __protected_stream_set() > __protected_stream_count() > __protected_stream_count_depth() // currently not implemented in gcc > __protected_stream_go() Those are pretty specific to CBE I think? > The implementation of stwcx() and stdcx() need revision on PPC. > As I understand it, there is no need the mfocrf instruction nor the > mask-and-shift on result. How else would you output the CR0.EQ bit? mfocrf does not exist on all ISA versions we support though.
[Bug libgomp/93219] unused return value in affinity-fmt.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93219 --- Comment #6 from Andrew Pinski --- (In reply to Roland Illig from comment #5) > This is worse than before. Not exactly because if write fails to stderr, there is not much to be done except abort :). You can print something out because the write fail again. So aborting would be the next best thing or rather just ignoring the error and continuing.
[Bug libgomp/93219] unused return value in affinity-fmt.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93219 --- Comment #5 from Roland Illig --- (In reply to Jakub Jelinek from comment #4) > Change return type from void to int. Not quite. The return type is now bool, not int. > Return true if not all characters have been written. This feels wrong to me. If the return type is bool, it should indicate whether the function was successful. And right now, the burden is on the caller. Since none of the possible callers was changed in this commit, the compiler warning is now gone but the error condition is not fixed anywhere. It's just hidden more deeply. This is worse than before.
[Bug target/93192] [m68k] incorrect conversion of inf and nan in __truncxfdf2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93192 --- Comment #5 from Mikael Pettersson --- Confirmed, needs -msoft-float or selecting a CPU model which implies that.
[Bug tree-optimization/93131] ((a&8) == 8) && ((a&2) == 2) is not optimized to (a&(8|2)) == (8|2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93131 --- Comment #19 from Andrew Pinski --- (In reply to Jakub Jelinek from comment #17) > Dunno about others, but this particular optimization could be done in a new > function called next to optimize_range_tests_cmp_bitwise and > optimize_range_tests_var_bound because reassoc already has a framework to > deal with the && and || across different bbs as well as inside of them. ok, I will take a look in a little bit. But yes this is much better. I did not realize reassoc added this support yet. It is not mentioned in the comment in the begining of the file either :).
