Am 07.01.25 um 17:52 schrieb Jakub Jelinek via Gcc:
But the compiler does in every ICE message in which -freport-bug isn't
enabled.
It seems that -freport-bug does nothing for Fortran, or at least the
Fortran front end (which why it was unfamiliar to me). Grabbing a
random ICE off bug
on -freport-bug.
> >
> > But the ICE message does.
> >
>
> Hm, OK.
>
> Question: Would it make sense to enable -freport-bug by default on
> non-release builds? I would see no real harm in doing so, because
> additional files are only generated when an ICE
Am 07.01.25 um 18:04 schrieb Andreas Schwab:
On Jan 07 2025, Thomas Koenig via Gcc wrote:
Side remark (which I will also address): https://gcc.gnu.org/bugs/ does
not mention -freport-bug.
But the ICE message does.
Hm, OK.
Question: Would it make sense to enable -freport-bug by default on
On Jan 07 2025, Thomas Koenig via Gcc wrote:
> Side remark (which I will also address): https://gcc.gnu.org/bugs/ does
> not mention -freport-bug.
But the ICE message does.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC
also address): https://gcc.gnu.org/bugs/ does
> not mention -freport-bug.
But the compiler does in every ICE message in which -freport-bug isn't
enabled.
...
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace wi
Am 07.01.25 um 16:41 schrieb Thomas Koenig via Gcc:
Thanks for the explanation. I think it might be good to add a bit
of this to the docs. I will prepare a patch.
Side remark (which I will also address): https://gcc.gnu.org/bugs/ does
not mention -freport-bug.
Best regards
Thomas
Am 07.01.25 um 16:14 schrieb Jakub Jelinek via Gcc:
It is "debug information" in the sense that it is everything needed
to debug the ICE.
Which isn't just preprocessed source, but also used compiler options,
and details on how the compiler has been configured and what ICE has been
On Tue, Jan 07, 2025 at 04:04:22PM +0100, Thomas Koenig wrote:
> Am 07.01.25 um 15:48 schrieb Jakub Jelinek:
> > On Tue, Jan 07, 2025 at 03:45:02PM +0100, Thomas Koenig via Gcc wrote:
> > > Would it be reasonable to dump a preprocessed file (if any) on an ICE,
> > > and
Am 07.01.25 um 15:48 schrieb Jakub Jelinek:
On Tue, Jan 07, 2025 at 03:45:02PM +0100, Thomas Koenig via Gcc wrote:
Would it be reasonable to dump a preprocessed file (if any) on an ICE,
and point the user to it? The error message could then be something
like "Please submit the preproc
On Jan 07 2025, Thomas Koenig via Gcc wrote:
> Would it be reasonable to dump a preprocessed file (if any) on an ICE,
> and point the user to it? The error message could then be something
> like "Please submit the preprocessed file at /home/foo/bar/baz.i".
Like -freport-bug?
On Tue, Jan 07, 2025 at 03:45:02PM +0100, Thomas Koenig via Gcc wrote:
> when an ICE occurs somewhere when building a complex software package,
> it can be cumbersome for the user to obtain the preprocessed file
> that we ask people to submit to us.
>
> Would it be reaso
Hello world,
when an ICE occurs somewhere when building a complex software package,
it can be cumbersome for the user to obtain the preprocessed file
that we ask people to submit to us.
Would it be reasonable to dump a preprocessed file (if any) on an ICE,
and point the user to it? The error
Am 03.09.24 um 18:12 schrieb Andrew MacLeod:
On 8/25/24 03:48, Richard Biener wrote:
On Sat, Aug 24, 2024 at 6:19 PM Georg-Johann Lay wrote:
Trying to use the value-range interface and functions I am running
into that ICE when using invert().
From what the sources suggest, invert
On Tue, Sep 3, 2024 at 6:12 PM Andrew MacLeod wrote:
>
>
> On 8/25/24 03:48, Richard Biener wrote:
> > On Sat, Aug 24, 2024 at 6:19 PM Georg-Johann Lay wrote:
> >> Trying to use the value-range interface and functions I am running
> >> into that ICE when using in
On 8/25/24 03:48, Richard Biener wrote:
On Sat, Aug 24, 2024 at 6:19 PM Georg-Johann Lay wrote:
Trying to use the value-range interface and functions I am running
into that ICE when using invert().
From what the sources suggest, invert() computes the complement of
the current set (the
ry run over a
> > > few thousand files one or more files will crash with an ICE, that goes
> > > away if you just build again. I was under the impression gcc was doing
> > > everything reproducable, so this is really confusing.
> > >
> > > The errors
when compiling the chromium part of
> > qtwebengine after the update to gcc 14 and during development for updating
> > Chromium to 126. On almost every run over a few thousand files one or more
> > files will crash with an ICE, that goes away if you just build again. I
ng development for updating
> Chromium to 126. On almost every run over a few thousand files one or more
> files will crash with an ICE, that goes away if you just build again. I was
> under the impression gcc was doing everything reproducable, so this is really
> confusing.
>
&g
files one or more
files will crash with an ICE, that goes away if you just build again. I was
under the impression gcc was doing everything reproducable, so this is really
confusing.
The errors claim different random spots in the sources with either "internal
compiler error: Segmentation faul
On Sat, Aug 24, 2024 at 6:19 PM Georg-Johann Lay wrote:
>
> Trying to use the value-range interface and functions I am running
> into that ICE when using invert().
>
> From what the sources suggest, invert() computes the complement of
> the current set (the union of finit
Trying to use the value-range interface and functions I am running
into that ICE when using invert().
From what the sources suggest, invert() computes the complement of
the current set (the union of finitely many intervals).
For example, when I have a range of [-128, -1] for int8_t, invert
The current implementation assumes to always be invoked with register
operands. For memory operands we even have an instruction
though (vlrep). With the patch we try this first and only if it fails
force the input into a register and continue.
vec_splats generation fails for single element 128bit
ldn't crash.
>
> the compiler (both 13.2 [1] and trunk [2]) experiences an ICE.
> >
>
> Bug reports belong in bugzilla, not on the mailing list please.
>
> https://gcc.gnu.org/bugs/
I've created <https://gcc.gnu.org/PR113674>:
[[attr]] causes interna
On Tue, 30 Jan 2024, 10:35 Amol Surati via Gcc, wrote:
> Hello,
>
> If a std attribute name is squeezed between 4x underscores,
>
Which is undefined behaviour, but shouldn't crash.
the compiler (both 13.2 [1] and trunk [2]) experiences an ICE.
>
Bug reports belong in
Hello,
If a std attribute name is squeezed between 4x underscores,
the compiler (both 13.2 [1] and trunk [2]) experiences an ICE.
for e.g. when using [[deprecated]] int a;
But, [[depreated]] int a; (i.e. the char 'c' removed from the
spelling) does not cause ICE.
Clan
On Sat, 9 Dec 2023 at 03:53, Paul Smith via Gcc wrote:
>
> I've tried this with both older versions as well as GCC 12.3 (latest I
> have access to). This is on GNU/Linux on x86_64.
>
>
> I have the following code:
[...]
> I'm assuming a bug should be filed for t
Just adding 1 to this, for 3, 4, doesn't help:
/tmp/virt.cpp:7:45: error: 'format' attribute argument 2 value '3'
refers to parameter type 'const void**'
7 | __attribute__((format(printf, 3, 4)));
|
:
> ccache 4.8.0 build fails with ICE when building with gcc 12.3.0:
> https://bugs.mageia.org/show_bug.cgi?id=31893#c0
> regression introduced in gcc-12-20230421 snapshot by commit:
>
> From 890d711a2477119a34cf435f6159b6253b124374 Mon Sep 17 00:00:00
> 2001
> From: Jason Merrill
ccache 4.8.0 build fails with ICE when building with gcc 12.3.0:
https://bugs.mageia.org/show_bug.cgi?id=31893#c0
regression introduced in gcc-12-20230421 snapshot by commit:
From 890d711a2477119a34cf435f6159b6253b124374 Mon Sep 17 00:00:00 2001
From: Jason Merrill <
ja...@redhat.com
>
Dat
onfigure
--enable-languages=c,ada,c++,fortran,java,lto,objc,obj-c++
--program-transform-name=s,y,y, --disable-option-checking
--with-target-subdir=i686-redhat-linux --build=i686-redhat-linux
--host=i686-redhat-linux --target=i686-redhat-linux
--srcdir=../.././libjava --disable-static
That reconf
Hi,
I'm using `build_function_call()` in a plugin I'm writing,
creating `printf()` and `sprintf()` calls.
A few days ago I tested it with recent GCC (9.2.0) and -Wall, and
got "internal compiler error: Segmentation fault" somewhere deep in
`build_function_call()`. Spent some time comparing the `tr
On 9/23/19 8:19 PM, Steve Ellcey wrote:
Before I submit a Bugzilla report or try to cut down a test case, has any
one seen this problem when compiling the 526.blender_r benchmark from
SPEC 2017:
Compiling with '-Ofast -flto -march=native -fprofile-generate' on Aarch64:
during GIMPLE pass: vect
Before I submit a Bugzilla report or try to cut down a test case, has any
one seen this problem when compiling the 526.blender_r benchmark from
SPEC 2017:
Compiling with '-Ofast -flto -march=native -fprofile-generate' on Aarch64:
during GIMPLE pass: vect
blender/source/blender/imbuf/intern/inde
On 5/1/19 10:56 AM, Paul Smith wrote:
On Wed, 2019-05-01 at 09:35 -0400, Paul Smith wrote:
Unfortunately my GCC is heavily optimized and stripped so backtraces
are useless. I will generate a debuggable GCC and see if I can get
more info on the ICE.
I have created a GCC with debug enabled so
aces
> > > are useless. I will generate a debuggable GCC and see if I can get
> > > more info on the ICE.
> >
> > I have created a GCC with debug enabled so I'll see what I find.
>
> I was able to reproduce this ICE quite readily with my debuggable GCC
> 8.1.0. Here's the failure:
On Wed, 2019-05-01 at 09:35 -0400, Paul Smith wrote:
> > Unfortunately my GCC is heavily optimized and stripped so backtraces
> > are useless. I will generate a debuggable GCC and see if I can get
> > more info on the ICE.
>
> I have created a GCC with debug enabled so
de=foo.h
Adding/removing -fpch-preprocess doesn't seem to matter. It's only the
-fpch-deps option during the compile, combined with the -MD/-MF options
when creating the PCH file, that seems to trigger the ICE.
> Unfortunately my GCC is heavily optimized and stripped so backtraces
&
On Tue, 2019-04-30 at 09:34 -0600, Zan Lynx wrote:
> > In the meantime, does this remind anyone of an existing bug,
> > hopefully one that was fixed in 8.2 or 8.3?
>
> It does remind me of a race condition bug with a Makefile I wrote
> years ago.
>
> One or two build tasks did not properly depend
On April 30, 2019 7:43:47 AM MDT, Paul Smith wrote:
>I have GCC 8.1.0 / binutils 2.30 on GNU/Linux 64bit (built locally).
>My codebase is almost all C++.
>
>I'm implementing precompiled headers and it was going well. However,
>sometimes a PCH file is generated that causes
I have GCC 8.1.0 / binutils 2.30 on GNU/Linux 64bit (built locally).
My codebase is almost all C++.
I'm implementing precompiled headers and it was going well. However,
sometimes a PCH file is generated that causes the compiler to ICE when
trying to use it during a source file compil
teger containing the bitfield bit).
> >
> > If that doesn't go anywhere try reducing the source file using creduce
> > or by other means.
> >
> > Maybe look at reset_decl_linkage () and visibility support in general.
>
> I trimmed the file a bit.
>
> Managed to find where public_flag is cleared. It is in cp/expr.c
> maybe_commonize_var, line 5619, here:
>
> else
> {
> /* While for initialized variables, we must use internal
> linkage -- which means that multiple copies will not
> be merged. */
> TREE_PUBLIC (decl) = 0;
> DECL_COMMON (decl) = 0;
>
> Could it be related to the fact that I have an a.out (rather than ELF) target?
I guess a.out is bitrotten (or too incapable) for C++ here. I see the
code above emits warnings about this
being unhandled as well, it possibly should simply sorry() when it can
figure out it
will run into the import_export_decl ICE later...
Richard.
> paul
>
> On Jul 17, 2018, at 9:36 AM, Richard Biener
> wrote:
>
> On Tue, Jul 17, 2018 at 3:08 PM Paul Koning wrote:
>>
>>
>>> On Jul 17, 2018, at 5:46 AM, Richard Biener
>>> wrote:
>>>
...
>>>
>>> There is not enough information for anyone to help you without
>>> reproducing the issue w
On 08/28/2018 05:40 PM, Segher Boessenkool wrote:
> On Mon, Aug 20, 2018 at 11:01:29AM -0600, Jeff Law wrote:
>> On 08/20/2018 10:50 AM, Paul Koning wrote:
>>> The internals manual seems to say that memory subregs are an old mechanism
>>> that should still work, give or take. If indeed it breaks
On Mon, Aug 20, 2018 at 11:01:29AM -0600, Jeff Law wrote:
> On 08/20/2018 10:50 AM, Paul Koning wrote:
> > The internals manual seems to say that memory subregs are an old mechanism
> > that should still work, give or take. If indeed it breaks LRA perhaps the
> > documentation should be updated
> On Aug 20, 2018, at 7:17 AM, Segher Boessenkool
> wrote:
>
> On Tue, Aug 14, 2018 at 03:32:01PM -0400, Paul Koning wrote:
>> I'm trying to convert the pdp11 target to use LRA.
>>
>> A lot of it "just works". But one of the test suite files fails in a way
>> that I can't figure out at all
On 08/20/2018 10:50 AM, Paul Koning wrote:
>
>
>> On Aug 20, 2018, at 7:17 AM, Segher Boessenkool
>> wrote:
>>
>> On Tue, Aug 14, 2018 at 03:32:01PM -0400, Paul Koning wrote:
>>> I'm trying to convert the pdp11 target to use LRA.
>>>
>>> A lot of it "just works". But one of the test suite file
> On Aug 20, 2018, at 7:17 AM, Segher Boessenkool
> wrote:
>
> On Tue, Aug 14, 2018 at 03:32:01PM -0400, Paul Koning wrote:
>> I'm trying to convert the pdp11 target to use LRA.
>>
>> A lot of it "just works". But one of the test suite files fails in a way
>> that I can't figure out at all
On Tue, Aug 14, 2018 at 03:32:01PM -0400, Paul Koning wrote:
> I'm trying to convert the pdp11 target to use LRA.
>
> A lot of it "just works". But one of the test suite files fails in a way
> that I can't figure out at all. I'm hoping for some help or hints to track
> down the cause and come
> On Aug 15, 2018, at 1:01 AM, Jeff Law wrote:
>
> On 08/14/2018 01:32 PM, Paul Koning wrote:
>> I'm trying to convert the pdp11 target to use LRA.
>>
>> A lot of it "just works". But one of the test suite files fails in a way
>> that I can't figure out at all. I'm hoping for some help or
On 08/14/2018 01:32 PM, Paul Koning wrote:
> I'm trying to convert the pdp11 target to use LRA.
>
> A lot of it "just works". But one of the test suite files fails in a way
> that I can't figure out at all. I'm hoping for some help or hints to track
> down the cause and come up with a fix.
>
I'm trying to convert the pdp11 target to use LRA.
A lot of it "just works". But one of the test suite files fails in a way that
I can't figure out at all. I'm hoping for some help or hints to track down the
cause and come up with a fix.
The failing program is testsuite/gcc.c-torture/compile/
> On Jul 23, 2018, at 10:21 AM, Joseph Myers wrote:
>
> On Tue, 17 Jul 2018, Paul Koning wrote:
>
>> That reveals some things but nothing jumps out at me. However... pdp11
>> is an a.out target, not an ELF target. Would that explain the problem?
>> If yes, is there a workaround (short of
On Tue, 17 Jul 2018, Paul Koning wrote:
> That reveals some things but nothing jumps out at me. However... pdp11
> is an a.out target, not an ELF target. Would that explain the problem?
> If yes, is there a workaround (short of implementing ELF)?
As there are hardly any targets left without
> On Jul 17, 2018, at 9:38 AM, Richard Biener
> wrote:
>
>> ...
>> lldb? eh ... ;)
Yes, gdb is hard to make work on Mac OS.
>> anyhow, this is
>>
>> namespace std
>> {
>>
>> # 56
>> "/Users/pkoning/Documents/svn/buildpdp/pdp11-aout/libstdc++-v3/include/type_traits"
>> 3
>> template
>>
On Tue, Jul 17, 2018 at 3:36 PM Richard Biener
wrote:
>
> On Tue, Jul 17, 2018 at 3:08 PM Paul Koning wrote:
> >
> >
> > > On Jul 17, 2018, at 5:46 AM, Richard Biener
> > > wrote:
> > >
> > >> ...
> > >
> > > There is not enough information for anyone to help you without
> > > reproducing the i
On Tue, Jul 17, 2018 at 3:08 PM Paul Koning wrote:
>
>
> > On Jul 17, 2018, at 5:46 AM, Richard Biener
> > wrote:
> >
> >> ...
> >
> > There is not enough information for anyone to help you without
> > reproducing the issue which is maybe too much to ask for ;)
> >
> > Can you debug_tree () the
; >>> Paul Koning wrote on 07/13/2018 08:27 PM:
> >>>> I'm trying to see if I can build the pdp11 target for languages other
> >>>> than just C, and the answer is for the most part yes. But I' running
> >>>> into an ICE I can't f
can build the pdp11 target for languages other than
>>>> just C, and the answer is for the most part yes. But I' running into an
>>>> ICE I can't figure out. It's way before the back end comes into the
>>>> picture as far as I can see, and the
> On Jul 13, 2018, at 2:52 PM, U.Mutlu wrote:
>
> Paul Koning wrote on 07/13/2018 08:27 PM:
>> I'm trying to see if I can build the pdp11 target for languages other than
>> just C, and the answer is for the most part yes. But I' running into an ICE
>>
I'm trying to see if I can build the pdp11 target for languages other than just
C, and the answer is for the most part yes. But I' running into an ICE I can't
figure out. It's way before the back end comes into the picture as far as I
can see, and there's nothing par
On Wed, Jun 20, 2018 at 8:26 PM Paul Koning wrote:
>
> I'm running into an ICE in the GIMPLE phase, for gcc.c-torture/compile/386.c,
> on pdp11 -mint32. That's an oddball where int is 32 bits (due to the flag)
> but Pmode is 16 bits (HImode).
>
> The ICE message is:
I'm running into an ICE in the GIMPLE phase, for gcc.c-torture/compile/386.c,
on pdp11 -mint32. That's an oddball where int is 32 bits (due to the flag) but
Pmode is 16 bits (HImode).
The ICE message is:
../../gcc/gcc/testsuite/gcc.c-torture/compile/386.c: In function ‘main’:
../
On Fri, Jun 01, 2018 at 02:49:51PM -0400, Paul Koning wrote:
> Given that the starting insn had a post_inc in it, what would be a proper
> parallel... construct? If the post_inc only appears in one of the two
> mentions of the source operatnd, then the match_dup is going to fail. I
> suppose I c
> On Jun 1, 2018, at 2:40 PM, Jakub Jelinek wrote:
>
> On Fri, Jun 01, 2018 at 02:35:41PM -0400, Paul Koning wrote:
>> during RTL pass: dse2
>> dump file: unwind-dw2-fde.c.288r.dse2
>> ../../../../gcc/libgcc/unwind-dw2-fde.c: In function ‘get_cie_encoding’:
>> ../../../../gcc/libgcc/unwind-dw2
On Fri, Jun 01, 2018 at 02:35:41PM -0400, Paul Koning wrote:
> during RTL pass: dse2
> dump file: unwind-dw2-fde.c.288r.dse2
> ../../../../gcc/libgcc/unwind-dw2-fde.c: In function ‘get_cie_encoding’:
> ../../../../gcc/libgcc/unwind-dw2-fde.c:342:1: internal compiler error: in
> cselib_record_set,
nstruction before it already set the CC correctly.
If I do that I get an ICE in cselib that I can't figure out. If I turn off the
post-reload compare elimination optimization then everything works.
The error is this:
during RTL pass: dse2
dump file: unwind-dw2-fde.c.288r.dse2
../../../../gc
On Mon, 2018-03-05 at 19:04 +0100, Marek Polacek wrote:
> On Mon, Mar 05, 2018 at 12:58:23PM -0500, Donald Parsons wrote:
> >
> > I am getting ICE bootstrapping gcc-8-20180304.tar.xz when using
> > either
> > isl-0.18 or isl-0.19. I had never had a problem using lates
On Mon, 2018-03-05 at 19:04 +0100, Marek Polacek wrote:
> On Mon, Mar 05, 2018 at 12:58:23PM -0500, Donald Parsons wrote:
> >
> > I am getting ICE bootstrapping gcc-8-20180304.tar.xz when using
> > either
> > isl-0.18 or isl-0.19. I had never had a problem using lates
On Mon, Mar 05, 2018 at 12:58:23PM -0500, Donald Parsons wrote:
>
> I am getting ICE bootstrapping gcc-8-20180304.tar.xz when using either
> isl-0.18 or isl-0.19. I had never had a problem using latest isl over
> the past couple of years, so a change in gcc last week introduced t
I am getting ICE bootstrapping gcc-8-20180304.tar.xz when using either
isl-0.18 or isl-0.19. I had never had a problem using latest isl over
the past couple of years, so a change in gcc last week introduced the
problem.
Normally I disable-bootstrap and use last weeks gcc-8 to build this
weeks
Today I get an ICE during configuration of libgcc in stage 2 on
x86_64-w64-mingw32. That's rev. 257390.
configure:3688:
/opt/devel/SCRATCH/tmp.Sbg1TmFqa7/gcc-8.0.0/gcc-8.0.0/./gcc/xgcc
-B/opt/devel/SCRATCH/tmp.Sbg1TmFqa7/gcc-8.0.0/gcc-8.0.0/./gcc/
-L/opt/devel/gnu/gcc/MINGW_NT/x86_6
On 10/11/2017 10:43 PM, Martin Sebor wrote:
Hi Vladimir,
On a hunch I backed out r253656. That let the Ada and Go bootstrap
complete. It looks like your fix for bug 82353 is triggering this
ICE.
Martin, thank you for informing me. I used the default bootstrap.
I've reverted LRA ch
Hi Vladimir,
On a hunch I backed out r253656. That let the Ada and Go bootstrap
complete. It looks like your fix for bug 82353 is triggering this
ICE.
Martin
On 10/11/2017 06:45 PM, Martin Sebor wrote:
I've been running into the following errors during the bootstrap
of the top of tru
I've been running into the following errors during the bootstrap
of the top of trunk on x86_64 with no local changes. They don't
seem to be triggered by other front ends. Before I open a new
bug, has anyone else noticed them and maybe already filed one?
(I don't see anything recent in Bugzilla
> From: Segher Boessenkool
>
> Ah. Is there a PR for it yet? Please open one, if not.
>
Yes, PR79150. I got carried away with the mailing and forgot about the PR,
sorry.
I have updated the PR thread with all of the things we've discussed in this
thread (and some more).
Let's continue this di
On Thu, Feb 23, 2017 at 10:43:36PM +, Matthew Fortune wrote:
> This is an ICE that will be reproducible on a primary target so is still
> appropriate to pursue in stage4 as far as I understand. I'm hoping to
> find time to work with Toma on this issue.
Ah. Is there a PR for i
gt; General... Patches need to go to gcc-patches@. You also should have
> your copyright assignment in order (I have no idea if you do; if you do,
> please ignore). Finally, trunk currently is in stage 4, this work will
> need to wait for stage 1 (a couple of months, something like that).
Hi Toma,
On Thu, Feb 23, 2017 at 04:27:26PM +, Toma Tabacu wrote:
> > This happens when you have inserted code ending in a jump on an edge.
> > This then will need updating of the CFG, and this code does not know
> > how to do that.
>
> Would the following be an appropriate solution ?
[ snip
Hi Segher,
Thank you for replying.
> From: Segher Boessenkool
>
> This happens when you have inserted code ending in a jump on an edge.
> This then will need updating of the CFG, and this code does not know
> how to do that.
>
Would the following be an appropriate solution ?
diff --git a/gcc/
Hello Toma,
On Thu, Feb 16, 2017 at 02:39:12PM +, Toma Tabacu wrote:
> It is caused by "gcc_assert (!JUMP_P (last))" in
> commit_one_edge_insertion (gcc/cfgrtl.c:2059-2077):
>
> if (returnjump_p (last))
> {
> /* ??? Remove all outgoing edges from BB and add one for EXIT.
>
Hello,
I have been looking into an ICE triggered by the gcc.dg/pr77834.c test for
MIPS targets (filed as PR 79150).
It turns out that it is unrelated to the fix for PR 77834, as the code from the
test case triggers the same ICE even without those changes.
It is caused by "gcc_assert (!J
On 01/06/2017 03:28 PM, Kyrill Tkachov wrote:
On 06/01/17 14:22, Toon Moene wrote:
On the attached (Fortran) source, the following version of gfortran
draws an ICE:
$ gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/6/lto-wrapper
Target
On 06/01/17 14:22, Toon Moene wrote:
On the attached (Fortran) source, the following version of gfortran draws an
ICE:
$ gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/6/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src
On the attached (Fortran) source, the following version of gfortran
draws an ICE:
$ gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/6/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='D
Hi, JBG
Yes, this is a known problem with Kelvin's recent patch.
- David
On Wed, Oct 19, 2016 at 12:59 PM, Jan-Benedict Glaw wrote:
> Hi!
>
> Building current GCC with current GCC (using config_list.mk) for
> --target=rs6000-ibm-aix5.3.0, I noticed a gcc_unreachable() during
> -fself-test,
>
Hi!
Building current GCC with current GCC (using config_list.mk) for
--target=rs6000-ibm-aix5.3.0, I noticed a gcc_unreachable() during -fself-test,
see build
http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=643401 :
[...]
/scratch/4/jbglaw/configlist/build/rs6000-ibm-aix5.3.0/build
> +gcc_assert (streamer_tree_cache_lookup (cache, node, NULL));
> + else
> +{
> + gcc_assert (cache->nodes.exists ());
> + /* Linear search... */
> + for (unsigned i = 0; !found && i < cache->nodes.length (); ++i)
> + if (cache->
ent types have already been
> > >> > handled
> > >> > +(and we thus don't need to recurse here). See PR lto/77458.
> > >> > */
> > >> > +[...]
>
> > >> So I very much like to go forward with this kind of chang
On Thu, Sep 29, 2016 at 4:48 PM, Thomas Schwinge
wrote:
> Hi Richard!
>
> On Mon, 19 Sep 2016 13:25:01 +0200, Richard Biener
> wrote:
>> On Mon, Sep 19, 2016 at 1:19 PM, Thomas Schwinge
>> wrote:
>> > On Mon, 19 Sep 2016 10:18:35 +0200, Richard Biener
>> > wrote:
>> >> On Fri, Sep 16, 2016 at
Hi Richard!
On Mon, 19 Sep 2016 13:25:01 +0200, Richard Biener
wrote:
> On Mon, Sep 19, 2016 at 1:19 PM, Thomas Schwinge
> wrote:
> > On Mon, 19 Sep 2016 10:18:35 +0200, Richard Biener
> > wrote:
> >> On Fri, Sep 16, 2016 at 3:32 PM, Thomas Schwinge
> >> wrote:
> >> > --- gcc/tree-streamer.c
> +[...]
> >> So I very much like to go forward with this kind of change as well
> > [patch]
> Ok with [changes]
Like this? (I'll then continue to replicate this for other tree codes.)
commit b304f88f7226d93c8e13584a916cc713a989a635
Author: Thomas Schwinge
Date: Wed
On Mon, 19 Sep 2016, Thomas Schwinge wrote:
> > The question is whether such a complex type could be a global tree which I
> > don't think it could.
>
> Specifically, my question was whether for every complex type that is part
> of the global trees, it holds that the complex type's component type
On Mon, Sep 19, 2016 at 1:19 PM, Thomas Schwinge
wrote:
> Hi!
>
> On Mon, 19 Sep 2016 10:18:35 +0200, Richard Biener
> wrote:
>> On Fri, Sep 16, 2016 at 3:32 PM, Thomas Schwinge
>> wrote:
>> > --- gcc/tree-core.h
>> > +++ gcc/tree-core.h
>> > @@ -553,20 +553,6 @@ enum tree_index {
>> >TI_BO
Hi!
On Mon, 19 Sep 2016 10:18:35 +0200, Richard Biener
wrote:
> On Fri, Sep 16, 2016 at 3:32 PM, Thomas Schwinge
> wrote:
> > --- gcc/tree-core.h
> > +++ gcc/tree-core.h
> > @@ -553,20 +553,6 @@ enum tree_index {
> >TI_BOOLEAN_FALSE,
> >TI_BOOLEAN_TRUE,
> >
> > - TI_COMPLEX_INTEGER_TYP
Hi!
On Mon, 19 Sep 2016 10:12:48 +0200, Richard Biener
wrote:
> On Fri, Sep 16, 2016 at 7:07 PM, Joseph Myers wrote:
> > On Fri, 16 Sep 2016, Thomas Schwinge wrote:
> >
> >> That's what I was afraid of: for example, I can't tell if it holds for
> >> all GCC configurations (back ends), that comp
component type -- which in "sane" configurations/ISAs would always match
> one of the already existing ones...
>
> Or, of course, we need to change the tree cache ID format, so that
> they're not allocated using a monotonically increasing step-one counter
>
On Fri, Sep 16, 2016 at 7:07 PM, Joseph Myers wrote:
> On Fri, 16 Sep 2016, Thomas Schwinge wrote:
>
>> That's what I was afraid of: for example, I can't tell if it holds for
>> all GCC configurations (back ends), that complex types' component types
>> will always match one of the already existing
On Fri, 16 Sep 2016, Richard Biener wrote:
> Humm ... do we anywhere compare to those global trees by pointer equivalence?
> If so then it breaks LTO support for those types.
The C front end compares main variants to those types for handling usual
arithmetic conversions (and more generally for t
On Fri, 16 Sep 2016, Thomas Schwinge wrote:
> That's what I was afraid of: for example, I can't tell if it holds for
> all GCC configurations (back ends), that complex types' component types
> will always match one of the already existing global trees? (I can
Well, a component type could certain
a monotonically increasing step-one counter
-- explicitly allowing the cc1/lto1s (etc.) to differ? Conceptually a
bit like (but differently) that we allow the mode table to differ,
streamer_mode_table.
> and it might need re-ordering of a few globals.
> Can you try if all hell breaks lose if
1 - 100 of 488 matches
Mail list logo
