On Tue, 14 Sep 2021, Xionghu Luo wrote:
>
>
> On 2021/9/13 16:17, Richard Biener wrote:
> >
[...]
> > I don't understand - BB6 is the header block of loop 2 which is
> > always entered and thus BB6 is always executed at least once.
> >
> > The important part is that BB4 which follows the inner
On 14.09.21 05:39, Sandra Loosemore wrote:
Here's a patch. Gerald, can you check that this fixes your bootstrap
problem on i586-unknown-freebsd11?
LGTM – thanks!
Tobias
Fortran: Prefer GCC internal macros to float.h in ISO_Fortran_binding.h.
2021-09-13 Sandra Loosemore
libgfor
Respecting Jakub's suggestion that it may be better to warn-on-valid for
"if (x << 0)" as the author might have intended "if (x < 0)" [which will
also warn when x is _Bool], the simplest way to resolve this regression
is to disable the recently added fold transformation for shifts by zero;
these w
Recent compilers enforce more strictly the RM C.6(18) clause, which says that
volatile record types are by-reference types. This changes the typical error
message now given in these cases.
Tested on x86-64/Linux, applied on the mainline, 11 and 10 branches.
2021-09-14 Eric Botcazou
On 10/09/2021 15:16, Jason Merrill via Gcc-patches wrote:
OK, time to finish this up. The main change relative to the last patch I sent
to the list is dropping the -finterference-tune flag and making that behavior
the default. Any more comments?
The last missing piece of the C++17 stan
On Mon, Sep 13, 2021 at 03:08:01PM -0700, sunil.k.pandey via Gcc-patches wrote:
> FAIL: 29_atomics/atomic_flag/test_and_set/explicit-hle.cc (test for excess
> errors)
Apparently all C++ compilations with
-m32 -march={i386,i486,i586,pentium,pentiumpro,lakemont,pentium4}
FAIL with:
: warning: ‘--pa
On Tue, Sep 14, 2021 at 7:14 AM David Malcolm wrote:
>
> On Tue, 2021-09-14 at 03:35 +0900, Michel Morin via Gcc-patches wrote:
> > Hi,
> >
> > PR77565 reports that, with the code `typdef int Int;`, GCC emits
> > "did you mean 'typeof'?" instead of "did you mean 'typedef'?".
> >
> > This happens b
For the sake of consistency with -Wall & -w, this makes -Werror imply -gnatwe.
Tested on x86-64/Linux, applied on the mainline.
2021-09-14 Eric Botcazou
PR ada/101385
* doc/gnat_ugn/building_executable_programs_with_gnat.rst
(-Wall): Minor fixes.
(-w): Likewis
Un-break the build for AArch64 Darwin, see PR bootstrap/102242. Build
fails with log below:
```
In file included from
../../../gcc-master-wip-apple-si/gcc/analyzer/engine.cc:69:
In file included from
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/
Hi!
This patch adds testing checks (goa_stabilize_expr with NULL pre_p) for more
tree codes, so that we don't gimplify their operands individually unless lhs
appears in them. Also, so that we don't have exponential compile time
complexity
with the added checks, I've added a depth computation, we
Hi!
As discussed, the test tests atomics on doubles which are 64-bit and so we
should use sync_long_long effective target instead of sync_int_long that
covers 64-bit atomics only on 64-bit arches. I've added -march=pentium
to follow what is documented for sync_long_long, I guess -march=zarch shou
Hi!
is_xible_helper returns error_mark_node (i.e. false from the traits)
for abstract classes by testing ABSTRACT_CLASS_TYPE_P (to) early.
Unfortunately, as the testcase shows, that doesn't work on class templates
that haven't been instantiated yet, ABSTRACT_CLASS_TYPE_P for them is false
until it
On Sep 14 2021, Jakub Jelinek via Gcc-patches wrote:
> On Mon, Sep 13, 2021 at 03:08:01PM -0700, sunil.k.pandey via Gcc-patches
> wrote:
>> FAIL: 29_atomics/atomic_flag/test_and_set/explicit-hle.cc (test for excess
>> errors)
>
> Apparently all C++ compilations with
> -m32 -march={i386,i486,i586
This is necessary for vector builtins, which are picky about the signedness of
the element type.
Tested on x86-64/Linux, applied on the mainline.
2021-09-14 Eric Botcazou
* libgnat/s-atopri.ads (bool): Delete.
(Atomic_Test_And_Set): Replace bool with Boolean.
(Atomic
Hi!
The C FE updates DECL_*SIZE for vars which have initializers for flexible
array members for many years, but C++ FE kept DECL_*SIZE the same as the
type size (i.e. as if there were zero elements in the flexible array
member). This results e.g. in ELF symbol sizes being too small.
The followin
They should not be 0-based, unless the array type itself is.
Tested on x86-64/Linux, applied on the mainline, 11 and 10 branches.
2021-09-14 Eric Botcazou
* gcc-interface/decl.c (gnat_to_gnu_entity): For vector types, make
the representative array the debug type.
--
Eric Bo
The ZOL pattern is missing modes which may lead to errors during
var_tracking. Add them.
gcc/
-xx-xx Claudiu Zissulescu
* config/arc/arc.md (doloop_end): Add missing mode.
(loop_end): Likewise.
Signed-off-by: Claudiu Zissulescu
---
gcc/config/arc/arc.md | 8
1 f
This is a regression present on the mainline and 11 branch in the form of an
ICE for an enumeration type with a full signed representation for its size.
Tested on x86-64/Linux, applied on the mainline and 11 branch.
2021-09-14 Eric Botcazou
PR ada/101970
* exp_attr.adb (Expa
Pushed as obvious.
Martin
gcc/testsuite/ChangeLog:
* g++.dg/gcov/gcov.py: Fix failing pytests as gcov.json.gz
filename was changed in b777f228b481ae881a7fbb09de367a053740932c.
---
gcc/testsuite/g++.dg/gcov/gcov.py | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
dif
Richard Biener via Gcc-patches writes:
> This changes us to maintain and compute (mis-)alignment info for
> the first element of a group only rather than for each DR when
> doing interleaving and for the earliest, first, or first in the SLP
> node (or any pair or all three of those) when SLP vecto
Committed as obvious as r12-3524.
I have also re-checked openmp.c omp_code_to_statement (seems to be
complete, 'omp declare...' + 'omp requires' missing but it is
probably fine that those are absent).
And I checked gfc_ascii_statement – missing are some internally
used ones (like ST_SIMPLE_IF),
Ping
On 26/08/2021 11:53, Raphael Moreira Zinsly wrote:
Without dwarf2 unwind tables available _Unwind_Backtrace() is not
able to return the full backtrace.
This patch adds a fallback function on powerpc to get the backtrace
by doing a backchain, this code was originally at glibc.
libgcc/Change
Hello,
On Mon, 13 Sep 2021, Aldy Hernandez via Gcc-patches wrote:
The testcase still tests what it's supposed to test with ...
> > typedef unsigned short uint16_t;
> >
> > uint16_t a, b;
> >
> > int *j_global;
> > uint16_t f(void)
> > {
> >int c, **p;
> >short d = 2, e = 4;
> >
... "c =
On 9/14/21 5:02 AM, Jakub Jelinek wrote:
Hi!
The C FE updates DECL_*SIZE for vars which have initializers for flexible
array members for many years, but C++ FE kept DECL_*SIZE the same as the
type size (i.e. as if there were zero elements in the flexible array
member). This results e.g. in ELF
On Mon, 13 Sep 2021, Tobias Burnus wrote:
> Can you run 'echo | cpp -E -g3|grep DBL' to (or in the build dir: echo |
> ./gcc/cc1 -E -g3 -dD|grep DBL) to check what's the output?
Thank you, Tobias, and I'm just testing the proposed patch, but still
wanted to follow up on your question:
% echo |
On 9/14/21 4:48 AM, Jakub Jelinek wrote:
is_xible_helper returns error_mark_node (i.e. false from the traits)
for abstract classes by testing ABSTRACT_CLASS_TYPE_P (to) early.
Unfortunately, as the testcase shows, that doesn't work on class templates
that haven't been instantiated yet, ABSTRACT_C
On 9/14/21 4:13 PM, Michael Matz wrote:
Hello,
On Mon, 13 Sep 2021, Aldy Hernandez via Gcc-patches wrote:
The testcase still tests what it's supposed to test with ...
typedef unsigned short uint16_t;
uint16_t a, b;
int *j_global;
uint16_t f(void)
{
int c, **p;
short d = 2, e = 4;
On 9/13/21 3:54 PM, Patrick Palka wrote:
Here, the union's constructor is defined to activate its empty data
member _M_rest, but during constexpr evaluation of this constructor the
subobject constructor call to O::O(&_M_rest, 42) produces no side
effects that actually activates the member, so the
Hi Gerald,
I note:
On 13.09.21 17:56, Gerald Pfeifer wrote:
% egrep -r '#define.*LDBL_(MANT_DIG|MIN_EXP|MAX_EXP)'/usr/include/
/usr/include/x86/float.h:#define LDBL_MANT_DIG 64
/usr/include/x86/float.h:#define LDBL_MIN_EXP (-16381)
/usr/include/x86/float.h:#define LDBL_MAX_EXP 16384
This
On Sep 14 2021, Gerald Pfeifer wrote:
> #define __LDBL_MANT_DIG__ 53
> #define __LDBL_DIG__ 15
> #define __LDBL_MIN_EXP__ (-16381)
> #define __LDBL_MIN_10_EXP__ (-4931)
> #define __LDBL_MAX_EXP__ 16384
> #define __LDBL_MAX_10_EXP__ 4932
> #define __LDBL_DECIMAL_DIG__ 17
> #define _
Hi Jason,
I was looking at handling some backports to 11.x and 10.x for coroutines
code-gen fixes ...
> On 7 May 2021, at 04:11, Jason Merrill wrote:
>
> A change to check glvalue_p rather than specifically for TARGET_EXPR
> revealed issues with the coroutines code's use of the 'rvalue' functio
On Tue, Sep 14, 2021 at 05:17:04PM +0200, Andreas Schwab wrote:
> On Sep 14 2021, Gerald Pfeifer wrote:
>
> > #define __LDBL_MANT_DIG__ 53
> > #define __LDBL_DIG__ 15
> > #define __LDBL_MIN_EXP__ (-16381)
> > #define __LDBL_MIN_10_EXP__ (-4931)
> > #define __LDBL_MAX_EXP__ 16384
> > #d
On 9/14/21 11:21 AM, Iain Sandoe wrote:
Hi Jason,
I was looking at handling some backports to 11.x and 10.x for coroutines
code-gen fixes ...
On 7 May 2021, at 04:11, Jason Merrill wrote:
A change to check glvalue_p rather than specifically for TARGET_EXPR
revealed issues with the coroutines
On Sep 14 2021, Jakub Jelinek wrote:
> But, wonder why it didn't work with the float.h include then, because
> https://github.com/lattera/freebsd/blob/master/sys/x86/include/float.h
> seems to define LDBL_MANT_DIG to 64, LDBL_MIN_EXP to (-16381) and
> LDBL_MAX_EXP to 16384 and that case was handle
Hi
Some small code cleanups that allow us to have just one place that
we handle a statement with await expression(s) embedded. Also we
can reduce the work done to figure out whether a statement contains
any such expressions.
tested on x86_64,powerpc64le-linux x86_64-darwin
OK for master?
thanks
On 9/13/21 7:17 PM, Segher Boessenkool wrote:
> On Mon, Sep 13, 2021 at 05:10:42PM -0500, Peter Bergner wrote:
>> It still has "a" match_operand...for operand 0. The match_operand
>> for operand 1 was what was removed. Want me to reword that as
>> "Remove source match_operand." or "Remove match_o
On 9/14/2021 8:53 AM, Aldy Hernandez wrote:
On 9/14/21 4:13 PM, Michael Matz wrote:
Hello,
On Mon, 13 Sep 2021, Aldy Hernandez via Gcc-patches wrote:
The testcase still tests what it's supposed to test with ...
typedef unsigned short uint16_t;
uint16_t a, b;
int *j_global;
uint16_t f(
On Mon, 13 Sep 2021, Sandra Loosemore wrote:
> Here's a patch. Gerald, can you check that this fixes your bootstrap
> problem on i586-unknown-freebsd11?
I does not change the bootstrap failure on i586-unknown-freebsd11
- though looking at the discussion here still looks like a good
change to ma
Please CC libstdc++ patches to the libstdc++ list, or they won't get
reviewed (because I don't subscribe to gcc-patches).
GCC 5 does implement SSO but it's only used conditionally. Your patch
uses numeric_limits unconditionally, which will result in
over-allocation for COW strings.
There also see
> On 9 Sep 2021, at 17:15, Jason Merrill wrote:
>
> On 8/18/21 3:13 PM, Iain Sandoe wrote:
>> Hi,
>> I have found it useful when working with modules stuff to have the completed
>> set of command/responses available (some people working with the interfaces
>> for more sophisticated tools are usin
Committed as obvious as r12-3533.
The fix to PR87737 did work for the given testcase, but could lead
to a bad internal compiler state for a variation of the testcase.
(Found by Gerhard...)
The solution was to not return too early after emitting the error
message but going through a 'cleanup' inst
As nicely described in the PR, we mishandled the case of passing
optional allocatable DT arguments with allocatable components
when the INTENT was declared as INTENT(OUT), as we unconditionally
tried to deallocate these components even when the argument was not
present. The obvious solution is to
In grok_special_member_properties we need to set TYPE_HAS_COPY_CTOR,
TYPE_HAS_DEFAULT_CONSTRUCTOR and TYPE_HAS_LIST_CTOR independently
from each other because a single constructor can be both a default and
list constructor (as in the first testcase), or both a default and copy
constructor (as in th
On Tue, 14 Sep 2021, Tobias Burnus wrote:
> And, related, does the following make sense and fixes the issue?
>
> --- a/libgfortran/ISO_Fortran_binding.h
> +++ b/libgfortran/ISO_Fortran_binding.h
> @@ -228,5 +228,5 @@ extern int CFI_setpointer (CFI_cdesc_t *, CFI_cdesc_t *,
> const CFI_index_t []);
Hi,
I'm sending this patch to get feedback for a new PRU CPU port feature.
My intention is to push it to master by end of September, so that it gets
included in GCC 12.
The PRU architecture provides single-cycle access to GPIO pins via
special designated CPU registers - R30 and R31. These two reg
Hi Will,
On 9/13/21 1:42 PM, will schmidt wrote:
On Wed, 2021-09-01 at 11:13 -0500, Bill Schmidt via Gcc-patches wrote:
This is another patch that looks bigger than it really is. Because we
have a new namespace for the builtins, allowing us to have both the old
and new builtin infrastructure s
Hi!
The following two patches adds support for complex types in libgccjit.
The complex types already are in the types enum, however they are not usable.
In the patch, to use complex types, the user need to call a option function
enabling
support. In this way, there will be a linking error i
>From ff47bbec5a833b4470cae7cb636a5fbf31c6432e Mon Sep 17 00:00:00 2001
From: Petter Tomner
Date: Tue, 14 Sep 2021 23:51:41 +0200
Subject: [PATCH 1/2] jit: Support for complex types
The patch adds support of complex floating point types to libgccjit.
A new binary operator 'COMPLEX' is added to cr
>From a833639e6dfe9ff44b1084b5a5cbbf477d023cf5 Mon Sep 17 00:00:00 2001
From: Petter Tomner
Date: Tue, 14 Sep 2021 23:52:06 +0200
Subject: [PATCH 2/2] jit: Testcases and documentation for complex types
Will squash with path 1
Signed-off-by:
2021-09-15 Petter Tomner
gcc/jit/docs/topics/
On Tue, 14 Sep 2021, Andreas Schwab wrote:
> On Sep 14 2021, Jakub Jelinek wrote:
>
> > But, wonder why it didn't work with the float.h include then, because
> > https://github.com/lattera/freebsd/blob/master/sys/x86/include/float.h
> > seems to define LDBL_MANT_DIG to 64, LDBL_MIN_EXP to (-16381
Hi:
As describled in PR, use vextract instead on valign when
byte_offset % 16 == 0.
Bootstrapped and regtest on x86_64-linux-gnu{-m32,}.
Pushed to trunk.
2020-09-13 Hongtao Liu
Peter Cordes
gcc/ChangeLog:
PR target/91103
* config/i386/sse.md (extract_suf):
2021-09-14 Max Filippov
gcc/
PR target/102336
* config/xtensa/t-xtensa (TM_H): Add include/xtensa-config.h.
---
gcc/config/xtensa/t-xtensa | 1 +
1 file changed, 1 insertion(+)
diff --git a/gcc/config/xtensa/t-xtensa b/gcc/config/xtensa/t-xtensa
index 973815c8c2d6..d06e49280545
While working on a larger change to destructor lookup I noticed that this
rule talks about declarators, but we weren't limiting the error to the case
where we're parsing a declarator. I don't know if this actually broke
anything, since a CPP_TEMPLATE_ID would have to have been parsed once
before,
The way cp_parser_lookup_name handles object scope (i.e. the scope on the
RHS of a . or -> expression) is a bit subtle: before the lookup it's in
parser->context->object type, and after the lookup it's in
parser->object_scope. But a couple of places that elide lookups were
failing to do the same t
We've always predeclared std::type_info, which has been wrong for a while,
but now with modules it becomes more of a practical problem, if we want to
declare it in the purview of a module. So don't predeclare it. For
building up the type_info information to write out with the vtable, we can
use v
On Mon, 13 Sep 2021, John David Anglin wrote:
> On 2021-09-13 11:05 a.m., Jeff Law wrote:
> >
> >
> > On 9/13/2021 8:58 AM, John David Anglin wrote:
> >> On 2021-09-13 9:53 a.m., Jeff Law wrote:
> It is in fact also hpux11*, thus all 32bit pa configs that do not support
> DWARF (for what
On Tue, 14 Sep 2021, Richard Sandiford wrote:
> Richard Biener via Gcc-patches writes:
> > This changes us to maintain and compute (mis-)alignment info for
> > the first element of a group only rather than for each DR when
> > doing interleaving and for the earliest, first, or first in the SLP
>
57 matches
Mail list logo
