Re: for discussion: should we close all the Java-related bugs?

[Andrew Pinski via Gcc-bugs]

On Fri, Apr 26, 2024 at 11:28 AM Abe Skolnik via Gcc-bugs
 wrote:
>
> Dear all,
>
> AFAIK, GCJ has been dead for _years_...  quoting 
> : "As of GCC 7, the GCC Java frontend and 
> associated libjava runtime library have been removed from GCC. The 
> information on this page is kept here for reference but only applies to GCC 6 
> and earlier."
>
> ... yet we still have at least...
>
> 67 bugs open against the component "awt":  
> https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=__open__=awt
>
> ... and at least...
>
> 479 bugs open against the product "classpath":  
> https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=__open__=classpath
>
>
>
> For discussion: why not close _all_ Java-related bugs in the GCC bugzilla, 
> perhaps with a nicely-granular status such as 
> "CLOSED_WONTFIX___WONTFIX_BECAUSE_FEATURE_IS_DEPRECATED", or at least "good" 
> old "CLOSED_WONTFIX"?
>
>
>
> With all due respect to whoever [if anybody] is unhappily still responsible 
> for backporting bug-fixes to pre-7 GCC re e.g. the C or C++ or Fortran 
> compiler[s], I think the chances of _anybody_ *ever* fixing those old 
> Java-in-GCC bugs is _extremely_ tiny.

Note the classpath component is not about GCJ (and GCC) but rather it
is for the GNU classpath project which is not really active but it is
still a project and might become more active in the future. So closing
these as won't fix is NOT the correct thing to do unless the classpath
project itself has decided it no longer wants to use the GCC's
bugzilla instance or has decided it is no longer being a project.

Thanks,
Andrew Pinski

>
> Sincerely,
>
> Abe

Re: _BitInt() as underlying enum type

[Andrew Pinski via Gcc-bugs]

On Sat, Jan 27, 2024 at 6:24 PM Andrew Pinski  wrote:
>
> On Sat, Jan 27, 2024 at 6:07 PM Thomas Voss via Gcc-bugs
>  wrote:
> >
> > Hi all,
> >
> > Earlier today I decided to clone the GCC repo and build the latest code
> > just to play around with some new C23 features.  One thing I attempted
> > was the following:
> >
> > typedef _BitInt(128) underlying;
> > enum my_enum : underlying {
> > FOO = (underlying)1 << 100;
> > BAR = (underlying)1 << 101;
> > };
> >
> > I expected this to work — it builds on Clang too — but it failed to
> > compile with the error ‘invalid underlying type’ (or something like that;
> > I’m going off of memory).
>
> The trunk  of clang rejects it:
> ```
> :4:20: error: 'underlying' (aka '_BitInt(128)') is an invalid
> underlying type
> 4 | enum my_enum : underlying {
>   |^
> ```
> While clang 17.0 accepts it.  So it looks like clang fixed their bug.

Just an FYI, the clang issue was
https://github.com/llvm/llvm-project/issues/69619 .
With the following commit to the LLVM git repo as the fix:
https://github.com/llvm/llvm-project/commit/5175cd777c57190ab9860c304796d386e4df9b8f


>
> Thanks,
> Andrew
>
> >
> > I took a look into the C23 working draft and I see no reference to
> > bit-precise integers being disallowed as an underlying type to an
> > enumeration.  As a result I assume this is a bug in GCC so I’m reporting
> > it here just in case.  If it’s not a bug, do let me know why that is the
> > case.
> >
> > --
> > — Thomas

Re: _BitInt() as underlying enum type

[Andrew Pinski via Gcc-bugs]

On Sat, Jan 27, 2024 at 6:07 PM Thomas Voss via Gcc-bugs
 wrote:
>
> Hi all,
>
> Earlier today I decided to clone the GCC repo and build the latest code
> just to play around with some new C23 features.  One thing I attempted
> was the following:
>
> typedef _BitInt(128) underlying;
> enum my_enum : underlying {
> FOO = (underlying)1 << 100;
> BAR = (underlying)1 << 101;
> };
>
> I expected this to work — it builds on Clang too — but it failed to
> compile with the error ‘invalid underlying type’ (or something like that;
> I’m going off of memory).

The trunk  of clang rejects it:
```
:4:20: error: 'underlying' (aka '_BitInt(128)') is an invalid
underlying type
4 | enum my_enum : underlying {
  |^
```
While clang 17.0 accepts it.  So it looks like clang fixed their bug.

Thanks,
Andrew

>
> I took a look into the C23 working draft and I see no reference to
> bit-precise integers being disallowed as an underlying type to an
> enumeration.  As a result I assume this is a bug in GCC so I’m reporting
> it here just in case.  If it’s not a bug, do let me know why that is the
> case.
>
> --
> — Thomas

Re: Strange compile error when g++ work with std=c++20.

[Andrew Pinski via Gcc-bugs]

On Mon, Nov 27, 2023 at 8:24 PM Lew Robin via Gcc-bugs
 wrote:
>
> This error happens when using macro and template.
> GCC Version: gcc version 12.3.0 (Ubuntu 12.3.0-1ubuntu1~22.04)
> OS: ubuntu 22.04 (x64)
> Compile Command:
> g++-12 ./testmacro.cc --std=c++20
>
> In fact, this error exisits from g++11 to g++13.  I also test it on clang and 
> msvc, but it cannot be reproduced.

GCC is correct here.

See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103593 which points
to C++20 DR 2237 (and the bug about diagnostic that should be improved
is https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97202).
I suspect clang and MSVC has not implemented that C++ defect report
which is why it is accepted by those 2.

Thanks,
Andrew Pinski


>
> short reproduction:
> #include 
>
> #define DECLARE_SINGLETON(classname_type) \
>   public: \
>   classname_type();
>
> template 
> class ReceiverManager
> {
> public:
>   ~ReceiverManager() { }
>
> private:
>   MessageT receiver_map_;
>   DECLARE_SINGLETON(ReceiverManager)
> };
>
> template 
> ReceiverManager::ReceiverManager(){}
>
> int main()
> {
>   auto m = ReceiverManager();
>   return 0;
> }
> compile it and report error:
>
> ./testmacro.cc:5:24: error: expected unqualified-id before ‘)’ token
> 5 | classname_type();
>   |^
> ./testmacro.cc:15:9: note: in expansion of macro ‘DECLARE_SINGLETON’
>15 | DECLARE_SINGLETON(ReceiverManager)
>   | ^
> ./testmacro.cc:19:1: error: no declaration matches 
> ‘ReceiverManager::ReceiverManager()’
>19 | ReceiverManager::ReceiverManager(){}
>   | ^
> ./testmacro.cc:19:1: note: no functions named 
> ‘ReceiverManager::ReceiverManager()’
> ./testmacro.cc:8:7: note: ‘class ReceiverManager’ defined here
> 8 | class ReceiverManager
>   |   ^~~

Re: Compiler bug with bitfields

[Andrew Pinski via Gcc-bugs]

On Thu, Aug 24, 2023 at 8:06 PM libreknight via Gcc-bugs
 wrote:
>
> Greetings.
>
> I have come across erroneous behavior whilst comparing optimizations
> performed by different compilers. Said behavior persists through
> different versions of GCC and flags. The output from GCC is incorrect
> and diverges from all compilers.
>
> In order to reproduce aforementioned behavior, compile with any flags of
> your liking the following code:
>
> #include 
> #include 
>
> typedef struct
> {
>   unsigned char value:1;
> } boolean;
>
> int
> main (void)
> {
>   boolean var;
>
>   var.value = 0;
>
>   printf ("%d %d\n", --var.value, --var.value);


GCC does produce a warning:
: In function 'main':
:16:35: warning: operation on 'var.value' may be undefined
[-Wsequence-point]
   16 |   printf ("%d %d\n", --var.value, --var.value);
  |   ^~~


Anyways the order of evaluation is not specified in the C standard
when it comes to function arguments; left to right or right to left is
both valid.

Thanks,
Andrew Pinski

>
>   return EXIT_SUCCESS;
> }
>
> The outcome disparates from the expected by producing the opposite
> result.
>
> GCC:
> 0 1
>
> clang, tcc, icc, icx, msvc, compcert:
> 1 0
>
> Inasmuch as the potential consequences of faulty logic allows for
> undefined behavior, security vulnerabilities emerges. Nevertheless,
> acknowledging the atypicality of causal application, I evaluate the
> significance of low-medium priority.
>
> Thanks in advance.

Re: [PATCH] match.pd: Implement missed optimization (x << c) >> c -> -(x & 1) [PR101955]

[Andrew Pinski via Gcc-bugs]

On Thu, Jul 20, 2023 at 8:17 AM Andrew Pinski  wrote:
>
> On Thu, Jul 20, 2023 at 7:47 AM Drew Ross via Gcc-bugs
>  wrote:
> >
> > PR middle-end/101955
> >
> > gcc/ChangeLog:
> >
> > * match.pd (x << c) >> c -> -(x & 1): New simplification.
> >
> > gcc/testsuite/ChangeLog:
> >
> > * gcc.dg/pr101955.c: New test.
> > ---
> >  gcc/match.pd|  9 +
> >  gcc/testsuite/gcc.dg/pr101955.c | 62 +
> >  2 files changed, 71 insertions(+)
> >  create mode 100644 gcc/testsuite/gcc.dg/pr101955.c
> >
> > diff --git a/gcc/match.pd b/gcc/match.pd
> > index 8543f777a28..bf63652e80f 100644
> > --- a/gcc/match.pd
> > +++ b/gcc/match.pd
> > @@ -3766,6 +3766,15 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
> >&& (wi::ltu_p (wi::to_wide (@1), element_precision (type
> >(bit_and @0 (rshift { build_minus_one_cst (type); } @1
> >
> > +/* Optimize (X << C) >> C where C = precision(type) - 1 and X is signed
> > +   into -(X & 1).  */
> > +(simplify
> > + (rshift (lshift @0 INTEGER_CST@1) @@1)
> > + (if (ANY_INTEGRAL_TYPE_P (type)
> > +  && !TYPE_UNSIGNED (type)
> > +  && wi::eq_p (wi::to_wide (@1), element_precision (type) - 1))
> > +  (negate (bit_and @0 { build_one_cst (type); }
>
> I think the lshift does not need to be in the same type but could be
> in the unsigned type so you should add a nop_convert? operand there
> That is:
> (simplify
>  (rshift (nop_convert? (lshift @0 INTEGER_CST@1)) @@1)
> ...
>  (negate (bit_and (convert @0) { build_one_cst (type); }
>
> Note I see you use INTEGER_CST and then ANY_INTEGRAL_TYPE_P. If you
> are going to support vectors, you should use uniform_integer_cst_p
> instead of INTEGER_CST and then use uniform_integer_cst_p to get the
> constant.

Note I just noticed you sent the patch to gcc-bugs@, it really should
go to gcc-patches@ .

Thanks,
Andrew

>
> Thanks,
> Andrew
>
>
> > +
> >  /* Optimize x >> x into 0 */
> >  (simplify
> >   (rshift @0 @0)
> > diff --git a/gcc/testsuite/gcc.dg/pr101955.c 
> > b/gcc/testsuite/gcc.dg/pr101955.c
> > new file mode 100644
> > index 000..0e233269e21
> > --- /dev/null
> > +++ b/gcc/testsuite/gcc.dg/pr101955.c
> > @@ -0,0 +1,62 @@
> > +/* { dg-do compile } */
> > +/* { dg-options "-O2 -fdump-tree-dse1 -Wno-psabi" } */
> > +
> > +typedef int v4si __attribute__((vector_size(16)));
> > +
> > +__attribute__((noipa)) int
> > +t1 (int x)
> > +{
> > +  return (x << 31) >> 31;
> > +}
> > +
> > +__attribute__((noipa)) int
> > +t2 (int x)
> > +{
> > +  int y = x << 31;
> > +  int z = y >> 31;
> > +  return z;
> > +}
> > +
> > +__attribute__((noipa)) int
> > +t3 (int x)
> > +{
> > +  int w = 31;
> > +  int y = x << w;
> > +  int z = y >> w;
> > +  return z;
> > +}
> > +
> > +__attribute__((noipa)) long long
> > +t4 (long long x)
> > +{
> > +  return (x << 63) >> 63;
> > +}
> > +
> > +__attribute__((noipa)) long long
> > +t5 (long long x)
> > +{
> > +  long long y = x << 63;
> > +  long long z = y >> 63;
> > +  return z;
> > +}
> > +
> > +__attribute__((noipa)) long long
> > +t6 (long long x)
> > +{
> > +  int w = 63;
> > +  long long y = x << w;
> > +  long long z = y >> w;
> > +  return z;
> > +}
> > +
> > +__attribute__((noipa)) v4si
> > +t7 (v4si x)
> > +{
> > +  return (x << 31) >> 31;
> > +}
> > +
> > +/* { dg-final { scan-tree-dump-not " >> " "dse1" } } */
> > +/* { dg-final { scan-tree-dump-not " << " "dse1" } } */
> > +/* { dg-final { scan-tree-dump-times " -" 7 "dse1" } } */
> > +/* { dg-final { scan-tree-dump-times " & " 7 "dse1" } } */
> > +
> > --
> > 2.39.3
> >

Re: [PATCH] match.pd: Implement missed optimization (x << c) >> c -> -(x & 1) [PR101955]

[Andrew Pinski via Gcc-bugs]

On Thu, Jul 20, 2023 at 7:47 AM Drew Ross via Gcc-bugs
 wrote:
>
> PR middle-end/101955
>
> gcc/ChangeLog:
>
> * match.pd (x << c) >> c -> -(x & 1): New simplification.
>
> gcc/testsuite/ChangeLog:
>
> * gcc.dg/pr101955.c: New test.
> ---
>  gcc/match.pd|  9 +
>  gcc/testsuite/gcc.dg/pr101955.c | 62 +
>  2 files changed, 71 insertions(+)
>  create mode 100644 gcc/testsuite/gcc.dg/pr101955.c
>
> diff --git a/gcc/match.pd b/gcc/match.pd
> index 8543f777a28..bf63652e80f 100644
> --- a/gcc/match.pd
> +++ b/gcc/match.pd
> @@ -3766,6 +3766,15 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
>&& (wi::ltu_p (wi::to_wide (@1), element_precision (type
>(bit_and @0 (rshift { build_minus_one_cst (type); } @1
>
> +/* Optimize (X << C) >> C where C = precision(type) - 1 and X is signed
> +   into -(X & 1).  */
> +(simplify
> + (rshift (lshift @0 INTEGER_CST@1) @@1)
> + (if (ANY_INTEGRAL_TYPE_P (type)
> +  && !TYPE_UNSIGNED (type)
> +  && wi::eq_p (wi::to_wide (@1), element_precision (type) - 1))
> +  (negate (bit_and @0 { build_one_cst (type); }

I think the lshift does not need to be in the same type but could be
in the unsigned type so you should add a nop_convert? operand there
That is:
(simplify
 (rshift (nop_convert? (lshift @0 INTEGER_CST@1)) @@1)
...
 (negate (bit_and (convert @0) { build_one_cst (type); }

Note I see you use INTEGER_CST and then ANY_INTEGRAL_TYPE_P. If you
are going to support vectors, you should use uniform_integer_cst_p
instead of INTEGER_CST and then use uniform_integer_cst_p to get the
constant.

Thanks,
Andrew


> +
>  /* Optimize x >> x into 0 */
>  (simplify
>   (rshift @0 @0)
> diff --git a/gcc/testsuite/gcc.dg/pr101955.c b/gcc/testsuite/gcc.dg/pr101955.c
> new file mode 100644
> index 000..0e233269e21
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/pr101955.c
> @@ -0,0 +1,62 @@
> +/* { dg-do compile } */
> +/* { dg-options "-O2 -fdump-tree-dse1 -Wno-psabi" } */
> +
> +typedef int v4si __attribute__((vector_size(16)));
> +
> +__attribute__((noipa)) int
> +t1 (int x)
> +{
> +  return (x << 31) >> 31;
> +}
> +
> +__attribute__((noipa)) int
> +t2 (int x)
> +{
> +  int y = x << 31;
> +  int z = y >> 31;
> +  return z;
> +}
> +
> +__attribute__((noipa)) int
> +t3 (int x)
> +{
> +  int w = 31;
> +  int y = x << w;
> +  int z = y >> w;
> +  return z;
> +}
> +
> +__attribute__((noipa)) long long
> +t4 (long long x)
> +{
> +  return (x << 63) >> 63;
> +}
> +
> +__attribute__((noipa)) long long
> +t5 (long long x)
> +{
> +  long long y = x << 63;
> +  long long z = y >> 63;
> +  return z;
> +}
> +
> +__attribute__((noipa)) long long
> +t6 (long long x)
> +{
> +  int w = 63;
> +  long long y = x << w;
> +  long long z = y >> w;
> +  return z;
> +}
> +
> +__attribute__((noipa)) v4si
> +t7 (v4si x)
> +{
> +  return (x << 31) >> 31;
> +}
> +
> +/* { dg-final { scan-tree-dump-not " >> " "dse1" } } */
> +/* { dg-final { scan-tree-dump-not " << " "dse1" } } */
> +/* { dg-final { scan-tree-dump-times " -" 7 "dse1" } } */
> +/* { dg-final { scan-tree-dump-times " & " 7 "dse1" } } */
> +
> --
> 2.39.3
>

Re: Y2038: GCC gthr-posix.h weakref symbol invoking function has impact on time values

[Andrew Pinski via Gcc-bugs]

On Sun, Apr 16, 2023 at 10:41 PM Puneet Kumar Yatnal (QUIC) via
Gcc-bugs  wrote:
>
>
> ++
> From: Puneet Kumar Yatnal (QUIC)
> Sent: Monday, April 17, 2023 9:26 AM
> To: gcc-h...@gcc.gnu.org
> Subject: Y2038: GCC gthr-posix.h wekref symbol invoking function has impact 
> on time values

First gcc-bugs@ is not the right place to report a bug report as
gcc-bugs is mainly for automated emails from bugzilla. Please use
bugzilla first.

>
> All
>
> if we fallowed https://sourceware.org/glibc/wiki/Y2038ProofnessDesign for 
> Y2038 fix(where all timer related variable moved to 64 bit instead of 32 bit 
> ), pthread_cond_timedwait function from gthr_posix.h is calling different 
> function in pthrea_cond_wait.c of glibc(due to weakref of symbol 
> pthread_cond_timedwait())  which impacting the time value.

Note libstdc++ does ABI changes too which is NOT part of that ABI design.
This is where the symbol
__gthread_cond_timedwait/__gthrw_pthread_cond_timedwait are used. So
any changes you might do to fix __gthrw_pthread_cond_timedwait is not
really going to work without wider ABI fixes to libstdc++.
I don't know any one who is making those changes/fixes. So you should
file an bug requesting it. And maybe even have a design document ready
for it. There are many/some classes which have timespec inside them
and not just the mutex related ones.

Thanks,
Andrew

>
> From pthread.h
> extern int pthread_cond_timedwait (pthread_cond_t *__restrict __cond, 
> pthread_mutex_t *__restrict __mutex, const struct timespec *__restrict 
> __abstime) __asm__ ("" "__pthread_cond_timedwait64")
>
> From gthread_posix.h:
> static __typeof(pthread_cond_timedwait) __gthrw_pthread_cond_timedwait 
> __attribute__ ((__weakref__("pthread_cond_timedwait"), __copy__ 
> (pthread_cond_timedwait)));
>
>
> __gthrw_(pthread_cond_timedwait) --> ___pthread_cond_timedwait   invoking in 
> glibc instead of   __pthread_cond_timedwait64 which is impacting time value 
> as __pthread_cond_timedwait is converting value from 32 bit to 64 bit.
>
> normal pthread_cond_timedwait is invoking __pthread_cond_timedwait64 properly 
> and its working fine.
>
> From: pthread_cond_wait.c
>
> #if __TIMESIZE == 64
> strong_alias (___pthread_cond_timedwait64, ___pthread_cond_timedwait)
> #else
> strong_alias (___pthread_cond_timedwait64, __pthread_cond_timedwait64)
> libc_hidden_def (__pthread_cond_timedwait64)
>
> int
> ___pthread_cond_timedwait (pthread_cond_t *cond, pthread_mutex_t *mutex,
> const struct timespec *abstime)
> {
>   struct __timespec64 ts64 = valid_timespec_to_timespec64 (*abstime);
>
>   return __pthread_cond_timedwait64 (cond, mutex, );
> }
> #endif /* __TIMESIZE == 64 */
> versioned_symbol (libc, ___pthread_cond_timedwait,
>   pthread_cond_timedwait, GLIBC_2_3_2);
> libc_hidden_ver (___pthread_cond_timedwait, __pthread_cond_timedwait)
> #ifndef SHARED
> strong_alias (___pthread_cond_timedwait, __pthread_cond_timedwait)
> #endif
>
> if add  #defing GTHREAD_USE_WEAK 0  in libgcc/gthr-posix.h issue is resolved 
> but that is not correct way as it disable weakref for all symbol, please let 
> me know what is correct way to fix this, this i observed with   gcc-9.3.0 gcc 
> and glibc 2.34
>
> Regards
> Puneet
>

Re: XMM/YMM assembly bloat

[Andrew Pinski via Gcc-bugs]

On Tue, Feb 14, 2023 at 2:14 PM Owen Cook via Gcc-bugs
 wrote:
>
> Adding white space/newlines outside the function also affect the length of
> assembly.

Note -march=native is dependent on the machine which is being used.
IIRC godbolt uses a few different machines and that means the answer
which -march=native will change based on which machine it is run on.

So don't trust godbolt with -march=native at all.

Thanks,
Andrew

>
> On Tue, Feb 14, 2023 at 5:09 PM Owen Cook  wrote:
>
> > Within "unrollOptimizations.c" compiled on a Ryzen 5 2600 using x86-64 gcc
> > 12.2 "-O2 -march=native" gives vastly different assembler results given
> > some scope things I have found. If the for loop iterator name is both int i
> > in each loop, gcc seemingly spreads arrayA and arrayB into one single XMM
> > register, name them differently and you get usages over XMM and YMM.
> > Additionally, white space seems to be a variable to this as well. you can
> > have the for loops one newline away from each other and this results in XMM
> > YMM, but put them together and you get XMM. Changing float* a to float*
> > const a (same goes for float* b) also changes these values.
> >
> > Godbolt equivalent for simplicity
> > https://godbolt.org/z/4xWrGoPaE
> >

Re: About ' * ' not recognized

[Andrew Pinski via Gcc-bugs]

On Fri, Jan 20, 2023 at 5:05 PM naoki ueda via Gcc-bugs
 wrote:
>
> When I tried to execute the attached file mycalc.c with a command line
> argument, it could not be executed normally only in the case of '*'.
> '+', '-' and '/' can be executed normally, but the compiler cannot
> execute '*' normally. Isn't this a gcc bug?

First off this email list is really for automated messages from gcc's
bugzilla rather than from users reporting issues.

>
>
> ~/Clearning$ ./mycalc 20 * 30

Oh * here is being handled by the shell you are using and being
expanded as all the files in the current working directory. This has
nothing to do with GCC really.
You can use quotes around the * to force the shell not expanding it
such as this:
./mycalc 20 '*' 30

or you use \ to force the shell not to expand what comes after the * like this:
./mycalc 20 \* 30

Thanks,
Andrew Pinski

> 用法:mycalc 数値1 演算子 数値2

Re: ICE on trunk with combination of "-Og -fcontracts", repro link in body

[Andrew Pinski via Gcc-bugs]

On Mon, Jan 2, 2023 at 10:21 AM Gavin Ray  wrote:
>
> I tried but it won't allow me to create an issue on the bugzilla, it says 
> "account creation is not allowed at this time"

Directly from https://gcc.gnu.org/bugzilla/createaccount.cgi :
"Because of spam, account creation through this form is restricted. If
creating an account fails, contact
gcc-bugzilla-account-requ...@gcc.gnu.org to request a GCC Bugzilla
account. You should receive a response within 24 hours."

Thanks,
Andrew Pinski

>
> On Mon, Jan 2, 2023 at 1:17 PM Andrew Pinski  wrote:
>>
>> Please file a bug to bugzilla. With attaching the source there.
>> This list is for automated emails from bugzilla really and most folks
>> are not tracking the list.
>>
>> Thanks,
>> Andrew
>>
>> On Mon, Jan 2, 2023 at 10:16 AM Gavin Ray via Gcc-bugs
>>  wrote:
>> >
>> > Hit the following ICE today, just sharing here to be helpful:
>> >
>> > https://gcc.godbolt.org/z/advKKxK43
>> >
>> > during RTL pass: final
>> > : In member function 'void Stack::push(int)':
>> > :20:3: internal compiler error: in gen_inlined_subroutine_die, at
>> > dwarf2out.cc:25002
>> >20 |   }
>> >   |   ^

Re: ICE on trunk with combination of "-Og -fcontracts", repro link in body

[Andrew Pinski via Gcc-bugs]

Please file a bug to bugzilla. With attaching the source there.
This list is for automated emails from bugzilla really and most folks
are not tracking the list.

Thanks,
Andrew

On Mon, Jan 2, 2023 at 10:16 AM Gavin Ray via Gcc-bugs
 wrote:
>
> Hit the following ICE today, just sharing here to be helpful:
>
> https://gcc.godbolt.org/z/advKKxK43
>
> during RTL pass: final
> : In member function 'void Stack::push(int)':
> :20:3: internal compiler error: in gen_inlined_subroutine_die, at
> dwarf2out.cc:25002
>20 |   }
>   |   ^

Re: [Bug regression/103997] [12 Regression] gcc.target/i386/pr88531-??.c scan-assembler-times FAILs

[Andrew Pinski via Gcc-bugs]

On Sat, Jan 29, 2022 at 2:40 PM write2mark1--- via Gcc-bugs
 wrote:
>
> Why does gcc use CVS and not git

GCC has used git for ~2 years now and before that it was using svn for
~14 years; before that used cvs for ~8 years and then used rcs (though
the overlap between rcs and cvs is real).
GCC's git repo has the history all the way back to the rcs days even.
GCC's web pages are in git too; moved to git before the source base
and before that it was in cvs (the reasons to move to svn were not
needed due to no branch usage, etc.).
So I am not understanding the question here really.

Thanks,
Andrew Pinski





> On Tue, Jan 25, 2022 at 5:27 PM admin at levyhsu dot com via Gcc-bugs <
> gcc-bugs@gcc.gnu.org> wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103997
> >
> > --- Comment #14 from Levy Hsu  ---
> > Hi Avieira and Richard
> >
> > I checked the data for the last half month and you are right, that no real
> > regression was caused. Thank you all for the detailed explanation.

Re: Compilation of rust-demangle.c fails on MinGW

[Andrew Pinski via Gcc-bugs]

On Wed, Aug 4, 2021 at 8:46 AM Eli Zaretskii via Gcc-bugs
 wrote:
>
> > Date: Wed, 4 Aug 2021 15:41:30 +0100
> > From: Jonathan Wakely 
> > Cc: gcc-bugs@gcc.gnu.org, e...@gnu.org
> >
> > > The libiberty README says to report bugs to gcc-bugs@gcc.gnu.org.
> >
> > Well that needs to be fixed. It should point to
> > https://gcc.gnu.org/bugs/ instead.
>
> Which points to GCC Bugzilla, which doesn't have a "libiberty"
> component.  So I suggest to add such a component on the Bugzilla.

It has a demangler component though.

Thanks,
Andrew Pinski

Re: compiler produces an error message

[Andrew Pinski via Gcc-bugs]

On Wed, May 26, 2021 at 8:55 AM lexa kop via Gcc-bugs
 wrote:
>
> [ver]i try compile it on gcc 11 and gcc 12
> [new features]i use gcc modules features(module;export module, import,
> import export)
> [command]g++ *.cpp -std=c++20 -fmodules-ts
> /usr/lib/gcc/x86_64-pc-linux-gnu/12.0.0/include/g++-v12/bits/basic_string.h:
> In member function ‘std::__cxx11::basic_string<_CharT, _Traits,
> _Alloc>::pointer std::__cxx11::basic_string<_CharT, _Traits,
> _Alloc>::_M_create(std::__cxx11::basic_string<_CharT, _Traits,
> _Alloc>::size_type&, std::__cxx11::basic_string<_CharT, _Traits,
> _Alloc>::size_type) [with _CharT = char; _Traits =
> std::char_traits; _Alloc = std::allocator]’:
> /usr/lib/gcc/x86_64-pc-linux-gnu/12.0.0/include/g++-v12/bits/basic_string.h:233:7:
> error: unrecognizable insn:
>   233 |   _M_create(size_type&, size_type);
>   |   ^
> (insn 20 19 21 5 (set (reg:DI 98)
> (reg/v 87 [ __old_capacity ]))
> "/usr/lib/gcc/x86_64-pc-linux-gnu/12.0.0/include/g++-v12/bits/basic_string.tcc":143:7
> -1
>  (nil))
> during RTL pass: vregs
> /usr/lib/gcc/x86_64-pc-linux-gnu/12.0.0/include/g++-v12/bits/basic_string.h:233:7:
> internal compiler error: in extract_insn, at recog.c:2770


The error message does not look related at all to modules.  Can you
file a bug to https://gcc.gnu.org/bugzilla/ after reading
https://gcc.gnu.org/bugs/?

So on the internal compiler error message here, it looks like a mode
is missing for reg 87; I don't know why off hand either.

Thanks,
Andrew

Re: bug in bit structure compilation

[Andrew Pinski via Gcc-bugs]

On Thu, May 14, 2020 at 4:19 PM Geoff Mulligan  wrote:
>
> Version:
> gcc -v
> Using built-in specs.
> COLLECT_GCC=gcc
> COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/7/lto-wrapper
> OFFLOAD_TARGET_NAMES=nvptx-none
> OFFLOAD_TARGET_DEFAULT=1
> Target: x86_64-linux-gnu
> Configured with: ../src/configure -v --with-pkgversion='Ubuntu
> 7.5.0-3ubuntu1~18.04'
> --with-bugurl=file:///usr/share/doc/gcc-7/README.Bugs
> --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++
> --prefix=/usr --with-gcc-major-version-only --program-suffix=-7
> --program-prefix=x86_64-linux-gnu- --enable-shared
> --enable-linker-build-id --libexecdir=/usr/lib
> --without-included-gettext --enable-threads=posix --libdir=/usr/lib
> --enable-nls --enable-bootstrap --enable-clocale=gnu
> --enable-libstdcxx-debug --enable-libstdcxx-time=yes
> --with-default-libstdcxx-abi=new --enable-gnu-unique-object
> --disable-vtable-verify --enable-libmpx --enable-plugin
> --enable-default-pie --with-system-zlib --with-target-system-zlib
> --enable-objc-gc=auto --enable-multiarch --disable-werror
> --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32
> --enable-multilib --with-tune=generic
> --enable-offload-targets=nvptx-none --without-cuda-driver
> --enable-checking=release --build=x86_64-linux-gnu
> --host=x86_64-linux-gnu --target=x86_64-linux-gnu
> Thread model: posix
> gcc version 7.5.0 (Ubuntu 7.5.0-3ubuntu1~18.04)
>
> Here is a simple program:
>
> #include 
>
> int main() {
>struct {
>  int a : 3;
>} foo;
>
>switch (foo.a) {
>case 3: break;
>case 4: break;
>}
>
>if (foo.a == 3) { }
>if (foo.a == 4) { }
> }
>
> When compiling the compiler complains:
> gcc -o a a.c
> a.c: In function ‘main’:
> a.c:10:3: warning: case label value exceeds maximum value for type
> case 4: break;
> ^~~~
>
> It would seem that 4 is within the bounds of 0 to 7.

But the range of foo.a is -4 ... 3  and not 0 ... 7.

>
> Geoff
>