Re: [PATCH] Various pages: SYNOPSIS: Use VLA syntax in function parameters

Am Samstag, den 12.11.2022, 01:09 + schrieb Joseph Myers: > On Fri, 11 Nov 2022, Martin Uecker via Gcc wrote: > > > > Even a compiler extension requires the level of detail of specification > > > that you get with a WG14 paper (and the level of work on finding bugs in > > > that specificatio

Re: How can Autoconf help with the transition to stricter compilation defaults?

> On 12 Nov 2022, at 00:53, Paul Eggert wrote: > > On 2022-11-11 15:25, Sam James wrote: >> That's not a judgement on whether the changes will ultimately remain in >> autoconf, I'm just >> hesitant to allow a discussion I've kicked off to derail something that we >> were planning >> on doing

Re: How can Autoconf help with the transition to stricter compilation defaults?

On Fri, 11 Nov 2022, Zack Weinberg via Gcc wrote: > These are also a trip hazard for novices, and the only way to turn them > off is with -std=cXX, which also turns another trip hazard (trigraphs) > *on*… so yeah, anything you can do to help speed up their removal, I > think it’d be worthwhile. A

Re: How can Autoconf help with the transition to stricter compilation defaults?

> On 12 Nov 2022, at 03:40, Zack Weinberg wrote: > > Florian Weimer writes: >> based on a limited attempt to get this fixed about three years >> ago, I expect that many of the problematic packages have not had their >> configure scripts regenerated using autoconf for a decade or more. This >>

Re: How can Autoconf help with the transition to stricter compilation defaults?

Florian Weimer writes: > based on a limited attempt to get this fixed about three years > ago, I expect that many of the problematic packages have not had their > configure scripts regenerated using autoconf for a decade or more. This > means that as an autoconf maintainer, you unfortunately won'

Re: How can Autoconf help with the transition to stricter compilation defaults?

Rich Felker writes: > On Thu, Nov 10, 2022 at 12:16:20PM -0500, Zack Weinberg wrote: >> The biggest remaining (potential) problem, that I’m aware of, is that >> AC_CHECK_FUNC unconditionally declares the function we’re probing for >> as ‘char NAME (void)’, and asks the compiler to call it with no

Re: How can Autoconf help with the transition to stricter compilation defaults?

Nick Bowler writes: > My gut feeling is that Autoconf should just determine the necessary > options to get compatible behaviour out of these modern compilers, at > least for the purpose of running configure tests. For example, Autoconf > should probably build the AC_CHECK_FUNC programs using gcc'

Re: [PATCH] Various pages: SYNOPSIS: Use VLA syntax in function parameters

On Fri, 11 Nov 2022, Martin Uecker via Gcc wrote: > > Even a compiler extension requires the level of detail of specification > > that you get with a WG14 paper (and the level of work on finding bugs in > > that specification), to avoid the problem we've had before with too many > > features ad

Re: How can Autoconf help with the transition to stricter compilation defaults?

On 2022-11-11 15:25, Sam James wrote: That's not a judgement on whether the changes will ultimately remain in autoconf, I'm just hesitant to allow a discussion I've kicked off to derail something that we were planning on doing anyway. What do you think? I'm hesitant to do that partly because

Re: How can Autoconf help with the transition to stricter compilation defaults?

> On 11 Nov 2022, at 03:33, Zack Weinberg wrote: > > On Thu, Nov 10, 2022, at 10:08 PM, Sam James wrote: >>> On 10 Nov 2022, at 21:10, Michael Orlitzky wrote: >>> While everyone else is discussing big ideas, it would be helpful for me >>> personally if autoconf just made a release with the lat

Re: Announcement: Porting the Docs to Sphinx - 9. November 2022

On Mon, 2022-10-17 at 15:28 +0200, Martin Liška wrote: > Hello. > > Based on the very positive feedback I was given at the Cauldron > Sphinx Documentation BoF, > I'm planning migrating the documentation on 9th November. There are > still some minor comments > from Sandra when it comes to the PDF o

gcc-11-20221111 is now available

Snapshot gcc-11-2022 is now available on https://gcc.gnu.org/pub/gcc/snapshots/11-2022/ 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

Re: Announcement: Porting the Docs to Sphinx - tomorrow

On 11/11/22 13:52, Gerald Pfeifer wrote: On Tue, 8 Nov 2022, Martin Liška wrote: After the migration, people should be able to build (and install) GCC even if they miss Sphinx (similar happens now if you miss makeinfo). My nightly *install* (not build) on amd64-unknown-freebsd12.2 broke (from

Re: Announcement: Porting the Docs to Sphinx - tomorrow

On Tue, 8 Nov 2022, Martin Liška wrote: > After the migration, people should be able to build (and install) GCC > even if they miss Sphinx (similar happens now if you miss makeinfo). My nightly *install* (not build) on amd64-unknown-freebsd12.2 broke (from what I can tell due to this - it's bee

Re: [PATCH] Various pages: SYNOPSIS: Use VLA syntax in function parameters

Am Donnerstag, den 10.11.2022, 23:19 + schrieb Joseph Myers: > On Thu, 10 Nov 2022, Martin Uecker via Gcc wrote: > > > One problem with WG14 papers is that people put in too much, > > because the overhead is so high and the standard is not updated > > very often. It would be better to build s

Re: Different outputs in Gimple pass dump generated by two different architectures

On Fri, Nov 11, 2022 at 8:39 AM Andrew Pinski wrote: > > On Fri, Nov 11, 2022 at 12:57 AM Marc Glisse via Gcc wrote: > > > > On Thu, 10 Nov 2022, Kevin Lee wrote: > > > What would be causing the difference? Is this intended? Link > > > for details. Thank you! >

Re: why does gccgit require pthread?

On Fri, 11 Nov 2022 at 17:16, Jonathan Wakely wrote: > > On Mon, 7 Nov 2022 at 13:51, Jonathan Wakely wrote: > > > > On Mon, 7 Nov 2022 at 13:33, LIU Hao wrote: > > > > > > 在 2022-11-07 20:57, Jonathan Wakely 写道: > > > > It would be a lot nicer if playback::context met the C++ Lockable > > > > requ

Re: why does gccgit require pthread?

On Mon, 7 Nov 2022 at 13:51, Jonathan Wakely wrote: > > On Mon, 7 Nov 2022 at 13:33, LIU Hao wrote: > > > > 在 2022-11-07 20:57, Jonathan Wakely 写道: > > > It would be a lot nicer if playback::context met the C++ Lockable > > > requirements, and playback::context::compile () could just take a > > > s

Re: Different outputs in Gimple pass dump generated by two different architectures

On Fri, Nov 11, 2022 at 12:57 AM Marc Glisse via Gcc wrote: > > On Thu, 10 Nov 2022, Kevin Lee wrote: > > > While looking at the failure for gcc.dg/uninit-pred-9_b.c, I observed that > > x86-64 and risc-v has a different output for the gimple pass since > > r12-4790-g4b3a325f07acebf4 > >

Issues with Sphinx

Can we just revert back to texinfo? Sphinx requires manual page splitting which is a downgrade from texinfo. Stable URLs and links was something which we pushed for fixes for texinfo too. And many other issues with sphinx which makes it better if we revert back to texinfo until those are fixed incl

Re: How can Autoconf help with the transition to stricter compilation defaults?

On Thu, Nov 10, 2022 at 4:05 PM Paul Eggert wrote: > > On 2022-11-10 10:19, Aaron Ballman wrote: > > In terms of the Clang side of things, I don't think we've formed any > > sort of official stance on how to handle that yet. It's UB (you can > > declare the C standard library interface without UB

Re: Handling of large stack objects in GPU code generation -- maybe transform into heap allocation?

On Fri, Nov 11, 2022 at 4:13 PM Thomas Schwinge wrote: > For example, for Fortran code like: > > write (*,*) "Hello world" > > ..., 'gfortran' creates: > The issue: the stack object 'dt_parm.0' is a half-KiB in size (yes, > really! -- there's a lot of state in Fortran I/O apparently). > Any

Re: Handling of large stack objects in GPU code generation -- maybe transform into heap allocation?

On Fri, Nov 11, 2022 at 3:13 PM Thomas Schwinge wrote: > > Hi! > > For example, for Fortran code like: > > write (*,*) "Hello world" > > ..., 'gfortran' creates: > > struct __st_parameter_dt dt_parm.0; > > try > { > dt_parm.0.common.filename = > &"source-gcc/libgomp/test

Handling of large stack objects in GPU code generation -- maybe transform into heap allocation?

Hi! For example, for Fortran code like: write (*,*) "Hello world" ..., 'gfortran' creates: struct __st_parameter_dt dt_parm.0; try { dt_parm.0.common.filename = &"source-gcc/libgomp/testsuite/libgomp.oacc-fortran/print-1_.f90"[1]{lb: 1 sz: 1}; dt_parm.0.comm

Re: Links to web pages are broken.

On 11/11/22 13:14, Georg-Johann Lay wrote: > > > Am 11.11.22 um 09:48 schrieb Martin Liška: >> On 11/10/22 18:01, Jonathan Wakely wrote: >>> Maybe just "docs" or "trunkdocs" or "latestdocs" instead of >>> "onlinedocs-new", since that is (1) very long, and (2) will look silly >>> in ten years when

Re: Links to web pages are broken.

Am 11.11.22 um 09:48 schrieb Martin Liška: On 11/10/22 18:01, Jonathan Wakely wrote: Maybe just "docs" or "trunkdocs" or "latestdocs" instead of "onlinedocs-new", since that is (1) very long, and (2) will look silly in ten years when it's not new and we need to add onlinedocs-even-newer 😉 I

Re: gcc.gnu.org/wiki/ – broken because /moin_static1910/ files fail with 404

On Fri, 11 Nov 2022, Mark Wielaard wrote: > I don't know how this happened, but I assume the moin_static1910 link > under /www/gcc/htdocs to the site-package MoinMoin/web/static/htdocs > somehow got misplaced. I added a symlink and all seems fine again. Thank you, Mark! I believe this was on me.

Re: gcc.gnu.org/wiki/ – broken because /moin_static1910/ files fail with 404

Hi Tobias, On Fri, Nov 11, 2022 at 09:14:17AM +0100, Tobias Burnus wrote: > this seems to be a very recent regression: https://gcc.gnu.org/wiki/ > is currently only limited usable. > > Looking at the browser console, the problem is: > > GET https://gcc.gnu.org/moin_static1910/common/js/common.js

Re: -Wint-conversion, -Wincompatible-pointer-types, -Wpointer-sign: Are they hiding constraint C violations?

On 10/11/2022 20:16, Florian Weimer via Gcc wrote: * Marek Polacek: On Thu, Nov 10, 2022 at 07:25:21PM +0100, Florian Weimer via Gcc wrote: GCC accepts various conversions between pointers and ints and different types of pointers by default, issuing a warning. I've been reading the (hopefully

Re: How can Autoconf help with the transition to stricter compilation defaults?

> On 10 Nov 2022, at 17:16, Zack Weinberg wrote: > > I’m the closest thing Autoconf has to a lead maintainer at present. > > It’s come to my attention (via https://lwn.net/Articles/913505/ and > https://fedoraproject.org/wiki/Changes/PortingToModernC) that GCC and > Clang both plan to disable

Re: Different outputs in Gimple pass dump generated by two different architectures

On Thu, 10 Nov 2022, Kevin Lee wrote: While looking at the failure for gcc.dg/uninit-pred-9_b.c, I observed that x86-64 and risc-v has a different output for the gimple pass since r12-4790-g4b3a325f07acebf4 . Probably since earli

Re: Links to web pages are broken.

On 11/10/22 18:01, Jonathan Wakely wrote: > Maybe just "docs" or "trunkdocs" or "latestdocs" instead of > "onlinedocs-new", since that is (1) very long, and (2) will look silly > in ten years when it's not new and we need to add > onlinedocs-even-newer 😉 I do support it, it would be probably nicer

Re: How can Autoconf help with the transition to stricter compilation defaults?

> On 11 Nov 2022, at 03:33, Zack Weinberg wrote: > > On Thu, Nov 10, 2022, at 10:08 PM, Sam James wrote: >>> On 10 Nov 2022, at 21:10, Michael Orlitzky wrote: >>> While everyone else is discussing big ideas, it would be helpful for me >>> personally if autoconf just made a release with the lat

gcc.gnu.org/wiki/ – broken because /moin_static1910/ files fail with 404

Hi all, this seems to be a very recent regression: https://gcc.gnu.org/wiki/ is currently only limited usable. Looking at the browser console, the problem is: GET https://gcc.gnu.org/moin_static1910/common/js/common.js[HTTP/2 404 Not Found 131ms] GEThttps://gcc.gnu.org/moin_static1910/modern/c