Re: Setting up editors for the GNU/GCC coding style?

[Marc Poulhies via Gcc]

Iannetta Paul  writes:

Hi Paul :)

> For the indexing, I produce a compile_commands.json file (recording only the
> files compiled by `make all', this includes auto-generated files such as
> config.h, and the insn-something.{h,c} files) with the help of
> https://github.com/gicmo/cdcc, this file is then picked up by the language
> server, which then provides nice autocompletion features.

I'm using the same process, but with the 'bear' command:

  https://github.com/rizsotto/Bear

I know other here are also using it.

As creating the json file can be long, I usually do a non-parallel build
(had issues with parallel jobs) when I'm not coding.

> About configuring recent editors to follow the GNU coding style, I don't 
> really
> know but it should always be possible to register a hook that will run 
> `indent`
> when the file is saved.

There is a clang-format config file in contrib that one can symlink in
the root dir as .clang-format. I hope/guess tools like CLion can pick it
and use it? At least this can be used to indent using clang-format tools
and derivatives (like git-clang-format). In the GCC Rust project, we are
using it (but judging by Jakub's last review for Philip's patch, the
config is maybe not exhaustive, or our setup is not correct).

Marc

Re: Setting up editors for the GNU/GCC coding style?

[Thomas Schwinge]

Hi!

On 2022-07-29T09:36:41+0200, Marc Poulhies via Gcc  wrote:
> Iannetta Paul  writes:
>> About configuring recent editors to follow the GNU coding style, I don't 
>> really
>> know but it should always be possible to register a hook that will run 
>> `indent`
>> when the file is saved.
>
> There is a clang-format config file in contrib that one can symlink in
> the root dir as .clang-format. I hope/guess tools like CLion can pick it
> and use it? At least this can be used to indent using clang-format tools
> and derivatives (like git-clang-format). In the GCC Rust project, we are
> using it (but judging by Jakub's last review for Philip's patch, the
> config is maybe not exhaustive, or our setup is not correct).

Simple answer there: these files are in 'gcc/config/' etc.,
but 'clang-format' is restricted to 'gcc/rust/' only (both in
'.github/workflows/clang-format.yml' and 'CONTRIBUTING.md':
"Running `clang-format` locally").

Unless everyone uses it, using 'clang-format' everywhere is too noisy;
it has a very strict (in my opinion: restrictive) understanding of
"proper" format.  ;-)


Grüße
 Thomas
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955

spaceship_replacement cannot see through simplified set of FP conditionals

[Aldy Hernandez via Gcc]

Hi.

With my upcoming patch enabling floating point VRP,
g++.dg/opt/pr94589-2.C is failing:

https://gcc.gnu.org/pipermail/gcc-patches/2022-July/598788.html

The problem is that phiopt no longer sees the following snippet,
because we have folded away the final conditional as true:

bool f5 (double i, double j)
{
  signed char __v$_M_value;
  signed char c$_M_value;
  bool D.8519;
  struct partial_ordering __v;
  struct partial_ordering c;
  unsigned int _11;
  bool _16;

   :
  if (i_2(D) != j_4(D))
goto ; [INV]
  else
goto ; [INV]

   :
  if (i_2(D) >= j_4(D))
goto ; [INV]
  else
goto ; [INV]

   :
  if (i_2(D) > j_4(D))
goto ; [INV]
  else
goto ; [INV]

   :

   :
  # c$_M_value_3 = PHI <-1(3), 0(2), 2(5), 1(4)>
  _11 = (unsigned int) c$_M_value_3;
  _16 = _11 <= 1;
  return _16;
}

This means that spaceship_replacement()  now sees one less argument to the PHI:

   :
  if (i_2(D) != j_4(D))
goto ; [INV]
  else
goto ; [INV]

   :
  if (i_2(D) >= j_4(D))
goto ; [INV]
  else
goto ; [INV]

   :

   :
  # c$_M_value_3 = PHI <-1(3), 0(2), 1(4)>

...and we bail because we are expecting 4 arguments:

  if (EDGE_COUNT (phi_bb->preds) != 4)
return false;

Could someone give me a hand here? Can spaceship_replacement easily be
adapted to handle this case, or should we be simplifying this
elsewhere?

Thanks.
Aldy

Re: spaceship_replacement cannot see through simplified set of FP conditionals

[Jakub Jelinek via Gcc]

On Fri, Jul 29, 2022 at 01:40:12PM +0200, Aldy Hernandez wrote:
> With my upcoming patch enabling floating point VRP,
> g++.dg/opt/pr94589-2.C is failing:
> 
> https://gcc.gnu.org/pipermail/gcc-patches/2022-July/598788.html
> 
> The problem is that phiopt no longer sees the following snippet,
> because we have folded away the final conditional as true:

> Could someone give me a hand here? Can spaceship_replacement easily be
> adapted to handle this case, or should we be simplifying this
> elsewhere?

Leave it to me, once you commit, file a PR and I'll work on it.

Jakub

Re: spaceship_replacement cannot see through simplified set of FP conditionals

[Aldy Hernandez via Gcc]

Swt!

Would you like me to XFAIL the test or leave it as a failure?

Thanks.
Aldy

On Fri, Jul 29, 2022 at 1:50 PM Jakub Jelinek  wrote:
>
> On Fri, Jul 29, 2022 at 01:40:12PM +0200, Aldy Hernandez wrote:
> > With my upcoming patch enabling floating point VRP,
> > g++.dg/opt/pr94589-2.C is failing:
> >
> > https://gcc.gnu.org/pipermail/gcc-patches/2022-July/598788.html
> >
> > The problem is that phiopt no longer sees the following snippet,
> > because we have folded away the final conditional as true:
>
> > Could someone give me a hand here? Can spaceship_replacement easily be
> > adapted to handle this case, or should we be simplifying this
> > elsewhere?
>
> Leave it to me, once you commit, file a PR and I'll work on it.
>
> Jakub
>

Re: spaceship_replacement cannot see through simplified set of FP conditionals

[Jakub Jelinek via Gcc]

On Fri, Jul 29, 2022 at 01:51:00PM +0200, Aldy Hernandez wrote:
> Swt!
> 
> Would you like me to XFAIL the test or leave it as a failure?

Either is fine.

Jakub

Re: Setting up editors for the GNU/GCC coding style?

[Richard Earnshaw via Gcc]

On 28/07/2022 22:43, Iannetta Paul wrote:

About configuring recent editors to follow the GNU coding style, I don't 
really know but it should always be possible to register a hook that 
will run `indent` when the file is saved.


I don't think that's a good idea.  It will result in quite a lot of 
minor changes that will just make diffs confused.  We do have a style, 
but not everything is exactly as GNU indent would lay it out (plus GNU 
indent says quite clearly that it can't handle C++).


R.

Re: [PATCH v2] powerpc: add documentation for HWCAPs

[Michael Ellerman]

On Fri, 15 Jul 2022 11:26:36 +1000, Nicholas Piggin wrote:
> Take the arm64 HWCAP documentation file and adjust it for powerpc.
> 
> 

Applied to powerpc/next.

[1/1] powerpc: add documentation for HWCAPs
  https://git.kernel.org/powerpc/c/ef1911c6d26678b0e91fea33f076e98925997f0c

cheers

GCC warns on defined behavior with Wrestrict?

[Tim Lange]

Hi everyone,

while testing a new buffer overlap and restrict checker in the analyzer,
it emitted a warning inside coreutils. During the discussion [0], Paul
Eggert posted a link to the current draft of the next C standard [1]
with new examples for the definition of 'restrict'. Especially example 3
in 6.7.3.1 is interesting:

  void h(int n, int * restrict p, int * restrict q, int * restrict r)
  {
int i;
for (i = 0; i < n; i++)
  p[i] = q[i] + r[i];
  }

The draft says that a call h(100, a, b, b) is *defined* behavior because
'b' is never modified inside the method. That brings up the question how
GCC should handle this. At the moment, Wrestrict (and my new
Wanalyzer-restrict) warns on defined behavior:

  /path/to/main.c:70:13: warning: passing argument 3 to ‘restrict’-qualified 
parameter aliases with argument 4 [-Wrestrict]
 70 |   h(100, a, b, b);
| ^  ~

But finding out that 'q' and 'r' are never modified needs a pass over
the callee. Further, when the callee implementation isn't available at
the point Wrestrict runs, we couldn't emit a warning at all if we don't
want any false positive.

I thought maybe a tradeoff would be to keep warning without checking for
writes on parameters in the callee but additionally issue a fix-it hint
that if the memory location the parameter points to is never written, to
add the points-to const type qualifier.
The addition of the const qualifier simplifies deducing that the
memory location the parameter point to is never written for Wrestrict
and already silences the warning.

What do you think?

- Tim

[0] https://lists.gnu.org/archive/html/bug-gnulib/2022-07/msg00066.html
[1] https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2912

Re: Regarding gnu.org

[Mark Smith via Gcc]

Hi,

So, what do you think?

Regards,
Mark Smith

[image: Mailtrack]

Sender
notified by
Mailtrack

07/29/22,
09:10:46 PM

FW: Redesigning the GCC website

[Vibby A. Bibby via Gcc]

Hello!
Nothing contained in this email is meant as an attack. The GCC compiler is
a wonderful piece of software and by God I'll do anything to avoid writing
ASM code.
However, the website for the GCC is... shall we say... "bad". It looks
outdated compared to the GNU project's homepage. Unfortunately, a few of my
friends seem to think so too, and I would like to lend a hand in
redesigning it. A piece of software as fine as GCC deserves a website to
reflect the quality of the software! Let me know if you're interested and
I'll get to work :)

~ VideoToblinski

Re: FW: Redesigning the GCC website

[Dave Blanchard]

> However, the website for the GCC is... shall we say... "bad". 

No, we shall not say that. We shall in fact loudly compliment the GCC web site 
as being "very well designed", because it serves exactly the purpose it's meant 
to serve with minimal distraction, while loading quickly on my slow connection.

> It looks outdated compared to the GNU project's homepage. 

"Outdated" is a high compliment these days, when everything around us is 
turning into absolute dogshit. Modernism is a mental disease.

> Unfortunately, a few of my friends seem to think so too, and I would like to 
> lend a hand in redesigning it. 

We're just fine, thanks.

-- 
Dave Blanchard 

gcc-11-20220729 is now available

[GCC Administrator via Gcc]

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

This snapshot has been generated from the GCC 11 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch 
releases/gcc-11 revision ba29e3537f3ab9b6f6fd212f3e3a48c946bf0897

You'll find:

 gcc-11-20220729.tar.xz   Complete GCC

  SHA256=68f58a0a8b691e5fb4446af1d085c71fe64a0faef06d2d8a75138f9b7c158f26
  SHA1=2f43efe815b86e91510674344f36cd534ac391e7

Diffs from 11-20220722 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-11
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.

[no subject]

[waqar ahmad via Gcc]

I want to apply for security visa for football match in Qatar