Hi Tobias!
On 2024-02-13T18:31:02+0100, Tobias Burnus wrote:
> --- a/gcc/fortran/openmp.cc
> +++ b/gcc/fortran/openmp.cc
> + /* Device number must be conforming, which includes
> + omp_initial_device (-1) and omp_invalid_device (-4). */
> + if (property_kind ==
On Tue, Feb 13, 2024 at 06:31:02PM +0100, Tobias Burnus wrote:
> PR middle-end/113904
>
> gcc/c/ChangeLog:
>
> * c-parser.cc (c_parser_omp_context_selector): Handle splitting of
> OMP_TRAIT_PROPERTY_EXPR into OMP_TRAIT_PROPERTY_{DEV_NUM,BOOL}_EXPR.
>
> gcc/cp/ChangeLog:
>
>
Jakub Jelinek wrote:
Isn't all this caused just by the missing check that condition trait has a
constant expression?
IMHO that is the way to handle it in GCC 14.
Concur – how about the following patch?
Tobias
PS: See PR113904 for follow up tasks. / Instead of '.AND.' etc. I could
have also
On Tue, Feb 13, 2024 at 03:54:28PM +0100, Tobias Burnus wrote:
> Inomp_resolve_declare_variant, a code path generates a new decl for the base
> function – in doing so, it ignores the assembler name. As the included
> Fortran example shows, this will lead to a linker error. Solution: Also copy
> ove
Inomp_resolve_declare_variant, a code path generates a new decl for the
base function – in doing so, it ignores the assembler name. As the
included Fortran example shows, this will lead to a linker error.
Solution: Also copy over the assembler name. Comments, suggestions,
remarks before I commi
