Hi!
installed as r14-9256
> diff --git a/contrib/mklog.py b/contrib/mklog.py
> index d764fb41f99..7d8d554b15e 100755
> --- a/contrib/mklog.py
> +++ b/contrib/mklog.py
> @@ -277,7 +277,7 @@ def generate_changelog(data, no_functions=False,
> fill_pr_titles=False,
> # it used to
On Wed, 28 Feb 2024 21:29:06 -0800
Jerry D wrote:
> The attached patch adds the error checks similar to the first patch
> previously committed.
>
> I noticed a redundancy in some defines MSGLEN and IOMSG_LEN so I
> consolidated this to one define in io.h. This is just cleanup stuff.
>
> I
On Tue, 27 Feb 2024 at 20:17, Tobias Burnus wrote:
>
> Minor update for older and more recent changes.
>
> Comments?
Nit:
+OpenACC 3.2: The following API routines are now available in
+ Fortran using the openacc module or the
+ open_lib.h header file: acc_alloc,
On Sun, 25 Feb 2024 at 22:12, Mark Harmstone wrote:
> Also, there are relocation types needed for Windows programs that are
> supported in COFF but not in ELF object files.
>
Right, it's been a long time since i last dealt with PECOFF and i had
assumed that things might have changed in the
On Thu, 22 Feb 2024 15:56:46 +
Evgeny Karpov wrote:
> A ChangeLog template using "Moved... ...here" has been generated by
> contrib/mklog.py.
> It seems that it needs modification.
>
> Regards,
> Evgeny
>
> -Original Message-
> Thursday, February 22, 2024 12:11 PM
> Richard
On Wed, 7 Feb 2024 12:43:53 +0100
arthur.co...@embecosm.com wrote:
> diff --git a/gcc/rust/typecheck/rust-hir-type-check-implitem.h
> b/gcc/rust/typecheck/rust-hir-type-check-implitem.h
> index 067465ec77a..4d178440775 100644
> --- a/gcc/rust/typecheck/rust-hir-type-check-implitem.h
> +++
On Wed, 7 Feb 2024 12:43:53 +0100
arthur.co...@embecosm.com wrote:
> diff --git a/gcc/rust/typecheck/rust-hir-type-check-implitem.h
> b/gcc/rust/typecheck/rust-hir-type-check-implitem.h
> index 067465ec77a..4d178440775 100644
> --- a/gcc/rust/typecheck/rust-hir-type-check-implitem.h
> +++
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
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
[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
ges do not regress but
behave as intended. I did check that the memory leak in
gfc_find_derived_vtab is fixed with the patch.
Ok for stage 1 if the rebased regression test passes?
thanks
>
> Am 17.11.21 um 09:12 schrieb Bernhard Reutner-Fischer via Gcc-patches:
> > On Tue, 16 Nov 2
Hi Kito!
On Thu, 11 Jan 2024 17:06:09 +0800
Kito Cheng wrote:
> Try to list all supported extensions: name, version and few description
> for each extension.
>
> gcc/ChangeLog:
>
> * doc/invoke.texi (RISC-V Options): Add list of supported
> extensions.
> ---
> gcc/doc/invoke.texi
On Wed, 10 Jan 2024 23:24:22 +0100
Harald Anlauf wrote:
> diff --git a/gcc/fortran/gfortran.h b/gcc/fortran/gfortran.h
> index 82f388c05f8..88502c1e3f0 100644
> --- a/gcc/fortran/gfortran.h
> +++ b/gcc/fortran/gfortran.h
> @@ -2926,6 +2926,10 @@ gfc_dt;
> typedef struct gfc_forall_iterator
> {
On Wed, 14 Jun 2023 21:14:02 +0200
Bernhard Reutner-Fischer wrote:
> plonk.
ping^3
patch at
https://inbox.sourceware.org/gcc-patches/20230526103151.3a7f6...@nbbrfq.loc/
I would regenerate it for rtx and/or tree, though, whatever you deem
desirable?
thanks
>
> On 26 May 2023 10:3
On Tue, 8 Aug 2023 16:31:39 -0400
Jason Merrill wrote:
> On 8/2/23 12:51, Patrick Palka via Gcc-patches wrote:
> > On Thu, Jun 1, 2023 at 2:11 PM Bernhard Reutner-Fischer
> > wrote:
> >>
> >> Hi David, Patrick,
> >>
> >> On Thu, 1 Jun 2023
[CCing Ian as libgcc maintainer]
On Wed, 1 Nov 2023 10:14:37 +
"Zhu, Lipeng" wrote:
> > >
> > > Hi Lipeng,
> > >
> > > >>> Sure, as your comments, in the patch V6, I added 3 test cases with
> > > >>> OpenMP to test different cases in concurrency respectively:
> > > >>> 1. find and create
On Wed, 25 Oct 2023 16:41:07 +0530
Ajit Agarwal wrote:
> On 25/10/23 2:19 am, Vineet Gupta wrote:
> > On 10/24/23 13:36, rep.dot@gmail.com wrote:
> >> As said, I don't see why the below was not cleaned up before the V1
> >> submission.
> >> Iff it breaks when manually CSEing,
On Mon, 23 Oct 2023 12:16:18 +0530
Ajit Agarwal wrote:
> Hello All:
>
> Addressed below review comments in the version 11 of the patch.
> Please review and please let me know if its ok for trunk.
s/satisified/satisfied/
> > As said, I don't see why the below was not cleaned up before the V1
On 27 September 2023 06:46:29 CEST, Bernhard Reutner-Fischer
wrote:
>On 27 September 2023 06:43:24 CEST, Jakub Jelinek wrote:
>>Hi!
>>
>>While looking into vec.h, I've noticed we still have a workaround for
>>GCC 4.1-4.3 bugs.
>
>
>This is https://gcc.gnu.o
On 27 September 2023 06:43:24 CEST, Jakub Jelinek wrote:
>Hi!
>
>While looking into vec.h, I've noticed we still have a workaround for
>GCC 4.1-4.3 bugs.
This is https://gcc.gnu.org/PR105656
thanks,
>As we now use C++11 and thus need to be built by GCC 4.8 or later,
>I think this is now never
On 26 September 2023 23:02:10 CEST, "Andre Vieira (lists)"
wrote:
>
>
>On 26/09/2023 21:26, Bernhard Reutner-Fischer wrote:
>> On 26 September 2023 18:46:11 CEST, Tobias Burnus
>> wrote:
>>> On 26.09.23 18:37, Andrew Stubbs wrote:
>>&
On 26 September 2023 18:46:11 CEST, Tobias Burnus
wrote:
>On 26.09.23 18:37, Andrew Stubbs wrote:
>> If the fall-through is deliberate please add a /* FALLTHROUGH */
>> comment (or whatever spelling disables the warning).
>
>It's: gcc_fallthrough ();
>
>Which gets converted to
Hi Maxim!
On Mon, 5 Jun 2023 18:06:25 +0400
Maxim Kuvyrkov via Gcc-patches wrote:
> > On Jun 3, 2023, at 19:17, Jeff Law wrote:
> >
> > On 6/2/23 09:20, Maxim Kuvyrkov via Gcc-patches wrote:
> >> This patch adds tracking of current testsuite "tool" and "exp"
> >> to the processing of .sum
On 18 September 2023 12:19:17 CEST, Julian Brown
wrote:
>On Thu, 14 Sep 2023 17:13:02 +0200
>Bernhard Reutner-Fischer via Gcc-patches
>wrote:
>
>> On Tue, 5 Sep 2023 12:28:28 -0700
>> Julian Brown wrote:
>>
>> > + static bool
>> > + equal (co
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)
>+ {
>+
d to add one
level of quotes -- sorry for that.
>
> On Jun 19, 2023, Bernhard Reutner-Fischer wrote:
>
> > I don't see explicit tests with _Complex nor __complex__. Would we
> > want to check these here, or are they handled thought the "underlying"
> > tests
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
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, se
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 Reutne
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 ty
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:
>>
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?
>
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 (co
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 "
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.
* objc-next-runtime-abi
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.
(Gcc_backend
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?
---
gcc/fortran
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 debug
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
On Mon, 17 Apr 2023 15:18:27 -0700
Steve Kargl wrote:
> On Mon, Apr 17, 2023 at 09:47:50PM +0200, Bernhard Reutner-Fischer via
> Fortran wrote:
> > On Mon, 03 Apr 2023 23:42:06 +0200
> > Bernhard Reutner-Fischer wrote:
> >
> > > On 3 April 2023 21
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? ;-)
nding on the underlying capabilities of available locks,
further tweaks, obviously.
PS: and, please, don't top-post
thanks,
>
> Best Regards,
> Zhu, Lipeng
>
> On 1/1/1970 8:00 AM, Bernhard Reutner-Fischer wrote:
> > On 19 April 2023 09:06:28 CEST, Lipeng Zhu via Fortran
1 - 100 of 908 matches
Mail list logo
