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

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.

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: 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

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: 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: [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

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

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: 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

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

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: 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

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: 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

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]

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

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

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: 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

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: -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

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: [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

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 

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

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};

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 > > >

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 = >

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: 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 > > > >

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 > >

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

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

[Bug libstdc++/107649] New: New std::complex specializations are never used

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107649 Bug ID: 107649 Summary: New std::complex specializations are never used Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component:

[Bug web/107651] Having two different kind of indexes is very useful still

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107651 --- Comment #1 from Andrew Pinski --- For the install page, one index should be index of configure option and another one will be of the env variables. For the preprocessor has an index of env variables too. Maybe even in the main document

[Bug fortran/107576] [10/11/12/13 Regression] ICE in gfc_conv_procedure_call, at fortran/trans-expr.cc:6193

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107576 --- Comment #4 from anlauf at gcc dot gnu.org --- Partial fix: diff --git a/gcc/fortran/trans-expr.cc b/gcc/fortran/trans-expr.cc index b95c5cf2f96..f09fad337bc 100644 --- a/gcc/fortran/trans-expr.cc +++ b/gcc/fortran/trans-expr.cc @@ -6193,6

[Bug libstdc++/95048] [10/11/12 Regression] wstring-constructor of std::filesystem::path throws for non-ASCII characters

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95048 --- Comment #21 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:8214ec0cf33482f60139ae18a40567317e63c1ff commit r13-3915-g8214ec0cf33482f60139ae18a40567317e63c1ff Author: Jonathan Wakely

[Bug other/107634] Very long filenames and URLs for sphinx-based docs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107634 --- Comment #4 from Andrew Pinski --- I came across a related issue here: Take: https://gcc.gnu.org/onlinedocs/gcc-12.2.0/gccint/C_002b_002b-ABI.html The original section name was just C++-ABI but had a heading of C++ ABI parameters Now post

[committed] libstdc++: Define INSTANTIATE_FACET_ACCESSORS macro in compat source [PR103755]

This fixes a build failure on powerpc64le when using ieeelongdouble as the default. Tested x86_64-linux. Pushed to trunk. -- >8 -- compatibility-ldbl-alt128.cc re-includes locale-inst-numeric.h and locale-inst-monetary.h but wasn't defining the macros added in r13-3888-gb3ac43a3c05744. Put

Re: [PATCH v2 3/4] LoongArch: Add fscaleb.{s,d} instructions as ldexp{sf,df}3

在 2022/11/9 下午9:53, Xi Ruoyao 写道: This allows optimizing __builtin_ldexp{,f} and __builtin_scalbn{,f} with -fno-math-errno. IMODE is added because we can't hard code SI for operand 2: fscaleb.d instruction always take the high half of both source registers into account. See my_ldexp_long in

Re: [PATCH] c++: init_priority and SUPPORTS_INIT_PRIORITY [PR107638]

On Fri, Nov 11, 2022 at 10:48 AM Patrick Palka via Gcc-patches wrote: > > The commit r13-3706-gd0a492faa6478c for correcting the result of > __has_attribute(init_priority) causes a bootstrap failure on hppa64-hpux > because it assumes SUPPORTS_INIT_PRIORITY expands to a simple constant, > but on

[PATCH 7/8] middle-end: Add c[lt]z idiom recognition

This recognises the patterns of the form: while (n & 1) { n >>= 1 } Unfortunately there are currently two issues relating to this patch. Firstly, simplify_using_initial_conditions does not recognise that (n != 0) and ((n & 1) == 0) implies that ((n >> 1) != 0). This preconditions

[Bug web/107650] New: Sphinx generated web pages don't have up (to the section index)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107650 Bug ID: 107650 Summary: Sphinx generated web pages don't have up (to the section index) Product: gcc Version: 13.0 Status: UNCONFIRMED Keywords: documentation

[Bug libstdc++/107649] New std::complex specializations are never used

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107649 --- Comment #2 from Jonathan Wakely --- Although if the _GLIBCXX_FLOAT_IS_IEEE_BINARY32 macro is not defined, it will still be ambiguous, because we won't define these overloads: #if _GLIBCXX_USE_C99_COMPLEX #if defined(__STDCPP_FLOAT16_T__)

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

[Bug analyzer/106147] RFE: -fanalyzer could complain about some cases of infinite loops and infinite recursion

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106147 --- Comment #6 from David Malcolm --- The above patch implements -Wanalyzer-infinite-recursion for GCC 13. I also have the beginnings of an implementation of -Wanalyzer-infinite-loop, but it won't be ready for the close of GCC 13 stage 1.

[Bug middle-end/107654] [13 Regression] md.rst should be in gcc/doc and not in doc

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107654 --- Comment #1 from Andrew Pinski --- cppdiropts.rst cppenv.rst cppopts.rst cppwarnopts.rst Also maybe should not be in the toplevel directory. Maybe place them in libcpp instead?

[Bug libstdc++/103755] {has,use}_facet() and iostream constructor performance

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103755 seurer at gcc dot gnu.org changed: What|Removed |Added CC||seurer at gcc dot gnu.org

[committed] analyzer: more state machine documentation

gcc/analyzer/ChangeLog: * sm-fd.dot: Fix typo in comment. * sm-file.dot: New file. * varargs.cc: Fix typo in comment. * varargs.dot: New file. Signed-off-by: David Malcolm --- gcc/analyzer/sm-fd.dot | 2 +- gcc/analyzer/sm-file.dot | 67

Re: old install to a different folder

On Fri, 11 Nov 2022, Tobias Burnus wrote: > For /onlinedocs/, I concur that we want to have the old doc there as there are > many > deep links. Still, we should consider adding a disclaimer box to all former > mainline > documentation stating that this data is no longer updated + point to the new

[Bug middle-end/107658] New: TARGET_EXPAND_TO_RTL_HOOK, TARGET_INSTANTIATE_DECLS, TARGET_MANGLE_TYPE don't really belong in the Storage Layout target hook section

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107658 Bug ID: 107658 Summary: TARGET_EXPAND_TO_RTL_HOOK, TARGET_INSTANTIATE_DECLS, TARGET_MANGLE_TYPE don't really belong in the Storage Layout target hook section Product: gcc

[Bug libstdc++/103755] {has,use}_facet() and iostream constructor performance

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103755 --- Comment #13 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:a7f51059fb009dcd7d491d6b2164bce75dbd9975 commit r13-3917-ga7f51059fb009dcd7d491d6b2164bce75dbd9975 Author: Jonathan Wakely

[PATCH 03/12] ipa-cp: Write transformation summaries of all functions

Hi, IPA-CP transformation summary streaming code currently won't stream out transformations necessary for clones which are only necessary for materialization of other clones (such as an IPA-CP clone which is then cloned again by IPA-SRA). However, a follow-up patch for bettor reconciling IPA-SRA

[PATCH 04/12] ipa: Better way of applying both IPA-CP and IPA-SRA (PR 103227)

Hi, this is basically a better fix for PR 103227. The one currently in use, rushed in late at stage3, which means that IPA-CP transformation simply does a replacement of default-definition of IPA-SRA-created scalar parameters with a constant, meant that IPA-SRA actually often led to creation of

[committed] libstdc++: Simplify build targets for debug library

I posted this at the start of the year while we were in stage 3. Tested x86_64-linux. Pushed to trunk. -- >8 -- This rewrites the stamp-debug and build-debug targets in src/Makefile so that each generated Makefile in the debug/$(SUBDIRS) directories is a make target, instead of being created by

[PATCH 01/12] ipa: IPA-SRA split detection simplification

Hi, I have noticed that the flag m_split_modifications_p of ipa_param_body_adjustments is not really necessary as it has to correspond to whether m_replacements is non-empty so this patch removes it. This also simplifies a bit some patches I work on. Bootstrapped and tested on x86_64-linux. OK

[PATCH 02/12] ipa-cp: Do not consider useless aggregate constants

Hi, When building vectors of known aggregate values, there is no point in including those for parameters which are not used in any way whatsoever. Bootstrapped and tested on x86_64-linux. OK for master? Thanks, Martin gcc/ChangeLog: 2022-11-11 Martin Jambor * ipa-cp.cc

[Bug c++/107660] Running binaries compiled with g++11 or later produces different results than g++ version 10 or earlier

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107660 --- Comment #2 from Tomoya Suzuki --- I Sorry I didn't follow your bug report guidelines. After this, I investigated the cause by myself, and it seems that there is a difference in the output of the std::shuffle function. Even if the input and

[Bug c++/107660] Running binaries compiled with g++11 or later produces different results than g++ version 10 or earlier

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107660 --- Comment #3 from Tomoya Suzuki --- Perhaps I should ask the question in libc instead of gcc?

[PATCH 5/8] middle-end: Add cltz_complement idiom recognition

This recognises patterns of the form: while (n) { n >>= 1 } This patch results in improved (but still suboptimal) codegen: foo (unsigned int b) { int c = 0; while (b) { b >>= 1; c++; } return c; } foo: .LFB11: .cfi_startproc cbz w0, .L3

[PATCH 6/8] docs: Add popcount, clz and ctz target attributes

gcc/ChangeLog: * doc/gccint/testsuites/directives-used-within-dejagnu-tests/keywords-describing-target-attributes.rst: Add missing target attributes. -- diff --git a/gcc/doc/gccint/testsuites/directives-used-within-dejagnu-tests/keywords-describing-target-attributes.rst

[PATCH 8/8] middle-end: Expand comment for tree_niter_desc.max

This requirement is enforced by a gcc_checking_assert in record_estimate. gcc/ChangeLog: * tree-ssa-loop.h (tree_niter_desc): Update comment. -- diff --git a/gcc/tree-ssa-loop.h b/gcc/tree-ssa-loop.h index

Re: [PATCH] [range-ops] Add ability to represent open intervals in frange.

Passes tests for all languages. Passes lapack tests. So ready to be installed unless you have any issues. Oh... I should write some tests.. Aldy On Fri, Nov 11, 2022, 19:11 Aldy Hernandez wrote: > Currently we represent < and > with a closed interval. So < 3.0 is > represented as [-INF,

[Bug tree-optimization/107523] [13 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu since r13-3628-g6fd485d15c1a2c42

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107523 Andrew Macleod changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

[Bug c++/105300] [10/11/12/13 Regression] segfault from static_assert with user-defined string suffix argument

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105300 Marek Polacek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org

[Bug web/107650] Sphinx generated web pages don't have up (to the section index)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107650 --- Comment #1 from Andrew Pinski --- The side bar has issues with the text being so much bigger and popping out compared to the main text. Plus when I scroll it, the search and icon part just takes up so much of it, the side bar becomes not

[Bug analyzer/106147] RFE: -fanalyzer could complain about some cases of infinite loops and infinite recursion

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106147 --- Comment #5 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:12c583a2a3da798e82737c2d0e11fd686636cfeb commit r13-3912-g12c583a2a3da798e82737c2d0e11fd686636cfeb Author: David Malcolm Date:

[Bug web/107651] New: Having two different kind of indexes is very useful still

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107651 Bug ID: 107651 Summary: Having two different kind of indexes is very useful still Product: gcc Version: 13.0 Status: UNCONFIRMED Keywords: documentation

[Bug c/107653] New: how-to-use-inline-assembly-language-in-c-code page is huge and should be split up

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107653 Bug ID: 107653 Summary: how-to-use-inline-assembly-language-in-c-code page is huge and should be split up Product: gcc Version: 13.0 Status: UNCONFIRMED

Re: [PATCH] 2/19 modula2 front end: Make-lang.in

Richard Biener writes: >> +M2_MAINTAINER = no >> + >> +CPP_GM2=-fpermissive -DIN_GCC -g > > Do we really need -fpermissive here? no not needed (and now removed) - thanks for spotting it. >> +GM2_1 = ./gm2 -B./stage1/m2 -g -fm2-g >> + >> +GM2_FOR_TARGET = $(STAGE_CC_WRAPPER) ./gm2 -B./

Re: [PATCH v2 3/4] LoongArch: Add fscaleb.{s,d} instructions as ldexp{sf,df}3

On Sat, 2022-11-12 at 11:54 +0800, Lulu Cheng wrote: > > 在 2022/11/9 下午9:53, Xi Ruoyao 写道: > > This allows optimizing __builtin_ldexp{,f} and __builtin_scalbn{,f} > > with > > -fno-math-errno. > > > > IMODE is added because we can't hard code SI for operand 2: > > fscaleb.d > > instruction

[Bug middle-end/107642] LOGICAL_OP_NON_SHORT_CIRCUIT vs BRANCH_COST confusion

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107642 --- Comment #1 from Andrew Pinski --- A --param option was added in 2018 to override the setting of LOGICAL_OP_NON_SHORT_CIRCUIT : https://gcc.gnu.org/legacy-ml/gcc-patches/2018-11/msg02604.html But the way it is implemented is such that the

[Bug c++/107652] New: c++20 gccchoses incorrect operator== overload

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107652 Bug ID: 107652 Summary: c++20 gccchoses incorrect operator== overload Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component:

Re: [Patch Arm] Fix PR 92999

On Thu, Nov 10, 2022 at 7:46 PM Ramana Radhakrishnan wrote: > > On Thu, Nov 10, 2022 at 6:03 PM Richard Earnshaw > wrote: > > > > > > > > On 10/11/2022 17:21, Richard Earnshaw via Gcc-patches wrote: > > > > > > > > > On 08/11/2022 18:20, Ramana Radhakrishnan via Gcc-patches wrote: > > >> PR92999

Re: [committed] libstdc++: Fix wstring conversions in filesystem::path [PR95048]

On Fri, 11 Nov 2022 at 17:44, Jonathan Wakely via Libstdc++ wrote: > > Tested x86_64-linux and x86_64-w64-ming32 (via Wine). Sigh, I did test on Wine, but then what I pushed didn't include the fix that was found thanks to that testing. This is needed to prevent runtime errors on Windows when

[Bug other/107634] Very long filenames and URLs for sphinx-based docs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107634 --- Comment #5 from Andrew Pinski --- One of the biggest drawbacks of not having one file is when you need to add a new section, you have to add a new file/directory rather than edditing one file. I also noticed the splitting up sections of the

[Bug fortran/107659] New: C procedure with no global scope is seen as global

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107659 Bug ID: 107659 Summary: C procedure with no global scope is seen as global Product: gcc Version: 10.3.0 Status: UNCONFIRMED Severity: normal Priority: P3

[PATCH 10/12] ipa-sra: Forward propagation of sizes which are safe to dereference

Hi, the previous patch established a way to propagate information about parameters from callers to callees (even though then the actual splitting is done in the opposite direction), this patch adds to that information about size of the parameters that is known to be safe to dereference in the

[PATCH 12/12] ipa: Avoid looking for IPA-SRA replacements where there are none

Hi, while modifying the code, I realized that we do look into statements even when there are no replacements. This patch adds the necessary early bail-outs to avoid that. ipa_param_body_adjustments::modify_call_stmt cannot have the same at the very beginning because calls can still contain

Re: [committed] libstdc++: Avoid redundant checks in std::use_facet [PR103755]

On Fri, 11 Nov 2022 at 21:00, Stephan Bergmann wrote: > > On 11/11/22 06:30, Jonathan Wakely via Gcc-patches wrote: > > As discussed in the PR, this makes it three times faster to construct > > iostreams objects. > > > > Tested x86_64-linux. Pushed to trunk. > > I haven't yet tried to track down

[PATCH v2] c, analyzer: support named constants in analyzer [PR106302]

Changes since v1: ported the doc changes from texinfo to sphinx Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu. Are the C frontend parts OK for trunk? (I can self-approve the analyzer parts) Thanks Dave The analyzer's file-descriptor state machine tracks the access mode of

c: C2x constexpr

[Global / middle-end reviewers, note there is a dfp.cc change here that needs review.] Implement C2x constexpr (a feature based on the C++ one but much more minimal, with only constexpr variables, not functions). I believe this implementation is fully functional for use of this feature.

[Bug c++/107484] [13 Regression] ICE: Segmentation fault (in decls_match)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107484 Marek Polacek changed: What|Removed |Added Last reconfirmed||2022-11-11 Priority|P1

[Bug target/107645] internal compiler error: RTL check: expected elt 0 type 'e' or 'u', have 'E' (rtx unspec) in symbolic_operand_1, at config/m68k/predicates.md:144

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107645 --- Comment #1 from jcmvbkbc at gcc dot gnu.org --- ICE in the reproducer is generated when predicate 'symbolic_operand' is applied to the 'const' node in the following rtl: (insn 342 341 343 35 (set (reg:SI 97) (mem/u:SI (plus:SI

Re: [PATCH v2] RISC-V missing __builtin_lceil and __builtin_lfloor

On Wed, Nov 9, 2022 at 1:49 AM Xi Ruoyao wrote: > > On Mon, 2022-11-07 at 20:36 -0800, Kevin Lee wrote: > I "shamelessly copied" your idea in > https://gcc.gnu.org/pipermail/gcc-patches/2022-November/605456.html. > During the review we found an issue. > > -fno-fp-int-builtin-inexact does not

[Bug middle-end/107642] LOGICAL_OP_NON_SHORT_CIRCUIT vs BRANCH_COST confusion

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107642 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill

[Bug rust/107633] [13 regression] Bootstrap failure due to -Werror=unused-parameter and -Werror=dangling-reference

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107633 --- Comment #5 from Marek Polacek --- https://gcc.gnu.org/pipermail/gcc-patches/2022-November/605800.html, if accepted, should help.

[Bug c++/107532] [13 Regression] -Werror=dangling-reference false positives in libcamera-0.0.1

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107532 Marek Polacek changed: What|Removed |Added Ever confirmed|0 |1 Assignee|unassigned at gcc

Re: [committed] libstdc++: Avoid redundant checks in std::use_facet [PR103755]

On 11/11/22 06:30, Jonathan Wakely via Gcc-patches wrote: As discussed in the PR, this makes it three times faster to construct iostreams objects. Tested x86_64-linux. Pushed to trunk. I haven't yet tried to track down what's going on, but with various versions of Clang (e.g.

Re: [PATCH 1/6] PowerPC: Add -mcpu=future

On 11/9/22 8:44 PM, Michael Meissner via Gcc-patches wrote: > + /* For now, make -mtune=future the same as -mtune=power10. */ > + if (rs6000_tune == PROCESSOR_FUTURE) > +rs6000_tune = PROCESSOR_POWER10; This comment matches the code... > + /* Some future processor. For now, just use

[committed] analyzer: new warning: -Wanalyzer-infinite-recursion [PR106147]

This patch adds a new -Wanalyzer-infinite-recursion warning to -fanalyzer, which complains about certain cases of infinite recursion. Specifically, when it detects recursion during its symbolic execution of the user's code, it compares the state of memory to that at the previous level of

[committed] analyzer: split out checker_event classes to their own header

Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu. Pushed to trunk as r13-3913-g65752c1f7c41c5. gcc/analyzer/ChangeLog: * checker-path.h: Split out checker_event and its subclasses to... * checker-event.h: ...this new header. Signed-off-by: David Malcolm ---

Re: [COMMITTED] process transitive inferred ranges in pre_fold_stmt.

On Fri, 11 Nov 2022 11:17:17 -0500 Andrew MacLeod via Gcc-patches wrote: > diff --git a/gcc/tree-vrp.cc b/gcc/tree-vrp.cc > index 3393c73a7db..a474d9d11e5 100644 > --- a/gcc/tree-vrp.cc > +++ b/gcc/tree-vrp.cc > @@ -4485,6 +4486,7 @@ public: > for (gphi_iterator gsi = gsi_start_phis (bb);

[Bug c/107653] how-to-use-inline-assembly-language-in-c-code page is huge and should be split up

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107653 --- Comment #1 from Andrew Pinski --- I thought it went one layer deap but nope it is kinda of random. For an example: Not split up: https://gcc.gnu.org/onlinedocs/gccint/target-macros/register-classes.html Splitted up:

Re: [PATCH] libstdc++: Set active union member in constexpr std::string [PR103295]

Thanks for that. I'll keep your comments in mind for the future. On Fri, Nov 11, 2022 at 05:59:33PM +, Jonathan Wakely wrote: > On Fri, 11 Nov 2022 at 17:55, Patrick Palka wrote: > > > > On Fri, 11 Nov 2022, Jonathan Wakely via Libstdc++ wrote: > > > > > On Fri, 11 Nov 2022 at 11:23,

[PATCH 09/12] ipa-sra: Be optimistic about Fortran descriptors

Hi, Fortran descriptors are structures which are often constructed just for a particular argument of a particular call where it is passed by reference. When the called function is under compiler's control, it can be beneficial to split up the descriptor and pass it in individual parameters.

[PATCH 07/12] ipa-sra: Treat REFERENCE_TYPES as always dereferencable

Hi, C++ and especially Fortran pass data by references which are not pointers potentially pointing anywhere and so can be assumed to be safely dereferencable. This patch teaches IPA-SRA to treat them as such and avoid the dance we do to prove that we can move loads from them to the caller. When

[PATCH 08/12] ipa-sra: Move caller->callee propagation before callee->caller one

Hi, this patch does not do any functional changes, it merely moves top-down propagation in the IPA-SRA WPA phase before bottom-up one. This also meant moving some preliminary checks from the latter to the former - where they need to be in their own loop over each SCC because the subsequent one

[PATCH 06/12] ipa-cp: Leave removal of unused parameters to IPA-SRA

Hi, looking at some benchmarks I have noticed many cases when IPA-CP cloned a function for all contexts just because it knew that some parameters were not used at all. Then IPA-SRA looked at the function and cloned it again to split another parameter or two. The latter pass is better equipped

  1   2   3   4   >