Hi Harald,
In answer to your question:
void
gfc_replace_expr (gfc_expr *dest, gfc_expr *src)
{
free_expr0 (dest);
*dest = *src;
free (src);
}
So it does indeed do the job.
I should perhaps have remarked that, following the divide error,
gfc_simplify_expr was returning a mutilated version
> Am 07.06.2023 um 18:59 schrieb Jakub Jelinek via Gcc-patches
> :
>
> Hi!
>
> We have expand_doubleword_clz for a couple of years, where we emit
> double-word CLZ as if (high_word == 0) return CLZ (low_word) + word_size;
> else return CLZ (high_word);
> We can do something similar for CTZ
> Am 07.06.2023 um 18:52 schrieb Jakub Jelinek via Gcc-patches
> :
>
> Hi!
>
> I'm getting
> +FAIL: gcc.target/i386/3dnow-1.c (internal compiler error: Segmentation fault
> signal terminated program cc1)
> +FAIL: gcc.target/i386/3dnow-1.c (test for excess errors)
> +FAIL:
On 5/25/23 06:35, Manolis Tsamis wrote:
Implementation of the new RISC-V optimization pass for memory offset
calculations, documentation and testcases.
gcc/ChangeLog:
* config.gcc: Add riscv-fold-mem-offsets.o to extra_objs.
* config/riscv/riscv-passes.def
From: Pan Li
This patch would like to refactor the requirement of both the ZVFH
and ZVFHMIN. By default, the ZVFHMIN will enable FP16 for all the
iterators of RVV. And then the ZVFH will leverage one function as
the gate for FP16 supported or not.
Please note the ZVFH will cover the ZVFHMIN
I would like to boldly suggest implementing P0847 should be targeted at
GCC14. In my anecdotal experiences, this feature is very important to
people, and very important to myself, I believe it should be a priority.
I am not suggesting this without offering to contribute, however
because of my
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110167
Bug ID: 110167
Summary: excessive compile time when optimizing std::to_array
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Micro-architecture unconditionally treats a "jr $ra" as "return from
subroutine",
hence doing "jr $ra" would interfere with both subroutine return prediction and
the more general indirect branch prediction.
Therefore, a problem like PR110136 can cause a significant increase in branch
error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110166
--- Comment #2 from Andrew Pinski ---
```
/* Max -> bool0 | bool1
Min -> bool0 & bool1 . */
(for op(max min)
logic (bit_ior bit_and)
(simplify
(op zero_one_valued_p@0 zero_one_valued_p@1)
(if (TYPE_PRECISION (type) != 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110162
--- Comment #7 from jinci kang ---
(In reply to Jonathan Wakely from comment #5)
> (In reply to Andrew Pinski from comment #4)
> > See https://gcc.gnu.org/gcc-13/porting_to.html also.
>
> I don't think this is related to the new rules.
>
>
From: Ju-Zhe Zhong
Co-authored-by: Richard Sandiford
Co-authored-by: Richard Biener
This patch address comments from Richard && Richi and rebase to trunk.
This patch is adding SELECT_VL middle-end support
allow target have target dependent optimization in case of
length calculation.
This
Hi Dave,
> If that's the code, does it work if you get rid of the "if (0)"
> conditional, or change it to "if (1)"? As written, that guard is
> false, so that call to "inform" will never be executed.
Woops! Somehow I missed that but yes, it works now. Thanks!
> Are you invoking gcc from an
Hi,
This patch checks if a constant is possible left/right cleaned on a rotated
value from a negative value of "li/lis". If so, we can build the constant
through "li/lis ; rldicl/rldicr".
Bootstrap and regtest pass on ppc64{,le}.
Is this ok for trunk?
BR,
Jeff (Jiufu)
gcc/ChangeLog:
Hi,
This patch checks if a constant is possible to be rotated to/from a negative
value from "lis". If so, we could use "lis;rotldi" to build it.
The positive value of "lis" does not need to be analyzed. Because if a
constant can be rotated from the positive value of "lis", it also can be
Hi,
This patch checks if a constant is possible to be built by "li;rldic".
We only need to take care of "negative li", other forms do not need to check.
For example, "negative lis" is just a "negative li" with an additional shift.
Bootstrap and regtest pass on ppc64{,le}.
Is this ok for trunk?
Hi,
This patch checks if a constant is possible to be rotated to/from a positive
or negative value from "li". If so, we could use "li;rotldi" to build it.
Bootstrap and regtest pass on ppc64{,le}.
Is this ok for trunk?
BR,
Jeff (Jiufu)
gcc/ChangeLog:
* config/rs6000/rs6000.cc
Hi,
These patches are just minor changes based on previous version/comments.
https://gcc.gnu.org/pipermail/gcc-patches/2023-February/611286.html
https://gcc.gnu.org/pipermail/gcc-patches/2023-June/620489.html
And also update the wording for patches in this series.
For a given constant, it would
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110165
--- Comment #2 from Andrew Pinski ---
This produces better gimple:
```
/* (zero_one == 0) ? y : z y -> ((typeof(y))zero_one * z) y */
(for op (bit_xor bit_ior plus)
(simplify
(cond (eq zero_one_valued_p@0
integer_zerop)
ping: https://gcc.gnu.org/pipermail/gcc-patches/2023-May/619951.html
Ref:
http://patchwork.ozlabs.org/project/gcc/patch/20230323080734.423-1-ji...@linux.alibaba.com/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110165
--- Comment #1 from Andrew Pinski ---
This will fix the issue:
/* (zero_one == 0) ? y : z y -> ((typeof(y))zero_one * z) y */
(for op (bit_xor bit_ior plus)
(simplify
(cond (eq@3 zero_one_valued_p@0
integer_zerop)
@1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110166
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110166
Bug ID: 110166
Summary: [14 Regression] wrong code with signed 1-bit integers
sometimes since r14-868-gb06cfb62229f
Product: gcc
Version: 14.0
Status: UNCONFIRMED
On 6/1/23 20:38, Vineet Gupta wrote:
Hi Jeff,
I finally got around to collecting various observations on PR/109279 -
more importantly the state of large constants in RV backend, apologies
in advance for the long email.
It seems the various commits in area have improved the original test
On 6/1/23 20:38, Vineet Gupta wrote:
Hi Jeff,
I finally got around to collecting various observations on PR/109279 -
more importantly the state of large constants in RV backend, apologies
in advance for the long email.
It seems the various commits in area have improved the original test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110165
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2023-06-07
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110165
Bug ID: 110165
Summary: [13/14 Regression] wrong code with signed 1 bit
integers sometimes since r13-4459-g6508d5e5a1a8
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
On Wed, Jun 7, 2023 at 4:11 PM Jeff Law wrote:
>
>
>
> On 6/7/23 17:05, Andrew Pinski wrote:
> > On Wed, Jun 7, 2023 at 3:57 PM Jeff Law via Gcc-patches
> > wrote:
> >>
> >>
> >>
> >> On 6/7/23 15:32, Andrew Pinski via Gcc-patches wrote:
> >>> Since there is a pattern to convert `(-zero_one) &
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105617
--- Comment #19 from Michael_S ---
(In reply to Mason from comment #18)
> Hello Michael_S,
>
> As far as I can see, massaging the source helps GCC generate optimal code
> (in terms of instruction count, not convinced about scheduling).
>
>
On 6/7/23 15:32, Andrew Pinski via Gcc-patches wrote:
This adds plus to the op list of `(zero_one == 0) ? y : z y` patterns
which currently has bit_ior and bit_xor.
This shows up now in GCC after the boolization work that Uroš has been doing.
OK? Bootstrapped and tested on x86_64-linux-gnu
On 6/7/23 17:05, Andrew Pinski wrote:
On Wed, Jun 7, 2023 at 3:57 PM Jeff Law via Gcc-patches
wrote:
On 6/7/23 15:32, Andrew Pinski via Gcc-patches wrote:
Since there is a pattern to convert `(-zero_one) & z` into `zero_one * z`
already,
it is better if we don't do a secondary
This minor tweak to the nvptx backend switches the representation of
of the brev instruction from an UNSPEC to instead use the new BITREVERSE
rtx. This allows various RTL optimizations including evaluation (constant
folding) of integer constant arguments at compile-time.
This patch has been
On Wed, Jun 7, 2023 at 3:57 PM Jeff Law via Gcc-patches
wrote:
>
>
>
> On 6/7/23 15:32, Andrew Pinski via Gcc-patches wrote:
> > Since there is a pattern to convert `(-zero_one) & z` into `zero_one * z`
> > already,
> > it is better if we don't do a secondary transformation. This reduces the
>
On 6/7/23 15:32, Andrew Pinski via Gcc-patches wrote:
Since there is a pattern to convert `(-zero_one) & z` into `zero_one * z`
already,
it is better if we don't do a secondary transformation. This reduces the extra
statements produced by match-and-simplify on the gimple level too.
Richard Sandiford was, of course, right to be warry of new code without
much test coverage. Converting the nvptx backend to use the BITREVERSE
rtx infrastructure, has resulted in far more exhaustive testing and
revealed a subtle bug in the new wi::bitreverse implementation. The
code needs to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109959
--- Comment #6 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #5)
> This is basically PR 102138 .
Except it works at -O1 because the cast is pushed out of the phi by phiopt but
the cast is the same as a & 1 here :(.
For
On 6/7/23 15:32, Andrew Pinski via Gcc-patches wrote:
This allows unsigned types if the inner type where the negation is
located has greater than or equal to precision than the outer type.
branchless-cond.c needs to be updated since now we change it to
use a multiply rather than still having
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109959
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
Snapshot gcc-10-20230607 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/10-20230607/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 10 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109791
--- Comment #17 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #16)
> (In reply to Richard Biener from comment #15)
> > Created attachment 55155 [details]
> > patch unfolding such PHIs
> >
> > Updated PHI unfolding patch.
On 5/25/23 06:35, Manolis Tsamis wrote:
Propagation of the stack pointer in cprop_hardreg is currenty forbidden
in all cases, due to maybe_mode_change returning NULL. Relax this
restriction and allow propagation when no mode change is requested.
gcc/ChangeLog:
* regcprop.cc
On 5/31/23 06:15, Manolis Tsamis wrote:
On Thu, May 25, 2023 at 4:38 PM Jeff Law wrote:
On 5/25/23 06:35, Manolis Tsamis wrote:
Propagation of the stack pointer in cprop_hardreg is currenty forbidden
in all cases, due to maybe_mode_change returning NULL. Relax this
restriction and allow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58487
--- Comment #7 from CVS Commits ---
The trunk branch has been updated by Jason Merrill :
https://gcc.gnu.org/g:28db36e2cfca1b7106adc8d371600fa3a325c4e2
commit r14-1624-g28db36e2cfca1b7106adc8d371600fa3a325c4e2
Author: Jason Merrill
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53637
--- Comment #10 from CVS Commits ---
The trunk branch has been updated by Jason Merrill :
https://gcc.gnu.org/g:28db36e2cfca1b7106adc8d371600fa3a325c4e2
commit r14-1624-g28db36e2cfca1b7106adc8d371600fa3a325c4e2
Author: Jason Merrill
Date:
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
Now that we support NRV from an inner block, we can also support non-NRV
returns from other blocks, since once the NRV is out of scope a later return
expression can't possibly alias it.
This fixes 58487 and half-fixes 53637: now one of the
On Wed, 7 Jun 2023, Qing Zhao via Gcc-patches wrote:
> Are you suggesting to use identifier directly as the argument of the
> attribute?
> I tried this in the beginning, however, the current parser for the attribute
> argument can not identify that this identifier is a field identifier inside
On Wed, 2023-06-07 at 19:19 +0200, Benjamin Priour wrote:
> Hi,
>
> I've been mapping where the analyzer is lacking support of the
> operator new
> different variants.
> I've written a bunch of test cases already to demonstrate it, you can
> find
> them below.
> They are not yet formatted for a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110164
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
Last reconfirmed|
On Wed, 2023-06-07 at 16:21 -0400, Eric Feng wrote:
> Hi everyone,
>
> I am one of the GSoC participants this year — in particular, I am
> working on a static analyzer plugin for CPython extension module
> code.
> I'm encountering a few challenges and would appreciate any guidance
> on
> the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110164
Bug ID: 110164
Summary: Improve diagnostic for incomplete standard library
types due to missing include
Product: gcc
Version: 14.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110155
Andrew Pinski changed:
What|Removed |Added
Keywords||patch
URL|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97711
Andrew Pinski changed:
What|Removed |Added
Keywords||patch
URL|
This adds plus to the op list of `(zero_one == 0) ? y : z y` patterns
which currently has bit_ior and bit_xor.
This shows up now in GCC after the boolization work that Uroš has been doing.
OK? Bootstrapped and tested on x86_64-linux-gnu with no regressions.
PR tree-optimization/97711
Since there is a pattern to convert `(-zero_one) & z` into `zero_one * z`
already,
it is better if we don't do a secondary transformation. This reduces the extra
statements produced by match-and-simplify on the gimple level too.
gcc/ChangeLog:
* match.pd (`zero_one ==/!= 0) ? y : z
This allows unsigned types if the inner type where the negation is
located has greater than or equal to precision than the outer type.
branchless-cond.c needs to be updated since now we change it to
use a multiply rather than still having (-a) in there.
OK? Bootstrapped and tested on
> On Jun 7, 2023, at 4:53 PM, Joseph Myers wrote:
>
> On Wed, 7 Jun 2023, Qing Zhao via Gcc-patches wrote:
>
>> Hi, Joseph,
>>
>> A question here: can an identifier in C be a wide char string?
>
> Identifiers and strings are different kinds of tokens; an identifier can't
> be a string of
The patterns match more than just `a & 1` so change the comment
for these two patterns to say that.
Committed as obvious after a bootstrap/test on x86_64-linux-gnu.
gcc/ChangeLog:
* match.pd: Fix comment for the
`(zero_one ==/!= 0) ? y : z y` patterns.
---
gcc/match.pd | 4
On 6/7/23 08:06, Andrew Pinski wrote:
On Sun, Jun 4, 2023 at 10:43 AM Jeff Law via Gcc-patches
wrote:
With Vlad's recent LRA fix to the elimination code, the H8 can be
converted to LRA.
Could you update the h8300 entry on https://gcc.gnu.org/backends.html
for this change?
Thanks for the
On 6/7/23 08:43, Jeff Law wrote:
On 6/7/23 08:13, Kito Cheng wrote:
I would like vendor cpu name start with vendor name, like
ventana-veyron-v1 which is consistent with all other vendor cpu, and
llvm are using same convention too.
Fair enough. Better to get it right now than have this
On 6/6/23 14:29, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?
-- >8 --
In the second testcase of PR110122, during regeneration of the generic
lambda with V=Bar{}, substitution followed by coerce_template_parms for
A's template argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109886
Andrew Macleod changed:
What|Removed |Added
CC||amacleod at redhat dot com
---
On Wed, 7 Jun 2023, Qing Zhao via Gcc-patches wrote:
> Hi, Joseph,
>
> A question here: can an identifier in C be a wide char string?
Identifiers and strings are different kinds of tokens; an identifier can't
be a string of any kind, wide or narrow. It just so happens that the
proposed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51571
--- Comment #11 from Jason Merrill ---
(In reply to CVS Commits from comment #9)
> This implements the guaranteed copy elision specified by P2025
Or not; I just noticed that P2025 also requires a fix for PR53637.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110163
Bug ID: 110163
Summary: [14 Regression] Comparing against a constant string is
inefficient on some targets
Product: gcc
Version: 14.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94566
--- Comment #13 from Andrew Macleod ---
(In reply to Andrew Pinski from comment #12)
> Aldy or Andrew, why in conv1 we don't get a range for
> SR.4_4 = sD.8798._M_valueD.7665;
>
> Even though the range we have is [-1,1] according to the
>
Hi everyone,
I am one of the GSoC participants this year — in particular, I am
working on a static analyzer plugin for CPython extension module code.
I'm encountering a few challenges and would appreciate any guidance on
the following issues:
1) Issue with "inform" diagnostics in the plugin:
I
On 6/7/23 13:15, Dimitar Dimitrov wrote:
On Tue, Jun 06, 2023 at 08:38:14PM -0600, Jeff Law wrote:
Regression tested for riscv32-none-elf. No changes in gcc.sum and
g++.sum. I don't have setup to test riscv64.
gcc/ChangeLog:
* config/riscv/riscv.cc (riscv_print_operand):
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99599
--- Comment #16 from danakj at orodu dot net ---
Well for anyone who hits the same issue, it appears that GCC _does_ follow
Clang and MSVC in not considering the overload and chasing through the concept
resolution if the non-concept types are
On 5/24/23 17:14, Jivan Hakobyan via Gcc-patches wrote:
Subject:
[RFC] RISC-V: Eliminate extension after for *w instructions
From:
Jivan Hakobyan via Gcc-patches
Date:
5/24/23, 17:14
To:
gcc-patches@gcc.gnu.org
`This patch tries to prevent generating unnecessary sign extension
after *w
On Wed, 7 Jun 2023 at 18:26, Jonathan Wakely wrote:
>
>
> On Wed, 7 Jun 2023, 18:17 Jakub Jelinek via Libstdc++, <
> libstd...@gcc.gnu.org> wrote:
>
>> Hi!
>>
>> This test apparently contains 3 problematic floating point constants,
>> 1e126, 4.91e-6 and 5.547e-6. These constants suffer from
Hi, Joseph,
A question here: can an identifier in C be a wide char string?
Qing
> On May 26, 2023, at 2:15 PM, Joseph Myers wrote:
>
> On Fri, 26 May 2023, Qing Zhao via Gcc-patches wrote:
>
>>> What if the string is a wide string? I don't expect that to work (either
>>> as a matter of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110162
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |INVALID
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107198
Thomas Schwinge changed:
What|Removed |Added
Last reconfirmed|2022-10-10 00:00:00 |2023-6-7
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110162
--- Comment #5 from Jonathan Wakely ---
(In reply to Andrew Pinski from comment #4)
> See https://gcc.gnu.org/gcc-13/porting_to.html also.
I don't think this is related to the new rules.
The std::move here is redundant because request is
Andrew Stubbs writes:
> On 30/05/2023 07:26, Richard Biener wrote:
>> On Fri, May 26, 2023 at 4:35 PM Andrew Stubbs wrote:
>>>
>>> Hi all,
>>>
>>> I want to implement a vector DIVMOD libfunc for amdgcn, but I can't just
>>> do it because the GCC middle-end models DIVMOD's return value as
>>>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110158
--- Comment #1 from Andrew Pinski ---
Here is a slightly reduced testcase (for a slightly different issue still
dealing with unions):
```
struct str1
{
// bool a;
char *var;
union {
char t[15];
int allocated;
};
constexpr
> On x864 Linux -fasynchronous-unwind-tables is the default. That is
> probably sufficient to make your test case work.
The testcase g++.dg/torture/except-1.C you recently added to the testsuite
does not pass at all if -fnon-call-exceptions is not specified (and does not
pass with optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106562
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110162
--- Comment #4 from Andrew Pinski ---
See https://gcc.gnu.org/gcc-13/porting_to.html also.
On Tue, Jun 06, 2023 at 08:38:14PM -0600, Jeff Law wrote:
>
>
> > Regression tested for riscv32-none-elf. No changes in gcc.sum and
> > g++.sum. I don't have setup to test riscv64.
> >
> > gcc/ChangeLog:
> >
> > * config/riscv/riscv.cc (riscv_print_operand): Calculate
> > memmodel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110162
--- Comment #3 from Andrew Pinski ---
See
https://gcc.gnu.org/onlinedocs/gcc-13.1.0/gcc/C_002b_002b-Dialect-Options.html#index-Wno-redundant-move
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110162
Andrew Pinski changed:
What|Removed |Added
Keywords||diagnostic
--- Comment #2 from Andrew
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110157
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
On Wed, Jun 7, 2023 at 10:09 AM Helmut Zeisel via Gcc wrote:
>
> I wrote some simple program that set a signal handler for SIGFPE, throws a
> C++ exception in the signal handler
> and catches the exception.
> I compiled with and without -fnon-call-exceptions (on x64 Linux).
> In both cases, the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106562
--- Comment #4 from Dimitar Dimitrov ---
The ideal PRU code sequence for the snippet would be:
char test(uint64_t a, uint64_t b)
{
return a && b;
}
or r14, r14, r15
or r16, r16, r17
uminr14, r14, 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110162
--- Comment #1 from jinci kang ---
# OK.
$ g++ -std=c++2a -Werror -Wall main.cpp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110157
--- Comment #1 from Andrew Pinski ---
If anything what is most likely happening is the stack is not being recorded as
executable which is needed for nest functions.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110162
Bug ID: 110162
Summary: redundant move in initialization
Product: gcc
Version: 13.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
On Wed, Jun 07, 2023 at 08:31:35PM +0200, Harald Anlauf via Fortran wrote:
> Hi FX,
>
> On 6/6/23 21:11, FX Coudert via Gcc-patches wrote:
> > Hi,
> >
> > > I cannot see if there is proper support for kind=17 in your patch;
> > > at least the libgfortran/ieee/ieee_arithmetic.F90 part does not
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110153
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99599
--- Comment #15 from danakj at orodu dot net ---
The workaround listed in Comment #6 does not work for templated types,
unfortunately, making Clang and MSVC more expressive here than GCC.
https://godbolt.org/z/obhsqhrbx
```
#include
#include
Hi Paul!
On 6/7/23 18:10, Paul Richard Thomas via Gcc-patches wrote:
Hi All,
Three more fixes for PR87477. Please note that PR99350 was a blocker
but, as pointed out in comment #5 of the PR, this has nothing to do
with the associate construct.
All three fixes are straight forward and the
Hi FX,
On 6/6/23 21:11, FX Coudert via Gcc-patches wrote:
Hi,
I cannot see if there is proper support for kind=17 in your patch;
at least the libgfortran/ieee/ieee_arithmetic.F90 part does not
seem to have any related code.
Can real(kind=17) ever be an IEEE mode? If so, something seriously
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110160
danakj at orodu dot net changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99599
danakj at orodu dot net changed:
What|Removed |Added
CC||danakj at orodu dot net
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109725
--- Comment #2 from CVS Commits ---
The master branch has been updated by Dimitar Dimitrov :
https://gcc.gnu.org/g:7f26e76c9848aeea9ec10ea701a6168464a4a9c2
commit r14-1621-g7f26e76c9848aeea9ec10ea701a6168464a4a9c2
Author: Dimitar Dimitrov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110160
--- Comment #2 from danakj at orodu dot net ---
Ugh, yeah, I guess it is. It means you can't redirect through a template
function that uses concepts with G++.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94566
Andrew Pinski changed:
What|Removed |Added
CC||aldyh at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110145
--- Comment #8 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:88e7f1f7ee67462713a89104ae07e99b191d5e2c
commit r14-1619-g88e7f1f7ee67462713a89104ae07e99b191d5e2c
Author: Jakub Jelinek
Date:
On Wed, 7 Jun 2023, 18:17 Jakub Jelinek via Libstdc++, <
libstd...@gcc.gnu.org> wrote:
> Hi!
>
> This test apparently contains 3 problematic floating point constants,
> 1e126, 4.91e-6 and 5.547e-6. These constants suffer from double rounding
> when -fexcess-precision=standard evaluates double
Hi,
I've been mapping where the analyzer is lacking support of the operator new
different variants.
I've written a bunch of test cases already to demonstrate it, you can find
them below.
They are not yet formatted for a patch submission, and as some of them may
require new warnings, I didn't use
1 - 100 of 258 matches
Mail list logo
