Tested on x86-64 Linux.
Committed as obvious.
gcc/ChangeLog:
* tree-ssa-loop-ch.c: Remove unnecessary include file.
---
gcc/tree-ssa-loop-ch.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/gcc/tree-ssa-loop-ch.c b/gcc/tree-ssa-loop-ch.c
index b4e09f97b28..ffb0aa85118 100644
---
The function postfold_gcond_edges() registers relations coming out of a
GIMPLE_COND. With upcoming changes, we may be called with statements
not in the IL (for example, dummy statements created by the
forward threader). This patch avoids breakage by exiting if the
statement does not have a
Currently we adjust statements containing an IMAGPART_EXPR if the
defining statement was one of a few built-ins known to return boolean
types. We can also adjust statements for both IMAGPART_EXPR and
REALPART_EXPR where the defining statement is a constant.
This patch adds such support, and
> This is not in one single place, but spread throughout the
> compiler, both common code and back-end. I do not think it will
> be possible to get the compiler to generate correct code if
> you do not specify the address size correctly.
1. Is there any way to put a constraint on index
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91442
--- Comment #4 from Thomas Schwinge ---
(In reply to paul.luckner from comment #2)
> integer, allocatable :: i(:)
> i = [1]
Is that PR77504?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91442
Thomas Schwinge changed:
What|Removed |Added
CC||tschwinge at gcc dot gnu.org
---
On Fri, Sep 03, 2021 at 10:38:36PM +1000, Paul Edwards via Gcc wrote:
> > This is not in one single place, but spread throughout the
> > compiler, both common code and back-end. I do not think it will
> > be possible to get the compiler to generate correct code if
> > you do not specify the
On Mon, Aug 02, 2021 at 02:31:12PM +0800, liuhongt via Gcc-patches wrote:
> * doc/extend.texi (Half-Precision Floating Point): Documemt
> _Float16 for x86.
> --- a/gcc/doc/extend.texi
> +++ b/gcc/doc/extend.texi
> @@ -1102,6 +1102,7 @@ typedef _Complex float __attribute__((mode(IC)))
>> > Also, the compiler
>> > will assume the base + index (+ displacement) arithmetic
>> > will operate in 32 bits -- I'm pretty sure this is
>> > actually the root cause of your "negative index" problem.
>> Where is this logic please? Can I do a #if 0 or similar
>> to disable it?
> This is
> On 3 Sep 2021, at 13:33, Jakub Jelinek via Gcc-patches
> wrote:
>
> On Fri, Sep 03, 2021 at 01:32:14PM +0100, Iain Sandoe via Gcc-patches wrote:
>> diff --git a/libgcc/libgcc-std.ver.in b/libgcc/libgcc-std.ver.in
>> index cea33267e53..f5c1bc1aa6c 100644
>> --- a/libgcc/libgcc-std.ver.in
>>
On Fri, Sep 03, 2021 at 01:32:14PM +0100, Iain Sandoe via Gcc-patches wrote:
> diff --git a/libgcc/libgcc-std.ver.in b/libgcc/libgcc-std.ver.in
> index cea33267e53..f5c1bc1aa6c 100644
> --- a/libgcc/libgcc-std.ver.in
> +++ b/libgcc/libgcc-std.ver.in
> @@ -1944,3 +1944,21 @@ GCC_7.0.0 {
>
> On 3 Sep 2021, at 10:00, Jakub Jelinek via Gcc-patches
> wrote:
>
> On Fri, Sep 03, 2021 at 03:41:13PM +0800, liuhongt via Gcc-patches wrote:
>> --- a/libgcc/config/i386/64/t-softfp
>> +++ b/libgcc/config/i386/64/t-softfp
>> @@ -1 +1,6 @@
>> softfp_extras := fixhfti fixunshfti floattihf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102102
H.J. Lu changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
"Paul Edwards" wrote on 03.09.2021 13:35:10:
> > Specifically, if you try to run AMODE64 with Pmode equals
> > SImode, the compiler will not be aware that the hardware
> > uses the high 32 bits of base and index registers, and
> > will not necessarily keep them zero.
> The compiler
On 24/08/2021 12:43, Richard Biener via Gcc-patches wrote:
On Tue, Aug 24, 2021 at 12:23 PM Thomas Schwinge
wrote:
Hi!
On 2021-08-19T22:13:56+0200, I wrote:
On 2021-08-16T10:21:04+0200, Jakub Jelinek wrote:
On Mon, Aug 16, 2021 at 10:08:42AM +0200, Thomas Schwinge wrote:
|> Concerning
Ping
-Original Message-
From: Jirui Wu
Sent: Friday, August 20, 2021 4:28 PM
To: Richard Biener
Cc: Richard Biener ; Andrew Pinski
; Richard Sandiford ;
i...@airs.com; gcc-patches@gcc.gnu.org; Joseph S. Myers
Subject: RE: [Patch][GCC][middle-end] - Generate FRINTZ for (double)(int)
> - AMODE64 means the native address size is 64 bits. This
> implies that Pmode has to be DImode, since Pmode tells
> the compiler what the native address size is.
> Specifically, if you try to run AMODE64 with Pmode equals
> SImode, the compiler will not be aware that the hardware
> uses
"Paul Edwards" wrote on 02.09.2021 22:05:39:
> > Is this about supporting a 4GB address space instead
> > of a 2GB space?
>
> Yes, correct.
OK, that makes things clearer. This implies in particular:
- 4GB address space means you need to run in AMODE64
- AMODE64 means the native address size
Tamar Christina writes:
> Hi All,
>
> The following example
>
> void f5(float * restrict z0, float * restrict z1, float *restrict x,
> float * restrict y, float c, int n)
> {
> for (int i = 0; i < n; i++) {
> float a = x[i];
> float b = y[i];
> if (a > b) {
>
Hi,
> -Original Message-
> From: Gcc On Behalf
> Of gengqi via Gcc
> Sent: 03 September 2021 11:56
> To: gcc@gcc.gnu.org
> Subject: How about providing an interface to fusing instructions via
> scheduling
>
> When I was adding pipeline to my backend, some instructions needed to be
>
On 03/09/2021 10:35, Prathamesh Kulkarni via Gcc-patches wrote:
On Thu, 2 Sept 2021 at 14:32, Christophe Lyon
wrote:
On Tue, Aug 24, 2021 at 10:17 AM Kyrylo Tkachov wrote:
-Original Message-
From: Prathamesh Kulkarni
Sent: 24 August 2021 09:01
To: Christophe Lyon
Cc: Kyrylo
When I was adding pipeline to my backend, some instructions needed to be
fused and I found that there was no suitable interface to implement my
requirements.
My hope is that
1. Do instruction scheduling and combine any two instructions, and sometimes
the two instructions can be treated as 1
*ping*
From: Paul Keir
Sent: 20 August 2021 21:17
To: gcc-patches@gcc.gnu.org
Cc: libstd...@gcc.gnu.org
Subject: [PATCH] libstdc++: Fix compare_three_way for constexpr and Clang
Hi,
The current compare_three_way implementation makes provision for
Tamar Christina via Gcc-patches writes:
> diff --git a/gcc/cse.c b/gcc/cse.c
> index
> 330c1e90ce05b8f95b58f24576ec93e10ec55d89..d76e01b6478e22e9dd5760b7c78cecb536d7daef
> 100644
> --- a/gcc/cse.c
> +++ b/gcc/cse.c
> @@ -44,6 +44,7 @@ along with GCC; see the file COPYING3. If not see
>
apinski--- via Gcc-patches writes:
> From: Andrew Pinski
>
> I got some ICEs in my latest testsing while running the libstdc++ testsuite.
> I had noticed the problem was connected to types and had just touched the
> builtins code but nothing which could have caused this and I looked for
> some
apinski--- via Gcc-patches writes:
> From: Andrew Pinski
>
> This patch adds simple folding of __builtin_aarch64_im_lane_boundsi where
> we are not going to error out. It fixes the problem by the removal
> of the function from the IR.
>
> OK? Bootstrapped and tested on aarch64-linux-gnu with no
This makes sure that the style and warning settings used in the C/C++ bindings
generated by -fdump-ada-spec do not leak into the units that use them.
Tested on x86-64/Linux, applied on the mainline.
2021-09-03 Eric Botcazou
c-family/
* c-ada-spec.c (dump_ads): Generate pragmas to
Hi,
On 03.09.21 09:46, Christophe Lyon wrote:
I'm not quite sure I understand the expected status of this patch: are
all the "expected" failures tagged as XFAIL?
I think that's the idea.
If yes, then there's a problem because I see lots of unresolved on
aarch64/arm
XFAIL:
Hi,
this old PR is about a link failure on x86-64/Cygwin with thread-local
storage variables:
use.o:use.cxx:(.text$_ZTWN1N3ptdE[_ZTWN1N3ptdE]+0x15): relocation
truncated to fit: R_X86_64_PC32 against undefined symbol `TLS init
function for N::ptd'
collect2: error: ld returned 1 exit status
At
apinski--- via Gcc-patches writes:
> From: Andrew Pinski
>
> After the recent r12-3278-823685221de986a change, the testcase
> gcc.target/aarch64/sve/acle/general-c/type_redef_1.c started
> to ICE as the code was not ready for error_mark_node in the
> type. This fixes that and the testcase now
On Fri, Sep 03, 2021 at 03:41:13PM +0800, liuhongt via Gcc-patches wrote:
> --- a/libgcc/config/i386/64/t-softfp
> +++ b/libgcc/config/i386/64/t-softfp
> @@ -1 +1,6 @@
> softfp_extras := fixhfti fixunshfti floattihf floatuntihf
> +
> +CFLAGS-fixhfti.c += -msse2
> +CFLAGS-fixunshfti.c += -msse2
>
On 8/31/21 3:24 PM, H.J. Lu via Gcc-patches wrote:
> On Thu, Aug 12, 2021 at 8:24 PM Ian Lance Taylor via Gcc-patches
> wrote:
>>
>> This patch updates libgo from the Go1.16.5 release to the Go 1.17rc2
>> release. As usual with these version updates, the patch itself is too
>> large to attach to
Hi,
packed array types are sometimes represented with integer types under the hood
in Ada, but we nevertheless need to emit them as array types in the debug info
so we have the types.get_array_descr_info langhook for this purpose; but it is
not invoked from modified_type_die, which is responsible
On Thu, 2 Sept 2021 at 14:32, Christophe Lyon
wrote:
>
>
>
> On Tue, Aug 24, 2021 at 10:17 AM Kyrylo Tkachov
> wrote:
>>
>>
>>
>> > -Original Message-
>> > From: Prathamesh Kulkarni
>> > Sent: 24 August 2021 09:01
>> > To: Christophe Lyon
>> > Cc: Kyrylo Tkachov ; gcc Patches > >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101947
Martin Liška changed:
What|Removed |Added
CC||jamborm at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102187
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102188
Bug ID: 102188
Summary: Over widening detection doesn't work when no range
information
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102187
Bug ID: 102187
Summary: Ada LTO bootstrap broken on x86_64 since
r12-2927-g29020d0527512a
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102024
--- Comment #14 from Jakub Jelinek ---
The generic support is now committed, each backend can decide on what to do
using those flags. That decision should be guided by psABI if it is clear on
those matters, or otherwise ideally the psABIs
Hi!
When __atomic_* builtins were introduced, omp-expand.c (omp-low.c
at that point) has been adjusted in several spots so that it uses
the atomic builtins instead of sync builtins, but
expand_omp_atomic_pipeline has not because the __atomic_compare_exchange_*
APIs take address of the argument,
On Fri, Aug 20, 2021 at 12:35:58PM +0200, Richard Biener wrote:
[...]
> > >
> > > + /* Handle strlen like loops. */
> > > + if (store_dr == NULL
> > > + && integer_zerop (pattern)
> > > + && TREE_CODE (reduction_iv.base) == INTEGER_CST
> > > + && TREE_CODE (reduction_iv.step) ==
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102154
--- Comment #15 from Hongtao.liu ---
(In reply to Segher Boessenkool from comment #14)
> (In reply to Jonathan Wakely from comment #13)
> > Is this also the cause of several libstdc++ FAILs on ppc64le?
>
>
> Yes.
>
> I have asked for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102024
--- Comment #13 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:e902136b310ee17d4b49eb42d9d5e487d5dcf4a1
commit r12-3324-ge902136b310ee17d4b49eb42d9d5e487d5dcf4a1
Author: Jakub Jelinek
Date:
Hi Joseph,
> On 2 Sep 2021, at 21:03, Joseph Myers wrote:
>
> On Thu, 2 Sep 2021, Iain Sandoe via Gcc-patches wrote:
>
>> diff --git a/libgcc/soft-fp/eqdf2.c b/libgcc/soft-fp/eqdf2.c
>> index 2a44ee377ce..a3bb664f5f1 100644
>> --- a/libgcc/soft-fp/eqdf2.c
>> +++ b/libgcc/soft-fp/eqdf2.c
>> @@
Hi,
On Thu, Aug 19, 2021 at 7:29 PM Sandra Loosemore
wrote:
> On 7/27/21 5:07 AM, Tobias Burnus wrote:
> > Hi Sandra, hi Thomas, hi all,
> >
> > @Thomas K: Comments about the following - and of course to the
> > testsuite itself - are highly welcome.
> >
> > In my opinion, the testsuite LGTM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102186
--- Comment #3 from Hongtao.liu ---
A patch is posted at
https://gcc.gnu.org/pipermail/gcc-patches/2021-September/578746.html
For 32-bit libgcc configure w/o sse2, there's would be an error since
GCC only support _Float16 under sse2. Explicitly add -msse2 for those
HF related libgcc functions, so users can still link them w/ the
upper configuration.
Bootstrapped and regtested on x86_64-linux-gnu{-m32,}.
Ok for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102182
--- Comment #4 from Hongtao.liu ---
After emit libcall in convert_to_mode, it failed maybe_emit_unop_insn, so all
insns deleted, but from here is already overrided, it seems to be a bug.
if (icode != CODE_FOR_nothing)
{
Currently, the asm output file for MIPS has no rev info.
It can make some trouble, for example:
assembler is mips1 by default,
gcc is fpxx by default.
To assemble the output of gcc -S, we have to pass -mips2
to assembler.
The same situation is for some CPU has extension insn.
Octeon is an
compression algorithms: zlib zstd
gcc version 12.0.0 20210903 (experimental) (GCC)
: zlib zstd
gcc version 12.0.0 20210903 (experimental) (GCC)
$ /dev/shm/objdir2/./gcc/xgcc -B/dev/shm/objdir2/./gcc/
-B/home/marxin/bin/gcc/i586-suse-linux/bin/ emu.i
emu.i:1:1: error: unable to emulate ‘HF’
1 | float HFtype __attribute__((mode(HF)));
| ^
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102186
Martin Liška changed:
What|Removed |Added
Last reconfirmed||2021-09-03
Priority|P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102186
Bug ID: 102186
Summary: [12 Regression] Broken bootstrap:
soft-fp/half.h:62:1: error: unable to emulate ‘HF’
since
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102185
Bug ID: 102185
Summary: d: STRING_CSTs converted back into StringExp include
null pointer in length
Product: gcc
Version: 11.2.1
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102182
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102184
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102178
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102184
Andrew Pinski changed:
What|Removed |Added
Keywords||diagnostic
--- Comment #1 from Andrew
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102184
Bug ID: 102184
Summary: Explicit template instantiation is wrongly considered
as specialization
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102182
--- Comment #3 from Hongtao.liu ---
during pass_expand we got
(debug_insn 24 23 0 (debug_marker) "test1.c":10:3 -1
(nil))
;; fv2.1_3 ={v} fv2;
(insn 25 24 0 (set (reg:HF 84 [ fv2.1_3 ])
(mem/v/c:HF (symbol_ref:SI ("fv2.1") [flags
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102183
Bug ID: 102183
Summary: sccvn compare predicated result issue in
vn_nary_op_insert_into
Product: gcc
Version: tree-ssa
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50994
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44089
Andrew Pinski changed:
What|Removed |Added
Keywords||ice-on-valid-code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102182
--- Comment #2 from Hongtao.liu ---
Reproduced case.
#include
int
main (void)
{
static volatile unsigned int ivin, ivout;
static volatile _Float16 fv1, fv2;
ivin = ((unsigned int)1);
fv1 = ((unsigned int)1);
fv2 = ivin;
ivout =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29778
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=17217
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|2005-01-25
101 - 166 of 166 matches
Mail list logo
