On Wed, Apr 22, 2020 at 10:25 AM Jakub Jelinek via Gcc wrote:
> An -O? option is not just a set of suboptions it enables
Maybe it should be. I notice this come up often enough at least.
On Mon, Jun 7, 2021, 06:12 Giacomo Tesio wrote:
> The Steering Committee can avoid all of this, now.
> I cannot really understand why they shouldn't.
>
Likely because the primary contributor to c++ has said he will stop
contributing unless the change is made.
>
On Mon, Jun 7, 2021, 07:36 Giacomo Tesio wrote:
> Hi NightStrike,
>
> On June 7, 2021 5:18:13 PM UTC, NightStrike wrote:
> > On Mon, Jun 7, 2021, 06:12 Giacomo Tesio wrote:
> >
> > > The Steering Committee can avoid all of this, now.
> > > I cannot really understand why they shouldn't.
> > >
> >
On Fri, Apr 16, 2021 at 7:23 AM Ville Voutilainen via Gcc
wrote:
> On the first part, other people have touched on it already,
> but the fear of a dreaded non-free software vendor co-opting
> GCC as a library to a non-free project has resulted in GCC
> being unsuitable to be used as a library in
On Thu, Apr 15, 2021, 23:42 Iain Sandoe via Gcc wrote:
> it is essential (IMO) that review of code is carried out on a fair and
> technical basis without personal attack or harrassment (or
> unwelcome unrelated attention).
>
Is this not the case on gcc-patches?
>
On Mon, Aug 23, 2021 at 8:16 PM NightStrike wrote:
> On Mon, Aug 23, 2021 at 4:09 PM David Malcolm wrote:
> > Which tests are failing, specifically?
Here's the full list of all 37 failures that fail for any reason:
FAIL: gcc.dg/analyzer/dot-output.c dg-check-dot dot-output.c.state-purge.dot
Should I make this a bugzilla? I guess I figured that wouldn't be
appropriate.
On Mon, Aug 9, 2021, 07:16 NightStrike wrote:
> When porting to GCC 11, care must be taken to adjust includes of GCC
> intrinsic headers due to this change:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97148
>
>
On Tue, Aug 24, 2021 at 8:48 AM David Malcolm wrote:
> Thanks for working through the above.
>
> Do you have an account in GCC's bugzilla? If so, please can you turn
> this into a bug report there. Is there a recipe for testing this via
> wine? (it's been almost 20 years since I did any
On Tue, Aug 24, 2021 at 10:21 PM Andrew Pinski wrote:
>
> On Tue, Aug 24, 2021 at 6:39 PM NightStrike via Gcc wrote:
> > On Mon, Aug 9, 2021, 07:16 NightStrike wrote:
> >
> > > When porting to GCC 11, care must be taken to adjust includes of GCC
> > >
David,
Many of the analyzer tests fail on windows because they hardcode in the
typedef of size_t to be unsigned long. This is not a platform independent
definition, though, and is wrong for 64 bit windows. This causes extra
warnings that all of the functions using size_t arguments are wrong,
On Mon, Aug 23, 2021 at 4:09 PM David Malcolm wrote:
>
> On Mon, 2021-08-23 at 09:52 -1000, NightStrike wrote:
> > David,
> >
> > Many of the analyzer tests fail on windows because they hardcode in
> > the
> > typedef of size_t to be unsigned long. This is not a platform
> > independent
> >
On Thu, Sep 16, 2021 at 11:45 AM Martin Sebor via Gcc wrote:
> ice-on-invalid-code: ICE on code that is not syntactically valid.
> ice-on-valid-code: ICE on code that is syntactically valid.
Presumably, the distinction is there because more attention would get
paid to the latter over the former.
When porting to GCC 11, care must be taken to adjust includes of GCC
intrinsic headers due to this change:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97148
That should be reflected in:
https://gcc.gnu.org/gcc-11/porting_to.html
On Sun, Sep 11, 2022, 10:30 Junk Trash via Gcc wrote:
> Hi,
>
> I want to get the opinions of GCC developers regarding adding CMake as a
> build system for GCC. Is it something you would like, something you are
> neutral about, or something you are strongly against?
>
> Thanks for your valuable
On Wed, Dec 21, 2022 at 11:37 PM Jacob Bachmeyer wrote:
>
> NightStrike wrote:
> > [...]
> > Second, the problems with extra \r's still remain, but I think we've
> > generally come to think that that part isn't Wine and is instead
> > either the testsuite or deja. So I'll keep those replies to
On Wed, Dec 28, 2022, 00:37 Alexander Zaitsev wrote:
> Hello.
>
> We are using GCC for our C++ projects. Our projects are huge, commit
> rate is quite huge, so our CI workers are always busy (so as any other
> CI workers, honestly). Since we want to increase build speed, one of the
> option is
On Fri, Dec 23, 2022 at 11:00 PM Jacob Bachmeyer wrote:
> NightStrike wrote:
> > On Wed, Dec 21, 2022 at 11:37 PM Jacob Bachmeyer wrote:
> >> NightStrike wrote:
> >>
> >>> [...]
> >>> Second, the problems with extra \r's still remain, but I think we've
> >>> generally come to think that that
On Tue, Jan 10, 2023 at 9:30 PM Jacob Bachmeyer wrote:
>
> NightStrike wrote:
> > [...]
> > I did another little test to try to better understand your point. I
> > ran a linux native testsuite under a simulator that just sets SIM to "
> > ". This resulted in extra ^M's also, although many tests
On Thu, Jan 5, 2023 at 10:33 PM Jacob Bachmeyer wrote:
>
> NightStrike wrote:
> > On Fri, Dec 23, 2022 at 11:00 PM Jacob Bachmeyer wrote:
> >
> >> NightStrike wrote:
> >>
> >>> On Wed, Dec 21, 2022 at 11:37 PM Jacob Bachmeyer
> >>> wrote:
> >>>
> [...]
> >>> So at least we know for sure
On Sat, Dec 17, 2022 at 5:52 AM Thomas Koenig wrote:
>
> On 17.12.22 01:26, NightStrike wrote:
> > On Fri, Dec 16, 2022 at 1:44 AM Thomas Koenig wrote:
> >>
> >> On 16.12.22 03:20, NightStrike via Fortran wrote:
> >>
> >>> When I run the testsuite under wine, I'm getting a lot of ANSI escape
>
On Sat, Dec 17, 2022 at 10:44 PM Jacob Bachmeyer wrote:
>
> NightStrike wrote:
> > On Sat, Dec 17, 2022 at 5:52 AM Thomas Koenig wrote:
> >
> >> On 17.12.22 01:26, NightStrike wrote:
> >>
> >>> On Fri, Dec 16, 2022 at 1:44 AM Thomas Koenig
> >>> wrote:
> >>>
> On 16.12.22 03:20,
On Sun, Dec 18, 2022 at 11:29 PM Jacob Bachmeyer wrote:
>
> NightStrike wrote:
> > On Sat, Dec 17, 2022 at 10:44 PM Jacob Bachmeyer wrote:
> >
> >> [...]
> >> This is either a testsuite problem or an environment problem. The GNU
> >> Fortran I/O module certainly has interesting behavior here.
On Mon, Dec 19, 2022 at 5:43 AM Torbjorn SVENSSON
wrote:
> I'm not sure if this helps anyone, but I experienced something similar with
> Cygwin a while back.
> What I had to do in order to have expect working when testing GCC on Windows
> 10 was to defined the "CYGWIN" environment variable to
On Wed, Dec 21, 2022 at 12:38 PM Jacek Caban wrote:
>
> Hi all,
>
>
> I'm responsible for Wine changes that cause your problems. I'm also
> CCing Eric, who is Wine console expert, maybe he has better ideas. Eric,
> see [1] if you're interested in the context.
>
>
> Recent Wine versions implement
On Fri, Nov 25, 2022 at 3:09 PM Paul Koning via Gcc wrote:
> But in any case, how does that relate to the error messages I got? They
> don't seem to have anything to do with missing compilers, but rather with the
> use of language features too new for the available (downloadable) Gnat.
On Sun, Jan 29, 2023 at 2:37 PM Jerry D via Fortran wrote:
>
> I had this show up today. I have no idea what this is about.
>
> Please advise.
I assume the buildbot thinks that
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=8011fbba7baa46947341ca8069b5a327163a68d5
broke the build, but I fail to
On Mon, Nov 14, 2022, 04:42 David Brown via Gcc wrote:
> On 13/11/2022 19:43, Alejandro Colomar via Gcc wrote:
> > Hi Andrew!
> >
> > On 11/13/22 19:41, Andrew Pinski wrote:
> >> On Sun, Nov 13, 2022 at 10:40 AM Andrew Pinski
> wrote:
> >>>
> >>> On Sun, Nov 13, 2022 at 10:36 AM Alejandro
On Mon, Nov 14, 2022, 10:49 David Brown wrote:
>
>
> On 14/11/2022 16:10, NightStrike wrote:
> >
> >
> > On Mon, Nov 14, 2022, 04:42 David Brown via Gcc
> >
> > Warnings are not perfect - there is always the risk of false
> positives
> > and false negatives. And different people will
On Tue, Feb 14, 2023 at 6:20 PM Gerald Pfeifer wrote:
> Alas http://www.wlandry.net/Projects/FTensor has been down for a while,
> and there does not appear to be a new location?
https://wlandry.net/Projects/FTensor/ works
On Sat, Feb 11, 2023, 14:37 Basile Starynkevitch
wrote:
> Modifying the pass manager
> https://gcc.gnu.org/onlinedocs/gccint/Pass-manager.html#Pass-manager to
> use clock_gettime system call. See
> https://man7.org/linux/man-pages/man2/clock_gettime.2.html
Since we can now use c++11,
On Thu, Apr 27, 2023 at 5:41 AM Jakub Jelinek via Gcc wrote:
>
> On Thu, Apr 27, 2023 at 11:35:23AM +0200, Helmut Zeisel wrote:
> > >Von: "Jakub Jelinek"
> > >An: "Helmut Zeisel"
> > >Cc: gcc@gcc.gnu.org
> > >Betreff: Re: GCC 13.1 compile error when using CXXFLAGS=-std=c++20
> > >On Thu, Apr
On Mon, Jan 22, 2024, 12:31 Arthur Cohen wrote:
> I am aware that this would mean restricting the Rust
> GCC front-end to platforms where the official Rust compiler is also
> available, which is less than ideal. However, this would only be
> temporary - as soon as the Rust front-end is able to
On Thu, Jan 25, 2024, 11:27 Iain Sandoe wrote:
> E.g. with Ada it is possible to port to a new platform by first building a
> cross-compiler and then to use that cross-compiler to build a “native
> cross” (build != host == target) to provide an initial compiler on the
> target platform.
>
And
On Tue, Apr 28, 2020 at 10:37 AM David Malcolm via Gcc-patches
wrote:
> I'm working on a rewrite of the region_model code for GCC 11 that I
> hope will fix these issues, and allow this warning to be reintroduced.
If that's the case, why remove the warning just to add it back? You
could leave it
On Thu, May 28, 2020, 4:25 PM David Malcolm via Gcc-patches <
gcc-patches@gcc.gnu.org> wrote:
> On Wed, 2020-05-27 at 22:27 -0300, Nicolas Bértolo wrote:
> > > New C++ source files should have a .cc extension.
> > > I hope that at some point we'll rename all the existing .c ones
> > >
On Thu, Jan 6, 2022, 18:31 cqwrteur via Gcc-patches
wrote:
> When building GCC hosted on windows with Canadian/native compilation
> (host==target), the build scripts in GCC would override DLLs with each
> other. For example, for MinGW-w64, 32-bit DLLs would override 64 bits
> because build
On Fri, Oct 21, 2022 at 8:33 AM Jacek Caban via Gcc-patches
wrote:
>
> On 2022-10-21 11:44, Eric Botcazou via Libstdc++ wrote:
> >>>/How does this compare with Eric B's proposal at
> >>>/>>>/https://gcc.gnu.org/legacy-ml/gcc-patches/2019-06/msg01840.html ?
> >>>/>>//>>/My proposal was to
On Wed, Jan 11, 2023 at 7:14 AM Jakub Jelinek wrote:
> I've committed following after regtesting it on x86_64-linux and i686-linux:
...
> +/* { dg-do run { target int32 } } */
Ah, I didn't realize you meant literally int32. I didn't see that as
a choice here:
On Fri, Jan 6, 2023 at 4:56 AM Jakub Jelinek via Gcc-patches
wrote:
> --- gcc/testsuite/gcc.dg/pr108308.c.jj 2023-01-06 10:43:45.793009294 +0100
> +++ gcc/testsuite/gcc.dg/pr108308.c 2023-01-06 10:43:40.218090375 +0100
> @@ -0,0 +1,39 @@
> +/* PR target/108308 */
> +/* { dg-do run { target {
On Wed, Jan 11, 2023 at 4:43 AM Jakub Jelinek wrote:
>
> On Wed, Jan 11, 2023 at 04:27:11AM -0500, NightStrike wrote:
> > On Wed, Jan 11, 2023 at 4:07 AM Jakub Jelinek wrote:
> > >
> > > On Wed, Jan 11, 2023 at 03:58:40AM -0500, NightStrike wrote:
> > > > On Fri, Jan 6, 2023 at 4:56 AM Jakub
On Wed, Jan 11, 2023 at 4:07 AM Jakub Jelinek wrote:
>
> On Wed, Jan 11, 2023 at 03:58:40AM -0500, NightStrike wrote:
> > On Fri, Jan 6, 2023 at 4:56 AM Jakub Jelinek via Gcc-patches
> > wrote:
> > > --- gcc/testsuite/gcc.dg/pr108308.c.jj 2023-01-06 10:43:45.793009294
> > > +0100
> > > +++
On Fri, Dec 23, 2022 at 7:00 PM Jonathan Yong via Gcc-patches
wrote:
>
> On 12/22/22 12:28, i.nix...@autistici.org wrote:
> > On 2022-12-22 12:21, Jonathan Yong wrote:
> >
> > hello,
> >
> >> On 12/16/22 19:20, Eric Botcazou wrote:
> The libgcc parts look reasonable to me, but I can't
On Fri, Jan 20, 2023 at 1:40 PM Gaius Mulley via Gcc-patches
wrote:
>
> Richard Biener writes:
>
> > The following adjusts libgm2 to properly use the multilib build
> > infrastructure, thereby fixing the install with
> > --enable-version-specific-runtime-libs
> >
> > In particular config-ml.pl
On Sat, Jan 21, 2023, 18:59 Jerry D via Fortran wrote:
>
> Proposed ChangeLog entry using git gcc-commit-mklog:
>
> Author: Jerry DeLisle
> Date: Sat Jan 21 15:47:19 2023 -0800
>
> Revise the line end tests to pass on certain windows test environments
> which inject spurious /r
On Tue, Jan 31, 2023 at 9:27 PM David Malcolm wrote:
>
> Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
> Pushed to trunk as r13-5615-gd03ae4be2c6d48.
>
> gcc/testsuite/ChangeLog:
> * gcc.dg/analyzer/call-summaries-2.c: Add
> dg-require-effective-target alloca.
>
The reason would be to show that they continue to not ICE as they used to.
No go paths are just as useful as go paths.
On Sat, Mar 11, 2023, 10:57 Jeff Law wrote:
>
>
> On 2/16/23 01:16, Eric Botcazou via Gcc-patches wrote:
> >> This fixes dg.exp/stack-check-2.c, -7, 8, and -16.c, which is
On Fri, Mar 3, 2023 at 10:14 PM Jerry D via Fortran wrote:
> I am certainly not a C++ expert but it seems to me this all begs for
> automatic finalization where one would not have to invoke free at all.
> I suspect the gfortran frontend is not designed for such things.
+1 for RAII
On Wed, Feb 15, 2023, 08:45 Jonathan Yong via Gcc-patches <
gcc-patches@gcc.gnu.org> wrote:
> gcc/testsuite/ChangeLog:
>
> * gcc.target/i386/harden-sls-6.c: fix warning on LLP64
> targets.
>
> Attached patch OK?
Ping
On Tue, Feb 14, 2023, 05:42 Jonathan Yong via Gcc-patches <
gcc-patches@gcc.gnu.org> wrote:
> Attached patches OK?
Ping
On Thu, Feb 16, 2023, 11:10 LIU Hao via Gcc-patches
wrote:
>
> --
> Best regards,
> LIU Hao
>
Ping
>
On Sat, Feb 18, 2023, 17:32 Gerald Pfeifer wrote:
> That was a bit too much in terms of additions things. :-)
>
> Pushed.
>
> Gerald
> ---
> htdocs/gcc-12/changes.html | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/htdocs/gcc-12/changes.html
On Thu, Feb 16, 2023 at 3:16 AM Eric Botcazou wrote:
>
> > This fixes dg.exp/stack-check-2.c, -7, 8, and -16.c, which is great!
>
> Try the attached patch.
Well... that patch just marks all of the tests as unsupported. But
for example, the ones quoted above run, work, and pass. And when they
Jakub, ping
On Thu, Jan 26, 2023, 12:50 i.nixman--- via Gcc-patches <
gcc-patches@gcc.gnu.org> wrote:
> hello,
>
> could someone look at the patch attached please?
>
> https://gcc.gnu.org/pipermail/gcc-patches/2023-January/610392.html
>
ping
On Sat, Jan 28, 2023 at 1:16 PM Jonathan Yong <10wa...@gmail.com> wrote:
>
> Patch OK?
>
> gcc/testsuite/ChangeLog:
>
> * gcc.dg/pr65658.c: fix LLP64 test.
On Sat, Feb 11, 2023 at 3:52 AM Gerald Pfeifer wrote:
>
> On Sat, 11 Feb 2023, Jonathan Yong via Gcc-patches wrote:
> >> could you please close the corresponding BR too?:
> >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350
> > I can't close it, but I put a note that it has been committed.
>
Is it too soon to ping again? :) I think Nixman needs some feedback as to
whether he's on the right track in addressing your concerns.
On Sun, Feb 5, 2023, 12:39 NightStrike wrote:
> Jakub, ping
>
> On Thu, Jan 26, 2023, 12:50 i.nixman--- via Gcc-patches <
> gcc-patches@gcc.gnu.org> wrote:
>
On Fri, Jan 20, 2023 at 10:21 PM Jerry DeLisle via Fortran
wrote:
>
> Hi all,
>
> Similar to a patch I committed a while ago for Cygwin, the attached
> patch allows it to pass on the mingw version of gfortran.
>
> It is trivial.
>
> Ok for trunk?
>
> Regards,
>
> Jerry
ping
On Wed, Feb 15, 2023 at 10:24 AM Eric Botcazou via Gcc-patches
wrote:
>
> Hi,
>
> this is the incompatibility of -fstack-clash-protection with Windows SEH. Now
> the Windows ports always enable TARGET_STACK_PROBE, which means that the stack
> is always probed (out of line) so
On Fri, Mar 10, 2023, 14:00 Gerald Pfeifer wrote:
> On Fri, 10 Mar 2023, Sandra Loosemore wrote:
> > AFAIK we have not knowingly changed any specific requirements beyond the
> > stated 4.7 and 4.9 for PDF output, but it concerns me that nobody is
> > likely to be using versions that old on a
59 matches
Mail list logo
