On Sat, 5 Sep 2020, Jakub Jelinek wrote:
> Hi!
>
> The following patch adds streaming of edge goto_locus (both LOCATION_LOCUS
> and LOCATION_BLOCK from it), the PR shows a testcase (inappropriate for
> gcc testsuite) where the lack of streaming of goto_locus results in worse
> debug info.
> Earli
Hi
As requested, attaching a patch for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96948. This solves a
problem with _Unwind_Backtrace() on mingw64 + SEH.
Best regards
Kirill
>From bbc163476cab9bcaaa044d8aa9ecee824f7284f5 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Kirill=20M=C3=BCller?=
D
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)
Hi FX,
Regtested on x86_64-apple-darwin19 and tested on aarch64-apple-darwin20.
OK to commit?
Looks good to me.
Best regards
Thomas
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 s
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): Us
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 date
> 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
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 40870
> Could you maybe put a FIXME at that place, explaining that we are
> in fact following K&R 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
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 pl
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 (pchar_ty
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 EXTENDS
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
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 mult
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 funct
20 matches
Mail list logo