-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: qrzhang at gatech dot edu
Target Milestone: ---
Recent regression. Bisection points to g:b6ff3ddecfa93d53867afaaa078f85f
$ gcc-trunk -v
gcc version 11.0.0 20200516 (experimental) [master revision
53b4d52f114
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95171
Bug ID: 95171
Summary: ICE: verify_flow_info failed (error: wrong outgoing
edge flags at end of bb 2)
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords:
On Sat, May 16, 2020 at 9:02 PM Rob Savoye wrote:
>
> On 5/16/20 5:45 PM, Maciej W. Rozycki wrote:
>
> > Overall perhaps a patch management system might be good having to make
> > chasing patches easier, such as patchwork, and we already use Git, so we
>
> As an old GNU project, we're required
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95170
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |MOVED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95170
--- Comment #1 from fdlbxtqi ---
Created attachment 48550
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48550=edit
Picture bug
printf works while iostream does not since it links to GetTickCount64.
On 5/16/20 5:45 PM, Maciej W. Rozycki wrote:
> Overall perhaps a patch management system might be good having to make
> chasing patches easier, such as patchwork, and we already use Git, so we
As an old GNU project, we're required to use what the FSF prefers,
which is on savannah.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95170
Bug ID: 95170
Summary: GetTickCount64 cannot get found in KERNEL32.dll on
Legacy Windows Platforms like Windows XP, 2000
Product: gcc
Version: 11.0
Status: UNCONFIRMED
On 17/05/20 05:15, Maciej W. Rozycki wrote:
> Siddhesh, would you care to tell us how much effort it would be to set up
> fresh patchwork? The patch traffic is surely much lower with DejaGnu than
> it is with glibc, and there would be no data to migrate (but we might want
> to feed a couple
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95169
--- Comment #4 from Andrew Pinski ---
0x11e6 <+45>:fcompl -0x10(%ebp)
0x11e9 <+48>:fnstsw %ax
0x11eb <+50>:sahf
That is what raises the invalid-operation exception
#(insn 23 56 24 2 (set (reg:HI 0 ax [99])
#
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95169
--- Comment #3 from Samuel Thibault ---
And for comparison, here is the disassemble of -march=i686 -mtune=generic,
which does not raise the exception:
Dump of assembler code for function f:
0x11b9 <+0>: push %ebp
0x11ba
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95169
--- Comment #2 from Samuel Thibault ---
Here are the results with -march=i386 -mtune=$i.
"0 1" thus means an exception is raised
i386 0 0
i486 0 0
i586 0 0
pentium 0 0
lakemont 0 0
pentium-mmx 0 0
winchip-c6 0 0
winchip2 0 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95169
Samuel Thibault changed:
What|Removed |Added
Known to work||9.3.0
Known to fail|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95169
Bug ID: 95169
Summary: i386 comparison between nan and 0.0 triggers Invalid
operation exception
Product: gcc
Version: 10.1.0
Status: UNCONFIRMED
Severity:
On Thu, 14 May 2020, Rob Savoye wrote:
> Right now working through patches is probably more important. :-)
> There's zero patches on the DejaGnu savannah site, so I'd ask anybody to
> submit them so I don't have to dig them out of email archives.
I have reposted the single patch I have had
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95168
Bug ID: 95168
Summary: libphobos: std.net.curl does not understand HTTP/2
status lines
Product: gcc
Version: 10.1.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95167
Bug ID: 95167
Summary: libphobos: std.zip unittest depends on unzip being
installed
Product: gcc
Version: 10.1.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95166
Bug ID: 95166
Summary: libphobos: core.cpuid.{cores,threads}PerCPU() returns
wrong value
Product: gcc
Version: 10.1.0
Status: UNCONFIRMED
Severity: normal
Snapshot gcc-10-20200516 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/10-20200516/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 10 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch
Since GCC 9, C++17 support is no longer experimental. It was too late
to change the default C++ dialect to C++17 in GCC 10, but I think now
it's time to pull the trigger (C++14 was made the default in GCC 6.1).
We're still missing two C++17 library features, but that shouldn't stop
us. See
Current cfns.h includes register-qualified variables and that wouldn't
play well when bootstrapping with GCC that uses the C++17 dialect,
because 'register' was removed in C++17. Regenerating it using the
command specified in cfns.h luckily cleaned this up.
Bootstrapped/regtested on
This patch resolves DR 1512 (and, by turn, DR 583). This entails:
1) Relational pointer comparisons against null pointer constants have
been made ill-formed:
void f(char *p) {
if (p > 0)
// ...
}
was always invalid in C but was -- accidentally -- allowed in C++.
2)
This feels extremely obscure but at least it's an opportunity to fix the
comments. P0002R1 removed deprecated operator++(bool) in C++17 so let's
avoid adding a builtin overload candidate for ++ when the type is bool.
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
* call.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95155
Iain Buclaw changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
Hi,
This patch fixes PR95155, which prevented the D front-end in gcc-9 from
being able to bootstrap a self-hosted D compiler.
The Semantic (pass 1) analysis for classes is handled by
ClassDeclaration::semantic. For a given class, this method may be ran
multiple times in order to resolve forward
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95155
--- Comment #2 from CVS Commits ---
The releases/gcc-9 branch has been updated by Iain Buclaw
:
https://gcc.gnu.org/g:7d505b0ed8565b8c120ddd2b0b4630c93eecdec5
commit r9-8599-g7d505b0ed8565b8c120ddd2b0b4630c93eecdec5
Author: Iain Buclaw
Date:
Hi,
The last change to the bindings removed the st_pad3 field from the wrong
struct. It should have been stat64_t that needed updating instead.
Patch backported from r10-8066, committed to gcc-9 branch.
Iain.
---
libphobos/ChangeLog
PR d/90719
*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90719
Iain Buclaw changed:
What|Removed |Added
Resolution|--- |FIXED
Status|REOPENED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90719
--- Comment #12 from CVS Commits ---
The releases/gcc-9 branch has been updated by Iain Buclaw
:
https://gcc.gnu.org/g:866f7405707dd2970868941635a32bd9197cd731
commit r9-8598-g866f7405707dd2970868941635a32bd9197cd731
Author: Iain Buclaw
Date:
On Fri, May 15, 2020 at 11:21:30AM +0200, Uros Bizjak wrote:
> On Wed, May 13, 2020 at 5:58 PM H.J. Lu wrote:
>
> > > > > The question is, why STV pass creates its funny sequence? The original
> > > > > sequence should be easily solved by storing DImode from XMM register
> > > > > and (with
On May 16, 2020 11:42:02 AM GMT+02:00, Erick Ochoa
wrote:
>Fixes documentation for gimple_assign functions
>
>This patch corrects the documented function signatures of
>gimple_assign*
>functions.
OK.
Richard.
>ChangeLog:
>
>2020-05-16 Erick Ochoa
>
> * gcc/gimple.h
On May 16, 2020 11:41:51 AM GMT+02:00, Erick Ochoa
wrote:
>Adds wrapper for gimple_return_retval to accept gimple*
>
>Most functions interact with GIMPLE IL using arguments of type gimple*.
>
>Functions interacting with GIMPLE_RETURN instructions still use
>greturn*
>types as arguments. This
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95161
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94730
--- Comment #5 from Andrew Pinski ---
*** Bug 95161 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95165
kargl at gcc dot gnu.org changed:
What|Removed |Added
Priority|P3 |P4
Last reconfirmed|
Hi!
On Sat, May 16, 2020 at 09:46:15AM -0500, Peter Bergner wrote:
> On 5/13/20 11:22 AM, Joel Brobecker wrote:
> > Would someone mind reviewing this patch, please?
> You should always CC the PPC maintainers on PPC patches.
> I've CC'd both Segher and David.
Thanks Peter. Yes, I hadn't seen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95165
Bug ID: 95165
Summary: Since 9.1 we do have ISO_Fortran_binding.h
Product: gcc
Version: 9.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: web
On 16/05/2020 01:42, Witold Baryluk via Gcc-patches wrote:
> Adds support for DMGL_RET_POSTFIX in D demangler, so it shows the type
> of the declared variable, or function return type. Postfix notation is
> used with space.
>
Hi,
Thanks for your contribution, it would be good to have a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95157
--- Comment #2 from Simon Marchi ---
Ah, good point!
So yeah, please consider the test case without `volatile`.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95157
Harald van Dijk changed:
What|Removed |Added
CC||harald at gigawatt dot nl
--- Comment
On Sat, 16 May 2020, Gerald Pfeifer wrote:
> This brought some problems with that page which I addressed per the
> follow-up patch below.
Some more, notably three cases of ... => ...,
note that closing .
Pushed.
Gerald
commit bb406fa02b9a9c47861bc2246513c198bffc90bb
Author: Gerald Pfeifer
On Fri, 15 May 2020, Kyrylo Tkachov wrote:
>> From: Srinath Parvathaneni
>> M-profile related changes in GCC-10.
> Ok.
This brought some problems with that page which I addressed per the
follow-up patch below.
(I am not sure I would have introduced a one-element list, but kept
that and just
On 5/13/20 11:22 AM, Joel Brobecker wrote:
> Hello,
>
> Would someone mind reviewing this patch, please?
>
> The test explicitly uses -mvsx in the compilation options, so it seems
> reasonable to require powerpc_vsx_ok...
>
> Thank you!
You should always CC the PPC maintainers on PPC patches.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95160
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85282
Marek Polacek changed:
What|Removed |Added
CC||mikelojkovic at gmail dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95164
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95164
Bug ID: 95164
Summary: ICE regression starting with 9.3
Product: gcc
Version: 10.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
--prefix=/software/compilers/gcc-offload/f5b461d4/gnu-9.2.0
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.0.0 20200516 (experimental) (GCC)
Cheers,
John
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95138
--- Comment #2 from anlauf at gcc dot gnu.org ---
Another datapoint: inserting
select type (o)
type is (integer)
print *, transfer(o, v)
end select
prints the right thing:
1 2 3
Also note the possibly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95053
--- Comment #28 from anlauf at gcc dot gnu.org ---
A patch based on comment#15 has been posted for review:
https://gcc.gnu.org/pipermail/fortran/2020-May/054321.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95162
H.J. Lu changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95162
--- Comment #1 from H.J. Lu ---
GCC manual says
'-mpreferred-stack-boundary=NUM'
Attempt to keep the stack boundary aligned to a 2 raised to NUM
byte boundary. If '-mpreferred-stack-boundary' is not specified,
the default is 4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95162
Bug ID: 95162
Summary: -mpreferred-stack-boundary=2 doesn't work with libgcc
functions
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95161
Bug ID: 95161
Summary: [10/11 Regression] internal compiler error: in
gimplify_expr, at gimplify.c:14609
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Sorry for the empty subject line earlier...
Jason Merrill writes:
> On Fri, May 15, 2020 at 9:47 PM Martin Sebor wrote:
>
>> On 5/15/20 8:08 AM, Richard Sandiford wrote:
>> >> Those are all good examples. Mind putting that into a patch
>> >> for the coding conventions?
>> > How's this? I
Fixes documentation for gimple_assign functions
This patch corrects the documented function signatures of gimple_assign*
functions.
ChangeLog:
2020-05-16 Erick Ochoa
* gcc/gimple.h (gimple_assign_rhs_code): Fix signature
(gimple_assign_rhs_class): same
Adds wrapper for gimple_return_retval to accept gimple*
Most functions interact with GIMPLE IL using arguments of type gimple*.
Functions interacting with GIMPLE_RETURN instructions still use greturn*
types as arguments. This patch adds wrappers around functions taking
greturn* as inputs. The
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95100
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |INVALID
On Jan 10 2020, Stam Markianos-Wright wrote:
> diff --git a/gcc/testsuite/gcc.target/arm/bfloat16_vector_typecheck_2.c
> b/gcc/testsuite/gcc.target/arm/bfloat16_vector_typecheck_2.c
> new file mode 100644
> index 000..16669dcf009
> --- /dev/null
> +++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95152
Fredrik Hederstierna changed:
What|Removed |Added
CC||fredrik.hederstierna@securi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94474
--- Comment #11 from Bernd Edlinger ---
Andrew,
(In reply to Andrew Burgess from comment #10)
> Further, I've seen no mention of exit views anywhere, and I think they
> would also be needed.
>
Yes, that is also my idea, when I say the dwarf2
On May 15, 2020 11:53:42 PM GMT+02:00, Jason Merrill wrote:
>On 5/15/20 2:21 PM, Richard Biener wrote:
>> On May 15, 2020 7:30:38 PM GMT+02:00, Jason Merrill
> wrote:
>>> On Fri, May 15, 2020 at 3:15 AM Richard Biener
>>>
>>> wrote:
>>>
> +# When bootstrapping with GCC, build stage 1 in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95160
Bug ID: 95160
Summary: Explicit specialization in non-namespace scope bug
Product: gcc
Version: 10.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
62 matches
Mail list logo
