Re: Rust: error[E0554]: `#![feature]` may not be used on the stable release channel

Hi! On 2025-03-17T20:03:48+, Iain Sandoe via Gcc wrote: >> On 17 Mar 2025, at 19:43, Toon Moene wrote: >> >> I was eager to try the new rust updates ... >> >> But I got this: >> >> error[E0554]: `#![feature]` may not be used on the stab

Re: Rust: error[E0554]: `#![feature]` may not be used on the stable release channel

> On 17 Mar 2025, at 19:43, Toon Moene wrote: > > I was eager to try the new rust updates ... > > But I got this: > > error[E0554]: `#![feature]` may not be used on the stable release channel > --> src/lib.rs:19:1 > |

Rust: error[E0554]: `#![feature]` may not be used on the stable release channel

I was eager to try the new rust updates ... But I got this: error[E0554]: `#![feature]` may not be used on the stable release channel --> src/lib.rs:19:1 | 19 | #![feature(extern_types)] | ^ For more information about this error, try `rustc --explain E0

Re: GCC does not optimize well enough with vectors on bitshift

ht to be a pop-up warning you against doing this (I'm not sure why it didn't show up). Please use a specific architecture e.g. `-march=skylake-avx512` - https://godbolt.org/z/GvTcqasqK Thanks, Matt :) On Mon, Mar 10, 2025 at 10:47 AM Qwert Nerdish via Gcc wrote: > Correct link i

Re: GCC does not optimize well enough with vectors on bitshift

Correct link is https://godbolt.org/z/GfeTobMvs On Mon, Mar 10, 2025 at 4:45 PM Qwert Nerdish wrote: > On this godbolt link at https://godbolt.org/z/GfeTobMvs, the two C source > codes behave identical. > Yet the second source code does not use vectors and is 30% slower when I > tested it. >

Re: GCC does not optimize well enough with vectors on bitshift

> > wrote: > > > > > On this godbolt link at https://godbolt.org/z/GfeTobMvs, the two C > > source > > > codes behave identical. > > > Yet the second source code does not use vectors and is 30% slower when > I > > > tested it. > > > > > > > > -- > Matt > (he/him) > >

GCC does not optimize well enough with vectors on bitshift

On this godbolt link at https://godbolt.org/z/GfeTobMvs, the two C source codes behave identical. Yet the second source code does not use vectors and is 30% slower when I tested it.

Re: Commits not appearing in bugzilla

Am 16.02.25 um 17:59 schrieb Thomas Koenig: Am 16.02.25 um 16:29 schrieb Mark Wielaard: For now I replaced Thomas last name with just "Koenig". Hope that resolve the issue. Thanks! We'll see with the next commit. ... which worked, so the non-ASCII letters in the name seems to have been the

Re: Commits not appearing in bugzilla

Am 16.02.25 um 16:29 schrieb Mark Wielaard: For now I replaced Thomas last name with just "Koenig". Hope that resolve the issue. Thanks! We'll see with the next commit. Best regards Thomas

Re: Commits not appearing in bugzilla

Hi Thomas, Hi Arsen, On Sun, Feb 16, 2025 at 01:35:05PM +0100, Arsen Arsenović via Gcc wrote: > Thomas Koenig via Gcc writes: > > > (Incidentally, the mailing system messes up the UTF-8 represntation > > of my last name, König, maybe that is somehing to do with it). > > IIRC my commits were fai

Re: Commits not appearing in bugzilla

Thomas Koenig via Gcc writes: > (Incidentally, the mailing system messes up the UTF-8 represntation > of my last name, König, maybe that is somehing to do with it). IIRC my commits were failing to go through due to the presence of a "ć" in my /etc/passwd entry on Sourceware. This might be the s

Commits not appearing in bugzilla

My commits have not been appearing in bugzilla for quite some time now. Some recent examples have been https://gcc.gnu.org/pipermail/gcc-cvs/2025-February/417177.html https://gcc.gnu.org/pipermail/gcc-cvs/2025-February/417426.html Is this a misconfiguration somewhere? Should I be doing

Re: RFC: Bugzilla keyword "interp" where it is not clear if a program is standard-conforming or not

and will go through a few bugs to see where I can reasonably add this. Fortran is a complicated language, and quite often the question is not if a program is illegal or not, but what it should do. Best regards Thomas

Re: RFC: Bugzilla keyword "interp" where it is not clear if a program is standard-conforming or not

Thomas Koenig via Gcc writes: > Hello world, > > looking at a few Fortran bug reports, I found some cases where > it was not clear if the program in question was standard-conforming > or not. I would propose to add a keyword for that, tentatively > called "interp". &

Re: RFC: Bugzilla keyword "interp" where it is not clear if a program is standard-conforming or not

will create > this in a day or so. > >> The fact that a testcase is (non-)compliant is >> also not telling anything about the bug reported, unlike rejects-valid >> or ice-on-invalid, >> so it does not help in bug searches. Now that you've said it: > I

Re: RFC: Bugzilla keyword "interp" where it is not clear if a program is standard-conforming or not

On Mon, 2025-02-10 at 09:29 +, Jonathan Wakely via Gcc wrote: > On Sun, 9 Feb 2025, 09:08 Thomas Koenig via Gcc, > wrote: > > > Hello world, > > > > looking at a few Fortran bug reports, I found some cases where > > it was not clear if the program in questi

Re: RFC: Bugzilla keyword "interp" where it is not clear if a program is standard-conforming or not

Am 10.02.25 um 21:05 schrieb David Malcolm: FWIW my first thought for "interp" was that we gaining an interpreter (there are some in the libgccjit test suite). It was motivated by Fortran interps, which are interpretation requrests. But I think that Richard's suggestion, neeeds-stdcheck, makes

Re: RFC: Bugzilla keyword "interp" where it is not clear if a program is standard-conforming or not

also not telling anything about the bug reported, unlike rejects-valid or ice-on-invalid, so it does not help in bug searches. It might attract language lawyers :-) Best regards Thomas

Re: RFC: Bugzilla keyword "interp" where it is not clear if a program is standard-conforming or not

On Sun, 9 Feb 2025, 09:08 Thomas Koenig via Gcc, wrote: > Hello world, > > looking at a few Fortran bug reports, I found some cases where > it was not clear if the program in question was standard-conforming > or not. I would propose to add a keyword for that, tentatively &

Re: RFC: Bugzilla keyword "interp" where it is not clear if a program is standard-conforming or not

gt; Sorry, for the new way in the discussion. We have need-bisection and other need-, so iff then maybe a need-stdchk for cases compliance is unclear? The fact that a testcase is (non-)compliant is also not telling anything about the bug reported, unlike rejects-valid or ice-on-invalid, so it does no

Re: RFC: Bugzilla keyword "interp" where it is not clear if a program is standard-conforming or not

/9/25 1:07 AM, Thomas Koenig wrote: > > Hello world, > > > > looking at a few Fortran bug reports, I found some cases where > > it was not clear if the program in question was standard-conforming > > or not.  I would propose to add a keyword for that, tentatively > &g

Re: RFC: Bugzilla keyword "interp" where it is not clear if a program is standard-conforming or not

On 2/9/25 1:07 AM, Thomas Koenig wrote: Hello world, looking at a few Fortran bug reports, I found some cases where it was not clear if the program in question was standard-conforming or not.  I would propose to add a keyword for that, tentatively called "interp". Comments? Suggest

RFC: Bugzilla keyword "interp" where it is not clear if a program is standard-conforming or not

Hello world, looking at a few Fortran bug reports, I found some cases where it was not clear if the program in question was standard-conforming or not. I would propose to add a keyword for that, tentatively called "interp". Comments? Suggestions for a different name? Should I jus

Re: branch prediction not correctly applied to an if statement in an inline with multiple conditoins

ne. > > In the particular case I ran into a prediction concerning the return > value of __access_ok is not correctly acted upon. > > #define access_ok(addr, size) likely(__access_ok(addr, size)) > > then in __access_ok: > return valid_user_address(sum) && sum >= (__force

branch prediction not correctly applied to an if statement in an inline with multiple conditoins

is not correctly acted upon. #define access_ok(addr, size) likely(__access_ok(addr, size)) then in __access_ok: return valid_user_address(sum) && sum >= (__force unsigned long)ptr; The expected asm contains 2 branches both with a jump towards the end of the function in the failing ca

Re: BUG: realloc(p,0) is not conforming to C99/C11/C17/POSIX.1-2008

On 10/17/24 12:09 PM, Alejandro Colomar via Gcc wrote: CC += JeanHeyd CC += Robert, Joseph, gcc@ CC += Doug, as the author of the original malloc(3). Please don't CC random people (and mailing lists) on a glibc bug report. See https://sourceware.org/glibc/wiki/FilingBugs for bug reporting i

Re: BUG: realloc(p,0) is not conforming to C99/C11/C17/POSIX.1-2008

Pedantically, I should say valid, not unique. More pedantically, it should be distinct from any other pointer returned by malloc or realloc and not freed or realloced since. Doug On Thu, Oct 17, 2024 at 12:09 PM Alejandro Colomar wrote: > > CC += JeanHeyd > > On Thu, Oct 17, 2

Re: BUG: realloc(p,0) is not conforming to C99/C11/C17/POSIX.1-2008

it were the > > > > >only good behavior, making every default malloc(0) non-conforming. > > > > >This was a huge mistake/crime. So far so good for realloc(,0). > > > > > > > > > > - X3J11 (ANSI C) decided that realloc(p,0) shall

Re: BUG: realloc(p,0) is not conforming to C99/C11/C17/POSIX.1-2008

> Pedantically, I should say valid, not unique. More pedantically, it should be distinct from any other pointer returned by malloc or realloc and not freed or realloced since. On Thu, Oct 17, 2024 at 11:25 AM Alejandro Colomar wrote: > On Thu, Oct 17, 2024 at 05:19:07PM GMT, Alejandro C

Re: BUG: realloc(p,0) is not conforming to C99/C11/C17/POSIX.1-2008

. > > > > - SVID surprisingly documented that bug in -lmalloc as if it were the > > > >only good behavior, making every default malloc(0) non-conforming. > > > >This was a huge mistake/crime. So far so good for realloc(,0). > > > > > &g

Re: BUG: realloc(p,0) is not conforming to C99/C11/C17/POSIX.1-2008

nforming. > > >This was a huge mistake/crime. So far so good for realloc(,0). > > > > > > - X3J11 (ANSI C) decided that realloc(p,0) shall be equivalent to > > >free(p) (allegedly, in line with their self-inflicted policy of not > > >

Re: gcc14.2 gprbuild not provided

"Berger, Lutz via Gcc" writes: > Airbus Amber > Hallo, > The command "gnatmake -P" cannot be executed anymore, > because gprbuild (gnatmake is forwarded to gprbuild in that case) is > not provided. Is there a restriction, or why it is not provided? Hel

gcc14.2 gprbuild not provided

Airbus Amber Hallo, The command "gnatmake -P" cannot be executed anymore, because gprbuild (gnatmake is forwarded to gprbuild in that case) is not provided. Is there a restriction, or why it is not provided? Regards Lutz Berger Modeling and Testing System Engineer Integrated Team PST

Re: c99 does not handle -O2 but cc does?

Am 11.10.2024 um 18:07 schrieb Jonathan Wakely: The c99 executable is provided by your distro, it's not part of GCC. Maybe it wants a space between the -O and 2, but I don't know. thanks for clearing that up does not work with spaces - will ask on the Tumbleweed list

Re: c99 does not handle -O2 but cc does?

99 the -O2 option should work > c99 is used in an older build system and that didn't work due to the -O2 > problem > > The c99 executable is provided by your distro, it's not part of GCC. Maybe it wants a space between the -O and 2, but I don't know.

c99 does not handle -O2 but cc does?

latest SUSE Tumbleweed/gcc 14.2 c99 -O2 test.c returns: c99: invalid option -- '2' cc -O2 test.c returns successfull according to https://linux.die.net/man/1/c99 the -O2 option should work c99 is used in an older build system and that didn't work due to the -O2 problem

Fwd: GCC arm target does not generate the correct code for adc patterns

It looks like GCC arm has not yet supported adc sbb for arm while clang does. https://gcc.gnu.org/onlinedocs/gcc/Integer-Overflow-Builtins.html clang: https://godbolt.org/z/8q9djE7fr gcc with aarch64 target: https://godbolt.org/z/Wxcf6r7sP gcc x86_64 correctly supports it while gcc arm does not

Re: [PATCH] fix PowerPC < 7 w/ Altivec not to default to power7

On 3/8/24 5:30 AM, Jonathan Wakely via Gcc wrote: > Patches should be sent to the gcc-patches list instead of this one, > and should be against trunk not an old gcc-11 RC. See > https://gcc.gnu.org/contribute.html#patches for more details - thanks! And you need to CC the rs6000/pow

Re: [PATCH] fix PowerPC < 7 w/ Altivec not to default to power7

On Fri, 8 Mar 2024 at 11:27, Rene Rebe wrote: > > This might not be the best timing -short before a major release-, > however, Sam just commented on the bug I filled years ago [1], so here > we go: > > Glibc uses .machine to determine assembler optimizations to use. > However

[PATCH] fix PowerPC < 7 w/ Altivec not to default to power7

This might not be the best timing -short before a major release-, however, Sam just commented on the bug I filled years ago [1], so here we go: Glibc uses .machine to determine assembler optimizations to use. However, since reworking the rs6000 .machine output selection in commit

Re: Expected warning maybe-uninitialized does not appear using g++13.2.0?

, function g starts with void g () { size_type __dnew; struct string a; [...] [local count: 1073741824]: _26 = a._M_string_length; if (_26 == 4611686018427387903) which should not require any interprocedural logic. -- Marc Glisse

Re: Expected warning maybe-uninitialized does not appear using g++13.2.0?

On Wed, 2023-12-20 at 11:16 -0800, Eric Batchelor wrote: > Hello, I unintentionally stumbled upon some strange behaviour that > occurred due to a typo. > I reproduced the behaviour where an object (std::string in my case) > can > be passed to a function by reference, uninitialized, WITHOUT a > co

Expected warning maybe-uninitialized does not appear using g++13.2.0?

Hello, I unintentionally stumbled upon some strange behaviour that occurred due to a typo. I reproduced the behaviour where an object (std::string in my case) can be passed to a function by reference, uninitialized, WITHOUT a compiler warning. Changing the code to pass the object by value DOES

The codeblocks which I installed is not compiling the program so guid me How to install a c compiler to codeblocks

Re: gcc/DATESTAMP not updated since 20231109

On Tue, Nov 14, 2023 at 09:30:21AM +0100, Rainer Orth wrote: > For the last couple of days (since 2023-11-09), gcc/DATESTAMP hasn't > been updated. I'll have a look. Probably some bad commit again. Jakub

gcc/DATESTAMP not updated since 20231109

For the last couple of days (since 2023-11-09), gcc/DATESTAMP hasn't been updated. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University

Subreg promotion not happening for the test case

Hi Jeff, Robin, This morning I was talking about the following test where subreg promoted is not being generated during expand, whereas for RISC-V ABI/ISA it should. gcc.c-torture/compile/20070121.c -Os -march=rv64gc -mabi=lp64d expand_gimple_basic_block     expand_gimple_stmt

Re: why not optimize static local variables

0; > x++; > } > > int main() { > foo(); > } > > After optimization with the -O3 -flto option, the entire program will > look something like this: > > int main() { > x_foo++; > } > > The question I want to ask is, why not optimize the 'x_foo++' lin

why not optimize static local variables

will look something like this: int main() { x_foo++; } The question I want to ask is, why not optimize the 'x_foo++' line of code out? Because its scope will only be in foo, and it will not be read at all for the entire program. Is it because it is stored in the global data area? Or

Re: Function return value can't be infered when it's not inlined

>>>> Hi, I'm a little confused about the behavior of gcc when the function >>>> is not inlined. >>>> >>>> Here is an example code: >>>> >>>> int __attribute__((noinline)) foo() { >>>>return

Re: Function return value can't be infered when it's not inlined

Richard Biener 于2023年10月4日周三 16:43写道： > > On Wed, Oct 4, 2023 at 10:37 AM Richard Biener > wrote: > > > > On Tue, Oct 3, 2023 at 6:30 PM Hanke Zhang via Gcc wrote: > > > > > > Hi, I'm a little confused about the behavior of gcc when the function

Re: Function return value can't be infered when it's not inlined

On Wed, Oct 4, 2023 at 10:37 AM Richard Biener wrote: > > On Tue, Oct 3, 2023 at 6:30 PM Hanke Zhang via Gcc wrote: > > > > Hi, I'm a little confused about the behavior of gcc when the function > > is not inlined. > > > > Here is an example code:

Re: Function return value can't be infered when it's not inlined

On Tue, Oct 3, 2023 at 6:30 PM Hanke Zhang via Gcc wrote: > > Hi, I'm a little confused about the behavior of gcc when the function > is not inlined. > > Here is an example code: > > int __attribute__((noinline)) foo() { > return 1; > } > > int main()

Function return value can't be infered when it's not inlined

Hi, I'm a little confused about the behavior of gcc when the function is not inlined. Here is an example code: int __attribute__((noinline)) foo() { return 1; } int main() { if (foo()) { printf("foo() returned 1\n"); } else { printf(&quo

Re: Using _POSIX_SEM_VALUE_MAX not _SC_SEM_VALUE_MAX?

On Sat, 2023-07-08 at 12:33 -0400, Paul Smith wrote: > On Sat, 2023-07-08 at 17:30 +0200, Andreas Schwab wrote: > > That needs to be sysconf (_SC_SEM_VALUE_MAX), and thus is not > > suitable for a constexpr. > > Oh right, obviously. > > Well, I guess I'll have t

Re: Using _POSIX_SEM_VALUE_MAX not _SC_SEM_VALUE_MAX?

On Sat, 2023-07-08 at 17:30 +0200, Andreas Schwab wrote: > That needs to be sysconf (_SC_SEM_VALUE_MAX), and thus is not > suitable for a constexpr. Oh right, obviously. Well, I guess I'll have to try to figure out why it's not defined. Sigh.

Re: Using _POSIX_SEM_VALUE_MAX not _SC_SEM_VALUE_MAX?

On Jul 08 2023, Paul Smith wrote: > Unfortunately because I am using limits.h from the clang intrinsics / > resource directory (else many other things break), _POSIX_SEM_VALUE_MAX > is not defined. POSIX requires conforming implementations to define _POSIX_SEM_VALUE_MAX. > I can&#x

Using _POSIX_SEM_VALUE_MAX not _SC_SEM_VALUE_MAX?

er things break), _POSIX_SEM_VALUE_MAX is not defined. I can't quite figure out why, and my attempts to generate preprocessor output to track it down through the #include / #define maze have failed. But the error I get (from clangd) suggests I want to be using _SC_SEM_VALUE_MAX and indeed if I

RE: gcc/config.in was not regenerated

Hi Coudert, Sorry, missed that one. I'll fix that. Tamar. > -Original Message- > From: FX Coudert > Sent: Saturday, June 10, 2023 9:21 PM > To: Tamar Christina > Cc: gcc@gcc.gnu.org; Jeff Law ; gcc- > patc...@gcc.gnu.org > Subject: gcc/config.in w

gcc/config.in was not regenerated

Hi, Building GCC in maintainer mode leads to changes in gcc/config.in : > diff --git a/gcc/config.in b/gcc/config.in > index 4cad077bfbe..25442c59aec 100644 > --- a/gcc/config.in > +++ b/gcc/config.in > @@ -67,6 +67,12 @@ > #endif > +/* Define to larger than one set the n

Re: std::format not listed on the C++ Standards support page

On Wed, 10 May 2023 at 17:38, C. Heide via Gcc wrote: > > Hello, just a note that support for std::format (P0645R10) does > not seem to be listed anywhere on the current C++ Standards > Support page (https://gcc.gnu.org/projects/cxx-status.html). > > I was trying to figure out

Re: std::format not listed on the C++ Standards support page

On Wed, May 10, 2023 at 06:45:55PM +0200, Jakub Jelinek via Gcc wrote: > On Wed, May 10, 2023 at 10:38:02AM -0600, C. Heide via Gcc wrote: > > Hello, just a note that support for std::format (P0645R10) does > > not seem to be listed anywhere on the current C++ Standards > >

Re: std::format not listed on the C++ Standards support page

On Wed, 10 May 2023 at 17:47, Jakub Jelinek via Gcc wrote: > > On Wed, May 10, 2023 at 10:38:02AM -0600, C. Heide via Gcc wrote: > > Hello, just a note that support for std::format (P0645R10) does > > not seem to be listed anywhere on the current C++ Standards >

Re: std::format not listed on the C++ Standards support page

On Wed, May 10, 2023 at 10:38:02AM -0600, C. Heide via Gcc wrote: > Hello, just a note that support for std::format (P0645R10) does > not seem to be listed anywhere on the current C++ Standards > Support page (https://gcc.gnu.org/projects/cxx-status.html). > > I was trying to figur

std::format not listed on the C++ Standards support page

Hello, just a note that support for std::format (P0645R10) does not seem to be listed anywhere on the current C++ Standards Support page (https://gcc.gnu.org/projects/cxx-status.html). I was trying to figure out if it was supposed to be in the 12.3 release or not, but based on PR104166 I guess

Re: Tags not allowed in user repository - Mildly urgent

ref in the GCC repo. The >>>> tag is annotated but the push was rejected. Here is the command >>>> >>>> git push origin master:refs/users/kubaneko/tags/Thesis Thesis >>>> >>>> and here is the response >>>> >>>> Total

Re: Tags not allowed in user repository - Mildly urgent

rejected. Here is the command >>> >>> git push origin master:refs/users/kubaneko/tags/Thesis Thesis >>> >>> and here is the response >>> >>> Total 0 (delta 0), reused 0 (delta 0), pack-reused 0 >>> remote: *** Lightweight tags ('kuban

Re: Tags not allowed in user repository - Mildly urgent

gin master:refs/users/kubaneko/tags/Thesis Thesis >> >> and here is the response >> >> Total 0 (delta 0), reused 0 (delta 0), pack-reused 0 >> remote: *** Lightweight tags ('kubaneko/tags/Thesis' in namespace >> 'refs/users') are not a

Re: Tags not allowed in user repository - Mildly urgent

the response > > Total 0 (delta 0), reused 0 (delta 0), pack-reused 0 > remote: *** Lightweight tags ('kubaneko/tags/Thesis' in namespace > 'refs/users') are not allowed in this repository. > remote: *** Use 'git tag [ -a | -s ]' for tags you want to propaga

Re: Tags not allowed in user repository - Mildly urgent

On Mai 10 2023, Ondřej Kubánek via Gcc wrote: > ! [remote rejected] master -> refs/users/kubaneko/tags/Thesis > (hook declined) As you can see here, you are not pushing the tag Thesis, but the local branch master. If you want to push the local tag Thesis to a particular pla

Tags not allowed in user repository - Mildly urgent

: *** Lightweight tags ('kubaneko/tags/Thesis' in namespace 'refs/users') are not allowed in this repository. remote: *** Use 'git tag [ -a | -s ]' for tags you want to propagate. remote: error: hook declined to update refs/users/kubaneko/tags/Thesis To git+ssh://gcc.

Re: can-be-null can-not-be-null break-instruction for better handling pointers.

Hi, I agree with you that C would benefit from a new type qualifier to indicate pointer nullability, although not with your suggestion that such a qualifier should indicate the property cannot-be-null. If you just want a syntax for declaring that a function parameter is not a null pointer, C

can-be-null can-not-be-null break-instruction for better handling pointers.

I am not C expert, so be polity. I do not see something similar in C world, but similar techniques in other languages, such like Vala. I suggest to create two new pointer type: 1. can-be-null 2. cannot-be-null (You must find other words to describe it behavior). First enforces to compiler

Re: zero length array example does not compile

, 25 Apr 2023 at 13:13, Jonny Grant wrote: >>>>> >>>>> Hello >>>>> >>>>> https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html >>>>> >>>>> I wondered 'this_length' refers to in that example, it doesn't c

Re: zero length array example does not compile

t; Hello > >>> > >>> https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html > >>> > >>> I wondered 'this_length' refers to in that example, it doesn't compile. > >> > >> It's not supposed to be a complete program. > >>

Re: zero length array example does not compile

; >>> I wondered 'this_length' refers to in that example, it doesn't compile. >> >> It's not supposed to be a complete program. >> >>> >>> : In function 'main&#

Re: zero length array example does not compile

On Tue, 25 Apr 2023 at 13:17, Jonathan Wakely wrote: > > On Tue, 25 Apr 2023 at 13:13, Jonny Grant wrote: > > > > Hello > > > > https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html > > > > I wondered 'this_length' refers to in that example, it doe

Re: zero length array example does not compile

On Tue, 25 Apr 2023 at 13:13, Jonny Grant wrote: > > Hello > > https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html > > I wondered 'this_length' refers to in that example, it doesn't compile. It's not supposed to be a complete program. > > : In fu

zero length array example does not compile

Hello https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html I wondered 'this_length' refers to in that example, it doesn't compile. : In function 'main': :13:34: error: 'this_length' undeclared (first use in this function) 13 | malloc (sizeof (struct line) + this_length); |

g++ does not suppress warnings even isystem flag is set

Hello. We use g++ to compile our big project and we use many 3rd party libraries and frameworks inside(like Qt or Poco). Some of these frameworks generate many warnings, so we use flag isystem to mark them as system to suppress 3dparty warnings. But it seems not all warnings suppressing by

Re: LTO apparently does not support _FloatNx types

t; ./gcc/gcc/testsuite/gcc.dg/torture/float16-complex.c \ > > > -O2 -flto -fno-use-linker-plugin -flto-partition=none -lm -o > > > ./float16-complex.exe > > > > > > I narrowed it down to the fact that lto-lang does not support _FloatNx > > > types, the function "

Re: LTO apparently does not support _FloatNx types

n "gcc.dg/torture/float16-complex.c" > > when compiled with lto: > > > > ./gcc/build/gcc/xgcc -B./gcc/build/gcc/ > > ./gcc/gcc/testsuite/gcc.dg/torture/float16-complex.c \ > > -O2 -flto -fno-use-linker-plugin -flto-partition=none -lm -o > > ./float16

Re: LTO apparently does not support _FloatNx types

/gcc/xgcc -B./gcc/build/gcc/ > ./gcc/gcc/testsuite/gcc.dg/torture/float16-complex.c \ > -O2 -flto -fno-use-linker-plugin -flto-partition=none -lm -o > ./float16-complex.exe > > I narrowed it down to the fact that lto-lang does not support _FloatNx > types, the f

Re: LRA produces RTL not meeting constraint

On Wed, Jan 11, 2023 at 07:38:44PM -0500, Paul Koning wrote: > > On Jan 11, 2023, at 2:52 PM, Segher Boessenkool > > wrote: > > On Tue, Jan 10, 2023 at 02:39:34PM -0500, Paul Koning via Gcc wrote: > > Before reload it did not have operands[0] and operands[1] the same, &

LTO apparently does not support _FloatNx types

use-linker-plugin -flto-partition=none -lm -o ./float16-complex.exe I narrowed it down to the fact that lto-lang does not support _FloatNx types, the function "lto_type_for_mode" (in gcc/lto/lto-lang.c) and "c_common_type_for_mode" (in gcc/c-family/c-common.c) are exactly the same

Re: LRA produces RTL not meeting constraint

0 11:r175 l0 0 13:r176 l0 2 12:r177 l0 2 > 10:r178 l0 06:r179 l0 mem7:r180 l0 04:r184 l0 0 > > so R5, if I read that correctly. Which makes sense given that the input > operand is R5. >> >>> Then in the .reload dump it appears this w

Re: LRA produces RTL not meeting constraint

d dump it appears this way: >> >> (insn 49 48 53 5 (set (reg/f:HI 5 r5 [136]) >>(plus:HI (reg/f:HI 6 sp) >>(const_int 40 [0x28]))) >> "../../../../../gcc/libgcc/libgcc2.c":276:4 68 {addhi3} >> (expr_list:REG_EQUIV (plus:HI (reg/f:HI

Re: LRA produces RTL not meeting constraint

../gcc/libgcc/libgcc2.c":276:4 68 {addhi3} > (expr_list:REG_EQUIV (plus:HI (reg/f:HI 5 r5) > (const_int -8 [0xfff8])) > (nil))) > > which obviously causes an ICE because that RTL doesn't meet the constraints. Before reload it did n

LRA produces RTL not meeting constraint

In pdp11.md I have: (define_insn_and_split "addhi3" [(set (match_operand:HI 0 "nonimmediate_operand" "=rR,rR,Q,Q") (plus:HI (match_operand:HI 1 "general_operand" "%0,0,0,0") (match_operand:HI 2 "general_operand" "rRLM,Qi,rRLM,Qi")))] "" "#" "reload_completed" [(p

Re: Division by zero on A53 which does not raise an exception

The 11/28/2022 21:37, Stephen Smith via Binutils wrote: > I am working on a project which is using an A53 core. The core does not > raise an exception if there is a division by zero (for either integer or > floating point division). floating-point division by zero signals the FE_

Re: Division by zero on A53 which does not raise an exception

On Tue, Nov 29, 2022 at 5:39 AM Stephen Smith via Gcc wrote: > > I am working on a project which is using an A53 core. The core does not > raise an exception if there is a division by zero (for either integer or > floating point division). > > The designers chose to set s

Division by zero on A53 which does not raise an exception

I am working on a project which is using an A53 core. The core does not raise an exception if there is a division by zero (for either integer or floating point division). The designers chose to set status bits for the floating point case but not raise an exception.With the integer

Re: Setting test suite not to try debug output cases

ain-output -Og -g -w -c -o 2105-1.o > >> /Users/pkoning/Documents/svn/gcc/gcc/testsuite/gcc.c-torture/compile/2105-1.c > >> xgcc: warning: target system does not support debug output > >> cc1: warning: target system does not support debug output > >> FA

Re: Setting test suite not to try debug output cases

t; >> spawn -ignore SIGHUP /Users/pkoning/Documents/svn/build/pdp/gcc/xgcc >> -B/Users/pkoning/Documents/svn/build/pdp/gcc/ -mlra >> -fdiagnostics-plain-output -Og -g -w -c -o 2105-1.o >> /Users/pkoning/Documents/svn/gcc/gcc/testsuite/gcc.c-torture/compile/2105-1.c &g

Re: Setting test suite not to try debug output cases

ild/pdp/gcc/ -mlra > -fdiagnostics-plain-output -Og -g -w -c -o 2105-1.o > /Users/pkoning/Documents/svn/gcc/gcc/testsuite/gcc.c-torture/compile/2105-1.c > xgcc: warning: target system does not support debug output > cc1: warning: target system does not support debug output > FAIL: g

Setting test suite not to try debug output cases

/Documents/svn/gcc/gcc/testsuite/gcc.c-torture/compile/2105-1.c xgcc: warning: target system does not support debug output cc1: warning: target system does not support debug output FAIL: gcc.c-torture/compile/2105-1.c -Og -g (test for excess errors) I assume there is some way in the test suite

Re: [MRISC32] Not getting scaled index addressing in loops

). I recently discovered that scaled index addressing (i.e. MEM[base + index * scale]) does not work inside loops, but I have not been able to figure out why. I believe that I have all the plumbing in the MD that's required (MAX_REGS_PER_ADDRESS, REGNO_OK_FOR_BASE_P, REGNO_OK_FOR_INDEX_P, etc),

Re: [MRISC32] Not getting scaled index addressing in loops

> I recently discovered that scaled index addressing (i.e. MEM[base + > index * scale]) does not work inside loops, but I have not been able to > figure out why. > > I believe that I have all the plumbing in the MD that's required > (MAX_REGS_PER_ADDRESS, REGNO_OK_FOR_BASE_P, RE

Re: [MRISC32] Not getting scaled index addressing in loops

I'm sorry about the messed up code formatting (I blame the WYSIWYG). I hope the message gets through anyway (have a look at the Compiler Explorer link - https://godbolt.org/z/drzfjsxf7 - it has all the code). /Marcus

[MRISC32] Not getting scaled index addressing in loops

* scale]) does not work inside loops, but I have not been able to figure out why. I believe that I have all the plumbing in the MD that's required (MAX_REGS_PER_ADDRESS, REGNO_OK_FOR_BASE_P, REGNO_OK_FOR_INDEX_P, etc), and I have verified that scaled index addressing is used in trivial cases

  1   2   3   4   5   6   7   8   9   10   >