https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96948
--- Comment #3 from Richard Biener ---
Patches should be sent to gcc-patc...@gcc.gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96937
Richard Biener changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
Last
Hi,
On 2020/9/4 18:23, Segher Boessenkool wrote:
diff --git a/gcc/config/rs6000/rs6000-c.c b/gcc/config/rs6000/rs6000-c.c
index 03b00738a5e..00c65311f76 100644
--- a/gcc/config/rs6000/rs6000-c.c
+++ b/gcc/config/rs6000/rs6000-c.c
/* Build *(((arg1_inner_type*)&(vector type){arg1})+arg2)
/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20200906/work/gcc-11-20200906/gcc/analyzer/store.cc:475
0x11fbe35 ana::binding_map::apply_ctor_to_region(ana::region const*,
tree_node*, ana::region_model_manager*)
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc
Hi FX,
Regtested on x86_64-apple-darwin19 and tested on aarch64-apple-darwin20.
OK to commit?
Looks good to me.
Best regards
Thomas
/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20200906/work/gcc-11-20200906/gcc/analyzer/analyzer.h:164
0x70304f ana::region_offset::get_bit_offset() const
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20200906/work/gcc-11-20200906/gcc/analyzer/analyzer.h:162
Hi Harald,
*ping*
I don't really know about the convert vs. fold_convert issue either,
but if it works, it works.
Regarding the patch: Could you change the test caes into a
run-time test and check for the results both for compile-time
simplification and evaluation at run-time? Just to make
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96948
--- Comment #2 from Kirill Müller ---
$ gcc -v
Using built-in specs.
COLLECT_GCC=C:\rtools40_\mingw64\bin\gcc.exe
COLLECT_LTO_WRAPPER=C:/rtools40_/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/8.3.0/lto-wrapper.exe
Target: x86_64-w64-mingw32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96948
--- Comment #1 from Kirill Müller ---
Created attachment 49188
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49188=edit
Proposed patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96948
Bug ID: 96948
Summary: _Unwind_GetIP() and _Unwind_GetIPInfo() empty in
_Unwind_Backtrace() with SEH on mingw64
Product: gcc
Version: 8.3.0
Status: UNCONFIRMED
This patch add cost tables for A64FX.
ChangeLog:
2020-09-07 Qian jianhua
gcc/
* config/aarch64/aarch64-cost-tables.h (a64fx_extra_costs): New.
* config/aarch64/aarch64.c (a64fx_addrcost_table): New.
(a64fx_regmove_cost, a64fx_vector_cost): New.
(a64fx_tunings):
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96933
--- Comment #5 from Kewen Lin ---
(In reply to Segher Boessenkool from comment #4)
> Yes, timing suggests there is some SHL/LHS flush.
>
> On p9 and later we can use mtvsrdd instead of mtvsrd (moving two
> bytes into place at one), which
On Fri, Sep 04, 2020 at 06:23:10PM +0200, Iain Buclaw wrote:
> If we're already using limits.h, I guess it should be fine to also add
>
> #define UINT_MAX ((unsigned) ~0U)
Yes, except that I'll use the simpler fall-back
#define UINT_MAX (~0U)
The habit of using a cast for unsigned constants
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96923
Andrew Pinski changed:
What|Removed |Added
Depends on||25290
--- Comment #2 from Andrew Pinski
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96923
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
On 9/4/20 6:26 AM, 易会战 via Gcc wrote:
how to check the location corresponding to a gimple statement? My instrument
stmt include some memory access, I wish get right source code line. By context
it is possible get wrong line.
The gimple_location() function returns the location of the GIMPLE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95189
--- Comment #16 from Martin Sebor ---
I think it should be. Let me do it.
GCC has an extension on machaines with cxx_implicit_extern_c (what used to be
!NO_IMPLICIT_EXTERN_C).
On such targets we'll treat 'extern "C" void Foo ()' as-if the argument list is
variadic. (or something approximating that)
perhaps that is confusing things?
nathan
On 9/6/20 4:43 PM,
Snapshot gcc-11-20200906 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/11-20200906/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 11 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96394
--- Comment #9 from Sergei Trofimovich ---
(In reply to Sergei Trofimovich from comment #8)
> Might end up being caused by the same bug in PR96913: TOPN streaming
> from/for shared libraries is incorrect.
>
> Proposed patch:
>
Jonathan Wakely via Gcc wrote:
On Sun, 6 Sep 2020 at 16:23, Iain Sandoe wrote:
g++.dg/abi/guard3.C
has:
extern "C" int __cxa_guard_acquire();
Which might not be a suitable declaration, depending on how the ‘extern
“C”’ is supposed to affect the function signature generated.
IF, the
On Sun, 6 Sep 2020 at 16:23, Iain Sandoe wrote:
>
> Hi
>
> g++.dg/abi/guard3.C
>
> has:
>
> extern "C" int __cxa_guard_acquire();
>
> Which might not be a suitable declaration, depending on how the ‘extern
> “C”’ is supposed to affect the function signature generated.
>
> IF, the extern C should
> OK (you can also put in a quick FIXME there).
Actually the decl being declared is using itself as one of the arguments, so I
think it’s on purpose that we don’t want to emit a full arglist here… to avoid
recursion. So I’m not sure we would want to change that.
FX
Hi FX,
The patch is regtested on x86_64-apple-darwin19.
I also tested it on aarch64-apple-darwin20, where it fixes wrong code issues in
several testcases.
OK (you can also put in a quick FIXME there).
Best regards
Thomas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53929
Arseny Solokha changed:
What|Removed |Added
CC||asolokha at gmx dot com
--- Comment #2
This is another function argtypes issue, very similar to
This code from proc_ptr_comp_13.f90 :
! PR 40882: [F03] infinite recursion in gfc_get_derived_type with PPC returning
derived type.
! At the same time, check that a formal argument does not cause infinite
recursion (PR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96947
Francois-Xavier Coudert changed:
What|Removed |Added
Resolution|--- |FIXED
On September 6, 2020 9:38:45 AM GMT+02:00, Gary Oblock via Gcc
wrote:
>>That's not a question? Are you asking why PHIs exist at all?
>>They are the standard way to represent merging in SSA
>>representations. You can iterate on the PHIs of a basic block, etc.
>
>Marc,
>
>I first worked with the
> Could you maybe put a FIXME at that place, explaining that we are
> in fact following K conventions there and what we would need
> to correc the function decl to use build_function_type_list?
Done.
FX
> OK!
Committed at
https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=3489d80fee42764460cb06f7a2e9f126c18602b4
It’s my first commit since GCC moved to git, let me know if I did it correctly
:)
FX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96947
--- Comment #1 from CVS Commits ---
The master branch has been updated by Franथà¤ois-Xavier Coudert
:
https://gcc.gnu.org/g:3489d80fee42764460cb06f7a2e9f126c18602b4
commit r11-3018-g3489d80fee42764460cb06f7a2e9f126c18602b4
Author:
Hi FX,
OK to commit?
OK!
Best regards
Thomas
Am 06.09.20 um 13:12 schrieb FX via Fortran:
Hi FX,
OK to commit?
The patch is OK in principle, I have also regtested it on POWER (which
is also somethat picky about calling conventions). However, in an
ideal world, this should only be a temporary fix.
Could you maybe put a FIXME at that
Hi,
The Fortran front-end, in gfc_trans_fail_image() emits a call to
_gfortran_caf_fail_image with one argument (a NULL pointer):
return build_call_expr_loc (input_location,
gfor_fndecl_caf_fail_image, 1,
build_int_cst
Hi,
The problem was reported in detail here:
https://gcc.gnu.org/pipermail/fortran/2020-September/055005.html and in
previous messages. When resolving select type constructs, the Fortran front-end
is trying to use the _gfortran_is_extension_of() library call (which is also
used for the
This patch corrects our handling of array new-expression with ()-init:
new int[4](1, 2, 3, 4);
should work even with the explicit array bound, and
new char[3]("so_sad");
should cause an error, but we weren't giving any.
Fixed by handling array new-expressions with ()-init in the same spot
There were some differences between the actual code in do_spec_1, its
source comment, and the documentation in doc/invoke.texi. These should
now be resolved.
gcc/ChangeLog:
* gcc.c: document %T spec file directive
* doc/invoke.texi:
remove %p, %P spec file directives
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96854
--- Comment #16 from Jakub Jelinek ---
If you want bugfixes as in this case. The cadence on the release branches is
gradually slowing down, the last release is usually about a year about the one
before that. It is already quite a lot of work
Hi
g++.dg/abi/guard3.C
has:
extern "C" int __cxa_guard_acquire();
Which might not be a suitable declaration, depending on how the ‘extern
“C”’ is supposed to affect the function signature generated.
IF, the extern C should make this parse as a “K” style function - then
the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96854
--- Comment #15 from Michael_S ---
Thank you.
That does not sound too different from what I assumed in post above.
10.1.0 is release. Expected to be used by "normal" people.
10.1.1 was for purpose of development of 10.2.0. Since release of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87256
John David Anglin changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96854
--- Comment #14 from Jakub Jelinek ---
The versioning is well documented https://gcc.gnu.org/develop.html#num_scheme
and the only way how things are fixed is fixing on the mainline and when needed
on still open release branches. Those will
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96854
--- Comment #13 from Michael_S ---
I don't follow gcc versioning policy all that closely.
What is the function "micro" versions now? For internal use and experimentation
only, but not for public release?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96854
--- Comment #12 from Jakub Jelinek ---
(In reply to Michael_S from comment #11)
> Just to understand
> Will 10.1 and 10.2 be fixed?
No, they were already released, so can't be fixed. You can apply the changes
to them if you want. The fix is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96394
--- Comment #8 from Sergei Trofimovich ---
Might end up being caused by the same bug in PR96913: TOPN streaming from/for
shared libraries is incorrect.
Proposed patch:
https://gcc.gnu.org/pipermail/gcc-patches/2020-September/553320.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96913
Sergei Trofimovich changed:
What|Removed |Added
Summary|gcc-11: __gcov_merge_topn |[10/11 regression] gcov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96913
Sergei Trofimovich changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96947
Bug ID: 96947
Summary: _gfortran_caf_fail_image called with wrong number of
arguments
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
From: Sergei Trofimovich
Before the change gcc did not stream correctly TOPN counters
if counters belonged to a non-local shared object.
As a result zero-section optimization generated TOPN sections
in a form not recognizable by '__gcov_merge_topn'.
The problem happens because in a case of
Hi,
Attached is a patch fixing the problem at:
https://gcc.gnu.org/pipermail/fortran/2020-September/054978.html
the reasoning behind the solution is explained here:
https://gcc.gnu.org/pipermail/fortran/2020-September/054997.html
In short, calls to class copy functions are made with wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96854
--- Comment #11 from Michael_S ---
Just to understand
Will 10.1 and 10.2 be fixed?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40771
--- Comment #3 from Zdenek Sojka ---
The vectorized code seems to have improved in gcc-9 over gcc-8.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96913
--- Comment #4 from Sergei Trofimovich ---
(In reply to Sergei Trofimovich from comment #3)
> Specifically I think this is already a wrong format on disk:
>
> > _json.gcda:01a7: 0:COUNTERS topn 0 counts
> > _json.gcda:01a9:
>Could you please get rid of this when posting on public mailing lists?
No, I have no control over that but I'll give the email of our corporate
IT if you want to complain to them...
From: Marc Glisse
Sent: Saturday, September 5, 2020 11:29 PM
To: Gary Oblock
>That's not a question? Are you asking why PHIs exist at all?
>They are the standard way to represent merging in SSA
>representations. You can iterate on the PHIs of a basic block, etc.
Marc,
I first worked with the SSA form twenty years ago so yes I am
aware of what a phi is... I've just never
On Sat, 5 Sep 2020, Gary Oblock via Gcc wrote:
First off one of the questions just me being curious but
second is quite serious. Note, this is GIMPLE coming
into my optimization and not something I've modified.
Here's the C code:
type_t *
do_comp( type_t *data, size_t len)
{
type_t *res;
56 matches
Mail list logo
