On Tue, 7 Dec 2021 16:07:01 +0100
Jan Hubicka via Gcc-patches wrote:
> Hi,
> as dicussed in PR ipa/103454 there are several benchmarks that regresses
> for -finline-functions-called once. Runtmes:
> - tramp3d with -Ofast. 31%
> - exchange2 with -Ofast 11-21%
> - roms O2 9%-10%
> - tonto
On Wed, 12 Jan 2022 16:54:46 +0100
Martin Liška wrote:
> +def replace_file_in_changelog(lines, filename):
> +if not filename.endswith('.cc'):
> +return
> +
> +# consider all componenets of a path: gcc/ipa-icf.cc
> +while filename:
> +for i, line in enumerate(lines):
>
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 21 April 2022 10:18:48 CEST, "Martin Liška" wrote:
>Pushed to master.
>- if test "$gcc_cv_gld_major_version" -eq 2 -a "$gcc_cv_gld_minor_version"
>-ge 19 -o "$gcc_cv_gld_major_version" -gt 2 \
>+ if test $ld_is_mold = yes; then
>+gcc_cv_ld_compress_debug=3
>+
On 25 April 2022 14:12:30 CEST, Jakub Jelinek via Fortran
wrote:
>On Mon, Apr 25, 2022 at 01:38:25PM +0200, Mikael Morin wrote:
>> I have just pushed the attached fix for two UNRESOLVED checks at -O0 that I
>> hadn’t seen.
>
>I don't like forcing of DSE in -O0 compilation, wouldn't it be better
On Fri, 29 May 2015 10:44:02 +0200
Bernhard Reutner-Fischer wrote:
> On 29 May 2015 at 10:21, Bernhard Reutner-Fischer
> wrote:
> > On 31 January 2015 at 22:10, Bernhard Reutner-Fischer
> > wrote:
> >> On January 31, 2015 9:17:57 PM GMT+01:00, Mike Stump
> &g
On Wed, 30 Oct 2013 10:41:33 +0100
Bernhard Reutner-Fischer wrote:
> > Hi!
> >
> > I've noticed that this testcase doesn't clean up after itself.
> > Fixed thusly, committed as obvious to trunk.
>
> This was nagging me last weekend.. ;)
> What about
On Fri, 2 Feb 2018 14:25:22 +0100
Bernhard Reutner-Fischer wrote:
> On 19 June 2016 at 22:21, Mike Stump wrote:
> > On Jun 18, 2016, at 12:31 PM, Bernhard Reutner-Fischer
> > wrote:
> >>
> >> A branch with a name matching scan-assembler pattern
On 20 May 2022 16:39:20 CEST, Segher Boessenkool
wrote:
>On Fri, May 20, 2022 at 10:11:32AM +0200, Eric Botcazou wrote:
>> > I suggest 'deduce', 'deduction', 'deducing a range'. What the code is
>> > actually doing is deducing that 'b' in 'a / b' cannot be zero. Function in
>> > GCC might be
Hi Andrew,
On Tue, 17 May 2022 14:38:39 -0400
Andrew MacLeod via Gcc-patches wrote:
> commit b7501739f3b14ac7749aace93f636d021fd607f7
> Author: Andrew MacLeod
> Date: Mon May 9 15:35:14 2022 -0400
> diff --git a/gcc/gimple-range-cache.cc b/gcc/gimple-range-cache.cc
> index
On Thu, 19 May 2022 10:52:35 -0400
David Malcolm wrote:
> > In file included from ../../../src/gcc-13.mine/gcc/tree-vrp.h:23,
> > from ../../../src/gcc-13.mine/gcc/ssa.h:28,
> > from ../../../src/gcc-13.mine/gcc/gimple-warn-
> > types.cc:30:
> >
On 25 May 2022 16:42:05 CEST, Andrew MacLeod via Gcc-patches
wrote:
>Just fixed some misspelling and such.
Thanks!
On 24 June 2022 14:35:20 CEST, Rainer Orth
wrote:
>Hi Xi,
>
>> On Fri, 2022-06-24 at 13:13 +0200, Bernhard Reutner-Fischer wrote:
>>
>>> > - if $(SHELL) -c 'install-info --version | sed 1q | fgrep -s -v
>>> > -i debian' >/dev/null 2>&
On 2 July 2022 14:47:01 CEST, Mikael Morin wrote:
>Le 02/07/2022 à 13:18, Thomas Koenig a écrit :
>>
>> One thought: If we have to bite the bullet and break the ABI, why not go
>> all the way and use the C descriptors in ISO_Fortran_binding.h as
>> gfortran's native format?
>>
>As far as I
On Fri, 24 Jun 2022 15:06:32 +0800
Xi Ruoyao via Gcc-patches 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.
>
> gcc/ChangeLog:
>
> *
On Fri, 29 Apr 2022 20:03:55 +0200
Thomas Koenig wrote:
> On 28.04.22 19:17, Bernhard Reutner-Fischer wrote:
> > ISTM that this should be s/mod.e/mode./ ?
>
> Yep, fixed as obvious and simple on trunk with
> r13-49-g4a8b45e8bc8246bd141dad65f571a3e0cc499c6b .
thanks!
&g
Hi Thomas,
On 27 April 2022 22:34:39 CEST, Thomas Koenig via Fortran
wrote:
+@item @code{'big_endian'} Do all unformatted I/O in big_endian mod.e
ISTM that this should be s/mod.e/mode./ ?
thanks,
On Wed, 4 May 2022 15:31:32 +0200
Martin Liška wrote:
> On 5/4/22 15:10, Alexander Monakov wrote:
> > On Wed, 4 May 2022, Martin Liška wrote:
> >
> >> On 5/4/22 14:32, Alexander Monakov wrote:
> >>> On Wed, 4 May 2022, Martin Liška wrote:
> >>>
> The patch is a follow-up of the
On 31 August 2022 20:29:12 CEST, FX via Fortran wrote:
+ case GFC_FPE_GFC_FPE_AWAY:
typo?
thanks,
On Tue, 27 Sep 2022 03:20:51 +0200
Ahmed Sayed Mousse via Gcc-patches wrote:
> diff --git a/libgomp/Makefile.am b/libgomp/Makefile.am
> index 6d913a93e7f..23f5bede1bf 100644
> --- a/libgomp/Makefile.am
> +++ b/libgomp/Makefile.am
> @@ -94,7 +94,7 @@ libgomp_la_SOURCES = alloc.c atomic.c
On 17 October 2022 03:02:22 CEST, Hongtao Liu via Gcc-patches
>> >> Do you have this series as a branch somewhere that I can try on one of the
>> >> like affected platforms?
>> >
>> > Not yet.
>> > Do we have any external place to put those patches so folks from the
>> > community can validate
On 17 October 2022 15:29:33 CEST, Christophe Lyon via Gcc-patches
wrote:
>Hi Srinath,
>
>
>On 10/10/22 10:20, Srinath Parvathaneni via Gcc-patches wrote:
>> Hi,
>>
>> This patch adds cde feature (optional) support for Cortex-M55 CPU, please
>> refer
>> [1] for more details. To use this feature
On Wed, 19 Oct 2022 at 15:56, Jonathan Yong via Gcc-patches
wrote:
> Just pushed to master branch.
Wouldn't you want to cut down on the libs respectively refine the
order of the libs, though?
You've now got:
+#define MCFGTHREAD_SPEC " -lmcfgthread -lkernel32 -lntdll "
+#else
+#define
On 25 October 2022 08:17:33 CEST, Monk Chiang wrote:
>gcc/ChangeLog:
>
>diff --git a/gcc/config/riscv/riscv-opts.h b/gcc/config/riscv/riscv-opts.h
>index 55e0bc0a0e9..63ac56a8ca0 100644
>--- a/gcc/config/riscv/riscv-opts.h
>+++ b/gcc/config/riscv/riscv-opts.h
>@@ -162,6 +162,12 @@ enum
On 17 September 2022 21:50:20 CEST, Mikael Morin wrote:
>Le 17/09/2022 à 21:33, Mikael Morin a écrit :
>> The testcase from the patch was not specifically checking lack of
>> side-effect clobbers, so I have double-checked with the following testcase,
>> which should lift your concerns.
>>
>The
On 17 September 2022 21:33:22 CEST, Mikael Morin wrote:
>Le 17/09/2022 à 19:03, Thomas Koenig via Fortran a écrit :
>>
>> Hi Mikael,
>>
>>> This adds support for clobbering of partial variable references, when
>>> they are passed as actual argument and the associated dummy has the
>>>
On 11 September 2022 10:04:51 CEST, David Malcolm via Gcc-patches
wrote:
>> +++ b/gcc/testsuite/gcc.dg/analyzer/pr106845.c
>> @@ -0,0 +1,11 @@
>> +int buf_size;
>> +
>> +int
>> +main (void)
>> +{
>> + char buf[buf_size];
>> +
>> + __builtin_memset ([1], 0, buf_size);
>> +
>> + return 0;
>>
On 16 September 2022 17:54:32 CEST, Patrick Palka via Gcc-patches
wrote:
>+++ b/gcc/testsuite/g++.dg/modules/typename-friend_a.C
>@@ -0,0 +1,11 @@
>+// { dg-additional-options "-fmodules-ts" }
>+export module foo;
>+// { dg-module-cmi foo }
>+
If that's a constant, repeating pain, you could
Hi Andrew!
On Thu, 29 Sep 2022 18:36:53 -0400
Andrew MacLeod via Gcc-patches wrote:
> diff --git a/gcc/gimple-range-gori.cc b/gcc/gimple-range-gori.cc
> index 57a7e820749..b37d03cddda 100644
> --- a/gcc/gimple-range-gori.cc
> +++ b/gcc/gimple-range-gori.cc
> @@ -934,6 +934,115 @@
On 4 October 2022 10:06:00 CEST, LIU Hao wrote:
>在 2022-10-03 13:03, Bernhard Reutner-Fischer 写道:
>>
>> No, sorry for my brevity.
>> Using __gthread_t like in your patch is correct.
>>
>
>I see. In 'libgfortran/io/async.c' there is
>
> ```
>
On Thu, 29 Sep 2022 18:38:10 -0400
Andrew MacLeod via Gcc-patches wrote:
> diff --git a/gcc/range-op.cc b/gcc/range-op.cc
> index 9bb04c361d0..830c64bd6b9 100644
> --- a/gcc/range-op.cc
> +++ b/gcc/range-op.cc
> @@ -1305,22 +1305,123 @@ operator_plus::wi_fold (irange , tree type,
>
On 1 October 2022 20:34:45 CEST, LIU Hao via Gcc-patches
wrote:
>Greetings.
>The first patch is necessary because somewhere in libgfortran, `pthread_t` is
>referenced. If the thread model is not `posix`, it fails to compile.
One of several shortcomings mentioned already on Sun, 02 Sep 2018
On Fri, 30 Sep 2022 17:32:34 -0600
Jeff Law wrote:
> + /* This looks good from a CFG standpoint. Now look at the guts
> + of PRED. Basically we want to verify there are no PHI nodes
> + and no real statements. */
> + if (! gimple_seq_empty_p (phi_nodes (pred)))
> +return false;
On Wed, 28 Sep 2022 16:44:29 -0400
Nathan Sidwell via Gcc-patches wrote:
> + else if (TREE_CODE (arg) == VAR_DECL && DECL_NTTP_OBJECT_P (arg))
Cosmetics, but I think the first part of the condition could be spelled
as VAR_P (arg)
thanks,
On 2 October 2022 14:54:54 CEST, LIU Hao wrote:
>在 2022-10-02 04:02, Bernhard Reutner-Fischer 写道:
>> On 1 October 2022 20:34:45 CEST, LIU Hao via Gcc-patches
>> wrote:
>>> Greetings.
>>
>>> The first patch is necessary because somewhere in libg
On 2 September 2022 13:37:41 CEST, FX via Fortran wrote:
>Hi,
Please do not call the non-standard abort, but use stop N.
IIRC I once had a trivial script..
https://www.mail-archive.com/search?l=gcc-patches@gcc.gnu.org=subject:%22%5C%5BPATCH%2C+OpenACC%5C%5D+Fortran+deviceptr%22=newest=1
On 2 September 2022 17:54:00 CEST, FX wrote:
>Hi Bernhard,
>
>> Please do not call the non-standard abort, but use stop N.
>
>Is there a specific reason? It’s a well-documented GNU extension, and it’s
>useful because it can easily display a backtrace and give line info for the
>failure, unlike
On 2 December 2022 20:30:56 CET, Jason Merrill wrote:
>Here's what I'm applying:
I meant to play with it during the weekend,
looks good, many thanks for taking care of this!
cheers,
Hi Arsen,
On 10 December 2022 14:14:59 CET, "Arsen Arsenović via Gcc-patches"
wrote:
>
>Arsen Arsenović writes:
>
>> Afternoon,
>>
>> This change prevents contracts from emitting wrapper functions that have the
>> same name as the original function, by moving the logic that disambiguates
>>
On Thu, 17 Nov 2022 18:52:36 -0500
Jason Merrill wrote:
> On 11/17/22 14:02, Bernhard Reutner-Fischer wrote:
> > On Thu, 17 Nov 2022 09:53:32 -0500
> > Jason Merrill wrote:
> >> Instead, you want to copy the location for instantiations, i.e. check
> >> DE
Hi Jason!
The "meh" of result-decl-plugin-test-2.C should likely be omitted,
grokdeclarator would need some changes to add richloc hints and we would not
be able to make a reliable guess what to remove precisely.
C.f. /* Check all other uses of type modifiers. */
Furthermore it is unrelated to
On Fri, 18 Nov 2022 11:06:29 -0500
Jason Merrill wrote:
> Ah, so the problem is deferred parsing of methods, rather than
> templates. Building the DECL_RESULT sooner does seem like the right
> approach to handling that, whether that's in grokfndecl or grokmethod.
> >> I'd like to get the
On Fri, 11 Nov 2022 11:17:17 -0500
Andrew MacLeod via Gcc-patches wrote:
> diff --git a/gcc/tree-vrp.cc b/gcc/tree-vrp.cc
> index 3393c73a7db..a474d9d11e5 100644
> --- a/gcc/tree-vrp.cc
> +++ b/gcc/tree-vrp.cc
> @@ -4485,6 +4486,7 @@ public:
> for (gphi_iterator gsi = gsi_start_phis (bb);
Hi Honza, Ping.
Regtests cleanly for c,fortran,c++,ada,d,go,lto,objc,obj-c++
Ok?
I'd need this for attribute target_clones for the Fortran FE.
thanks,
On Wed, 9 Nov 2022 20:02:24 +0100
Bernhard Reutner-Fischer wrote:
> We were changing the ASSEMBLER_NAME of the function decl
> but not th
On Tue, 15 Nov 2022 18:52:41 -0500
Jason Merrill wrote:
> On 11/12/22 13:45, Bernhard Reutner-Fischer wrote:
> > gcc/cp/ChangeLog:
> >
> > * decl.cc (start_function): Set the result decl source location to
> > the location of the typespec.
> >
>
Hi Jason!
Possible test.
An existing test might be to equip the existing warning for
bool unsigned double meh(void) {return 0;}
with a fix-it hint instead of the brief
error: two or more data types in declaration of ‘meh’.
Likewise for
bool unsigned meh(void) {return 0;}
error: ‘unsigned’
On Mon, 21 Nov 2022 12:24:11 +0100
Mikael Morin wrote:
> > --- a/gcc/fortran/decl.cc
> > +++ b/gcc/fortran/decl.cc
> (...)
> > @@ -11849,7 +11850,9 @@ gfc_match_gcc_attributes (void)
> > if (strcmp (name, ext_attr_list[id].name) == 0)
> > break;
> >
> > - if (id ==
On Mon, 21 Nov 2022 20:02:49 +0100
Jan Hubicka wrote:
> > Hi Honza, Ping.
> > Regtests cleanly for c,fortran,c++,ada,d,go,lto,objc,obj-c++
> > Ok?
> > I'd need this for attribute target_clones for the Fortran FE.
> Sorry for delay here.
> > > void
> > > @@ -303,6 +301,10 @@
On Mon, 21 Nov 2022 20:13:40 +0100
Mikael Morin wrote:
> Hello,
>
> Le 09/11/2022 à 20:02, Bernhard Reutner-Fischer via Fortran a écrit :
> > Hi!
> >
> > Add support for attribute target_clones:
> > !GCC$ ATTRIBUTES target_clones("arch1", "arc
On Mon, 21 Nov 2022 12:08:20 +0100
Mikael Morin wrote:
> > * gfortran.h (struct ext_attr_t): Remove middle_end_name.
> > * trans-decl.cc (add_attributes_to_decl): Move building
> > tree_list to ...
> > * decl.cc (gfc_match_gcc_attributes): ... here. Add the attribute to
> >
On Thu, 17 Nov 2022 09:53:32 -0500
Jason Merrill wrote:
> On 11/17/22 03:56, Bernhard Reutner-Fischer wrote:
> > On Tue, 15 Nov 2022 18:52:41 -0500
> > Jason Merrill wrote:
> >
> >> On 11/12/22 13:45, Bernhard Reutner-Fischer wrote:
> >>>
---
ceb17928e5d1d5 copied (parts of) the valgrind annotation checks from gcc
to libcpp. The above copies the missing pieces to libcpp to diagnose
when libcpp is configured with --enable-valgrind-annotations but
valgrind is not installed.
Tested with --enable-valgrind-annotations without valgrind
On 19 January 2023 20:39:08 CET, Jason Merrill wrote:
>On Sat, Nov 12, 2022 at 4:24 PM Harald Anlauf via Gcc-patches
> wrote:
>>
>> Am 12.11.22 um 22:05 schrieb Bernhard Reutner-Fischer via Gcc-patches:
>> > This function definition was removed years ago, remove it
On Thu, 3 Nov 2022 23:23:55 +0100
Bernhard Reutner-Fischer wrote:
> Hi!
>
> I encounter a problem/pilot error when using the target_clones
> attribute.
>
> The symptom is that the default clone is not renamed in the output and
> thus conflicts with the (proper) glob
Tiny cleanup opportunity since we now have ext_attr_args in
struct symbol_attribute.
Bootstrapped and regtested on x86_64-unknown-linux with no new
regressions.
Ok for trunk if the prerequisite was approved ([PATCH 2/2] Fortran: add
attribute target_clones) ?
gcc/fortran/ChangeLog:
*
Bootstrapped and regtested cleanly on x86_unknown-linux.
The document bits will be rewritten for rst.
Ok for trunk if the prerequisite target_clones patch is approved?
gcc/fortran/ChangeLog:
* decl.cc (gfc_match_gcc_attributes): Handle flatten.
* f95-lang.cc
Hi!
I could imagine that the flatten attribute might be useful.
Do we want to add support for it for gcc-13?
Bernhard Reutner-Fischer (2):
Fortran: Cleanup struct ext_attr_t
Fortran: Add attribute flatten
gcc/fortran/decl.cc | 41 +---
gcc/fortran
Hi!
I encounter a problem/pilot error when using the target_clones
attribute.
The symptom is that the default clone is not renamed in the output and
thus conflicts with the (proper) global name which is used for the
ifunc:
$ nl -ba < /tmp/cc3jBX3x.s | grep sub1
12 .type
It looks like there was some memory leak in the handling
of attribute target_clones, introduced in 5928bc2ec06d .
Ok for trunk if testing passes?
gcc/ChangeLog:
* multiple_target.cc (expand_target_clones): Free memory.
Signed-off-by: Bernhard Reutner-Fischer
---
gcc
Ok for trunk if testing passes?
gcc/ChangeLog:
* cgraph.cc (cgraph_node::make_local): Remove redundant set_section.
* multiple_target.cc (create_dispatcher_calls): Likewise.
Signed-off-by: Bernhard Reutner-Fischer
---
gcc/cgraph.cc | 1 -
gcc/multiple_target.cc | 1
Hi!
Add support for attribute target_clones:
!GCC$ ATTRIBUTES target_clones("arch1", "arch3","default") :: mysubroutine
Bootstrapped and regtested on x86_64-unknown-linux with
--target_board=unix'{-m32,-m64}'.
OK for trunk?
gcc/fortran/ChangeLog:
* decl.cc: Include fold-const.h for
#endif" \
| ./xgcc -B. -x f95-cpp-input -ffree-form -E -dD - | grep -i x86
$ # nothing
versus
$ echo -e "#ifndef __x86_64__\nbummer\n#endif" \
| ./xgcc -B. -x assembler-with-cpp -E -dD - | grep -i x86
#define __x86_64 1
#define __x86_64__ 1
I'm sure we have existing PRs about
We were changing the ASSEMBLER_NAME of the function decl
but not the name in DECL_RTL which is used as the function name
fnname in rest_of_handle_final(). This led to using the old, wrong name
for the attribute target default function when using target_clones.
Bootstrapped and regtested cleanly
On Fri, 11 Nov 2022 18:17:46 -0500
Andrew MacLeod wrote:
> On 11/11/22 16:56, Bernhard Reutner-Fischer wrote:
> > So of course it doesn't really matter what that stmt was, a non_debug
> > is as good as a debug one AFAIU, it's just a marker, as good as any SSA
> > version
gcc/cp/ChangeLog:
* decl.cc (start_function): Set the result decl source location to
the location of the typespec.
---
Bootstrapped and regtested on x86_86-unknown-linux with no regressions.
Ok for trunk?
Cc: Nathan Sidwell
Cc: Jason Merrill
---
gcc/cp/decl.cc | 15
gcc/fortran/ChangeLog:
* arith.cc (compare_complex): Use narrower return type.
(gfc_compare_string): Likewise.
* arith.h (gfc_compare_string): Same.
(gfc_compare_with_Cstring): Ditto.
* array.cc (compare_bounds): Ditto.
(gfc_compare_array_spec):
| ^~~
| unsigned char
return-narrow.cc:55:1: note: with a range of [46,122]
So, any help wrt the template case? -- many TIA!
Bernhard Reutner-Fischer (5):
c: Set the locus of the function result decl
c++: Set the locus of the function result decl
Fortran: Narrow return types [PR78798]
gcc/ChangeLog:
* value-range.cc (get_bound_with_infinite_markers): New static helper.
(irange::as_string): New definition.
* value-range.h: New declaration.
---
Provide means to print a value range to a newly allocated buffer.
The caller is responsible to free() the
Bootstrapped and regtested on x86_86-unknown-linux with no regressions.
Ok for trunk?
Cc: Joseph Myers
---
gcc/c/ChangeLog:
* c-decl.cc (start_function): Set the result decl source
location to the location of the typespec.
---
gcc/c/c-decl.cc | 6 +-
1 file changed, 5
This function definition was removed years ago, remove it's prototype.
gcc/fortran/ChangeLog:
* gfortran.h (gfc_check_include): Remove declaration.
---
gcc/fortran/gfortran.h | 1 -
1 file changed, 1 deletion(-)
---
Regtests cleanly, ok for trunk?
diff --git a/gcc/fortran/gfortran.h
..e0b7212a1bb
--- /dev/null
+++ b/gcc/gimple-warn-types.cc
@@ -0,0 +1,441 @@
+/* Pass to detect and issue warnings about possibly using narrower types.
+
+ Copyright (C) 2021-2022 Free Software Foundation, Inc.
+ Contributed by Bernhard Reutner-Fischer
+
+ This file is part of GCC.
+
+ GCC
yearly ping. Ok for trunk after re-regtesting?
thanks,
On Sun, 31 Oct 2021 13:57:46 +0100
Bernhard Reutner-Fischer wrote:
> From: Bernhard Reutner-Fischer
>
> gcc/fortran/ChangeLog:
>
> PR fortran/99884
> * io.c (check_open_constraints): Remove double sp
On Sun, 13 Nov 2022 12:13:26 +0200
Janne Blomqvist wrote:
> On Sun, Nov 13, 2022 at 1:47 AM Bernhard Reutner-Fischer via Fortran
> wrote:
> > --- a/gcc/fortran/arith.cc
> > +++ b/gcc/fortran/arith.cc
> > @@ -1135,7 +1135,7 @@ compare_complex (gfc_expr *op1, gfc_expr *o
On 2 November 2022 15:45:39 CET, Tamar Christina via Gcc-patches
wrote:
>Hi All,
>
>This patch adds initial support for early break vectorization in GCC.
>The support is added for any target that implements a vector cbranch optab.
>
>Concretely the kind of loops supported are of the forms:
>
>
On Sun, 13 Nov 2022 19:42:52 +
Jonathan Wakely via Gcc-patches wrote:
> On Sun, 13 Nov 2022, 18:06 Arsen Arsenović via Libstdc++, <
> libstd...@gcc.gnu.org> wrote:
>
> > I'm unsure why this issue only started manifesting now with how old this
> > code is, but this should fix it.
> >
>
On 13 November 2022 21:29:50 CET, Harald Anlauf wrote:
>Replacing "int" by "signed char" adds confusion and makes code
>less understandable, so I would oppose it, as we don't solve a
>real problem and rather add confusion.
Ok so consider the non-bool hunks dropped, they just fell out of my
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 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 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 zer
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 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 Tue, 22 Nov 2022 12:54:01 +0100
Jan Hubicka wrote:
> > > I am not quite sure how safe this is. We generally produce DECL_RTL
> > > when we produce assembly file. So if DECL_RTL is set then we probably
> > > already output the original function name and it is too late to change
> > > it.
>
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 ++
>>> li
Hi!
Mere cosmetics.
- if (foo != NULL)
free (foo);
With the caveat that coccinelle ruins replacement whitespace or i'm
uneducated enough to be unable to _not_ run the diff through
sed -e 's/^+\([[:space:]]*\)free(/+\1free (/'
at least. If anybody knows how to improve replacement
On Wed, 1 Mar 2023 22:58:59 +0100
Bernhard Reutner-Fischer wrote:
> On Wed, 1 Mar 2023 22:28:56 +0100
> Bernhard Reutner-Fischer wrote:
>
> > Remarks:
> > 1) We should do this in if-conversion (?) on our own.
> >I suppose. Independently of -fdelete-null-pointer-c
On Wed, 1 Mar 2023 22:28:56 +0100
Bernhard Reutner-Fischer wrote:
> Remarks:
> 1) We should do this in if-conversion (?) on our own.
>I suppose. Independently of -fdelete-null-pointer-checks
and iff we can prove that ptr was NULL when passed to free(ptr) then we
can elide
On Thu, 2 Mar 2023 00:54:33 +0100
Hans-Peter Nilsson wrote:
> > Date: Thu, 2 Mar 2023 00:23:36 +0100
> > From: Bernhard Reutner-Fischer
>
> > On Wed, 1 Mar 2023 17:02:31 +0100
> > Hans-Peter Nilsson via Gcc-patches wrote:
> >
> > > > From:
On Wed, 1 Mar 2023 10:40:15 +0100
Tobias Burnus wrote:
> Hi,
>
> Please CC fortran@gcc for Fortran patches.
> > --- a/gcc/fortran/target-memory.cc
> > +++ b/gcc/fortran/target-memory.cc
> > @@ -417,10 +417,13 @@ gfc_interpret_float (int kind, unsigned char *buffer,
> > size_t buffer_size,
> >
On Wed, 1 Mar 2023 17:02:31 +0100
Hans-Peter Nilsson via Gcc-patches wrote:
> > From: Hans-Peter Nilsson
> > Date: Wed, 1 Mar 2023 16:36:46 +0100
>
> > ... this is what I intend to commit later
> > today, just keeping the added comment as brief as
> > reasonable:
>
> Except I see the hook
On Wed, 1 Mar 2023 14:59:44 -0800
Andrew Pinski wrote:
> On Wed, Mar 1, 2023 at 1:31 PM Bernhard Reutner-Fischer via Fortran
> wrote:
> >
> > Hi!
> >
> > Mere cosmetics.
> >
> > - if (foo != NULL)
> > free (foo);
> >
> > With th
On Wed, 1 Mar 2023 07:39:40 -0800
Steve Kargl via Gcc-patches wrote:
> In fact, Hollerith should be hidden behind a -fallow-hollerith
> option and added to -std=legacy.
While i'd be all for that, in my mind this will block off literally all
consultants and quite some scientists unless we error
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,
>
Bernhard Reutner-Fischer wrote:
> On 3 April 2023 21:50:49 CEST, Harald Anlauf wrote:
> >Hi Bernhard,
> >
> >there is neither context nor a related PR with a testcase showing
> >that this patch fixes issues seen there.
>
> Yes, i forgot to mention the PR:
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 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 =
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
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
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: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 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? ;-)
701 - 800 of 881 matches
Mail list logo
