On Thu, 28 Oct 2021, Hans-Peter Nilsson wrote:
> On Wed, 20 Oct 2021, Richard Biener via Gcc-patches wrote:
>
> > This maps -ftrapv to -fsanitize=signed-integer-overflow
> > -fsanitize-undefined-trap-on-error,
>
> Isn't that UBSAN target-dependent, i.e. not supported on all
> targets, whereas -f
On Thu, 28 Oct 2021, Qing Zhao wrote:
> Ping….
>
> Hi,
>
> Based on the previous discussion, I thought that we have agreed that the
> proposed patch for this current bug is the correct fix.
> And This bug is an important bug that need to be fixed.
>
> I have created another new PR for the ot
On Thu, Oct 28, 2021 at 5:25 PM Aldy Hernandez via Gcc-patches
wrote:
>
> Same thing as the relational change. Walk any equivalences that have
> been registered on the path, and remove the name being killed. The
> only reason we had added the equivalence with itself earlier is so we
> wouldn't s
On Thu, Oct 28, 2021 at 5:44 PM Iain Sandoe wrote:
>
> Hi Richard,
>
> > On 8 Sep 2021, at 07:35, Richard Biener wrote:
> >
> > On Tue, Sep 7, 2021 at 10:11 PM Iain Sandoe wrote:
> >>
>
> >> So, looking through the various email threads and the PR, I think that
> >> what has happened is :
> >>
>
On Thu, Oct 28, 2021 at 8:34 PM Jeff Law via Gcc-patches
wrote:
>
>
>
> On 10/28/2021 9:24 AM, Aldy Hernandez wrote:
> > This patch upgrades the pre-VRP threading passes to fully resolving
> > backward threaders, and removes the post-VRP threading passes altogether.
> > With it, we reduce the numb
On Fri, Oct 29, 2021 at 2:42 AM Bernhard Reutner-Fischer via
Gcc-patches wrote:
>
> From: Bernhard Reutner-Fischer
>
> Bump required DejaGnu version to 1.5.3 (or later).
> Ok for trunk?
OK.
Thanks,
Richard.
> gcc/ChangeLog:
>
> * doc/install.texi: Bump required minimum DejaGnu version.
This forces -fexcess-precision=standard since the testcase is
otherwise prone to fail with x87 math.
Tested on x86_64-unknown-linux-gnu with {,-m32}, pushed.
2021-10-29 Richard Biener
* gcc.dg/torture/fp-uint64-convert-double-1.c: Add
-fexcess-precision=standard.
---
gcc/test
Robin Dapp writes:
> Hi,
>
> as discussed in
> https://gcc.gnu.org/pipermail/gcc-patches/2021-October/582627.html this
> introduces a bias parameter for the len_load/len_store ifns as well as
> optabs that is meant to distinguish between Power and s390 variants.
> The default is a bias of 0, while
Hi!
As mentioned yesterday, gimple_fold_builtin_memset doesn't preserve
locus which means e.g. the -Wstringop-overflow warnings are emitted as:
In function 'test_max':
cc1: warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=]
The function emits up to 2 new statements, but the lat
On Fri, Oct 29, 2021 at 9:30 AM Richard Biener
wrote:
> Btw, in case the "fully resolving" mode is slower than not fully resolving
> please consider gating it on -fexpensive-optimizations (aka -O2+), thus
> run the passes in not fully resolving modes at-O1.
Sorry for the awkward naming. I could
On Fri, 29 Oct 2021, Jakub Jelinek wrote:
> Hi!
>
> As mentioned yesterday, gimple_fold_builtin_memset doesn't preserve
> locus which means e.g. the -Wstringop-overflow warnings are emitted as:
> In function 'test_max':
> cc1: warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=]
On Fri, Oct 29, 2021 at 10:06 AM Aldy Hernandez wrote:
>
> On Fri, Oct 29, 2021 at 9:30 AM Richard Biener
> wrote:
>
> > Btw, in case the "fully resolving" mode is slower than not fully resolving
> > please consider gating it on -fexpensive-optimizations (aka -O2+), thus
> > run the passes in not
ping
On Mon, Oct 11, 2021 at 02:14:53PM +0200, Stefan Schulze Frielinghaus wrote:
> On Mon, Oct 11, 2021 at 09:38:36AM +0200, Richard Biener wrote:
> > On Fri, Oct 8, 2021 at 1:31 PM Stefan Schulze Frielinghaus via
> > Gcc-patches wrote:
> > >
> > > gcc/ChangeLog:
> > >
> > > * regcprop.c
On Fri, Oct 29, 2021 at 10:10 AM Richard Biener
wrote:
>
> On Fri, Oct 29, 2021 at 10:06 AM Aldy Hernandez wrote:
> >
> > On Fri, Oct 29, 2021 at 9:30 AM Richard Biener
> > wrote:
> >
> > > Btw, in case the "fully resolving" mode is slower than not fully resolving
> > > please consider gating it
Hi,
this patch extends modref and tree-ssa-structalias to handle retslot flags.
Since retslot it essentially a hidden argument that is known to be write-only
we can do pretty much the same stuff as we do for regular parameters.
I plan to add static chain handling similar way.
We do not handle IPA
On Tue, Oct 26, 2021 at 5:27 PM Martin Liška wrote:
>
> On 10/26/21 10:13, Richard Biener wrote:
> > On Tue, Oct 19, 2021 at 8:49 AM Martin Liška wrote:
> >>
> >> On 10/18/21 12:08, Richard Biener wrote:
> >>> Can you please use a subdirectory for the sources, a "toplevel"
> >>> license.txt doesn
On Fri, 29 Oct 2021, Jan Hubicka wrote:
> Hi,
> this patch extends modref and tree-ssa-structalias to handle retslot flags.
> Since retslot it essentially a hidden argument that is known to be write-only
> we can do pretty much the same stuff as we do for regular parameters.
> I plan to add static
The original motivation was to fix the routine part
of the restriction quoted below. Namely that the only
routines calls to
omp_get_num_teams() and omp_get_team_num()
are permitted in teams when closely nested.
"Restrictions to the teams construct are as follows:
...
• distribute regions, incl
On Fri, Oct 29, 2021 at 12:09:55PM +0200, Tobias Burnus wrote:
> The original motivation was to fix the routine part
> of the restriction quoted below. Namely that the only
> routines calls to
> omp_get_num_teams() and omp_get_team_num()
> are permitted in teams when closely nested.
>
>
> "Rest
On Thu, Oct 28, 2021 at 05:51:59PM +0200, Tobias Burnus wrote:
> libcpp/ChangeLog:
>
> PR c++/102409
> * directives.c (destringize_and_run): Add PRAGMA_OP to the
> CPP_PRAGMA token's flags to mark is as coming from _Pragma.
> * include/cpplib.h (PRAGMA_OP): #define, to be u
Hi All,
The layout of the SLP tree has changed in GCC 12 which
broke the detection of complex FMA and FMS.
This patch updates the detection to the new tree shape
and by necessity merges the complex MUL and FMA detection
into one.
This does not yet address the wrong code-gen PR which I
will fix i
Hi All,
This beefs up the complex numbers vectorization testsuite
and adds target independent checks next to the target
dependent ones.
This allows regressions to the detection code to be found
when running on any target, not just aarch64.
Regtested on aarch64-none-linux-gnu,
x86_64-pc-linux-gnu
On Fri, Oct 29, 2021 at 01:52:58AM +0200, Bernhard Reutner-Fischer wrote:
> From: Bernhard Reutner-Fischer
>
> Introduce a helper to construct a user operator from a name and the
> reverse operation, i.e. a helper to construct a name from a user
> operator.
>
> Cc: Jakub Jelinek
>
> gcc/fortra
On Fri, 29 Oct 2021, Tamar Christina wrote:
> Hi All,
>
> The layout of the SLP tree has changed in GCC 12 which
> broke the detection of complex FMA and FMS.
>
> This patch updates the detection to the new tree shape
> and by necessity merges the complex MUL and FMA detection
> into one.
>
> T
On Fri, 29 Oct 2021, Tamar Christina wrote:
> Hi All,
>
> This beefs up the complex numbers vectorization testsuite
> and adds target independent checks next to the target
> dependent ones.
>
> This allows regressions to the detection code to be found
> when running on any target, not just aarch
On Wed, Oct 27, 2021 at 4:40 AM Xionghu Luo wrote:
>
>
>
> On 2021/10/26 21:20, Richard Biener wrote:
> > On Mon, Oct 18, 2021 at 6:29 AM Xionghu Luo wrote:
> >>
> >>
> >>
> >> On 2021/10/15 16:11, Richard Biener wrote:
> >>> On Sat, Oct 9, 2021 at 5:45 AM Xionghu Luo wrote:
>
> Hi,
>
On Wed, 27 Oct 2021, Xionghu Luo wrote:
> gcc/ChangeLog:
>
> * cfghooks.c (cfg_hook_duplicate_loop_to_header_edge): Rename
> duplicate_loop_to_header_edge to
> duplicate_loop_body_to_header_edge.
> (cfg_hook_duplicate_loop_body_to_header_edge): Likewise.
> * cfghooks
On Wed, 27 Oct 2021, Xionghu Luo wrote:
> loop_version currently does lv_adjust_loop_entry_edge
> before it loopifys the copy inserted on the header. This patch moves
> the condition generation later and thus we have four pieces to help
> understanding of how the adjustment works:
> 1) duplicati
On Thu, Oct 28, 2021 at 03:35:20PM -0400, Patrick Palka wrote:
> > Is there a reason to turn this mode of evaluating everything twice if an
> > error should be diagnosed all the time, rather than only if we actually see
> > a TRUTH_*_EXPR we want to handle this way?
> > If we don't see any TRUTH_*_
Hi,
in intrinsic.texi, a lot of tables wrap lines when watching the
resulting info file in a 80char terminal.
Adjust the @columnfractions items to fit screen. Some minor white space
changes are added as well to help saving space.
Signed-off-by Manfred Schwarb
[Note: I do not have commit acces
Hi,
on 2019-07-23, support for SHORT and LONG intrinsics were removed be Steve
Kargl by
adding an error message in check.c. However, the error message
Error: 'long' intrinsic subprogram at (1) has been deprecated
is misleading, as support has been disabled by this patch.
Adjust the error mess
Hi,
on 2019-07-23, support for SHORT and LONG intrinsics was removed be Steve Kargl
by
adding an error message in check.c. As far as I can see code support is still
there, though.
Remove documentation for these intrinsics.
Signed-off-by Manfred Schwarb
[Note: I do not have commit access]
-
Hi,
documentation for REAL intrinsic is slightly wrong. Fix it.
Patch is done on top of the column adjustment patch.
Signed-off-by Manfred Schwarb
[Note: I do not have commit access]
--- gcc/gcc/fortran/intrinsic.texi.2 2021-10-29 15:08:38.302188947 +0200
+++ gcc/gcc/fortran/intrinsic.texi 202
Hi,
there were really a lot of test cases provided by Gerhard Steinmetz lately.
Although I'm not really in the position to suggest this,
I would appreciate it, if one could recognize him by adding an entry to
gfortran.texi.
As e.g. in the proposed patch. Such a patch should probably be signed-off
On Fri, Oct 29, 2021 at 10:10 AM Richard Biener
wrote:
>
> On Fri, Oct 29, 2021 at 10:06 AM Aldy Hernandez wrote:
> >
> > On Fri, Oct 29, 2021 at 9:30 AM Richard Biener
> > wrote:
> >
> > > Btw, in case the "fully resolving" mode is slower than not fully resolving
> > > please consider gating it
When range-of_stmt is invoked on a statement, out-of-date updating is
keyed off the timestamp on the definition.
When the def is calculated, and its global value stored, a timestamp is
created for the cache. if range_of_stmt is invoked again, the timestamp
of the uses are compared to the defi
> On 26/10/2021 03:28 Joseph Myers wrote:
>
>
> On Mon, 25 Oct 2021, Richard Biener via Gcc-patches wrote:
>
> > So it looks like tm_d.h is much more stripped down compared to regular
> > tm_p.h but also oddly enough config/default-d.c includes tm_d.h
> > while config/default-c.c explicitely d
Looks good and simple. Proceed. Thanks
Jerry
On 10/28/21 5:05 PM, Bernhard Reutner-Fischer via Fortran wrote:
ping
[Rebased, re-regtested cleanly. Ok for trunk?]
On Wed, 5 Sep 2018 14:57:31 +
Bernhard Reutner-Fischer wrote:
From: Bernhard Reutner-Fischer
compiling gfortran.dg/typeboun
Hi All,
Attached is a new version that fixes the previous SVE fallouts in a new way.
Ok for master?
Thanks,
Tamar
--- inline copy of patch ---
diff --git a/gcc/config/aarch64/aarch64-cost-tables.h
b/gcc/config/aarch64/aarch64-cost-tables.h
index
dd2e7e7cbb13d24f0b51092270cd7e2d75fabf29..bb4
Tamar Christina writes:
> Hi All,
>
> Attached is a new version that fixes the previous SVE fallouts in a new way.
>
> Ok for master?
>
> Thanks,
> Tamar
>
> --- inline copy of patch ---
>
>
> diff --git a/gcc/config/aarch64/aarch64-cost-tables.h
> b/gcc/config/aarch64/aarch64-cost-tables.h
> ind
On Tue, Oct 26, 2021 at 04:58:11PM -0400, Jason Merrill wrote:
> > I'm afraid I don't have a good idea where to move that diagnostic to though,
> > it would need to be done somewhere where we are certain we aren't in a
> > subexpression of immediate invocation. Given statement expressions, even
>
Occasionally I've been seeing failures with the multi-line diagnostics.
It's never been clear what's causing the spurious failures, though I
have long suspected a greedy regexp match.
It happened again yesterday with a local change that in no way should
affect diagnostics, so I finally went s
Since registering a kill means removing all references to it from the
path oracle list, make sure we don't look back to the root oracle
either.
Tested on x86-64 Linux.
Co-authored-by: Andrew MacLeod
gcc/ChangeLog:
* value-relation.cc (path_oracle::killing_def): Add a
self-equiv
On 29.10.21 12:53, Jakub Jelinek wrote:
On Fri, Oct 29, 2021 at 12:09:55PM +0200, Tobias Burnus wrote:
[...] only routines calls to
omp_get_num_teams() and omp_get_team_num()
are permitted in teams when closely nested.
I'm afraid using DECL_ASSEMBLER_NAME opens a new can of worms. [...]
At l
On 29.10.21 13:06, Jakub Jelinek wrote:
On Thu, Oct 28, 2021 at 05:51:59PM +0200, Tobias Burnus wrote:
libcpp/ChangeLog:
PR c++/102409
* directives.c (destringize_and_run): Add PRAGMA_OP to the
CPP_PRAGMA token's flags to mark is as coming from _Pragma.
* include/cpplib.h (P
On Fri, Oct 29, 2021 at 06:20:15PM +0200, Tobias Burnus wrote:
> On 29.10.21 13:06, Jakub Jelinek wrote:
> > On Thu, Oct 28, 2021 at 05:51:59PM +0200, Tobias Burnus wrote:
> > > libcpp/ChangeLog:
> > >
> > > PR c++/102409
> > > * directives.c (destringize_and_run): Add PRAGMA_OP to the
>
On Fri, 29 Oct 2021 07:54:21 -0700
Jerry D wrote:
> Looks good and simple. Proceed. Thanks
Committed as 7883a7f07c1ad9c8aaccc5bbd96e0ae1fa230c89
Thanks!
Maybe somebody could eyeball and ACK "Fix memory leak in finalization
wrappers"
https://gcc.gnu.org/pipermail/fortran/2021-October/056838.html
Ping.
On Mon, Oct 11, 2021 at 11:17:11AM -0400, Marek Polacek wrote:
> Ping.
>
> On Tue, Sep 28, 2021 at 04:20:46PM -0400, Marek Polacek wrote:
> > On Thu, Sep 23, 2021 at 02:25:16PM -0400, Jason Merrill wrote:
> > > On 9/20/21 18:59, Marek Polacek via Gcc-patches wrote:
> > > > +void
> > > > +ha
On Fri, Oct 29, 2021 at 05:54:57PM +0200, Tobias Burnus wrote:
> --- a/gcc/omp-low.c
> +++ b/gcc/omp-low.c
> @@ -3926,8 +3926,9 @@ omp_runtime_api_call (const_tree fndecl)
>
>static const char *omp_runtime_apis[] =
> {
> - /* This array has 3 sections. First omp_* calls that don't
Thank you.
I will commit this patch the beginning of next week.
Jakub, let me know if you have any objection on this.
Qing
> On Oct 29, 2021, at 2:21 AM, Richard Biener wrote:
>
> On Thu, 28 Oct 2021, Qing Zhao wrote:
>
>> Ping….
>>
>> Hi,
>>
>> Based on the previous discussion, I thought t
On Fri, Oct 29, 2021 at 04:55:07PM +, Qing Zhao wrote:
> I will commit this patch the beginning of next week.
> Jakub, let me know if you have any objection on this.
No objections, sorry for the delay.
Jakub
On Fri, 29 Oct 2021 13:13:52 +0200
Jakub Jelinek wrote:
> On Fri, Oct 29, 2021 at 01:52:58AM +0200, Bernhard Reutner-Fischer wrote:
> > From: Bernhard Reutner-Fischer
> >
> > Introduce a helper to construct a user operator from a name and the
> > reverse operation, i.e. a helper to construct a
On Linux/x86_64,
4045d5fa42f2ee7b284977c8f2f0edc300a63e43 is the first bad commit
commit 4045d5fa42f2ee7b284977c8f2f0edc300a63e43
Author: Tamar Christina
Date: Fri Oct 29 12:47:39 2021 +0100
middle-end: Add target independent tests for Arm complex numbers
vectorization.
caused
FAIL: gcc
On Thu, 28 Oct 2021 23:03:05 +0200
Harald Anlauf via Fortran wrote:
> Dear Fortranners,
>
> the original fix by Steve was lingering in the PR.
>
> We did ICE in situations where in a SELECT CASE a kind conversion
> was deemed necessary, but it did involve different types.
> The check gfc_conver
ping
On Wed, 5 Sep 2018 14:57:04 +
Bernhard Reutner-Fischer wrote:
> From: Bernhard Reutner-Fischer
>
> Aids debugging the fortran FE.
>
> gcc/ChangeLog:
>
> 2017-11-12 Bernhard Reutner-Fischer
>
> * gdbinit.in: Break on gfc_internal_error.
> ---
> gcc/gdbinit.in | 1 +
> 1 f
Dear Bernhard, all,
Am 29.10.21 um 02:05 schrieb Bernhard Reutner-Fischer via Gcc-patches:
diff --git a/gcc/fortran/symbol.c b/gcc/fortran/symbol.c
index 53c760a6c38..cde34c67482 100644
--- a/gcc/fortran/symbol.c
+++ b/gcc/fortran/symbol.c
@@ -5052,7 +5052,7 @@ gfc_get_typebound_proc (gfc_ty
Hi Manfred,
Am 29.10.21 um 16:05 schrieb Manfred Schwarb via Fortran:
Hi,
in intrinsic.texi, a lot of tables wrap lines when watching the
resulting info file in a 80char terminal.
Adjust the @columnfractions items to fit screen. Some minor white space
changes are added as well to help saving s
Hi Manfred,
Am 29.10.21 um 16:12 schrieb Manfred Schwarb via Fortran:
Hi,
on 2019-07-23, support for SHORT and LONG intrinsics were removed be Steve
Kargl by
adding an error message in check.c. However, the error message
Error: 'long' intrinsic subprogram at (1) has been deprecated
is misl
Hi Manfred,
Am 29.10.21 um 16:13 schrieb Manfred Schwarb via Gcc-patches:
Hi,
on 2019-07-23, support for SHORT and LONG intrinsics was removed be Steve Kargl
by
adding an error message in check.c. As far as I can see code support is still
there, though.
Remove documentation for these intrin
Hi Manfred,
Am 29.10.21 um 16:33 schrieb Manfred Schwarb via Fortran:
Hi,
there were really a lot of test cases provided by Gerhard Steinmetz lately.
Although I'm not really in the position to suggest this,
I would appreciate it, if one could recognize him by adding an entry to
gfortran.texi.
On Fri, Oct 15, 2021, 12:39 Aldy Hernandez wrote:
>
>
> On 10/15/21 2:47 AM, Andrew MacLeod wrote:
> > On 10/14/21 6:07 PM, Martin Sebor via Gcc-patches wrote:
> >> On 10/9/21 12:47 PM, Aldy Hernandez via Gcc-patches wrote:
> >>> We seem to be passing a lot of context around in the strlen code.
On Fri, 29 Oct 2021 21:36:26 +0200
Harald Anlauf via Gcc-patches wrote:
> Dear Bernhard, all,
>
> Am 29.10.21 um 02:05 schrieb Bernhard Reutner-Fischer via Gcc-patches:
>
> >> diff --git a/gcc/fortran/symbol.c b/gcc/fortran/symbol.c
> >> index 53c760a6c38..cde34c67482 100644
> >> --- a/gcc/fort
Hi Manfred,
Am 29.10.21 um 16:18 schrieb Manfred Schwarb via Gcc-patches:
Hi,
documentation for REAL intrinsic is slightly wrong. Fix it.
Patch is done on top of the column adjustment patch.
the patch looks fine, but it would help a lot to have a ChangeLog entry.
Thanks,
Harald
Signed-off-
Tested x86_64-linux, committed to trunk.
libstdc++-v3/ChangeLog:
* testsuite/23_containers/stack/deduction.cc: Fix typo.
---
libstdc++-v3/testsuite/23_containers/stack/deduction.cc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libstdc++-v3/testsuite/23_containers/st
On Thu, 2021-10-28 at 17:24 +0200, Aldy Hernandez via Gcc-patches
wrote:
[...snip...]
> gcc/ChangeLog:
>
> * passes.def: Replace the pass_thread_jumps before VRP* with
> pass_thread_jumps_full. Remove all pass_vrp_threader
> instances.
Given that you're deleting all pass_vrp_th
Hi All,
The sharing of the COMPLEX_MUL node makes it so it's
more efficient to not generate both a MUL and FMA
in this node.
Because the shape for a normal FMA is not different
the FMA is no longer detected here which results in
better codegen so update the testcase.
Regtested on aarch64-none-li
On Fri, 29 Oct 2021 19:15:13 +0200
Bernhard Reutner-Fischer wrote:
> > But most importantly, I really don't like these helpers at all, they
> > unnecessarily allocate memory of the remaining duration of compilation,
> > and the second one even uses heap for temporary.
> I can easily switch the
On Thu, Oct 28, 2021 at 2:38 PM Jeff Law via Gcc-patches
wrote:
>
>
>
> On 10/9/2021 7:32 AM, Iain Buclaw via Gcc-patches wrote:
> > Hi,
> >
> > The implementation of the D front-end in GCC is based on the original
> > C++ version of the D programming language compiler, which was ported to
> > D i
On Wed, Oct 27, 2021 at 10:17:39PM -0500, Peter Bergner wrote:
> Sorry for reposting, but I forgot to CC the gcc-patches mailing list. :-(
Whoops, and I replied to your original message :-/
> 2021-10-27 Martin Liska
>
> gcc/
> PR target/101324
> * config/rs6000/rs6000.c (rs6000_op
On Mon, Oct 11, 2021 at 11:19 AM Marek Polacek via Gcc-patches
wrote:
>
> Any thoughts?
I think it's a good idea, but then again I can't approve it, so...
well, who can, then?
>
> On Thu, Sep 23, 2021 at 12:16:36PM -0400, Marek Polacek via Gcc-patches wrote:
> > Clang implements something we don
On Thu, Oct 21, 2021 at 12:49 PM H.J. Lu via Gcc-patches
wrote:
>
> PR target/98667
> * doc/invoke.texi: Document -fcf-protection requires i686 or
> new.
> ---
> gcc/doc/invoke.texi | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/gcc/doc/invoke.t
Looks OK.
Cheers
On 10/29/21 11:58 AM, Bernhard Reutner-Fischer via Fortran wrote:
ping
On Wed, 5 Sep 2018 14:57:04 +
Bernhard Reutner-Fischer wrote:
From: Bernhard Reutner-Fischer
Aids debugging the fortran FE.
gcc/ChangeLog:
2017-11-12 Bernhard Reutner-Fischer
* gdbin
Am 29.10.21 um 21:44 schrieb Harald Anlauf via Fortran:
> Hi Manfred,
>
> Am 29.10.21 um 16:05 schrieb Manfred Schwarb via Fortran:
>> Hi,
>>
>> in intrinsic.texi, a lot of tables wrap lines when watching the
>> resulting info file in a 80char terminal.
>>
>> Adjust the @columnfractions items to fi
Am 29.10.21 um 21:51 schrieb Harald Anlauf via Fortran:
> Hi Manfred,
>
> Am 29.10.21 um 16:12 schrieb Manfred Schwarb via Fortran:
>> Hi,
>>
>> on 2019-07-23, support for SHORT and LONG intrinsics were removed be Steve
>> Kargl by
>> adding an error message in check.c. However, the error message
Am 29.10.21 um 21:52 schrieb Harald Anlauf via Fortran:
> Hi Manfred,
>
> Am 29.10.21 um 16:13 schrieb Manfred Schwarb via Gcc-patches:
>> Hi,
>>
>> on 2019-07-23, support for SHORT and LONG intrinsics was removed be Steve
>> Kargl by
>> adding an error message in check.c. As far as I can see cod
Am 29.10.21 um 21:56 schrieb Harald Anlauf via Fortran:
> Hi Manfred,
>
> Am 29.10.21 um 16:18 schrieb Manfred Schwarb via Gcc-patches:
>> Hi,
>>
>> documentation for REAL intrinsic is slightly wrong. Fix it.
>> Patch is done on top of the column adjustment patch.
>
> the patch looks fine, but it w
Am 29.10.21 um 21:58 schrieb Harald Anlauf via Fortran:
> Hi Manfred,
>
> Am 29.10.21 um 16:33 schrieb Manfred Schwarb via Fortran:
>> Hi,
>> there were really a lot of test cases provided by Gerhard Steinmetz lately.
>> Although I'm not really in the position to suggest this,
>> I would appreciate
Hi Martin,
On 28.10.21 18:28, Martin Sebor wrote:
There are a number of bug reports of _Pragma not working right
in macros, including (and especially) to control diagnostics:
https://gcc.gnu.org/bugzilla/buglist.cgi?quicksearch=_Pragma%20macro&list_id=328003
Just by the description this change
Yes as well as anything ASSERT related in the forward threader. That'll be
a follow-up patch.
Aldy
On Fri, Oct 29, 2021, 22:58 David Malcolm wrote:
> On Thu, 2021-10-28 at 17:24 +0200, Aldy Hernandez via Gcc-patches
> wrote:
>
> [...snip...]
>
> > gcc/ChangeLog:
> >
> > * passes.def: R
79 matches
Mail list logo
