https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102317
--- Comment #6 from Jakub Jelinek ---
That doesn't make sense. -fsanitize=signed-integer-overflow also removes that
undefined behavior by defining what happens on signed integer overflow, one can
choose whether to get a non-fatal runtime
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69689
Andrew Pinski changed:
What|Removed |Added
CC||ro at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86744
Andrew Pinski changed:
What|Removed |Added
Resolution|FIXED |DUPLICATE
--- Comment #6 from Andrew
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69274
Bug 69274 depends on bug 69689, which changed state.
Bug 69689 Summary: gcc.target/i386/addr-sel-1.c FAILs with PR69274 fix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69689
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69689
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |FIXED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97142
luoxhu at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97142
--- Comment #21 from CVS Commits ---
The releases/gcc-10 branch has been updated by Xiong Hu Luo
:
https://gcc.gnu.org/g:68d525ee859041b21d87b23030d1e829a9cc3b6f
commit r10-10116-g68d525ee859041b21d87b23030d1e829a9cc3b6f
Author: Xionghu Luo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97142
--- Comment #20 from CVS Commits ---
The releases/gcc-11 branch has been updated by Xiong Hu Luo
:
https://gcc.gnu.org/g:a87d7fbef55f72781905bffb298aab698fe6ed40
commit r11-8985-ga87d7fbef55f72781905bffb298aab698fe6ed40
Author: Xionghu Luo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102316
Tee KOBAYASHI changed:
What|Removed |Added
CC||xtkoba at gmail dot com
--- Comment #2
I reworked the fix today based on feedback from Jason and Jakub (thank
you), and the subject line is now outdated. I added another test for a
closely related bug that's also fixed here (dependent-expr11.C -- this one
would even fail without the second declaration). All the new tests in the
patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21496
--- Comment #2 from Andrew Pinski ---
So I think this testcase was fixed in two different ways.
First was by using dg-excess-errors for the testcase which was introduced by
r0-98409 to testcase.
And then fixed with r0-109419 for GCC 4.7.0
i'm going to commit 8 patches:
[PATCH 16/62] AVX512FP16: Add vsqrtph/vrsqrtph/vsqrtsh/vrsqrtsh.
[PATCH 17/62] AVX512FP16: Add testcase for vsqrtph/vsqrtsh/vrsqrtph/vrsqrtsh.
[PATCH 18/62] AVX512FP16: Add vrcpph/vrcpsh/vscalefph/vscalefsh.
[PATCH 19/62] AVX512FP16: Add testcase for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21132
--- Comment #5 from Andrew Pinski ---
(In reply to Hans-Peter Nilsson from comment #4)
> (In reply to Andrew Pinski from comment #2)
> > >1. While working on this I noticed that genpreds treats
> >
> > Fixed/changed with r6-1344.
> >
> >
> >
On 9/13/21 11:07 AM, Tobias Burnus wrote:
On 13.09.21 18:59, Sandra Loosemore wrote:
On 9/13/21 10:51 AM, Jakub Jelinek wrote: >>> Wouldn't it be better to use the
__LDBL_* macros anyway and not rely on
float.h? The header doesn't want to test what float.h tells about the
long double type,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21132
Hans-Peter Nilsson changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
Ping again.
Thanks,
Feng
From: Feng Xue OS
Sent: Wednesday, September 1, 2021 9:46 AM
To: Martin Liška; Jan Hubicka; gcc@gcc.gnu.org
Cc: JiangNing OS
Subject: PING: [RFC] Whole Program Devirtualization
Honza,
How do you think about proposal in this
On Tue, Sep 14, 2021 at 10:06 AM Hongtao Liu wrote:
>
> On Tue, Sep 14, 2021 at 8:58 AM Andrew Pinski wrote:
> >
> > On Wed, Sep 8, 2021 at 2:55 AM Hongtao Liu via Gcc-patches
> > wrote:
> > >
> > > On Wed, Sep 8, 2021 at 5:33 PM Jakub Jelinek wrote:
> > > >
> > > > On Wed, Sep 08, 2021 at
On Tue, Sep 14, 2021 at 8:58 AM Andrew Pinski wrote:
>
> On Wed, Sep 8, 2021 at 2:55 AM Hongtao Liu via Gcc-patches
> wrote:
> >
> > On Wed, Sep 8, 2021 at 5:33 PM Jakub Jelinek wrote:
> > >
> > > On Wed, Sep 08, 2021 at 05:23:40PM +0800, Hongtao Liu wrote:
> > > > > Bootstrapped/regtested on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102294
--- Comment #13 from Bart Van Assche ---
Hi H.J. Lu, thank you for having taken a look. I would like to try your patch.
However, I'm not a gcc developer so I don't have a gcc tree checked out on my
development workstation. It may take some time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21132
--- Comment #3 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #2)
> >1. While working on this I noticed that genpreds treats
>
> Fixed/changed with r6-1344.
https://gcc.gnu.org/pipermail/gcc-patches/2015-May/420317.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21132
--- Comment #2 from Andrew Pinski ---
>1. While working on this I noticed that genpreds treats
Fixed/changed with r6-1344.
I think that is the only ask in this bug report, is that correct?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102075
luoxhu at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
On 2021/9/13 16:17, Richard Biener wrote:
On Mon, 13 Sep 2021, Xionghu Luo wrote:
On 2021/9/10 21:54, Xionghu Luo via Gcc-patches wrote:
On 2021/9/9 18:55, Richard Biener wrote:
diff --git a/gcc/tree-ssa-loop-im.c b/gcc/tree-ssa-loop-im.c
index 5d6845478e7..4b187c2cdaf 100644
---
On Wed, Sep 8, 2021 at 2:55 AM Hongtao Liu via Gcc-patches
wrote:
>
> On Wed, Sep 8, 2021 at 5:33 PM Jakub Jelinek wrote:
> >
> > On Wed, Sep 08, 2021 at 05:23:40PM +0800, Hongtao Liu wrote:
> > > > Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
> > > >
> > > Patch LGTM.
>
Hello, this is the mail server on server.hiteutomotive.com.
I am sending you this message to inform you on the delivery status of a
message you previously sent. Immediately below you will find a list of
the affected recipients; also attached is a Delivery Status Notification
(DSN) report in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102278
--- Comment #5 from Piotr Kubaj ---
Still the same issue:
/wrkdirs/usr/ports/lang/gcc12-devel/work/.build/./gcc/xgcc
-B/wrkdirs/usr/ports/lang/gcc12-devel/work/.build/./gcc/
-B/usr/local/powerpc-portbld-freebsd13.0/bin/
On Mon, Sep 13, 2021 at 05:10:42PM -0500, Peter Bergner wrote:
> >>* config/rs6000/mma.md (unspec): Delete UNSPEC_MMA_XXSETACCZ.
> >>(unspecv): Add UNSPECV_MMA_XXSETACCZ.
> >
> > Unrelated to this patch, but I have been wondering this for years:
> > should we have an unspecv enum at all?
Signed-off-by: Benjamin Peterson
gcc/
* attribs.c (make_unique_name): Delete.
* attribs.h (make_unique_name): Delete.
---
gcc/attribs.c | 34 --
gcc/attribs.h | 1 -
2 files changed, 35 deletions(-)
diff --git a/gcc/attribs.c b/gcc/attribs.c
On Wed, Sep 01, 2021 at 11:13:37AM -0500, Bill Schmidt wrote:
> Although this patch looks quite large, the changes are fairly minimal.
> Most of it is duplicating the large function that does the overload
> resolution using the automatically generated data structures instead of
> the old
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=27791
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100380
--- Comment #7 from Antoni ---
Since then, I found a workaround to fix the similar segfault in my other
feature.
It might work for solving this and goes like this:
instead of trying to access the rvalue when first replaying the asm, create an
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 because the typo corrector determines that `typeof` is a
> candidate
On 9/12/21 2:26 PM, Segher Boessenkool wrote:
>> I also removed the mma_xxsetaccz define_expand and
>> define_insn_and_split and replaced it with a simple define_insn.
>
> In the future pleaase do that in a separate patch. That makes it *much*
> easier to read and review this.
Will do.
>>
On Linux/x86_64,
76b75018b3d053a890ebe155e47814de14b3c9fb is the first bad commit
commit 76b75018b3d053a890ebe155e47814de14b3c9fb
Author: Jason Merrill
Date: Thu Jul 15 15:30:17 2021 -0400
c++: implement C++17 hardware interference size
caused
FAIL:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91050
Andrew Pinski changed:
What|Removed |Added
CC||dealer4587 at yahoo dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12691
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102317
--- Comment #5 from Qing Zhao ---
> On Sep 13, 2021, at 4:45 PM, pinskia at gcc dot gnu.org
> wrote:
>
>> is it possible to make -fsanitize=signed-integer-overflow work with -fwrapv?
>
> Why would it? they conflict.
This is a feature that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102317
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45881
--- Comment #3 from Jan Waclawek ---
Thanks for the comments and the link.
Small embedded is generally frowned upon. The proposal is characteristically
heavyweight and unwieldy.
Maybe in C5x.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102317
--- Comment #3 from Andrew Pinski ---
(In reply to qinzhao from comment #2)
> (In reply to Andrew Pinski from comment #1)
> > -fno-strict-overflow maps directly to -fwrapv .
> >
> > If you want to use -fsanitize=signed-integer-overflow, you
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102317
--- Comment #2 from qinzhao at gcc dot gnu.org ---
(In reply to Andrew Pinski from comment #1)
> -fno-strict-overflow maps directly to -fwrapv .
>
> If you want to use -fsanitize=signed-integer-overflow, you can just remove
> both
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102317
--- Comment #1 from Andrew Pinski ---
-fno-strict-overflow maps directly to -fwrapv .
If you want to use -fsanitize=signed-integer-overflow, you can just remove both
-fno-strict-overflow -fwrapv. -fwrapv is implied for code later on.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102317
Bug ID: 102317
Summary: signed integer overflow sanitizer cannot work well
with -fno-strict-overflow
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58748
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2021-09-13
Hi, I see that a number of targets are going to be deprecated for GCC 12:
- m32r{,le}-linux:
https://gcc.gnu.org/pipermail/gcc-patches/2021-September/579265.html
- cr16: https://gcc.gnu.org/pipermail/gcc-patches/2021-September/579280.html
- m68k-openbsd:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33451
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82701
Andrew Pinski changed:
What|Removed |Added
Component|inline-asm |target
Severity|normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102287
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC||anlauf at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45881
--- Comment #2 from Andrew Pinski ---
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2763.pdf
It seems like they did not add this ...
But they do have _Bitwidthof now ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61893
Andrew Pinski changed:
What|Removed |Added
CC||john at mcfarlane dot name
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102303
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102295
--- Comment #4 from Andrew Pinski ---
(In reply to Jakub Jelinek from comment #3)
> Note, we have other issues, consider:
> struct A
> {
> float a;
> int b[];
> };
>
> int x[4];
> struct A c = { 42.0f, { ++x[0], ++x[1], ++x[2], ++x[3] } };
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102316
--- Comment #1 from Andrew Pinski ---
Looks like it is unrolling ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102316
Bug ID: 102316
Summary: Unexpected stringop-overflow Warnings on POWER CPU
Product: gcc
Version: 11.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
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 union still appears
uninitialized after
I merged trunk revision 104c05c5284b7822d770ee51a7d91946c7e56d50 to
the gccgo branch.
Ian
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102287
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
On Wed, 2021-09-01 at 11:13 -0500, Bill Schmidt via Gcc-patches wrote:
> This patch just duplicates a couple of functions and adjusts them to use the
> new builtin names. There's no logical change otherwise.
>
> 2021-08-31 Bill Schmidt
>
> gcc/
> * config/rs6000/rs6000.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102311
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC||anlauf at gcc dot gnu.org
On 9/13/2021 10:52 AM, Koning, Paul wrote:
On Sep 13, 2021, at 3:31 AM, Richard Biener wrote:
This makes defaults.h choose DWARF2_DEBUG if PREFERRED_DEBUGGING_TYPE
is not specified by the target and NO_DEBUG if DWARF is not supported.
It also makes us warn when STABS is enabled and
Hi Folks
> On 10 Sep 2021, at 16:16, Jeff Law wrote:
> On 9/10/2021 1:19 AM, Richard Biener via Gcc-patches wrote:
>> This removes the always defined DARWIN_PREFER_DWARF and the code
>> guarded by it being not defined, removing the possibility to
>> default some i386 darwin configurations to
On Wed, 2021-09-01 at 11:13 -0500, Bill Schmidt via Gcc-patches wrote:
> Peter Bergner recently added two new builtins __builtin_vsx_lxvp and
> __builtin_vsx_stxvp. These happened to break a pattern in MMA builtins that
> I had been using to automate gimple folding of MMA builtins. Previously,
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102311
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Last reconfirmed||2021-09-13
Ever
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 supported at once, we need versions of
> these
Hi,
PR77565 reports that, with the code `typdef int Int;`, GCC emits
"did you mean 'typeof'?" instead of "did you mean 'typedef'?".
This happens because the typo corrector determines that `typeof` is a
candidate for suggestion (through `cp_keyword_starts_decl_specifier_p`),
but `typedef` is not.
On Mon, Sep 13, 2021 at 05:56:53PM +0200, 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
Hi,
I tried to merge trunk to into the coarray_native branch in preparation
of some further work. After some problems, it seems that the commit
worked. However, pushing it resulted in an error message, and it seems
there was no e-mail to the gcc-cvs mailing list.
The commit is
commit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77565
--- Comment #5 from Michel Morin ---
Confirmed the fix. Will send a patch to ML.
> I had use -std=c++98
This comment helps me a lot to understand what's going on. Thanks!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102307
--- Comment #7 from jyhgekyfbkjsyebf at protonmail dot ch ---
Note that:
* based on repro: if I add constexpr to the first ctor and provide body, it
will compile without error. Like this:
constexpr Matrix(double const ()[N][M]) {}
* based on
On Wed, 2021-09-01 at 11:13 -0500, Bill Schmidt via Gcc-patches wrote:
> I over-restricted use of __builtin_mffsl, since I was unaware that it
> automatically uses mffs when mffsl is not available. Paul Clarke
> pointed
> this out in discussion of his SSE 4.1 compatibility patches.
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102276
--- Comment #2 from Alexander Monakov ---
That -ftrivial-auto-var-init places an initialization at the point of the
declaration is an implementation detail: there's no initializer in the testcase
itself, so it is valid C and C++ (spelling this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102211
--- Comment #10 from Jim Wilson ---
I attached a patch which is my proposed solution to the RISC-V backend. It
adds a new f_register_operand predicate and modifies patterns that use the f
constraint to use it instead of register_operand.
This
On Sep 13 2021, 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 looks like
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102211
--- Comment #9 from Jim Wilson ---
Created attachment 51456
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51456=edit
proposed RISC-V backend solution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102315
Bug ID: 102315
Summary: ICE tree check: expected integer_cst, have save_expr
in gfc_trans_array_constructor_value, at
fortran/trans-array.c:2056
Product: gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102285
qinzhao at gcc dot gnu.org changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |qinzhao at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102314
Bug ID: 102314
Summary: [11/12 Regression] ICE in verify_ssa, at
tree-ssa.c:1076
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82314
--- Comment #10 from CVS Commits ---
The master branch has been updated by Harald Anlauf :
https://gcc.gnu.org/g:104c05c5284b7822d770ee51a7d91946c7e56d50
commit r12-3500-g104c05c5284b7822d770ee51a7d91946c7e56d50
Author: Harald Anlauf
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102313
Bug ID: 102313
Summary: [12 Regression] ICE in gfc_ascii_statement(): Bad
statement code
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102312
Bug ID: 102312
Summary: [12 Regression] ICE in gfc_get_dtype_rank_type, at
fortran/trans-types.c:1558
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85130
--- Comment #7 from CVS Commits ---
The master branch has been updated by Harald Anlauf :
https://gcc.gnu.org/g:8d93ba93d3b13ac3d3c34404cad87732c809605b
commit r12-3499-g8d93ba93d3b13ac3d3c34404cad87732c809605b
Author: Harald Anlauf
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102311
Bug ID: 102311
Summary: [11/12 Regression] ICE in
gfc_enforce_clean_symbol_state, at
fortran/symbol.c:4278
Product: gcc
Version: 12.0
Status:
On Mon, Sep 13, 2021 at 07:07:01PM +0200, Tobias Burnus wrote:
> Regarding FreeBSD: Does this output different values? – If yes, we know
> what to do, otherwise – hmm.
>
> [...]
>
> > > Wouldn't it be better to use the __LDBL_* macros anyway and not rely on
> > > float.h? The header doesn't
On Wed, 2021-09-01 at 11:13 -0500, Bill Schmidt via Gcc-patches wrote:
Hi,
Just a couple cosmetic nits noted below, the majority if which is also in
the original code this is based on.
THanks
-Will
> Although this patch looks quite large, the changes are fairly minimal.
> Most of it is
On 13.09.21 18:59, Sandra Loosemore wrote:
On 9/13/21 10:51 AM, Jakub Jelinek wrote:
On Mon, Sep 13, 2021 at 06:32:56PM +0200, Tobias Burnus wrote:
On 13.09.21 17:56, Gerald Pfeifer wrote:
This broke bootstrap on i586-unknown-freebsd11:
% egrep -r '#define.*LDBL_(MANT_DIG|MIN_EXP|MAX_EXP)'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102310
Bug ID: 102310
Summary: ICE in visit_ref_for_mod_analysis with OpenACC
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
On 9/13/21 4:18 PM, Michael Matz wrote:
> Hello,
>
> On Mon, 13 Sep 2021, Jeff Law via Gcc-patches wrote:
>
>>> So it looks like there's some undefined behavior going on, even before
>>> my patch. I'd like to get some feedback, because this is usually the
>>> type of problems I see in the
On 9/13/21 10:51 AM, Jakub Jelinek wrote:
On Mon, Sep 13, 2021 at 06:32:56PM +0200, Tobias Burnus wrote:
On 13.09.21 17:56, Gerald Pfeifer wrote:
This broke bootstrap on i586-unknown-freebsd11:
In file included from
.../GCC-HEAD/libgfortran/runtime/ISO_Fortran_binding.c:30:
> On Sep 13, 2021, at 3:31 AM, Richard Biener wrote:
>
> This makes defaults.h choose DWARF2_DEBUG if PREFERRED_DEBUGGING_TYPE
> is not specified by the target and NO_DEBUG if DWARF is not supported.
>
> It also makes us warn when STABS is enabled and removes the corresponding
> diagnostic
On Mon, Sep 13, 2021 at 06:32:56PM +0200, Tobias Burnus wrote:
> On 13.09.21 17:56, Gerald Pfeifer wrote:
> > This broke bootstrap on i586-unknown-freebsd11:
> >
> >In file included from
> > .../GCC-HEAD/libgfortran/runtime/ISO_Fortran_binding.c:30:
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101574
Thomas Schwinge changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |tschwinge at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101574
--- Comment #10 from CVS Commits ---
The master branch has been updated by Thomas Schwinge :
https://gcc.gnu.org/g:6c79057fae6bbb36c4a4fd61c5b7107a16b71b17
commit r12-3498-g6c79057fae6bbb36c4a4fd61c5b7107a16b71b17
Author: Thomas Schwinge
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102295
--- Comment #3 from Jakub Jelinek ---
Note, we have other issues, consider:
struct A
{
float a;
int b[];
};
int x[4];
struct A c = { 42.0f, { ++x[0], ++x[1], ++x[2], ++x[3] } };
When splitting the init into DECL_INITIAL constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102295
Jakub Jelinek changed:
What|Removed |Added
Last reconfirmed||2021-09-13
Hi Gerald,
On 13.09.21 17:56, Gerald Pfeifer wrote:
This broke bootstrap on i586-unknown-freebsd11:
In file included from
.../GCC-HEAD/libgfortran/runtime/ISO_Fortran_binding.c:30:
.../GCC-HEAD/libgfortran/ISO_Fortran_binding.h:255:2:
error: #error "Can't determine kind of long
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102282
sandra at gcc dot gnu.org changed:
What|Removed |Added
CC||sandra at gcc dot gnu.org
On Wed, 18 Aug 2021, Sandra Loosemore wrote:
> I realized last week that having multilib-specific versions of
> ISO_Fortran_binding.h (generated by running the compiler to ask what kinds it
> supports) was still broken outside of the test support; the directory where
> it's being installed isn't
On 9/13/2021 9:44 AM, 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 whatever reasons).
We used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102300
Patrick Palka changed:
What|Removed |Added
Ever confirmed|0 |1
Known to fail|
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 whatever reasons).
>>> We used embedded stabs for SOM (the
1 - 100 of 275 matches
Mail list logo
