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
>> th
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 Tue, 5 Sep 2023 12:28:28 -0700
Julian Brown wrote:
> + static bool
> + equal (const omp_name_type &a,
> + const omp_name_type &b)
> + {
> +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 a
On 20 April 2020 13:43:42 CEST, Christophe Lyon via Gcc-patches
wrote:
>Some tests use --save-temps, but schedule-cleanups strictly matches
>-save-temps, so we leave many temporary files after validation.
>Instead of fixing every offending testcase, it's simpler and
>future-proof to make schedule
On 17 April 2020 23:18:05 CEST, Martin Sebor via Gcc-patches
wrote:
+ zero-initialialization for its type, taking pointers to members
s/initialialization/initialization/
On 17 April 2020 21:21:41 CEST, Martin Sebor via Gcc-patches
wrote:
>On 4/17/20 11:48 AM, Alexandre Oliva wrote:
>> On Apr 9, 2020, Alexandre Oliva wrote:
>>
>>> Some target C libraries that aren't recognized as freestanding don't
>>> have filesystem support, so calling tmpnam, fopen/open and
On Tue, 21 Apr 2020 at 16:59, Martin Sebor wrote:
> >>> https://gcc.gnu.org/pipermail/gcc-patches/2020-April/543672.html
> >>
> >> I'm okay with the changes to the tests.
> >>
> >> The target-supports.exp changes look reasonable to me as well but
> >> I can't approve them. Since you said it's fo
On 24 April 2020 11:59:50 CEST, Alexandre Oliva wrote:
>On Apr 23, 2020, Martin Sebor wrote:
>
>> Sure. I'd go with _fileio but that's just a suggestion.
>
>Okiedokie, here's the patch using fileio instead of tmpnam for the
>effective target name. I'm going to check it in shortly.
>
>
>introduc
On 5 June 2020 17:12:58 CEST, Thomas Koenig via Fortran
wrote:
>Hi Tom,
>
>> My earlier patch to add case handling to the spell checker caused a
>> Fortran regression. I believe I must have misread the test results.
>>
>> This patch fixes the problem by changing the cutoff. I chose this
>> val
On Tue, 9 Jun 2020 08:14:55 +0200
Thomas Koenig wrote:
> Hi Tom,
>
> > Bernhard> Yes, this is probably OK although Fortran is case-
> > Bernhard> insensitive. I think we lowercase names coming in from the
> > Bernhard> source (at least for the internal identifier nodes), so we
> > Bernhard> shou
On 22 October 2020 17:02:36 CEST, Jakub Jelinek via Gcc-patches
wrote:
>On Thu, Oct 22, 2020 at 04:52:10PM +0200, Tobias Burnus wrote:
>> + else
>> +{
>> + enum memmodel mo = MEMMODEL_LAST;
>> + switch (code->ext.omp_clauses->memorder)
>> +{
>> +case OMP_MEMORDER_ACQ_REL: m
On 16 October 2020 11:20:23 CEST, Richard Biener wrote:
>IMHO the cleanest way would be to swap the CAF token field and
>the dim[] field (which is an ABI change for -fcoarray)
I think coarrays are new anyway so I suppose an ABI break is fine?
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
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
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 __m_MOD_su
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) global n
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
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 size
\nbummer\n#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 exis
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
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:
* gfor
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 (gfc_attribute_table):
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); !
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
> &g
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 b/g
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/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 alloca
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 insert
:55:1: warning: Function ‘i64c’ could return ‘unsigned char’
[-Wtype-demotion]
55 | int i64c(int i)
| ^~~
| 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 funct
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): Like
100644
index 000..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
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 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 helpe
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
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 n
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.
> >
> >
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 i
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 = TAIL_RW
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;
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 message
[+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
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 insert_unit
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 Haral
he list. A second step would
be RELEASE.
And, depending 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:
> > O
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? ;-)
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 a52277abdbf..54
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 ch
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" "=&r")
>> (match_operand:GPR 1 "memory_operand" "+A"))
>> (set (match_dup 1)
>> -(unspec_volatile:GPR [(match_op
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.
> * config/riscv/sy
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 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 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 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 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 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, 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 ques
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 func
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? Other
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 could
On 3 February 2023 12:35:32 CET, Richard Biener via Gcc-patches
>
>I think it's OK as-is given this explanation.
>
s/derefernce/dereference/
thanks,
On 25 May 2022 16:42:05 CEST, Andrew MacLeod via Gcc-patches
wrote:
>Just fixed some misspelling and such.
Thanks!
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:
>
> * for
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
On Fri, 26 Mar 2021 23:14:41 +
Patrick McGehearty via Gcc-patches wrote:
> Changes in Version 9 since Version 8:
>
> Revised code to meet gcc coding standards in all files, especially
> with respect to adding spaces around operations and removing
> excess () in #define macro definiti
On Fri, 26 Mar 2021 23:14:41 +
Patrick McGehearty via Gcc-patches wrote:
> diff --git a/gcc/c-family/c-cppbuiltin.c b/gcc/c-family/c-cppbuiltin.c
> index 9f993c4..c0d9e57 100644
> --- a/gcc/c-family/c-cppbuiltin.c
> +++ b/gcc/c-family/c-cppbuiltin.c
> @@ -1277,8 +1277,10 @@ c_cpp_builtins (cp
On 1 April 2021 18:54:07 CEST, "H.J. Lu via Gcc-patches"
wrote:
>Since uiret should be used only for user interrupt handler return,
>don't
>generate uiret in interrupt handler return with -mcmodel=kernel even if
>UINTR is enabled.
>
>gcc/
>
> PR target/99870
> * config/i386/i386.md (i
On 1 April 2021 20:31:13 CEST, Bernhard Reutner-Fischer
wrote:
>On 1 April 2021 18:54:07 CEST, "H.J. Lu via Gcc-patches"
> wrote:
>>Since uiret should be used only for user interrupt handler return,
>>don't
>>generate uiret in interrupt handler return w
On 1 April 2021 20:32:34 CEST, Joel Sherrill wrote:
>Change the preprocessor logic so RTEMS uses utime().
>gcc/ada/
> * adaint.c (__gnat_copy_attribs): RTEMS should use utime().
RTEMS probably doesn't care alot about accurate time, from the looks. Otherwise
it would not mandate use of
On 1 April 2021 21:01:27 CEST, Bernhard Reutner-Fischer
wrote:
>On 1 April 2021 20:32:34 CEST, Joel Sherrill wrote:
>>Change the preprocessor logic so RTEMS uses utime().
>>gcc/ada/
>> * adaint.c (__gnat_copy_attribs): RTEMS should use utime().
>
>RTEMS proba
On Fri, 09 Apr 2021 11:54:59 -0500
will schmidt via Gcc-patches wrote:
> On Fri, 2021-04-09 at 10:43 -0400, Michael Meissner wrote:
> > gcc/
> > 2021-04-09 Michael Meissner
> > (movcc_fpmask): Replace
> > movcc_p9. Add IEEE 128-bit fp support.
> > (movcc_invert_fpmask
On 14 April 2021 21:01:15 CEST, Segher Boessenkool
wrote:
>> > > --- /dev/null
>> > > +++ b/gcc/testsuite/gcc.target/powerpc/float128-cmove.c
>> > > @@ -0,0 +1,93 @@
>> > > +/* { dg-do compile } */
>> > > +/* { dg-require-effective-target ppc_float128_hw } */
>> > > +/* { dg-require-effective-ta
On Fri, 7 Sep 2018 10:30:30 +0200
Bernhard Reutner-Fischer wrote:
> On Thu, 6 Sep 2018 at 03:25, Jerry DeLisle wrote:
> >
> > On 09/05/2018 07:57 AM, Bernhard Reutner-Fischer wrote:
> > > Hi,
> > >
> > > The fortran frontend still uses stack-based h
From: Bernhard Reutner-Fischer
gcc/ChangeLog:
* config/i386/x86-tune-sched-bd.c (dispatch_group): Commentary
typo fix.
---
gcc/config/i386/x86-tune-sched-bd.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/config/i386/x86-tune-sched-bd.c
b/gcc/config
On Thu, 22 Apr 2021 14:28:24 -0600
Martin Sebor via Gcc-patches wrote:
> > enum E { e = 5 };
> > struct A { E e: 3; };
> >
> > constexpr int number_of_bits ()
> > {
> > A a = { };
> > a.e = (E)-1;
> > return 32 - __builtin_clz(a.e);
> > }
> >
>
> I had the same thought about usin
On 15 June 2021 08:46:57 CEST, Richard Biener via Gcc-patches
wrote:
>On Tue, Jun 15, 2021 at 8:02 AM Trevor Saunders
>wrote:
>>
>> Signed-off-by: Trevor Saunders
>>
>> bootstrapped and regtested on x86_64-linux-gnu, ok?
>
>OK.
>
>Thanks,
>Richard.
>
>> gcc/ChangeLog:
>>
>> * dominance.
On 15 June 2021 13:48:39 CEST, Aldy Hernandez via Gcc-patches
wrote:
>For bitwise or, nonzero|X is always nonzero. Make sure we don't drop
>to
>varying in this case.
>
>This was found while examining differences between VRP/DOM threaders
>and
>the upcoming work, but it could be useful for any us
On 16 June 2021 05:09:17 CEST, Trevor Saunders wrote:
>> I'm curious why you keep the release() above and ...
>
>There was no particular reason, I just didn't make a very complete
>search to remove them all, as they should be harmless. I'm certainly
>happy to remove them, but wonder if it wouldn
Hi Andrew,
just a nit..
On Wed, 23 Jun 2021 15:19:13 -0700
apinski--- via Gcc-patches wrote:
> From: Andrew Pinski
>
> Since match and simplify does not have all of the inverted
> comparison patterns, it make sense to just have
> phi-opt try to do the inversion and try match and simplify agai
On 28 June 2021 01:24:59 CEST, apinski--- via Gcc-patches
wrote:
>From: Andrew Pinski
>
>Since match and simplify does not have all of the inverted
>comparison patterns, it make sense to just have
>phi-opt try to do the inversion and try match and simplify again.
>
>OK? Bootstrapped and tested o
On 2 July 2021 09:36:54 CEST, Richard Biener via Gcc-patches
wrote:
>On Thu, Jul 1, 2021 at 11:26 PM Joseph Myers
>wrote:
>>
>> On Thu, 1 Jul 2021, liuhongt via Gcc-patches wrote:
>>
>> > +/* Optimize for code like (_Float16) __builtin_ceif ((float) f16)
>> > + since it's not handled in fronte
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
> >> DECL_
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 temp
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’ speci
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 DE
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 @@ symbol_table::chang
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 == EXT_ATTR_LA
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
> > th
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 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,
On 22 December 2021 19:19:12 CET, Azat Khuzhin via Gcc-patches
wrote:
>Fixes: b667dd7017a ("Libsanitizer merge from trunk r368656.")
>Refs: https://reviews.llvm.org/D116176
>---
> .../sanitizer_common/sanitizer_common_interceptors.inc | 7 ---
> 1 file changed, 4 insertions(+), 3 deletions
On Wed, 22 Dec 2021 23:50:39 +0300
Azat Khuzhin wrote:
> Thanks!
you're welcome.
You should state how you tested the patch. Please refer to
https://gcc.gnu.org/contribute.html#testing
thanks,
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 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 count
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 enhance
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
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
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 b
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
801 - 900 of 906 matches
Mail list logo
