> The problem shows in loop-doloop.c when I introduce a loop end pattern
> that replaces the first jump instruction (JUMP_INSN 15) with a pattern
> that clobbers CC reg. However, the DF doesn't look like it works as
> the doloop step cannot find the CC reg alive. Please see
> loop-doloop.c:766. Hen
Solaris 11.3 has reached the end of its support live, as can be seen in
the following overview based on
https://www.oracle.com/us/support/library/lifetime-support-hardware-301321.pdf,
p.40:
Release GA Date Last Premier Extended GCC
Update Support Support Obso
It looks like that. The df_analyze_loop is only looking at the loop
BBs, and it is not clear for me if df_analyze_loop is required to have
all the df_live_outs correctly computed or not. Do you know if it is
true?
If the df_analyze_loop is not supposed to compute all the df_live_outs
correctly, th
The release of GNU MPFR 4.2.0 ("fondue savoyarde") is imminent.
Please help to make this release as good as possible by downloading
and testing this release candidate:
https://www.mpfr.org/mpfr-4.2.0/mpfr-4.2.0-rc1.tar.xz
https://www.mpfr.org/mpfr-4.2.0/mpfr-4.2.0-rc1.tar.bz2
https://www.mpfr.org/
I think Nathan might've been asking not only about what currently
happens, but what we think should happen?
On Mon, Dec 12, 2022 at 7:11 PM chuanqi.xcq wrote:
>
> Hi Nathan,
>
> > 1) Are these flags silently ignored, if no module output is to be
> > generated? Or is some kind of diagnostic gene
I'm updating an old C language program and looked to download the man
page for gcc. I was astonished by:
1) I could not find any place to download the man page. I lost my
internet connect and I have not man page :(
2) How over pervasive gcc has become. It appears to be everything for
ever
On Tue, 2022-12-13 at 11:28 -0500, Jim Anderson via Gcc wrote:
> 1) I could not find any place to download the man page. I lost my
> internet connect and I have not man page :(
You didn't say what platform you're working on, nor how you obtained
the GCC that you are using, but recall that the GCC
UPDATE:
The df_analyze_loop is calling the df_set_blocks. Thus, the analysis
behaves as if the function only contains those blocks and any edges
that occur directly between the blocks in the set (see df-core.cc).
This said, the loop-doloop behaves faulty at loop-doloop.cc:772 as the
df_get_lives_ou
> Am 13.12.2022 um 17:54 schrieb Claudiu Zissulescu Ianculescu via Gcc
> :
>
> UPDATE:
> The df_analyze_loop is calling the df_set_blocks. Thus, the analysis
> behaves as if the function only contains those blocks and any edges
> that occur directly between the blocks in the set (see df-core.
>
> Maybe you want to iterate over the loops exit edges and include their
> destination block instead?
>
This is better approach, let me try it and I will be back to you.
Thanks,
Claudiu
On Tue, 2022-12-13 at 11:35 -0600, Dave Blanchard wrote:
> *angry, grumpy, pissed off, GNU-hating distro maintainer enters the
> chat*
> nobody on the mailing list has any idea what it could possibly be I
> guess, since nobody responded to my email.
Yes, I can't imagine any other reason no one has
Hi!
For the following program:
$ cat buf.c
#include
int main(void)
{
char *p, buf[5];
p = buf + 6;
printf("%p\n", p);
}
There are no warnings in gcc, as I would expect:
$ gcc -Wall -Wextra buf.c -O0
Clang does warn, however:
$ clang -W
Since my response did not get posted (maybe one of the words wasn't allowed? or
because I attached binaries?) here it is again:
Begin forwarded message:
Date: Tue, 13 Dec 2022 11:35:39 -0600
From: Dave Blanchard
To: gcc@gcc.gnu.org
Cc: p...@mad-scientist.net
Subject: Re: Good grief Charlie Bro
On 12/13/22 20:08, Alejandro Colomar wrote:
Hi!
For the following program:
$ cat buf.c
#include
int main(void)
{
char *p, buf[5];
p = buf + 6;
printf("%p\n", p);
}
There are no warnings in gcc, as I would expect:
I just re-read my te
On Tue, Dec 13, 2022 at 11:16 AM Alejandro Colomar via Gcc
wrote:
>
>
>
> On 12/13/22 20:08, Alejandro Colomar wrote:
> > Hi!
> >
> > For the following program:
> >
> >
> > $ cat buf.c
> > #include
> >
> > int main(void)
> > {
> > char *p, buf[5];
> >
> > p =
> On Dec 13, 2022, at 2:09 PM, Dave Blanchard wrote:
>
> Since my response did not get posted (maybe one of the words wasn't allowed?
> or because I attached binaries?) here it is again:
> ...
I'm puzzled. What is your purpose? What result do you expect from your
messages? What action wo
On Tue, 2022-12-13 at 20:15 +0100, Alejandro Colomar via Gcc wrote:
>
>
> On 12/13/22 20:08, Alejandro Colomar wrote:
> > Hi!
> >
> > For the following program:
> >
> >
> > $ cat buf.c
> > #include
> >
> > int main(void)
> > {
> > char *p, buf[5];
> >
> >
> On Dec 13, 2022, at 2:08 PM, Alejandro Colomar via Gcc
> wrote:
>
> Hi!
>
> For the following program:
>
>
>$ cat buf.c
>#include
>
>int main(void)
>{
>char *p, buf[5];
>
>p = buf + 6;
>printf("%p\n", p);
>}
>
>
> There are no warnings in
Hi Paul,
On 12/13/22 20:22, Paul Koning wrote:
On Dec 13, 2022, at 2:08 PM, Alejandro Colomar via Gcc wrote:
Hi!
For the following program:
$ cat buf.c
#include
int main(void)
{
char *p, buf[5];
p = buf + 6;
printf("%p\n", p);
}
There are
On Tue, 13 Dec 2022 14:20:39 -0500
Paul Koning wrote:
> I'm puzzled. What is your purpose? What result do you expect from your
> messages? What action would you like to see?
GCC is a "mailing list." This is a recent innovation in which people post
comments about subjects they are interested
On Tue, 13 Dec 2022, 19:28 Dave Blanchard, wrote:
>
>
> Hell, I haven't even got started complaining about anything. Should we get
> into The Entire Linux Ecosystem, Led By GNU's recent bizarre decision to
> start incrementing major version numbers seemingly every 3 months? It's
> almost like you
On Tue, 13 Dec 2022, 19:23 Paul Koning via Gcc, wrote:
>
>
>
> > On Dec 13, 2022, at 2:08 PM, Alejandro Colomar via Gcc
> > wrote:
> >
> > Hi!
> >
> > For the following program:
> >
> >
> >$ cat buf.c
> >#include
> >
> >int main(void)
> >{
> >char *p, buf[5];
> >
> >
22 matches
Mail list logo
