Re: Using nonzero_bits() in insn conditions?

[Jeff Law via Gcc]

On 3/13/25 5:39 AM, Georg-Johann Lay via Gcc wrote:

There are situations where knowledge about which bits
of a value are (not) set can be used for optimization.
For example in an insn combine pattern like:

(define_insn_and_split ""
   [(set (match_operand:QI 0 "register_operand"   "=d")
     (ior:QI (ashift:QI (match_operand:QI 1 "register_operand" "r")
    (match_operand:QI 2 "const_0_to_7_operand" 
"n"))

     (match_operand:QI 3 "register_operand" "0")))]
   "optimize
    && !reload_completed
    && nonzero_bits (operands[1], VOIDmode) == 1"
...

This pattern is only correct when operands[1] is 0 or 1.

While such patterns seem to work, it's all quite wonky,
in particular since nonzero_bits() may forget about known
properties in later passes.
While it works most of the time, it's fundamentally wrong to have a 
pattern where the conditional is dependent on state that changes based 
on pass specific data, nearby context, etc.




For the use case I have in mind, it is in order when the
pattern works until split1 which would transform it into
something else (and without nonzero_bits() in the insn
condition, asserting that the existence of the pattern
certifies the bit condition).
It's still the wrong thing to do.  You'll get away with it for a while, 
but one day it'll break.


We have similar problems in the RISC-V world where we would like to be 
able to match certain patterns based on known ranges of an operand.  The 
most common case would be bset/bclr/binv on an SImode object on rv64 
where the bit twiddled is variable.  In particular we need to know the 
bit position is not bit 31.


There's no way to really describe that in an insn's condition because 
range information like that isn't available in RTL and something like 
nonzero bits is pass specific.


As a result we're limited in our ability to use the bset/bclr/binv 
instructions.


Jeff

GSoC 2025 Rust Front-End: Name Resolution Pass Rewrite

[Christina / via Gcc]

Hello! I'm interested in the idea of "Name Resolution Pass Rewrite".
I took the compiler course and implemented a ALGOL-like language compiler.
I have huge passion about compiler and would love to contribute to GCC
community.

I looked up some resources on this topic. Name resolution · Rust-GCC/gccrs
Wiki · GitHub ,
gccrs/gcc/rust/resolve/rust-name-resolver.cc
at master · Rust-GCC/gccrs · GitHub


I am familiar with both trie tree and lexically scoped symbol table.
Are there any specific areas I should focus on? Any issues I could start
looking into for better context?
Also, I appreciate it if you tell me what features of old name-resolver are
expected to implement for this project.

best regards,
Jie Wu

gcc-15-20250316 is now available

[GCC Administrator via Gcc]

Snapshot gcc-15-20250316 is now available on
  https://gcc.gnu.org/pub/gcc/snapshots/15-20250316/
and on various mirrors, see https://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 15 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch master 
revision b2b139ddee763dd5fd71a3368e5e66399e3c52a3

You'll find:

 gcc-15-20250316.tar.xz   Complete GCC

  SHA256=0742ab7e92e2a3cd29f2cc7b20f81be14debabb873ffafb7fde272b9cd3e073a
  SHA1=550103879cff828e8f4d04a042c5e6f195017374

Diffs from 15-20250309 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-15
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

Re: gcc.gnu.org performance issues?

[Harald Anlauf via Gcc]

Hello all,

Am 15.08.24 um 21:31 schrieb Mark Wielaard:

Hi,

On Thu, Aug 15, 2024 at 10:31:12AM -0700, H.J. Lu via Gcc wrote:

On Thu, Aug 15, 2024 at 10:17 AM Harald Anlauf via Gcc  wrote:

is it only me who is recently experiencing intermittent
but extreme slowness of "git pull"?

[...]

This was caused by agressive spiders that ignore robots.txt and
queried bugzilla over and over again. We have apache modqos and
fail2ban to capture so such spiders get banned after a short time,
till they get unbanned again and the whole circus starts over :{ We
should probably be more agressive, but we don't want to block regular
really active users or multiple users behind the same outgoing NAT ip.

The 16 most frequent fail2banners, those that just come back every
time after the ban times out, have been added to the permanent block
list. Hopefully that helps.

We have isolated the services so no service can overload the system
completely. But it can still slow down some others.


since I am experiencing extreme (temporary) performance problems
again with a recently increased frequency and only during evening
hours in Europe, I am asking if this is still the same cause.

Today I've been waiting for hours for a git pull to succeed (i.e.
to not timeout), not to mention a push.

Is there some throttling also affecting me?  Or am I doing
anything wrong?

Thanks,
Harald



Cheers,

Mark

Re: gcc.gnu.org performance issues?

[Harald Anlauf via Gcc]

Am 16.03.25 um 22:37 schrieb Jonathan Wakely via Gcc:

On Sun, 16 Mar 2025 at 21:30, Harald Anlauf via Gcc  wrote:

since I am experiencing extreme (temporary) performance problems
again with a recently increased frequency and only during evening
hours in Europe, I am asking if this is still the same cause.

Today I've been waiting for hours for a git pull to succeed (i.e.
to not timeout), not to mention a push.


Bugzilla is slow again, but waiting hours for simple Git operations is
not normal. If you're not doing anything crazy like pushing thousands
of commits to a new branch, it should not take hours. (For pulls from
trunk or release branches, you can always use the
https://github.com/gcc-mirror/gcc repo mirror, which benefits for
github's CDN and removes load from the gcc.gnu.org server).


I am not aware of doing anything crazy: git pull / rebase / push
for the present case, and a single, small commit.


Do you use connection multiplexing with ssh, using the -O option or
the ControlMaster ssh_config setting? If the connection hangs, then
git operations over ssh will not complete. When that happens to me I
do 'ssh -O exit gcc.gnu.org' to close the stalled multiplexed
connection so that a new one can be created.


I have never tried any complex setups besides simple ssh tunnels
with git in the past, so believe this does not apply.

Doing even a simple ssh -Tvv to gcc.gnu.org takes a very long time
when trying in parallel to the git command.  And empirically this
seems to happen only during a certain time of the day.

Regarding your comment on using github for fetching (and keeping
gcc.gnu.org for push), the gcc website does not give a recommendation
on how to use that in practice.  Could we update
  https://gcc.gnu.org/about.html#git
and/or
  https://gcc.gnu.org/gitwrite.html
with best practices?

Thanks,
Harald

Re: gcc.gnu.org performance issues?

[Mark Wielaard]

Hi Harald,

On Sun, Mar 16, 2025 at 10:57:08PM +0100, Harald Anlauf wrote:
> I have never tried any complex setups besides simple ssh tunnels
> with git in the past, so believe this does not apply.
> 
> Doing even a simple ssh -Tvv to gcc.gnu.org takes a very long time
> when trying in parallel to the git command.  And empirically this
> seems to happen only during a certain time of the day.

That is really odd. If you are using ssh then there shouldn't be any
throtteling and you shouldn't really be affected by current http based
ddos. It might be your local network?

I just did a clean clone of the whole gcc.git which took ~8 minutes
over http and ~5 minutes over ssh. So cloning/pulling over https is
certainly slower, but you should get reasonable speeds over https.

> Regarding your comment on using github for fetching (and keeping
> gcc.gnu.org for push), the gcc website does not give a recommendation
> on how to use that in practice.  Could we update
>   https://gcc.gnu.org/about.html#git
> and/or
>   https://gcc.gnu.org/gitwrite.html
> with best practices?

I don't think anybody wants to recommend github for these things.
https://giveupgithub.com Also those aren't under our control. If you
really need a mirror then try the ones at https://forge.sourceware.org/
or https://git.sr.ht/~sourceware/ which we keep up to date.

Cheers,

Mark

Re: gcc.gnu.org performance issues?

[Harald Anlauf via Gcc]

Am 16.03.25 um 22:59 schrieb Mark Wielaard:

There is currently a botnet attacking lots of http git endpoints on
various systems including sourceware. We are trying to coordinate a
bit, but given that it seems a fairly large botnet with lots of ips
(which often only do one or two hits per day), it is hard to get a
good defense in place. We believe we have something now that at least
makes sure people can get at git (and bugzilla), although maybe a bit
slower than usual.


Slow is OK for me, given these conditions...


Today I've been waiting for hours for a git pull to succeed (i.e.
to not timeout), not to mention a push.


Hours however is really odd. Certainly for pushes which should go over
ssh and aren't throttled.


Is there some throttling also affecting me?  Or am I doing
anything wrong?


Things can be slow with the botnet attacks going on, but shouldn't be
that slow. Feel free to reach out to overse...@sourceware.org or join
#overseers on irc.libera.chat if you need more help.


I just tried again and pull/push went through fine. :-)

If I get stuck again next time, I'll try your suggestions and ask
off-list for help.

Thanks,
Harald


Cheers,

Mark

Re: gcc.gnu.org performance issues?

[Jonathan Wakely via Gcc]

On Sun, 16 Mar 2025 at 21:30, Harald Anlauf via Gcc  wrote:
> since I am experiencing extreme (temporary) performance problems
> again with a recently increased frequency and only during evening
> hours in Europe, I am asking if this is still the same cause.
>
> Today I've been waiting for hours for a git pull to succeed (i.e.
> to not timeout), not to mention a push.

Bugzilla is slow again, but waiting hours for simple Git operations is
not normal. If you're not doing anything crazy like pushing thousands
of commits to a new branch, it should not take hours. (For pulls from
trunk or release branches, you can always use the
https://github.com/gcc-mirror/gcc repo mirror, which benefits for
github's CDN and removes load from the gcc.gnu.org server).

Do you use connection multiplexing with ssh, using the -O option or
the ControlMaster ssh_config setting? If the connection hangs, then
git operations over ssh will not complete. When that happens to me I
do 'ssh -O exit gcc.gnu.org' to close the stalled multiplexed
connection so that a new one can be created.