Hi Joseph!
On Tue, 30 Jan 2024 14:54:49 + (UTC)
Joseph Myers wrote:
> On Tue, 30 Jan 2024, Bernhard Reutner-Fischer via Gcc wrote:
>
> > * builtin-attrs.def (ATTR_TM_NOTHROW_RT_LIST): Use ATTR_NOTHROW_LIST
> > instead of ATTR_TM_NOTHROW_LIST, thus removi
[I was torn towards asking gcc@ only, individual i386 maintainers in
private or bluntly asking for help on gcc-patches or re-iterate through
ABI, so in an attempt to cut off years of latency i hereby ask all and
everybody for assistance. Stage4 means any chances are low, i know..
hence stage 1
On Tue, 5 Sep 2023 12:28:28 -0700
Julian Brown wrote:
> + static bool
> + equal (const omp_name_type ,
> + const omp_name_type )
> + {
> +if (a.name == NULL_TREE && b.name == NULL_TREE)
> + return a.type == b.type;
I'm curious if (and why) the type comparison above is safe and
On 23 June 2023 10:03:45 CEST, Richard Sandiford
wrote:
>> Fuse the block below into the one above as the condition seems to be
>> identical?
>
>Yeah, true, but I think the idea is that the code above “Arguments are
>ready” is calculating argument values, and the code after it is creating
On 23 June 2023 01:51:12 CEST, juzhe.zh...@rivai.ai wrote:
>From: Ju-Zhe Zhong
I am sorry but I somehow overlooked a trivial spot in V5.
Nit which does not warrant an immediate next version, but please consider it
before pushing iff approved:
>+if (final_len)
>+ {
>+
On Wed, 21 Jun 2023 22:08:55 -0300
Alexandre Oliva wrote:
> Thanks for the test.
>
> Did you mean for me to incorporate it into the patch, or do you mean to
> contribute it separately, if the feature happens to be accepted?
These were your tests that i quoted but i or my MUA botched to add one
Hi!
First of all, many thanks for the patch!
If i may, i have a question concerning the chosen style in the error
message and one nitpick concerning a return type though, the latter
primarily prompting this reply.
On Tue, 20 Jun 2023 11:54:25 +0100
Paul Richard Thomas via Fortran wrote:
> diff
On 16 June 2023 07:35:27 CEST, Alexandre Oliva via Gcc-patches
wrote:
index 0..634feaed4deef
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/hardbool-err.c
@@ -0,0 +1,28 @@
+/* { dg-do compile } */
+/* { dg-options "" } */
+
+typedef _Bool __attribute__ ((__hardbool__))
+hbbl; /* {
On 13 June 2023 17:11:13 CEST, Martin Jambor wrote:
>Ping.
s/funtction/function/
s/runing/running/
>
>Thanks,
plonk.
On 26 May 2023 10:31:51 CEST, Bernhard Reutner-Fischer
wrote:
>On Thu, 25 May 2023 18:58:04 +0200
>Bernhard Reutner-Fischer wrote:
>
>> On Wed, 24 May 2023 18:54:06 +0100
>> "Roger Sayle" wrote:
>>
>> > My understanding is that GCC's preferred null value for rtx is NULL_RTX
>> > (and
On Sat, 10 Jun 2023 11:29:36 -0700
Mike Stump wrote:
> On Jun 9, 2023, at 2:47 PM, Bernhard Reutner-Fischer
> wrote:
> > But well. Either way, what
> > should we do about remote env, if there is one? If the target
> > supports it, send it and skip otherwise?
On 9 June 2023 19:18:45 CEST, Mike Stump via Gcc-patches
wrote:
> simulation ports. Maybe a 20-100x speedup? If you want to go this way I'd
> say do it in python at the bottom as it would be nice to switch over to
> python in the next 5-20 years and away from tcl.
Yes, i guess we have all
On 3 June 2023 15:46:02 CEST, Xi Ruoyao wrote:
>Unfortunately __builtin_cpu_is performs CPU detection on runtime, not
>compile time.
Right, you were talking about configure, sorry.
On 3 June 2023 13:25:32 CEST, Xi Ruoyao via Gcc-patches
wrote:
>There seems no good way to check if the CPU is Intel or AMD from
>the built-in macros (maybe we can check every known model like __skylake,
>__bdver2, ..., but it will be very error-prune and require an update
>whenever we add the
Hi David, Patrick,
On Thu, 1 Jun 2023 18:33:46 +0200
Bernhard Reutner-Fischer wrote:
> On Thu, 1 Jun 2023 11:24:06 -0400
> Patrick Palka wrote:
>
> > On Sat, May 13, 2023 at 7:26 PM Bernhard Reutner-Fischer via
> > Gcc-patches wrote:
>
> > > diff --git
On Thu, 1 Jun 2023 11:24:06 -0400
Patrick Palka wrote:
> On Sat, May 13, 2023 at 7:26 PM Bernhard Reutner-Fischer via
> Gcc-patches wrote:
> > diff --git a/gcc/cp/tree.cc b/gcc/cp/tree.cc
> > index 131b212ff73..19dfb3ed782 100644
> > --- a/gcc/cp/tree.cc
> > +++ b
On 1 June 2023 09:20:08 CEST, Ajit Agarwal wrote:
>Hello All:
>
>This patch improves code sinking pass to sink statements before call to reduce
>register pressure.
>Review comments are incorporated.
Hi Ajit!
I had two comments for v4 that you did not address in v5 or followed up.
thanks,
On Thu, 1 Jun 2023 10:53:02 +0530
Ajit Agarwal via Gcc-patches wrote:
> Hello All:
>
> This new version of patch 4 use improve ree pass for rs6000 target using
> defined ABI interfaces.
> Bootstrapped and regtested on power64-linux-gnu.
>
> Review comments incorporated.
Not a review:
On Wed, 31 May 2023 09:40:24 +0200
Uros Bizjak via Gcc-patches wrote:
> On Wed, May 31, 2023 at 9:17 AM Richard Biener
> wrote:
> > Do we have a diagnostic that would point out places we
> > assign the bool result to an integer variable? Do we want
> > to change those places as well (did you
Hi!
On Wed, 31 May 2023 12:31:35 +0530
Ajit Agarwal via Gcc-patches wrote:
> Hello All:
>
> This patch improves code sinking pass to sink statements before call to reduce
> register pressure.
> Review comments are incorporated.
>
> For example :
>
> void bar();
> int j;
> void foo(int a, int
On Wed, 5 Sep 2018 17:32:04 +0200
Bernhard Reutner-Fischer wrote:
> On Tue, 21 Jun 2016 at 00:19, Jeff Law wrote:
> >
> > On 06/18/2016 01:31 PM, Bernhard Reutner-Fischer wrote:
> > > gcc/testsuite/ChangeLog
> > >
> > > 2016-06-18 Bernhard Reutner-Fischer
> > >
> > > PR
On Thu, 25 May 2023 18:58:04 +0200
Bernhard Reutner-Fischer wrote:
> On Wed, 24 May 2023 18:54:06 +0100
> "Roger Sayle" wrote:
>
> > My understanding is that GCC's preferred null value for rtx is NULL_RTX
> > (and for tree is NULL_TREE), and by being typed allows strict type checking,
> > and
On Wed, 24 May 2023 18:54:06 +0100
"Roger Sayle" wrote:
> My understanding is that GCC's preferred null value for rtx is NULL_RTX
> (and for tree is NULL_TREE), and by being typed allows strict type checking,
> and use with function polymorphism and template instantiation.
> C++'s nullptr is
On 24 May 2023 16:09:21 CEST, Qing Zhao wrote:
>Bernhard,
>
>Thanks a lot for your comments.
>
>> On May 19, 2023, at 7:11 PM, Bernhard Reutner-Fischer
>> wrote:
>>
>> On Fri, 19 May 2023 20:49:47 +
>> Qing Zhao via Gcc-patches wrote:
>>
>>> GCC extension accepts the case when a struct
On Fri, 19 May 2023 20:49:47 +
Qing Zhao via Gcc-patches wrote:
> GCC extension accepts the case when a struct with a flexible array member
> is embedded into another struct or union (possibly recursively).
Do you mean TYPE_TRAILING_FLEXARRAY()?
> diff --git a/gcc/tree.h b/gcc/tree.h
>
On Thu, 18 May 2023 21:20:41 +0200
Mikael Morin wrote:
> Le 18/05/2023 à 17:18, Bernhard Reutner-Fischer a écrit :
> > I've fed gfortran.h into the script and found some CLASS_DATA spots,
> > see attached bootstrapped and tested patch.
> > Do we want to have that?
> Some of it makes sense,
On 19 May 2023 07:58:48 CEST, "SenthilKumar.Selvaraj--- via Gcc-patches"
wrote:
Just a nit:
>+static bool
>+avr_addr_space_zero_address_valid (addr_space_t as ATTRIBUTE_UNUSED)
>+{
>+ return flag_delete_null_pointer_checks == 0;
>+}
Since we are c++ nowadays, you can omit the parameter name
On Sun, 14 May 2023 17:03:55 -0600
Jeff Law wrote:
> On 5/13/23 17:23, Bernhard Reutner-Fischer via Gcc-patches wrote:
> > From: Bernhard Reutner-Fischer
> >
> > gcc/ada/ChangeLog:
> >
> > * gcc-interface/decl.cc (gnat_to_gnu_entity): Use _P defines
>
On Mon, 15 May 2023 12:05:10 +0200
Eric Botcazou wrote:
> > && DECL_RETURN_VALUE_P (inner))
> > diff --git a/gcc/ada/gcc-interface/utils.cc b/gcc/ada/gcc-interface/utils.cc
> > index 0c4f8b90c8e..460ef6f1f01 100644
> > --- a/gcc/ada/gcc-interface/utils.cc
> > +++
On Sun, 14 May 2023 14:27:42 +0200
Mikael Morin wrote:
> Le 10/05/2023 à 18:47, Bernhard Reutner-Fischer via Fortran a écrit :
> > From: Bernhard Reutner-Fischer
> >
> > gcc/fortran/ChangeLog:
> >
> > PR fortran/78798
> > * array.cc (compare_bounds): Use narrower return type.
> >
On Sun, 14 May 2023 15:10:12 +0200
Mikael Morin wrote:
> Le 14/05/2023 à 01:23, Bernhard Reutner-Fischer via Gcc-patches a écrit :
> > From: Bernhard Reutner-Fischer
> >
> > gcc/fortran/ChangeLog:
> >
> > * trans-array.cc (is_pointer_arr
On 18 May 2023 14:56:45 CEST, Jonathan Wakely via Gcc-patches
wrote:
>From: Michael B��uerle
>
>POSIX sh does not support the == for string comparisons, use = instead.
>
>gcc/ChangeLog:
>
> PR bootstrap/105831
>
>diff --git a/gcc/configure.ac b/gcc/configure.ac
>index
On Mon, 15 May 2023 12:35:23 +0200
Aldy Hernandez via Gcc-patches wrote:
> +// For resizable ranges, resize the range up to HARD_MAX_RANGES if the
> +// NEEDED pairs is greater than the current capacity of the range.
> +
> +inline void
> +irange::maybe_resize (int needed)
> +{
> + if
On 15 May 2023 10:25:30 CEST, "juzhe.zh...@rivai.ai"
wrote:
>Address comments.
s/VXRM_RENUM/VXRM_REGNUM/g
thanks,
On Sun, 14 May 2023 15:04:15 +0200
Thomas Koenig wrote:
> On 14.05.23 14:27, Mikael Morin wrote:
> >
> > (...)
> >> @@ -2098,7 +2098,7 @@ ref_same_as_full_array (gfc_ref *full_ref,
> >> gfc_ref *ref)
> >> there is some kind of overlap.
> >> 0 : array references are identical
From: Bernhard Reutner-Fischer
gcc/ChangeLog:
* lto-streamer-in.cc (lto_input_var_decl_ref): Use _P defines from
tree.h.
(lto_read_body_or_constructor): Ditto.
* lto-streamer-out.cc (tree_is_indexable): Ditto.
(lto_output_var_decl_ref): Ditto.
From: Bernhard Reutner-Fischer
gcc/ChangeLog:
* alias.cc (ref_all_alias_ptr_type_p): Use _P() defines from tree.h.
* attribs.cc (diag_attr_exclusions): Ditto.
(decl_attributes): Ditto.
(build_type_attribute_qual_variant): Ditto.
* builtins.cc
From: Bernhard Reutner-Fischer
Dear maintainers
I propose the following mechanical change to use the defines in tree.h.
(Common convention is to use the defines as per tree.h, which is what we
keep telling people.)
Exceptions applied to the generator here:
NULL_TREE # we want to retain "NULL"
From: Bernhard Reutner-Fischer
gcc/rust/ChangeLog:
* backend/rust-compile-expr.cc (CompileExpr::type_cast_expression): Use
_P() defines from tree.h
* backend/rust-tree.cc (build_cplus_array_type): Ditto.
* backend/rust-tree.h (ARITHMETIC_TYPE_P): Ditto.
From: Bernhard Reutner-Fischer
gcc/ada/ChangeLog:
* gcc-interface/decl.cc (gnat_to_gnu_entity): Use _P defines
from tree.h.
(constructor_address_p): Ditto.
(elaborate_expression_1): Ditto.
* gcc-interface/trans.cc (Identifier_to_gnu): Ditto.
From: Bernhard Reutner-Fischer
gcc/cp/ChangeLog:
* call.cc (promoted_arithmetic_type_p): Use _P defines from tree.h.
(build_conditional_expr): Ditto.
(convert_like_internal): Ditto.
(convert_arg_to_ellipsis): Ditto.
(build_over_call): Ditto.
From: Bernhard Reutner-Fischer
gcc/ChangeLog:
* config/aarch64/aarch64.cc (aarch64_short_vector_p): Use _P
defines from tree.h.
(aarch64_mangle_type): Ditto.
* config/alpha/alpha.cc (alpha_in_small_data_p): Ditto.
(alpha_gimplify_va_arg_1): Ditto.
From: Bernhard Reutner-Fischer
gcc/fortran/ChangeLog:
* trans-array.cc (is_pointer_array): Use _P() defines from tree.h.
(gfc_conv_scalarized_array_ref): Ditto.
(gfc_conv_array_ref): Ditto.
* trans-decl.cc (gfc_finish_decl): Ditto.
(gfc_get_symbol_decl):
From: Bernhard Reutner-Fischer
gcc/m2/ChangeLog:
* gm2-gcc/m2builtins.cc (doradix): Use _P defines from tree.h.
(doplaces): Ditto.
(doexponentmin): Ditto.
(doexponentmax): Ditto.
(dolarge): Ditto.
(dosmall): Ditto.
(dogUnderflow): Ditto.
From: Bernhard Reutner-Fischer
gcc/objc/ChangeLog:
* objc-act.cc (objc_volatilize_decl): Use _P() defines from tree.h.
(objc_is_global_reference_p): Ditto.
(objc_generate_write_barrier): Ditto.
(objc_gimplify_property_ref): Ditto.
*
From: Bernhard Reutner-Fischer
gcc/go/ChangeLog:
* go-gcc.cc (Gcc_backend::fill_in_array): Use _P() defines from tree.h.
(Gcc_backend::named_type): Ditto.
(Gcc_backend::convert_expression): Ditto.
(operator_to_tree_code): Ditto.
From: Bernhard Reutner-Fischer
gcc/ChangeLog:
* omp-low.cc (scan_sharing_clauses): Use _P() defines from tree.h.
(lower_reduction_clauses): Ditto.
(lower_send_clauses): Ditto.
(lower_omp_task_reductions): Ditto.
* omp-oacc-neuter-broadcast.cc
From: Bernhard Reutner-Fischer
gcc/c-family/ChangeLog:
* c-ada-spec.cc (has_static_fields): Use _P() defines from tree.h.
(dump_ada_declaration): Ditto.
(dump_ada_structure): Ditto.
* c-common.cc (unsafe_conversion_p): Ditto.
(shorten_compare): Ditto.
From: Bernhard Reutner-Fischer
gcc/d/ChangeLog:
* d-codegen.cc (underlying_complex_expr): Use _P defines from tree.h.
* d-convert.cc (convert): Ditto.
(convert_for_rvalue): Ditto.
---
gcc/d/d-codegen.cc | 2 +-
gcc/d/d-convert.cc | 9 -
2 files changed, 5
From: Bernhard Reutner-Fischer
gcc/analyzer/ChangeLog:
* region-model-manager.cc (get_code_for_cast): Use _P defines from
tree.h.
(region_model_manager::get_or_create_cast): Ditto.
(region_model_manager::get_region_for_global): Ditto.
* region-model.cc
On 12 May 2023 14:45:14 CEST, Martin Jambor wrote:
>gcc/ChangeLog:
>
>2023-05-11 Martin Jambor
>
> PR ipa/108007
> * cgraph.h (cgraph_edge): Add a parameter to
> redirect_call_stmt_to_callee.
> * ipa-param-manipulation.h (ipa_param_adjustments): Added a
>
On 12 May 2023 08:49:53 CEST, Richard Biener via Gcc-patches
wrote:
>> gcc/ChangeLog:
>>
>> * combine.cc (struct reg_stat_type): Extended machine mode to 16 bits.
>> * cse.cc (struct qty_table_elem): Ditto.
>> (struct table_elt): Ditto.
>> (struct set): Ditto.
>> *
On 11 May 2023 04:30:16 CEST, "Li, Pan2 via Gcc-patches"
wrote:
>../../gcc/var-tracking.cc:3233:28: error: no match for 'operator!=' (operand
>types are 'rtx' {aka 'rtx_def*'} and 'decl_or_value' {aka
>'pointer_mux'}).
Wouldn't you usually declare operator!= by !(left == right) ?
thanks,
On Mon, 27 Jun 2022 14:10:36 +0800
Xi Ruoyao wrote:
> fgrep has been deprecated in favor of grep -F for a long time, and the
> next grep release (3.8 or 4.0) will print a warning of fgrep is used.
> Stop using fgrep so we won't see the warning.
>
> We can't hard code grep -F here or it may
[re-adding the lists, i hope you don't mind]
On Wed, 10 May 2023 18:52:54 +0200
Thomas Koenig wrote:
> Hi Bernhard,
>
> both patches look good to me.
Pushed as r14-664-g39f7c0963a9c00 and r14-665-gbdc10c2bfaceb3
Thanks!
>
> No user impact, so they should have the lowest possible impact :-)
From: Bernhard Reutner-Fischer
gcc/fortran/ChangeLog:
* dump-parse-tree.cc (gfc_debug_expr): Remove forward declaration.
(debug): Add DEBUG_FUNCTION.
(show_code_node): Remove erroneous whitespace.
---
Regression tested on x86_64-linux, OK for trunk?
---
From: Bernhard Reutner-Fischer
gcc/fortran/ChangeLog:
PR fortran/109624
* dump-parse-tree.cc (debug): New function for gfc_namespace.
(gfc_debug_code): Delete forward declaration.
(show_attr): Make sure to print balanced braces.
---
(gdb) call
From: Bernhard Reutner-Fischer
gcc/fortran/ChangeLog:
PR fortran/78798
* array.cc (compare_bounds): Use narrower return type.
(gfc_compare_array_spec): Likewise.
(is_constant_element): Likewise.
(gfc_constant_ac): Likewise.
* check.cc
Hi Roger!
On 10 May 2023 16:46:10 CEST, Roger Sayle wrote:
Just a nit:
+/* { dg-final { scan-tree-dump-times "bswap" 0 "optimized" } } */
Can you please use scan-tree-dump-not instead?
thanks,
Thomas,
On Fri, 5 May 2023 10:59:31 +0200
Thomas Schwinge wrote:
> Worth noting is that with nvptx offloading, there is one execution test case
> that times out ('libgomp.fortran/reverse-offload-5.f90'). This effectively
> stalls progress for almost 5 min:
Short of fixing it for real you
On Mon, 8 May 2023 12:42:33 +0200
Thomas Schwinge wrote:
> >> +if [info exists ::env(GCC_RUNTEST_PARALLELIZE_DIR)] {
> >> +load_file ../libgomp-test-support.exp
> >> +} else {
> >> +load_file libgomp-test-support.exp
> >> +}
> >
> > Do we have to re-read those?
On Mon, 8 May 2023 17:44:43 +0800
Lipeng Zhu wrote:
> This patch try to introduce the rwlock and split the read/write to
> unit_root tree and unit_cache with rwlock instead of the mutex to
> increase CPU efficiency. In the get_gfc_unit function, the percentage
> to step into the insert_unit
On Mon, 8 May 2023 17:31:27 +0800
"Zhu, Lipeng" wrote:
> > BTW, did you look at the RELEASE semantics, respectively the note that one
> > day (and now is that very
> > day), we might improve on the release semantics? Can of course be
> > incremental AFAIC
> >
> Not quite understand your
On Wed, 1 Mar 2023 16:07:14 -0800
Steve Kargl wrote:
> On Wed, Mar 01, 2023 at 10:28:56PM +0100, Bernhard Reutner-Fischer via
> Fortran wrote:
> > libgfortran/caf/single.c |6 ++
> > libgfortran/io/async.c |6 ++
> > libgfortran/io/format.c |3 +--
> >
>
> > > PR fortran/68800
> > >
> > > I did not construct individual test cases but it should be obvious that
> > > we should not leak these.
> > >
> > > >
> > > >On 4/2/23 17:05, Bernhard Reutner-Fischer via Gcc-patc
On Fri, 5 May 2023 10:55:41 +0200
Thomas Schwinge wrote:
> So I recently had re-created this patch independently, before remembering
> that Rainer had -- just eight years ago... ;-) -- already submitted this.
thanks to you both :)
> etc. (where "normal" is a libstdc++ detail), and regarding:
>
On 28 April 2023 09:26:06 CEST, Tobias Burnus wrote:
>Committed as r14-319-g7ebd4a1d61993c0a75e9ff3098aded21ef04a4da
> Only other changes are fixing the variable name a(b)breviated_modproc_decl
I think this is not good, I've mentioned it somewhere, i think, but I'll rename
it.
thanks!
On 28 April 2023 11:23:55 CEST, Florian Weimer via Fortran
wrote:
>* Martin Liška:
>But that's okay for me as well.
Even better.
On 28 April 2023 11:23:55 CEST, Florian Weimer via Fortran
wrote:
>* Martin Liška:
>But that's okay for me as well.
Even better.
On 26 April 2023 23:59:37 CEST, Patrick O'Neill wrote:
>>> gcc/ChangeLog:
>>>
>>> * config/riscv/riscv.cc: Fix whitespace.
>>> * config/riscv/sync.md: Fix whitespace.
>> The .md change above is gone by now.
>
>There are still some sync.md changes (comment whitespace/function whitespace
On 26 April 2023 23:21:06 CEST, Patrick O'Neill wrote:
>This patch fixes whitespace errors introduced with
>https://gcc.gnu.org/pipermail/gcc-patches/2023-April/616807.html
>
>2023-04-26 Patrick O'Neill
>
>gcc/ChangeLog:
>
> * config/riscv/riscv.cc: Fix whitespace.
> *
On 26 April 2023 23:10:01 CEST, Andreas Schwab wrote:
>On Apr 26 2023, Patrick O'Neill wrote:
>
>> @@ -290,10 +290,10 @@
>>[(set (match_operand:GPR 0 "register_operand" "=")
>> (match_operand:GPR 1 "memory_operand" "+A"))
>> (set (match_dup 1)
>> -(unspec_volatile:GPR
On 26 April 2023 20:31:10 CEST, Florian Weimer via Fortran
wrote:
>* Martin Liška:
>
>> On 11/15/22 16:47, Martin Liška wrote:
>>> Hi.
>>>
>>> I've just pushed libsanitizer update that was tested on x86_64-linux and
>>> ppc64le-linux systems.
>>> Moreover, I run bootstrap on x86_64-linux and
On 26 April 2023 20:31:10 CEST, Florian Weimer via Fortran
wrote:
>* Martin Liška:
>
>> On 11/15/22 16:47, Martin Liška wrote:
>>> Hi.
>>>
>>> I've just pushed libsanitizer update that was tested on x86_64-linux and
>>> ppc64le-linux systems.
>>> Moreover, I run bootstrap on x86_64-linux and
On 25 April 2023 18:58:10 CEST, Richard Sandiford via Gcc-patches
wrote:
>juzhe.zh...@rivai.ai writes:
>> diff --git a/gcc/internal-fn.cc b/gcc/internal-fn.cc
>> index 6e81dc05e0e..5f44def90d3 100644
>> diff --git a/gcc/tree-ssa-loop-manip.cc b/gcc/tree-ssa-loop-manip.cc
>> index
On 25 April 2023 17:12:50 CEST, Jan Hubicka via Gcc-patches
wrote:
+ fprintf (stderr, "Bingo\n");
You forgot to remove that..
Do we prune Bingo in the testsuite? ;-)
Hi!
[please do not top-post]
On Thu, 20 Apr 2023 21:13:08 +0800
"Zhu, Lipeng" wrote:
> Hi Bernhard,
>
> Thanks for your questions and suggestions.
> The rwlock could allow multiple threads to have concurrent read-only
> access to the cache/unit list, only a single writer is allowed.
right.
On Sun, 23 Apr 2023 23:48:03 +0200
Harald Anlauf via Fortran wrote:
> Am 22.04.23 um 10:32 schrieb Paul Richard Thomas via Gcc-patches:
> > PR103931 - I couldn't reproduce the bug, which involves 'ambiguous c_ptr'.
> > To judge by the comments, it seems that this bug is a bit elusive.
See
On 19 April 2023 09:06:28 CEST, Lipeng Zhu via Fortran
wrote:
>This patch try to introduce the rwlock and split the read/write to
>unit_root tree and unit_cache with rwlock instead of the mutex to
>increase CPU efficiency. In the get_gfc_unit function, the percentage
>to step into the
[+list]
On 19 April 2023 21:21:18 CEST, Bernhard Reutner-Fischer
wrote:
>Hi H-P!
>
>This begs the question iff now (i fear it's not), upon successful match(es),
>the whole peepholes get re-run again per BB (ATM?), exposing more
>opportunities?
>If not, would we want to retry, at least for
On Wed, 19 Apr 2023 at 03:03, Jerry D via Fortran wrote:
>
> On 4/18/23 12:39 PM, Harald Anlauf via Fortran wrote:
> > Dear all,
> >
> > the attached patch adjusts the scan-tree-dump patterns of the
> > reported testcases which likely were run in a location such
> > that a path in an error
On Wed, 19 Apr 2023 at 14:51, Bernhard Reutner-Fischer
wrote:
>
> On 19 April 2023 09:06:28 CEST, Lipeng Zhu via Fortran
> wrote:
>
> >+#ifdef __GTHREAD_RWLOCK_INIT
> >+#define RWLOCK_DEBUG_ADD(rwlock) do { \
> >+aio_rwlock_debug *n; \
> >+n = malloc
On 19 April 2023 09:06:28 CEST, Lipeng Zhu via Fortran
wrote:
>+#ifdef __GTHREAD_RWLOCK_INIT
>+#define RWLOCK_DEBUG_ADD(rwlock) do { \
>+aio_rwlock_debug *n; \
>+n = malloc (sizeof(aio_rwlock_debug));\
My malloc can fail.
>+n->prev =
>
> PR fortran/68800
>
> I did not construct individual test cases but it should be obvious that we
> should not leak these.
>
> >
> >On 4/2/23 17:05, Bernhard Reutner-Fischer via Gcc-patches wrote:
> >> From: Bernhard Reutner-Fischer
> >>
> &
Hi all, Janne!
On Wed, 19 Sep 2018 16:40:01 +0200
Bernhard Reutner-Fischer wrote:
> On Fri, 7 Sep 2018 at 10:07, Bernhard Reutner-Fischer
> wrote:
> >
> > On Wed, 5 Sep 2018 at 20:57, Janne Blomqvist
> > wrote:
> > >
> > > On Wed, Sep 5, 2018 at 5:58 PM Bernhard Reutner-Fischer
> > >
On 6 April 2023 12:49:53 CEST, Ajit Agarwal via Gcc-patches
wrote:
>Hello All:
>
>Eliminate unnecessary redundant extension within basic and across basic blocks.
To borrow HP's "arm-chair development mode", unfortunately most of the comments
i had for the previous version apply to this version
On 12 April 2023 16:21:24 CEST, Jakub Jelinek via Gcc-patches
wrote:
>--- gcc/range-op-float.cc.jj 2023-04-12 12:17:44.784962757 +0200
>+++ gcc/range-op-float.cc 2023-04-12 16:07:54.948759355 +0200
>@@ -835,10 +835,17 @@ public:
> bool fold_range (irange , tree type,
>
d be obvious that we
should not leak these.
>
>On 4/2/23 17:05, Bernhard Reutner-Fischer via Gcc-patches wrote:
>> From: Bernhard Reutner-Fischer
>>
>> Cc: fort...@gcc.gnu.org
>>
>> gcc/fortran/ChangeLog:
>>
>> * array.cc (gfc_ref_d
ping?
libcpp maintainers, is the helper in incpath.* ok?
fortraners,
Do you prefer a rogue, local forward declaration, or is the
introduction of that trivial wrapper ok? I don't think pulling in cpp.h
from f95-lang.cc is desirable, but i can do that if you all think
that's preferred.
From: Bernhard Reutner-Fischer
Cc: Arthur Cohen
Cc: Philip Herron
gcc/rust/ChangeLog:
* backend/rust-compile-expr.cc (CompileExpr::compile_integer_literal):
(CompileExpr::compile_float_literal): Fix memory leak.
---
gcc/rust/backend/rust-compile-expr.cc | 7 +++
1 file
From: Bernhard Reutner-Fischer
Cc: Ian Lance Taylor
gcc/go/ChangeLog:
* gofrontend/expressions.cc (Integer_expression::do_import): Fix
memory leak.
---
gcc/go/gofrontend/expressions.cc | 5 +
1 file changed, 5 insertions(+)
diff --git a/gcc/go/gofrontend/expressions.cc
From: Bernhard Reutner-Fischer
Cc: fort...@gcc.gnu.org
gcc/fortran/ChangeLog:
* array.cc (gfc_ref_dimen_size): Free mpz memory before ICEing.
* expr.cc (find_array_section): Fix mpz memory leak.
* simplify.cc (gfc_simplify_reshape): Fix mpz memory leaks in
error
From: Bernhard Reutner-Fischer
Hi!
These patches for the go, rust and fortran frontends fix the mpfr and
mpz memory leaks my coccinelle script found.
Bootstrapped and regtested without regressions on x86_64-unknown-linux,
including go,rust,fortran.
Ok for trunk for the fortran bits?
I'd hope
On Thu, 30 Mar 2023 17:30:43 +0530
Ajit Agarwal via Gcc-patches wrote:
> Hello All:
Just some nits.
And this seems to be an incremental diff ontop of your v2.
You might want check for coding-style errors by running:
contrib/check_GNU_style.py /tmp/ree-v2bis.patch
>
> This patch added
On 22 March 2023 13:29:52 CET, Richard Biener via Gcc-patches
wrote:
>The alternative would be to change last_stmt, explicitely introducing
>last_nondebug_stmt. I remember we chickened out and made last_stmt
>conservative here but not anticipating the compile-time issues this
>creates. I
On 12 March 2023 03:47:08 CET, Sean Bright via Gcc-patches
wrote:
>On 3/11/2023 6:39 PM, Bernhard Reutner-Fischer wrote:
>> On 11 March 2023 18:33:46 CET, Sean Bright via Gcc-patches
>> wrote:
>>> Hi,
>>>
>>> This fixes a minor issue where the zero-length-bound docs read "See See
>>> Zero
On 11 March 2023 18:33:46 CET, Sean Bright via Gcc-patches
wrote:
>Hi,
>
>This fixes a minor issue where the zero-length-bound docs read "See See
>Zero Length."
>
>gcc/ChangeLog:
> * doc/invoke.texi (Warning Options): Remove errant 'See'
> before @xref.
>---
> gcc/doc/invoke.texi | 2 +-
>
On 7 March 2023 07:21:23 CET, juzhe.zh...@rivai.ai wrote:
>From: Ju-Zhe Zhong
>
>+class vleff : public function_base
>+{
>+public:
>+ unsigned int call_properties (const function_instance &) const override
>+ {
>+return CP_READ_MEMORY | CP_WRITE_CSR;
>+ }
>+
>+ gimple *fold
On Mon, 6 Mar 2023 11:29:30 + (UTC)
Richard Biener via Gcc-patches wrote:
> On Mon, 6 Mar 2023, Jakub Jelinek wrote:
>
> > On Mon, Mar 06, 2023 at 11:01:18AM +, Richard Biener wrote:
> > > + auto_mpfr =(const auto_mpfr &) = delete;
> > > + auto_mpz =(const auto_mpz &) = delete;
>
On 2 March 2023 02:23:10 CET, Jerry D wrote:
>On 3/1/23 4:07 PM, Steve Kargl via Fortran wrote:
>> On Wed, Mar 01, 2023 at 10:28:56PM +0100, Bernhard Reutner-Fischer via
>> Fortran wrote:
>>> libgfortran/caf/single.c |6 ++
>>> libgfortran/io/async.c |6 ++
>>>
1 - 100 of 322 matches
Mail list logo
