The *_HAS_* floating-point feature macros are defined as 0/1 rather than
#undef/#define settings by gcc/c-family/c-cppbuiltin.c. Consequently we
choose to use infinity and NaN features even with non-IEEE-754 targets
such as `vax-netbsdelf' that lack them, causing build warnings and
failures li
While we have `configure' checks for the individual POSIX 2008 extended
locale functions we refer to and use to guard the respective call sites,
we only verify the presence of `newlocale' for our global feature enable
check. Consequently compilation fails for targets like NetBSD that only
have
LGTM.
Does this solve all infinity issues? Or is there still code requiring it
implicitly? From the previous exchange, it sounded as if there are still
issues.
Tobias
On 25.11.20 19:14, Maciej W. Rozycki wrote:
The *_HAS_* floating-point feature macros are defined as 0/1 rather than
#undef/#de
Patch looks good to me.
Thanks,
Tobias
PS: Are there still remaining issues to be solved? Or does libgfortran
now build?
On 25.11.20 19:14, Maciej W. Rozycki wrote:
While we have `configure' checks for the individual POSIX 2008 extended
locale functions we refer to and use to guard the respec
On 11/25/20 2:31 AM, Richard Biener wrote:
On Wed, Nov 25, 2020 at 1:45 AM Martin Sebor via Gcc-patches
wrote:
Offsets in pointer expressions are signed but GCC prefers to
represent them as sizetype instead, and sometimes (though not
always) crashes during GIMPLE verification when they're not.
On Tue, 24 Nov 2020, Maciej W. Rozycki wrote:
> I am going to give up at this point, as porting libgfortran to non-IEEE FP
> is surely well beyond what I can afford to do right now.
I have now posted fixes for the issues handled so far.
For the other pieces that are missing perhaps my work I
On Fri, 20 Nov 2020, Maciej W. Rozycki wrote:
> These changes have been regression-tested throughout development with the
> `vax-netbsdelf' target running NetBSD 9.0, using said VAXstation 4000/60,
> which uses the Mariah implemementation of the VAX architecture. The host
> used was `powerpc6
On 25/11/20 10:35 +, Jonathan Wakely wrote:
I've pushed that as ad9cbcee543ecccd79fa49dafcd925532d2ce210 but there
are still other FAILs to be fixed.
I think the other FAILs are due to a race condition in the tests,
fixed by this patch. Tested x86_64-linux, powerpc64le-linux,
sparc-solaris2
This introduces a new internal utility, std::__condvar, which is a
simplified form of std::condition_variable. It has no dependency on
or std::unique_lock, which allows it to be used in
.
This avoids repeating the #ifdef __GTHREAD_COND_INIT preprocessor
conditions and associated logic for initial
For the case where a timeout is specified using the system_clock we
perform a conversion to the preferred clock (which is either
steady_clock or system_clock itself), wait using __cond_wait_until_impl,
and then check the time by that clock again to see if it was reached.
This is entirely redundant,
On Wed, Nov 25, 2020 at 12:26:17PM -0500, Jason Merrill wrote:
> > + if (DECL_BIT_FIELD (fld)
> > + && DECL_NAME (fld) == NULL_TREE)
> > + continue;
>
> I think you want to check DECL_PADDING_P here; the C and C++ front ends set
> it on unnamed
On 11/24/20 8:40 AM, Stefan Kanthak wrote:
> Andreas Schwab wrote:
>
>> On Nov 24 2020, Stefan Kanthak wrote:
>>
>>> 'nuff said
>> What's your point?
> Pinpoint deficiencies and bugs in GCC and libgcc, plus a counter
> example to your "argument"!
> I recommend careful reading.
Umm, you should br
On Wed, 25 Nov 2020, Tobias Burnus wrote:
> Does this solve all infinity issues? Or is there still code requiring it
> implicitly? From the previous exchange, it sounded as if there are still
> issues.
Infinity is the least of a problem, because as it turns out we have
numerous FP library funct
Am Montag, den 23.11.2020, 20:21 + schrieb Joseph Myers:
> On Mon, 23 Nov 2020, Uecker, Martin wrote:
>
> > Joseph,
> >
> > here is the patch to not drop qualifiers for _Atomic in
> > typeof. I am not sure whether this is appropriate in
> > stage3, but I wanted to leave it here for you to com
Hi!
I've pushed "Fix templatized C++ OpenACC 'cache' directive ICEs" to
master branch in commit 0cab70604cfda30bc64351b39493ef884ff7ba10, and
backported to releases/gcc-10 branch in commit
5bfcc9e103c06d85de43766fe05eb59f4f50c3db, to releases/gcc-9 branch in
commit 1cb1c9e62f92ad674976b0da8cc46d73
Hi Maciej,
Infinity is the least of a problem, because as it turns out we have
numerous FP library functions in libgfortran that require explicit porting
to each FP format supported, like these settings:
xbig = 26.543, xhuge = 6.71e+7, xmax = 2.53e+307;
The Fortran intrinsis l
On 11/11/20 1:03 AM, Hongtao Liu via Gcc-patches wrote:
>
>
>
> vec_set_rebaserebase_onr11-4901.patch
>
> From c9d684c37b5f79f68f938f39eeb9e7989b10302d Mon Sep 17 00:00:00 2001
> From: liuhongt
> Date: Mon, 19 Oct 2020 16:04:39 +0800
> Subject: [PATCH] Support variable index vec_set.
>
> gcc/C
On 11/3/20 2:15 PM, Nathan Sidwell wrote:
> This is the user documentation.
>
>
> 12-core-doc.diff
>
I think this is fine.
jeff
On Tue, 24 Nov 2020, Thomas Koenig wrote:
> > I am going to give up at this point, as porting libgfortran to non-IEEE FP
> > is surely well beyond what I can afford to do right now.
>
> Can you file a PR about this? Eliminating __builtin_inf and friends
> sounds doable.
There's more to that unf
On 11/18/20 2:20 PM, Martin Sebor wrote:
> On 11/18/20 1:41 PM, David Malcolm wrote:
>
>> So hopefully that gives us a way forward. I'm about to disappear for a
>> week and a half, so don't let my analyzer patches stand in the way of
>> Martin's. I can finish reworking my stuff on top of Marti
Hi!
On 2020-11-25T11:52:44+0100, Jakub Jelinek wrote:
> On Wed, Nov 25, 2020 at 11:43:48AM +0100, Thomas Schwinge wrote:
>> On 2020-11-25T11:10:18+0100, Jakub Jelinek wrote:
>> > On Wed, Nov 25, 2020 at 11:00:57AM +0100, Thomas Schwinge wrote:
>> >> I had reason to look into OpenMP C++ 'map' cla
On 11/3/20 2:15 PM, Nathan Sidwell wrote:
> Here are the new options, along with the C++ lang-spec changes.
>
> Modules is enabled by -fmodules-ts, it is not implicitly enabled by
> -std=c++20. Usually that's the only option you need to add for a
> module-aware build.
>
> to build a header unit
Hi,
this constructing testcase for the direct escape analysis I noticed that
I forgot to duplicate arg_flags in duplicate hook so we lose track of
that when clonning. I am sure I had it there at some point, but
apparently it got lost while breaking up patches.
Bootstrapped/regtested x86_64-linux,
On 11/19/20 8:59 AM, Qing Zhao via Gcc-patches wrote:
> Hi,
>
> PR9 - ICE: in df_refs_verify, at df-scan.c:3991 with -O
> -ffinite-math-only -fzero-call-used-regs=all
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=9
>
> Is a bug triggered by the new pass zero-call-used-regs, however,
On 11/23/20 2:09 AM, Kewen.Lin via Gcc-patches wrote:
> Hi,
>
> I adjusted some vectorization test cases for vect_partial_vectors_usage_1
> before, but as exposed in the recent testings, some of them need to be
> adjusted again. The reason is that the commit r11-3393 improved the
> epilogue loo
On 11/13/20 1:10 AM, Richard Sandiford via Gcc-patches wrote:
> Just after GCC 10 stage 1 closed (oops), I posted a patch to add a new
> combine pass. One of its main aims was to allow instructions to move
> around where necessary in order to make a combination possible.
> It also tried to para
On 11/13/20 1:11 AM, Richard Sandiford via Gcc-patches wrote:
> I noticed during compatibility testing that clang warns that this
> operator won't be implicitly const in C++14 onwards.
>
> gcc/
> * vec.h (vnull::operator vec): Make const.
OK
jeff
On 11/13/20 1:12 AM, Richard Sandiford via Gcc-patches wrote:
> A later patch wants to use the set of global registers as a HARD_REG_SET
> rather than a bool/char array. Most other arrays already have a
> HARD_REG_SET counterpart, but this one didn't.
>
> gcc/
> * hard-reg-set.h (global_r
On 11/13/20 1:12 AM, Richard Sandiford via Gcc-patches wrote:
> noop_move_p currently keeps any instruction that has a REG_EQUAL
> note, on the basis that the equality might be useful in future.
> But this creates a perverse incentive not to add potentially-useful
> REG_EQUAL notes, in case they
On 11/13/20 1:13 AM, Richard Sandiford via Gcc-patches wrote:
> A later patch will add more iterator-related utilities. Rather than
> putting them all directly in coretypes.h, it seemed better to add a
> new header file, here called "iterator-utils.h". This preliminary
> patch moves the existi
On 11/13/20 1:13 AM, Richard Sandiford via Gcc-patches wrote:
> This patch adds some more iterator helper classes. They really fall
> into two groups, but there didn't seem much value in separating them:
>
> - A later patch has a class hierarchy of the form:
>
> Base
> +- Derived1
>
On 11/13/20 1:14 AM, Richard Sandiford via Gcc-patches wrote:
> This patch adds an RAII class for managing the lifetimes of objects
> on an obstack. See the comments in the patch for more details and
> example usage.
>
> gcc/
> * obstack-utils.h: New file.
RAII is goodness. One could arg
On 11/13/20 1:14 AM, Richard Sandiford via Gcc-patches wrote:
> This patch adds a pointer_mux class that provides similar
> functionality to:
>
> union { T1 *a; T2 *b; };
> ...
> bool is_b_rather_than_a;
>
> except that the is_b_rather_than_a tag is stored in the low bit
> of the poi
On 11/13/20 1:17 AM, Richard Sandiford via Gcc-patches wrote:
> Later patches want to use print_insn_with_notes (printing to
> a pretty_printer). This patch exports it from print-rtl.c.
>
> The non-notes version is already public.
>
> gcc/
> * print-rtl.h (print_insn_with_notes): Declare.
On 11/13/20 1:18 AM, Richard Sandiford via Gcc-patches wrote:
> verify_changes has a test for whether a particular hard register
> is a user-defined register asm. A later patch needs to test the
> same thing, so this patch splits it out into a helper.
>
> gcc/
> * rtl.h (register_asm_p):
Jeff Law wrote:
> On 11/24/20 8:40 AM, Stefan Kanthak wrote:
>> Andreas Schwab wrote:
>>
>>> On Nov 24 2020, Stefan Kanthak wrote:
>>>
'nuff said
>>> What's your point?
>> Pinpoint deficiencies and bugs in GCC and libgcc, plus a counter
>> example to your "argument"!
>> I recommend careful r
On 11/13/20 1:19 AM, Richard Sandiford via Gcc-patches wrote:
> In some cases, it can be convenient to roll back the changes that
> have been made by validate_change to see how things looked before,
> then reroll the changes. For example, this makes it possible
> to defer calculating the cost o
On 11/13/20 1:20 AM, Richard Sandiford via Gcc-patches wrote:
> When using validate_change to make a group of changes, you have
> to remember to cancel them if something goes wrong. This patch
> adds an RAII class to make that easier. See the comments in the
> patch for details and examples.
>
On 11/13/20 1:21 AM, Richard Sandiford via Gcc-patches wrote:
> This patch adds a routine for finding a “simple” SET for a register
> definition. See the comment in the patch for details.
>
> gcc/
> * rtl.h (simple_regno_set): Declare.
> * rtlanal.c (simple_regno_set): New function.
On Wed, Nov 25, 2020 at 09:22:53PM +0100, Stefan Kanthak wrote:
> > As Jakub has already indicated, your change will result in infinite
> > recursion on avr.Ã I happened to have a cr16 handy and it looks like
> > it'd generate infinite recursion there too.
>
> JFTR: does GCC emit a warning then?
On 11/25/20 1:22 PM, Stefan Kanthak wrote:
> Jeff Law wrote:
>
>> On 11/24/20 8:40 AM, Stefan Kanthak wrote:
>>> Andreas Schwab wrote:
>>>
On Nov 24 2020, Stefan Kanthak wrote:
> 'nuff said
What's your point?
>>> Pinpoint deficiencies and bugs in GCC and libgcc, plus a counte
Jakub Jelinek wrote:
> On Wed, Nov 25, 2020 at 09:22:53PM +0100, Stefan Kanthak wrote:
>> > As Jakub has already indicated, your change will result in infinite
>> > recursion on avr.Ã, I happened to have a cr16 handy and it looks like
>> > it'd generate infinite recursion there too.
>>
>> JFTR: d
Hi!
On 2020-11-25T15:44:56+, Richard Biener wrote:
> On Wed, 25 Nov 2020, Jakub Jelinek wrote:
>
>> On Wed, Nov 25, 2020 at 04:30:44PM +0100, Richard Biener wrote:
>> > This fixes the search when configured with --libexecdir=lib64,
(I can't comment on that one specifically, not using this op
On Wed, 25 Nov 2020, Thomas Koenig wrote:
> >xbig = 26.543, xhuge = 6.71e+7, xmax = 2.53e+307;
>
> The Fortran intrinsis like HUGE, EPSILON, SELECTED_REAL_KIND etc
> would have to be handled correctly, both for simplification in
> the front end and in the library.
>
> Does the program
>
Make the following simplifications:
X <= MAX(X, Y) -> true
X > MAX(X, Y) -> false
X >= MIN(X, Y) -> true
X < MIN(X, Y) -> false
This fixes PR96708.
Tested on x86_64-pc-linux-gnu.
bool f(int a, int b)
{
int tmp = (a < b) ? b : a;
return tmp >= a;
}
Code without th
On Tue, 24 Nov 2020, Eric Botcazou wrote:
> > I'm intested in any notes, however vague, on that matter. I was
> > a bit surprised to see that myself...that is, after fixing
> > *some* related regressions, like the one in combine. (Did I
> > actually miss something?)
>
> My recollection for the V
On 11/25/20 2:22 PM, Stefan Kanthak wrote:
> Jakub Jelinek wrote:
>
>> On Wed, Nov 25, 2020 at 09:22:53PM +0100, Stefan Kanthak wrote:
As Jakub has already indicated, your change will result in infinite
recursion on avr.Ã, I happened to have a cr16 handy and it looks like
it'd ge
On Wed, 25 Nov 2020, Maciej W. Rozycki wrote:
> For the other pieces that are missing perhaps my work I did many years
> ago to port glibc 2.4 (the last one I was able to cook up without NPTL),
> and specifically libm within, to the never-upstreamed VAX/Linux target
> might be useful to comple
On Tue, Nov 24, 2020 at 05:27:10AM +, Maciej W. Rozycki wrote:
> On Tue, 24 Nov 2020, Maciej W. Rozycki wrote:
>
> > > I don't know how or why __FLT_HAS_INFINITY is set for a target which
> > > does not support it, but if you get rid of that macro, that particular
> > > problem should be solve
On Wed, 25 Nov 2020, Uecker, Martin wrote:
> So OK to apply with the following Changelog?
OK fixed as noted.
> 2020-11-25 Martin Uecker
>
> gcc/c/
Should mention the PR number in the ChangeLog entry (the part that will
end up automatically added to the ChangeLog file), not just the
On 25.11.20 23:02, Maciej W. Rozycki wrote:
Well, it does not link, for the somewhat unsurprising reason of a missing
libgfortran runtime. I have modified the program with whatever little
Fortran skills I gained a while ago to get something that can be parseable
for a human being in the assembl
Jeff Law wrote:
[...]
> By understanding how your proposed changes affect other processors, you
> can write better changes that are more likely to get included.
> Furthermore you can focus efforts on things that matter more in the real
> world. DImode shifts in libgcc are _not_ useful to try an
On 11/13/20 1:14 AM, Richard Sandiford via Gcc-patches wrote:
This patch adds a pointer_mux class that provides similar
functionality to:
union { T1 *a; T2 *b; };
...
bool is_b_rather_than_a;
except that the is_b_rather_than_a tag is stored in the low bit
of the pointer. See the
On 11/24/20 9:54 AM, Qing Zhao via Gcc-patches wrote:
On Nov 24, 2020, at 9:55 AM, Richard Biener wrote:
On Tue, Nov 24, 2020 at 4:47 PM Qing Zhao wrote:
On Nov 24, 2020, at 1:32 AM, Richard Biener wrote:
On Tue, Nov 24, 2020 at 12:05 AM Qing Zhao via Gcc-patches
wrote:
Hi,
Does
On Linux/x86_64,
bb07490abba850fd5b1d2d09d76d18b8bdc7d817 is the first bad commit
commit bb07490abba850fd5b1d2d09d76d18b8bdc7d817
Author: Jan Hubicka
Date: Wed Nov 25 20:51:26 2020 +0100
Add EAF_NODIRECTESCAPE flag
caused
FAIL: gcc.target/i386/avx512vl-vandnpd-2.c execution test
FAIL: gc
On 11/25/20 1:50 PM, Jakub Jelinek wrote:
On Wed, Nov 25, 2020 at 12:26:17PM -0500, Jason Merrill wrote:
+ if (DECL_BIT_FIELD (fld)
+ && DECL_NAME (fld) == NULL_TREE)
+ continue;
I think you want to check DECL_PADDING_P here; th
The following patch fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97983
The patch was successfully bootstrapped on x86_64 and s390x (with
--enable-languages=c,c++ --enable-checking=release --disable-multilib
--with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions
--enable
Thanks for the review.
BTW, the patch is already installed because uros helped to review this
patch in another thread
https://gcc.gnu.org/pipermail/gcc-patches/2020-November/558682.html
On Thu, Nov 26, 2020 at 3:15 AM Jeff Law wrote:
>
>
>
> On 11/11/20 1:03 AM, Hongtao Liu via Gcc-patches wrote:
On Tue, Nov 24, 2020 at 08:34:51PM -0600, Pat Haugen wrote:
> On 11/24/20 8:17 PM, Pat Haugen via Gcc-patches wrote:
> > On 11/24/20 12:59 PM, Carl Love via Gcc-patches wrote:
> >> +(define_insn "modu_"
> >> + [(set (match_operand:VIlong 0 "vsx_register_operand" "=v")
> >> + (umod:VIlong (match_o
On Wed, Nov 25, 2020 at 7:37 PM Jakub Jelinek wrote:
>
> On Wed, Nov 25, 2020 at 07:32:44PM +0800, Hongtao Liu wrote:
> > Update patch:
> > 1. ix86_expand_special_args_builtin is used for expanding mask load
> > intrinsics, this function will always convert the constant mask
> > operands into re
Hi:
This patch is about to delete dead code in ix86_expand_special_args_builtin.
Bootstrap and regression test are ok.
gcc/ChangeLog:
* config/i386/i386-expand.c
(ix86_expand_special_args_builtin): Delete last_arg_constant.
From 948756dae8f67bf766714d9ecc064b4eea9952cd Mon Sep
Am 25.11.20 um 23:02 schrieb Maciej W. Rozycki:
The Fortran intrinsis like HUGE, EPSILON, SELECTED_REAL_KIND etc
would have to be handled correctly, both for simplification in
the front end and in the library.
Does the program
print *,HUGE(1.0)
print *,EPSILON(1.0)
end
print correct valu
On Wed, Nov 25, 2020 at 7:22 PM Martin Sebor wrote:
>
> On 11/25/20 2:31 AM, Richard Biener wrote:
> > On Wed, Nov 25, 2020 at 1:45 AM Martin Sebor via Gcc-patches
> > wrote:
> >>
> >> Offsets in pointer expressions are signed but GCC prefers to
> >> represent them as sizetype instead, and someti
On Thu, Nov 26, 2020 at 12:50:17PM +0800, Hongtao Liu wrote:
> Hi:
> This patch is about to delete dead code in ix86_expand_special_args_builtin.
>
> Bootstrap and regression test are ok.
>
> gcc/ChangeLog:
> * config/i386/i386-expand.c
> (ix86_expand_special_args_builtin): De
101 - 164 of 164 matches
Mail list logo
