gcc/fortran/ChangeLog:
* dump-parse-tree.cc (show_code_node): Updated to use
c->ext.concur.forall_iterator instead of c->ext.forall_iterator.
Added support for dumping DO CONCURRENT locality specifiers.
* frontend-passes.cc (index_interchange, gfc_code_walker): Upda
On Sunday, September 22, 2024, Sandra Loosemore
wrote:
> […] I think the predicate of the more general case for
>
> target_device={device_num (NUM), kind(KIND), arch(ARCH), isa(ISA)}
>
> can be expressed (using GCC statement expression syntax) as
>
> ({
>int matches;
>#pragma omp target de
On Sat, Sep 21, 2024 at 08:08:29PM -0600, Sandra Loosemore wrote:
> On 9/20/24 01:41, Jakub Jelinek wrote:
> > > +
> > > + /* Check for unknown properties. */
> > > if (omp_ts_map[ts_code].valid_properties == NULL)
> > > continue;
> > > -
> >
> > Why?
>
> Why what? I
From: thor
This is the second revision of:
https://gcc.gnu.org/pipermail/gcc-patches/2024-September/662849.html
I've incorporated the feedback given both by Richard and David - I didn't
find any memory leaks when testing in valgrind :)
As before: This patch allows the compiler to dump GENERI
From: thor
This patch allows one to dump a tree as HTML from within gdb by invoking,
i.e,
htlml-tree tree
gcc/ChangeLog:
* gcc/gdbhooks.py: Rudimentary dumping of GENERIC trees as html through
one new python function (jsonNodeToHtml) and one new gdb command
(html-tree). There
On 9/20/24 01:41, Jakub Jelinek wrote:
+
+ /* Check for unknown properties. */
if (omp_ts_map[ts_code].valid_properties == NULL)
continue;
-
Why?
Why what? I made this change because when I added another check in this
loop I was temporarily confused about the
On 9/9/24 04:46, Tobias Burnus wrote:
I wonder whether we should do something like the following.
[The following is a mix between compile code and generated code, for
illustrative
purpose.]
Inside the compiler do:
#ifndef ACCEL_COMPILER
intr = 0; if (targetm.omp.device_kind_arch_isa != NULL
Add support of the 'self_maps' clause in 'omp requires',
an OpenMP 6 feature but added here mostly as part of the
on-going improvement of the unified-shared memory (USM) handling.
Comments, remarks concerns before I commit it?
* * *
Regarding USM, there is on one hand the hardware:
- some hard
On Sat, 21 Sept 2024, 14:24 Jason Merrill, wrote:
> Tested x86_64-pc-linux-gnu, OK for trunk?
>
All those macros already make them cluttered so this doesn't make them any
more unreadable!
OK, thanks
> -- 8< --
>
> With the changes to #pragma system_header, g++.dg/tm/pr46270.C was
> failing be
Hi!
It seems that we currently require
1) enabling at least c,c++,fortran,d in --enable-languages
2) first doing make html
before one can successfully regenerate-opt-urls, otherwise without 2)
one gets
make regenerate-opt-urls
make: *** No rule to make target
'/home/jakub/src/gcc/obj12x/gcc/HTML/
On Sat, Sep 21, 2024 at 04:32:38PM +0200, Mikael Morin wrote:
> Thanks for the tip.
> The Makefile dependencies seem to be incomplete.
> Here is what I get:
AFAIK right now one needs to configure at least c,c++,fortran,d
in --enable-languages (or some superset thereof) and
make -C gcc html
make -C
Le 21/09/2024 à 16:32, Mikael Morin a écrit :
Le 19/09/2024 à 23:24, Jakub Jelinek a écrit :
(...)
Just note lang.opt.urls will need to be updated, either you do it
right away
with make regenerate-opt-urls or commit, wait for a nag-mail from CI and
commit incrementally the patch it creates.
On Fri, Sep 20, 2024 at 07:03:45PM -0400, Jason Merrill wrote:
> > The CALL_EXPR case in cp_fold uses !flag_no_inline instead, that makes more
> > sense to me.
> > Because checking "noinline" attribute (which means don't inline this
> > function) on current_function_decl rather than on functions be
Le 19/09/2024 à 23:24, Jakub Jelinek a écrit :
On Mon, Sep 16, 2024 at 10:52:43AM +0200, Mikael Morin wrote:
While I understand the intent of 'positive form' vs 'negative form', the
above might be clearer as
Usage of intrinsics can be implemented either by generating a call
to the lib
From: Pan Li
Form 3:
#define DEF_VEC_SAT_S_ADD_FMT_3(T, UT, MIN, MAX) \
void __attribute__((noinline)) \
vec_sat_s_add_##T##_fmt_3 (T *out, T *op_1, T *op_2, unsigned limit) \
{
From: Pan Li
This patch would like to support the form 3 of the vector signed
integer .SAT_ADD. Aka below example:
Form 3:
#define DEF_VEC_SAT_S_ADD_FMT_3(T, UT, MIN, MAX) \
void __attribute__((noinline)) \
vec_sat_s_add_##T##_fmt_
Tested x86_64-pc-linux-gnu, OK for trunk?
-- 8< --
With the changes to #pragma system_header, g++.dg/tm/pr46270.C was
failing because didn't implement the N4514 change to [new.delete] that
says "The library versions of the global allocation and deallocation
functions are declared transaction_saf
On Fri, 20 Sep 2024, Tobias Burnus wrote:
> Comments, remarks to, approval of the attached wwwdocs patch?
+ Experimental support for unsigned integers; enabled by the
+ -funsigned, see https://gcc.gnu.org/onlinedocs/gfortran/Experimental-features-for-Fortran-202Y.html";
+ >gfortran docu
Arsen Arsenović writes:
> Okay, these patch should work correctly in all cases, at least all I
> could think of. The first patch is unchanged, the second one is simpler
> than it was before, I think.
Ah, and of course: tested on x86_64-pc-linux-gnu, OK for trunk?
--
Arsen Arsenović
signature
Okay, these patch should work correctly in all cases, at least all I
could think of. The first patch is unchanged, the second one is simpler
than it was before, I think.
-- >8 --
If such a diagnostic is necessary, it has already been emitted,
otherwise, it is not correct and emitti
convert_to_void has, so far, when converting a co_await expression to
void altered the await_resume expression of a co_await so that it is
also converted to void. This meant that the type of the await_resume
expression, which is also supposed to be the type of the whole co_await
expression, was no
On 31/07/2024 00:19, Jonathan Wakely wrote:
One more thing that I missed last time, sorry:
+#if __glibcxx_string_view >= 202403L
+ // const string & + string_view
+ template
+_GLIBCXX_NODISCARD _GLIBCXX20_CONSTEXPR
+inline basic_string<_CharT, _Traits, _Alloc>
+operator+(const basi
Hello,
The attached patch modifies std::atomic's primary template. The goal is
to improve compatibility with Clang, while also possibly making it more
complaint with the changes introduced by P0883 / C++20.
Simplifying, std::atomic has a `T t = T()` NDSMI and a defaulted default
constructor.
Hi Andrew, Sam!
On 2024-09-20T14:21:33-0700, Andrew Pinski wrote:
> On Fri, Sep 20, 2024 at 1:53 AM Thomas Schwinge
> wrote:
>> On 2024-09-20T05:12:19+0100, Sam James wrote:
>> > In this case, they were all harmless in reality (no diff in test logs).
>>
>> > -/* { dg-do compile ) */
>> > +/*
24 matches
Mail list logo