Re: Analyzer tests fail on windows

[David Malcolm via Gcc]

On Mon, 2021-08-23 at 22:36 -0400, NightStrike wrote:
> 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.

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 Windows coding...)

Dave

Re: Analyzer tests fail on windows

[Jonathan Wakely via Gcc]

On Tue, 24 Aug 2021 at 13:49, David Malcolm wrote:
> Is there a recipe for testing this via
> wine?  (it's been almost 20 years since I did any Windows coding...)

I use this for running libstdc++ tests under Wine:

Xvfb :9 -screen 0 1024x768x16 &
trap 'kill %1' EXIT
# Start wine on the dummy X server, running a simple program.
# This means that each "wine a.exe" below won't start wine again.
DISPLAY=:9.0 WINEDEBUG=fixme-all wine view.exe &
trap 'kill -INT %2 && sleep 2 && kill -INT %1' EXIT

and then "WINEDEBUG=fixme-font wine a.exe" to run an executable a.exe
built by a mingw-w64 cross compiler.

Re: Analyzer tests fail on windows

[Jonathan Wakely via Gcc]

On Tue, 24 Aug 2021 at 14:32, Jonathan Wakely  wrote:
>
> On Tue, 24 Aug 2021 at 13:49, David Malcolm wrote:
> > Is there a recipe for testing this via
> > wine?  (it's been almost 20 years since I did any Windows coding...)
>
> I use this for running libstdc++ tests under Wine:
>
> Xvfb :9 -screen 0 1024x768x16 &
> trap 'kill %1' EXIT
> # Start wine on the dummy X server, running a simple program.
> # This means that each "wine a.exe" below won't start wine again.
> DISPLAY=:9.0 WINEDEBUG=fixme-all wine view.exe &
> trap 'kill -INT %2 && sleep 2 && kill -INT %1' EXIT
>
> and then "WINEDEBUG=fixme-font wine a.exe" to run an executable a.exe
> built by a mingw-w64 cross compiler.

That's in a script btw. The traps mean that no wine processes are left
hanging around after the script exits.

Re: Usage of EBCDIC (IBM 1047)

[Joseph Myers]

On Mon, 23 Aug 2021, Jesus Diaz via Gcc wrote:

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

See .

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: Porting to gcc 11 / intrinsics

[NightStrike via Gcc]

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
>
> That should be reflected in:
>
> https://gcc.gnu.org/gcc-11/porting_to.html
>

Re: Porting to gcc 11 / intrinsics

[Andrew Pinski via Gcc]

On Tue, Aug 24, 2021 at 6:39 PM NightStrike via Gcc  wrote:
>
> Should I make this a bugzilla? I guess I figured that wouldn't be
> appropriate.

I don't see a reason why this should go into porting as there was no
change needed from previous versions of GCC.
Supporting -mno-sse is a new feature even.

Thanks,
Andrew


>
> 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
> >
> > That should be reflected in:
> >
> > https://gcc.gnu.org/gcc-11/porting_to.html
> >

Re: Analyzer tests fail on windows

[NightStrike via Gcc]

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 Windows coding...)
>
> Dave

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102052

The method I'm using to test this is convoluted and difficult to set
up.  Based on his parallel reply to this thread, Jon might have a test
setup that works better (and more professionally) with an internal
redhat environment (W, not Y, obvoiusly :) )

What I did, though, was all on CentOS 6, which in itself needs newer
tools, but not many.

1) Build a modern native compiler with binutils installed to the same
prefix.  For my test I used 11.2.0 and 2.37.
2) Build the cross compiler (note: for steps c and f, I needed to
include dejagnu in the source tree b/c it wasn't available for me)
  a) Make a new sysroot with a mingw symlink to the target x86_64-w64-mingw32
  b) Build the mingw-w64 headers, install into the sysroot
  c) Build binutils, install into the sysroot
  d) Build part of gcc, use the all-gcc target
  e) Build the mingw-w64 crt using the result of (d), install to sysroot
  f) Build the rest of gcc (use the normal all target), install to sysroot
3) Use the native compiler to build a modern bison (I used 3.something)
4) Use (1), (2), and (3) to build a stripped down wine with most
features disabled (like any GUI features, for instance)
5) Use a new wine prefix with debug disabled and a custom dejagnu
board that uses wine as the driver

So, the above sequence 1) sucks, and 2) is probably not the way
smarter people would do it.  But, I got it up and running in under a
day, so that does meet at least some basic requirements.  I put most
of that in a shell script that I can send you to at least illustrate
the configure options at each step, and other details.  I guess I
should check all this in to mingw-w64's repos.

Note that there are a LOT of testsuite failures.  There was a time in
the 4.4 era when Kai and I (let's be honest, it was 90% him) worked it
down to < 20 failures across all languages.  That is no longer the
case, so we are trying once again to get the failure count down.

On that note, Jon (W), it's interesting to hear that you regularly run
the libstdc++ testsuite under wine.  I'd like to compare my results to
yours to see if my environment is just completely bogus.  Are your
results on the testresults mailing list?  I haven't started with g++
yet, though, as it's harder to run, and I figured that gcc should pass
first.  I have one question, though, that perhaps you can answer
upfront.  After you do a build, before you run make check, what do you
do to make the dll's available to the testsuite?  Do you set WINEPATH
to include their location, do you copy them somewhere first, do you
make install first, or is there maybe a RUNTESTFLAGS option?  I was
struggling with this part, as no fix seemed to work permanently.

> I use this for running libstdc++ tests under Wine:
>
> Xvfb :9 -screen 0 1024x768x16 &
> trap 'kill %1' EXIT
> # Start wine on the dummy X server, running a simple program.
> # This means that each "wine a.exe" below won't start wine again.
> DISPLAY=:9.0 WINEDEBUG=fixme-all wine view.exe &
> trap 'kill -INT %2 && sleep 2 && kill -INT %1' EXIT
>
> and then "WINEDEBUG=fixme-font wine a.exe" to run an executable a.exe
> built by a mingw-w64 cross compiler.

Also, note that there's a command line option to wineserver to
automate backgrounding it to avoid the workaround you are using.  I
haven't tried it, though, but I can let you know if I can get it to
work.  You are right that there is non-trivial overhead in starting
wine each time.  For my WINEDEBUG, I use "=-all" to shut everything
off.  Maybe that's a bad idea.  Thoughts?

Re: Porting to gcc 11 / intrinsics

[NightStrike via Gcc]

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
> > > 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
> > Should I make this a bugzilla? I guess I figured that wouldn't be
> > appropriate.
>
> I don't see a reason why this should go into porting as there was no
> change needed from previous versions of GCC.
> Supporting -mno-sse is a new feature even.

(Fixed my top posting gaff, sorry about that)

Ok.  I would have found the information useful, perhaps another place
would be better?  In general, documentation here is lacking.

What is this GIMPLE?

[Gary Oblock via Gcc]

I print out a bit of GIMPLE for a program and it looks like this:

   [local count: 13634385]:
  # a_1 = PHI 
  # n_11 = PHI 
loop:
  # DEBUG n => n_11
  # DEBUG a => a_1
  _2 = (long unsigned int) a_1;
  _3 = _2 & 7;
  _347 = _3 != 0;

That bit that says "loop:" isn't a GIMPLE_LABEL and
it has operands, the first of which is "size_t n = size_t;"
and I find that a bit odd...

What is this thing and what does it do? Note, I'm trying to
parse and transform some GIMPLE and this is confusing my
code (and me.) I looked in the internals doc and grepped the
code but I'm still in the dark.

Note,I'd like be able to detect and ignore this if it's just informational.

Thanks,

Gary

Gary


CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for 
the sole use of the intended recipient(s) and contains information that is 
confidential and proprietary to Ampere Computing or its subsidiaries. It is to 
be used solely for the purpose of furthering the parties' business 
relationship. Any unauthorized review, copying, or distribution of this email 
(or any attachments thereto) is strictly prohibited. If you are not the 
intended recipient, please contact the sender immediately and permanently 
delete the original and any copies of this email and any attachments thereto.

How to define Struct / Array type with runtime invariants like SVE or RVV

[Jojo R via Gcc]

Hi,

I want to use struct or array type as container in my project,

but GCC does not support this usage by now because that

the size of these types are decided at compile-time :(

so is there any good solution to fix this ?

or some new feature patches to add supporting for these types with
computed size at runtime ?

— Jojo R