Re: On(c)e more: optimizer failure

[Gabriel Ravier via Gcc]

On 8/22/21 11:22 PM, Stefan Kanthak wrote:

Gabriel Ravier  wrote:


On 8/21/21 10:19 PM, Stefan Kanthak wrote:

Jakub Jelinek  wrote:

[...]


You should file missed optimizations into gcc bugzilla where they can be
seen any time.

You should better implement such missing optimisations your users might
expect from a mature compiler.


I don't have a bugzilla account, and I don't use GCC for anything serious.

Stefan

It's *that* demanding for you to create a Bugzilla account ?

You (and everybody else) if free to use GCC bugzilla.
Everybody and me is but also free NOT to use GCC bugzilla.

Stefan


Yes, you are free not to use the GCC Bugzilla. And GCC developers are 
free to prefer to see bug reports be made to the GCC Bugzilla, as it is 
the place dedicated to GCC bug reports, made specifically for that 
purpose and with the infrastructure to handle it.


What would you think if you had a Github or a Gitlab repository and some 
people felt the need to randomly e-mail you about bugs they found 
instead of filing them using the dedicated Issues system there ? And 
what would you say if, upon being recommended to use that system, they 
said that they are "free not to use" the system dedicated to helping 
them reporting bugs when reporting bugs ? To me, that would just sound 
rude and like they don't actually want to help find and fix bugs.

Re: On(c)e more: optimizer failure

[Stefan Kanthak]

Gabriel Ravier  wrote:

> On 8/22/21 11:22 PM, Stefan Kanthak wrote:

[ 2bugzilla | !2bugzilla ]

>> You (and everybody else) if free to use GCC bugzilla.
>> Everybody and me is but also free NOT to use GCC bugzilla.
>>
>> Stefan
> 
> Yes, you are free not to use the GCC Bugzilla. And GCC developers are 
> free to prefer to see bug reports be made to the GCC Bugzilla, as it is 
> the place dedicated to GCC bug reports, made specifically for that 
> purpose and with the infrastructure to handle it.
> 
> What would you think if you had a Github or a Gitlab repository and some 
> people felt the need to randomly e-mail you about bugs they found 
> instead of filing them using the dedicated Issues system there ? And 
> what would you say if, upon being recommended to use that system, they 
> said that they are "free not to use" the system dedicated to helping 
> them reporting bugs when reporting bugs ? To me, that would just sound 
> rude and like they don't actually want to help find and fix bugs.

That's a VERY WILD and of course RUDE SPECULATION:
0. I'm old school, I don't use git-something.
1. I explicitly invite everybody who reads my web pages or uses code I
   publish there to send bug reports, comments, feedback, flames, ...
   per mail!
Before you ask: I receive quite some mail from complete strangers, even
bug reports.

I consider the statement on 

| gcc is a high volume list for general development discussions about GCC.
| Anything relevant to the development or testing of GCC and not covered
  ~~
| by other mailing lists is suitable for discussion here.

as such an invitation too.

Stefan

JFTR: do you consider your wild speculations to be on-topic here?

Re: On(c)e more: optimizer failure

[Gabriel Ravier via Gcc]

On 8/23/21 3:46 PM, Stefan Kanthak wrote:
> Gabriel Ravier  wrote:
>
>> On 8/22/21 11:22 PM, Stefan Kanthak wrote:
>
> [ 2bugzilla | !2bugzilla ]
>
>>> You (and everybody else) if free to use GCC bugzilla.
>>> Everybody and me is but also free NOT to use GCC bugzilla.
>>>
>>> Stefan
>>
>> Yes, you are free not to use the GCC Bugzilla. And GCC developers are
>> free to prefer to see bug reports be made to the GCC Bugzilla, as it is
>> the place dedicated to GCC bug reports, made specifically for that
>> purpose and with the infrastructure to handle it.
>>
>> What would you think if you had a Github or a Gitlab repository and 
some

>> people felt the need to randomly e-mail you about bugs they found
>> instead of filing them using the dedicated Issues system there ? And
>> what would you say if, upon being recommended to use that system, they
>> said that they are "free not to use" the system dedicated to helping
>> them reporting bugs when reporting bugs ? To me, that would just sound
>> rude and like they don't actually want to help find and fix bugs.
>
> That's a VERY WILD and of course RUDE SPECULATION:
> 0. I'm old school, I don't use git-something.
> 1. I explicitly invite everybody who reads my web pages or uses code I
>    publish there to send bug reports, comments, feedback, flames, ...
>    per mail!
> Before you ask: I receive quite some mail from complete strangers, even
> bug reports.

If you want an example that does not involve git: Let us assume some of 
your users started to randomly use rather impractical means of reporting 
bugs to you, like sending you letters or randomly accosting you in the 
street about them. It would be possible to try and handle those bugs, 
but would you not try to redirect those users to more practical means of 
making bug reports ?


Note that *you* may find e-mail to be a practical way of handling bug 
reports, but from what I know, the GCC development team have found that 
impractical and much less efficient than using a bug tracker, especially 
on such a huge project as GCC: if all the bugs that are reported on the 
Bugzilla were instead reported here and all the discussion about them 
was done here, then today there would have been no less than:

- 12 e-mails about new bugs, and
- 159 e-mails relating to existing bugs

>
> I consider the statement on 
>
> | gcc is a high volume list for general development discussions about 
GCC.

> | Anything relevant to the development or testing of GCC and not covered
>       ~~
> | by other mailing lists is suitable for discussion here.
>
> as such an invitation too.

While this might imply in some way that this mailing list might be 
appropriate for this purpose, would it have taken that much time to also 
take a look at the GCC homepage ? The sidebar has an entire "Bugs" 
section, including a link literally called "How to report", which states 
directly to "Please submit your bug report directly to the GCC bug 
tracker." and links to https://gcc.gnu.org/bugzilla/


>
> Stefan
>
> JFTR: do you consider your wild speculations to be on-topic here?

I suppose I should apologize: I did not intend to make any accusations 
here. I simply could not think at the time of any other reasons why you 
would be so hostile to the idea of using Bugzilla (when you've been 
explicitly told that sending issues to the mailing list is close to 
equivalent to sending them to /dev/null) and, not being a native English 
speaker, I must have formulated the message more aggressively than I 
intended. I also had been rather angered by you saying "You should 
better implement such missing optimisations your users might expect from 
a mature compiler" which I misinterpreted (at least, I hope so) as being 
some kind of threat.

Re: On(c)e more: optimizer failure

[Stefan Kanthak]

Gabriel Ravier  wrote:

> On 8/23/21 3:46 PM, Stefan Kanthak wrote:

>> JFTR: do you consider your wild speculations to be on-topic here?
>
> I suppose I should apologize: I did not intend to make any accusations 
> here.

No need to, I can stand a little heat.

[...]

> I also had been rather angered by you saying "You should better implement
> such missing optimisations your users might expect from a mature compiler"
> which I misinterpreted (at least, I hope so) as being some kind of threat.

You did (the misinterpretation).
This was my direct reply to Jakub's
| You should file missed optimizations into gcc bugzilla where they can be
| seen any time.
Read it as "You should implement missing optimisations (independent from
a bug report) so your users get better code all the time."
The emphasis is on "You should" as well as "all the time."

Stefan

Analyzer tests fail on windows

[NightStrike via 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,
because they need to be unsigned long long.

Is their either 1) a built in type you can use,  like __SIZE_T__ if that's
such a thing,  or 2) can you just include stddef.h instead of manually
putting the typedef at the top of each test?

Re: Analyzer tests fail on windows

[David Malcolm via Gcc]

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
> definition, though, and is wrong for 64 bit windows. This causes
> extra
> warnings that all of the functions using size_t arguments are wrong,
> because they need to be unsigned long long.
> 
> Is their either 1) a built in type you can use,  like __SIZE_T__ if
> that's
> such a thing,  or 2) can you just include stddef.h instead of
> manually
> putting the typedef at the top of each test?

Which tests are failing, specifically?

In many analyzer tests I'm using __SIZE_TYPE__ or stddef.h, however
I've recently added various tests reduced from the Linux kernel on
x86_64 which use unsigned long - maybe I need to rethink those.

Thanks
Dave

Re: Analyzer tests fail on windows

[NightStrike via Gcc]

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
> > definition, though, and is wrong for 64 bit windows. This causes
> > extra
> > warnings that all of the functions using size_t arguments are wrong,
> > because they need to be unsigned long long.
> >
> > Is their either 1) a built in type you can use,  like __SIZE_T__ if
> > that's
> > such a thing,  or 2) can you just include stddef.h instead of
> > manually
> > putting the typedef at the top of each test?
>
> Which tests are failing, specifically?
>
> In many analyzer tests I'm using __SIZE_TYPE__ or stddef.h, however
> I've recently added various tests reduced from the Linux kernel on
> x86_64 which use unsigned long - maybe I need to rethink those.

At least pr99774-1.c failed, but a non-comprehensive grep shows these:

gzio-3a.c:typedef long unsigned int size_t;
gzio-3.c:typedef long unsigned int size_t;
pr99774-1.c:typedef long unsigned int size_t;
zlib-5.c:typedef long unsigned int size_t;

I can look more thoroughly later today.

I admit my qualification of "many" is incorrect, given how many tests
use __SIZE_TYPE__.

Re: Analyzer tests fail on windows

[NightStrike via Gcc]

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
FAIL: gcc.dg/analyzer/malloc-callbacks.c (test for excess errors)
FAIL: gcc.dg/analyzer/pr98969.c  (test for warnings, line 17)
FAIL: gcc.dg/analyzer/pr98969.c (test for excess errors)
FAIL: gcc.dg/analyzer/pr99716-1.c  (test for warnings, line 25)
FAIL: gcc.dg/analyzer/pr99716-2.c (test for excess errors)
FAIL: gcc.dg/analyzer/pr99774-1.c (test for excess errors)
FAIL: gcc.dg/analyzer/sensitive-1.c  (test for warnings, line 16)
FAIL: gcc.dg/analyzer/sensitive-1.c warning (test for warnings, line 17)
FAIL: gcc.dg/analyzer/sensitive-1.c event (test for warnings, line 17)
FAIL: gcc.dg/analyzer/sensitive-1.c  (test for warnings, line 23)
FAIL: gcc.dg/analyzer/sensitive-1.c  (test for warnings, line 24)
FAIL: gcc.dg/analyzer/sensitive-1.c event (test for warnings, line 24)
FAIL: gcc.dg/analyzer/sensitive-1.c  (test for warnings, line 30)
FAIL: gcc.dg/analyzer/sensitive-1.c warning (test for warnings, line 31)
FAIL: gcc.dg/analyzer/sensitive-1.c event (test for warnings, line 31)
FAIL: gcc.dg/analyzer/sensitive-1.c  (test for warnings, line 44)
FAIL: gcc.dg/analyzer/sensitive-1.c  (test for warnings, line 50)
FAIL: gcc.dg/analyzer/sensitive-1.c  (test for warnings, line 55)
FAIL: gcc.dg/analyzer/sensitive-1.c  (test for warnings, line 60)
FAIL: gcc.dg/analyzer/sensitive-1.c  (test for warnings, line 61)
FAIL: gcc.dg/analyzer/signal-1.c  (test for warnings, line 13)
FAIL: gcc.dg/analyzer/signal-1.c  (test for warnings, line 25)
FAIL: gcc.dg/analyzer/signal-2.c  (test for warnings, line 16)
FAIL: gcc.dg/analyzer/signal-2.c  (test for warnings, line 28)
FAIL: gcc.dg/analyzer/signal-3.c  (test for warnings, line 10)
FAIL: gcc.dg/analyzer/signal-3.c  (test for warnings, line 21)
FAIL: gcc.dg/analyzer/signal-4a.c  (test for warnings, line 15)
FAIL: gcc.dg/analyzer/signal-4a.c expected multiline pattern lines
33-75 not found: 
FAIL: gcc.dg/analyzer/signal-6.c  (test for warnings, line 11)
FAIL: gcc.dg/analyzer/signal-6.c  (test for warnings, line 16)
FAIL: gcc.dg/analyzer/signal-registration-loc.c  (test for warnings, line 15)
FAIL: gcc.dg/analyzer/signal-registration-loc.c  (test for warnings, line 21)
FAIL: gcc.dg/analyzer/strndup-1.c (test for excess errors)
FAIL: gcc.dg/analyzer/zlib-5.c (test for excess errors)

Of those, here is what I diagnosed so far:
pr98969.c:9:19: warning: cast to pointer from integer of different
size [-Wint-to-pointer-cast]
* This fails because the function arguments are "long int", and that
tries to hold a pointer.  It should be uintptr_t or similar.

pr98969.c:17:3: warning: double-'free' of '*((struct foo *)(long long
int)i).expr' [CWE-415] [-Wanalyzer-double-free]
* My guess is that the regex is not right for running under wine,
because that shouldn't be an excess error.

pr99716-2.c:13:30: warning: implicit declaration of function 'random';
did you mean 'rand'? [-Wimplicit-function-declaration]
* The warning is probably right here.  The C function is rand().
Where does random() come from?

pr99774-1.c:12:14: warning: conflicting types for built-in function
'calloc'; expected 'void *(long long unsigned int,  long long unsigned
int)' [-Wbuiltin-declaration-mismatch]
* size_t issue

strndup-1.c:9:13: warning: incompatible implicit declaration of
built-in function 'strndup' [-Wbuiltin-declaration-mismatch]
* This function doesn't exist on windows.  So, either we add it to
libmingwex if it isn't already there and then link that library in to
the test, or just mark it as unsupported.  I'd probably prefer the
former, but it's not up to me.

zlib-5.c:10:15: warning: conflicting types for built-in function
'strlen'; expected 'long long unsigned int(const char *)'
[-Wbuiltin-declaration-mismatch]
zlib-5.c:16:14: warning: conflicting types for built-in function
'calloc'; expected 'void *(long long unsigned int,  long long unsigned
int)' [-Wbuiltin-declaration-mismatch]
* size_t issue

gcc.dg/analyzer/gzio-3.c:
gcc.dg/analyzer/gzio-3a.c:
* For some reason, these work.  Maybe fread() isn't a builtin? Maybe
there's a way to make gcc emit a warning when fread() is redefined
differently.

Usage of EBCDIC (IBM 1047)

[Jesus Diaz via Gcc]

Hi.

I recently started using GCC for compiling a bare-metal application for 
the ESA S390X architecture, called UDOS.


I have to say that the EBCDIC support is amazing for GCC, and i don't 
really know of it's usage outside of experiments or "theorical" field.


However i've noticed that on functions with the printf-style formatting 
attribute the EBCDIC strings tend to generate spurious errors - to my 
surprise the "%" character seems to cause these issues. This may be due 
to the ASCII host mis-representing characters or something else?


I'm using GCC 11, with a s390-linux as target.