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

[Jonathan Wakely via Gcc]

On Wed, 25 Aug 2021, 07:45 Jojo R wrote:

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

Do you mean something like
https://en.m.wikipedia.org/wiki/Flexible_array_member ?

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

[Jojo R via Gcc]

— Jojo
在 2021年8月25日 +0800 PM3:27，Jonathan Wakely ，写道：
>
>
> On Wed, 25 Aug 2021, 07:45 Jojo R wrote:
> > 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 ?
>
> Do you mean something like
> https://en.m.wikipedia.org/wiki/Flexible_array_member ?
>
No, it’s similar but include vector type as member like :

struct vectord {
 vint8m1_t data; // Vector Length Agnostic (VLA)
};

Re: Analyzer tests fail on windows

[Jonathan Wakely via Gcc]

On Wed, 25 Aug 2021, 03:37 NightStrike,  wrote:

> 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


I just use my personal fedora box for this.


(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



I just use the mingw-w64 binutils and sysroot installed by the Fedora
mingw-w64 cross compiler, and copy some of the options from the configure
command use to build that Fedora compiler. I also use the Fedora Wine
packages. Fedora provides everything I need to be able to build+test my
libstdc++ changes before I push them upstream.


On that note, Jon (W), it's interesting to hear that you regularly run

the libstdc++ testsuite under wine.


I wouldn't say I do it regularly, only when changing std::filesystem code,
because that has a lot of Windows-specific #if code that I can't test
otherwise. I generally only run the filesystem tests this way.


  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?


No, sorry, I don't submit them (because I only run a fraction of the tests).


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 don't run make check, I use a shell script of my own devising which
handles a small subset of { dg-* } directives, and links statically to
avoid needing to find DLLs. It's a hack, but it does just enough for my
needs.



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


I'd be interested in that. My approach was just cobbled together by trial
and error.


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

I just used enough to silence some irrelevant warnings. There do seem to be
more warnings from the latest Wine so maybe I should just use -all (I don't
think I've ever seen one of those warnings that was relevant to my testing,
or that I could do anything about).

>

Stackpath

[Gail Genuino]

Good Day,



I would like to know you are interested in Stackpath Users  List Data Set Users 
across a range of industries and geographic regions.



If yes we can move forward.



Who we are



We are a global database providing company .



Hope we get positive reply from your team.



Thanks and Stay Safe

Gail Genuino

Access tech data

post-commit hook failure

[Lewis Hyatt via Gcc]

Hello-

I wanted to note I got some errors when pushing this commit:

commit 3ac6b5cff1eca4e1748c671960ef7b4ca5e47fd2 (HEAD -> master,
origin/trunk, origin/master, origin/HEAD)
Author: Lewis Hyatt 
Date:   Tue Aug 24 19:30:44 2021 -0400

diagnostics: Support for -finput-charset [PR93067]

The errors were:

remote: Traceback (most recent call last):
remote:   File "hooks/post_receive.py", line 118, in 
remote: post_receive(refs_data, args.submitter_email)
remote:   File "hooks/post_receive.py", line 65, in post_receive
remote: submitter_email)
remote:   File "hooks/post_receive.py", line 47, in post_receive_one
remote: update.send_email_notifications()
remote:   File 
"/sourceware1/projects/src-home/git-hooks/hooks/updates/__init__.py",
line 189, in send_email_notifications
remote: self.__email_new_commits()
remote:   File 
"/sourceware1/projects/src-home/git-hooks/hooks/updates/__init__.py",
line 1031, in __email_new_commits
remote: commit, self.get_standard_commit_email(commit))
remote:   File 
"/sourceware1/projects/src-home/git-hooks/hooks/updates/__init__.py",
line 1011, in __send_commit_email
remote: default_diff=email.diff)
remote:   File 
"/sourceware1/projects/src-home/git-hooks/hooks/updates/__init__.py",
line 946, in __maybe_get_email_custom_contents
remote: hook_input=json.dumps(hooks_data),
remote:   File "/usr/lib64/python2.7/json/__init__.py", line 244, in dumps
remote: return _default_encoder.encode(obj)
remote:   File "/usr/lib64/python2.7/json/encoder.py", line 207, in encode
remote: chunks = self.iterencode(o, _one_shot=True)
remote:   File "/usr/lib64/python2.7/json/encoder.py", line 270, in iterencode
remote: return _iterencode(o, 0)
remote: UnicodeDecodeError: 'utf8' codec can't decode byte 0xf5 in
position 14638: invalid start byte


I think the commit has pushed fine, however some expected things did
not happen such as updating Bugzilla. The error makes some sense
because this commit added tests with non-standard encodings, while
python3 wants everything it reads to be utf-8 by default. I wanted to
mention in case it breaks some other things, such as ChangeLog
updating, that need to be addressed... Please let me know if I should
have done something different here. Thanks!

-Lewis

Re: post-commit hook failure

[Martin Liška]

On 8/25/21 17:27, Lewis Hyatt via Gcc wrote:

Hello-

I wanted to note I got some errors when pushing this commit:

commit 3ac6b5cff1eca4e1748c671960ef7b4ca5e47fd2 (HEAD -> master,
origin/trunk, origin/master, origin/HEAD)
Author: Lewis Hyatt 
Date:   Tue Aug 24 19:30:44 2021 -0400

 diagnostics: Support for -finput-charset [PR93067]

The errors were:

remote: Traceback (most recent call last):
remote:   File "hooks/post_receive.py", line 118, in 
remote: post_receive(refs_data, args.submitter_email)
remote:   File "hooks/post_receive.py", line 65, in post_receive
remote: submitter_email)
remote:   File "hooks/post_receive.py", line 47, in post_receive_one
remote: update.send_email_notifications()
remote:   File 
"/sourceware1/projects/src-home/git-hooks/hooks/updates/__init__.py",
line 189, in send_email_notifications
remote: self.__email_new_commits()
remote:   File 
"/sourceware1/projects/src-home/git-hooks/hooks/updates/__init__.py",
line 1031, in __email_new_commits
remote: commit, self.get_standard_commit_email(commit))
remote:   File 
"/sourceware1/projects/src-home/git-hooks/hooks/updates/__init__.py",
line 1011, in __send_commit_email
remote: default_diff=email.diff)
remote:   File 
"/sourceware1/projects/src-home/git-hooks/hooks/updates/__init__.py",
line 946, in __maybe_get_email_custom_contents
remote: hook_input=json.dumps(hooks_data),
remote:   File "/usr/lib64/python2.7/json/__init__.py", line 244, in dumps
remote: return _default_encoder.encode(obj)
remote:   File "/usr/lib64/python2.7/json/encoder.py", line 207, in encode
remote: chunks = self.iterencode(o, _one_shot=True)
remote:   File "/usr/lib64/python2.7/json/encoder.py", line 270, in iterencode
remote: return _iterencode(o, 0)
remote: UnicodeDecodeError: 'utf8' codec can't decode byte 0xf5 in
position 14638: invalid start byte


Oh yeah. Well, to be honest we somehow mix Python2 and Python3 script in the 
server hooks.




I think the commit has pushed fine, however some expected things did
not happen such as updating Bugzilla. The error makes some sense
because this commit added tests with non-standard encodings, while
python3 wants everything it reads to be utf-8 by default. I wanted to
mention in case it breaks some other things, such as ChangeLog
updating, that need to be addressed... Please let me know if I should
have done something different here. Thanks!


I believe ChangeLog will be updated correctly as we don't read content of the 
changes:

$ ./contrib/gcc-changelog/git_check_commit.py 
3ac6b5cff1eca4e1748c671960ef7b4ca5e47fd2 -p
-- gcc/c-family/ChangeLog --

2021-08-25  Lewis Hyatt  



PR other/93067

* c-opts.c (c_common_input_charset_cb): New function.

(c_common_post_options): Call new function

diagnostic_initialize_input_context().

-- gcc/d/ChangeLog --

2021-08-25  Lewis Hyatt  



PR other/93067

...

So no action is needed for now I think.

Martin



-Lewis

Re: post-commit hook failure

[Michael Matz via Gcc]

Hello,

On Wed, 25 Aug 2021, Martin Liška wrote:

> > remote:   File "hooks/post_receive.py", line 47, in post_receive_one
> > remote: update.send_email_notifications()
> > remote:   File
> > "/sourceware1/projects/src-home/git-hooks/hooks/updates/__init__.py",
...
> > remote: UnicodeDecodeError: 'utf8' codec can't decode byte 0xf5 in
> > position 14638: invalid start byte
...
> I believe ChangeLog will be updated correctly as we don't read content 
> of the changes:

But the email notifications (and bugzilla updating) isn't done if that 
place throws, so that should eventually be made more robust in the future.


Ciao,
Michael.

Re: post-commit hook failure

[Joseph Myers]

On Wed, 25 Aug 2021, Lewis Hyatt via Gcc wrote:

> I think the commit has pushed fine, however some expected things did
> not happen such as updating Bugzilla. The error makes some sense
> because this commit added tests with non-standard encodings, while
> python3 wants everything it reads to be utf-8 by default. I wanted to
> mention in case it breaks some other things, such as ChangeLog
> updating, that need to be addressed... Please let me know if I should
> have done something different here. Thanks!

See .  Commits that aren't 
UTF-8 should be very rare, even if not just the one commit per year 
updating libcpp .po files.

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

[RISCV] RISC-V GNU Toolchain Biweekly Sync-up call (Aug 26, 2021)

[吴伟]

Hi all,

There is an agenda for tomorrow's meeting. If you have topics to
discuss or share, please let me know and I can add them to the agenda.


Agenda:

1. https://github.com/riscv/riscv-toolchain-conventions/pull/16
2. https://github.com/riscv/riscv-c-api-doc/pull/21
3. Status update of implementations for unratified extensions.
4. Open Discussion

Topic: RISC-V GNU Toolchain Biweekly Sync-up

Join Zoom Meeting
https://zoom.com.cn/j/89393600951?pwd=ZFpWMkZ6Tm1TbUFXT1hZZjZZMHhRQT09

Meeting ID: 893 9360 0951
Passcode: 899662



BEIJING, China
11:00pThu, Aug 26 2021
12:00aFri, Aug 27 2021

PDT/PST, Pacific Daylight Time (US)
8:00aThu, Aug 26 2021
9:00aThu, Aug 26 2021

PHILADELPHIA, United States, Pennsylvania
11:00aThu, Aug 26 2021
12:00pThu, Aug 26 2021

PARIS, France
5:00pThu, Aug 26 2021
6:00pThu, Aug 26 2021



-- 
Best wishes,
Wei Wu (吴伟)

Re: On(c)e more: optimizer failure

[Manuel López-Ibáñez]

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

Cheers,

Manuel.

Request for catalogue

[David Liu via Gcc]

Hello gcc@gcc.gnu.org

I am David from IMEX sourcing company. Our customer finds your product 
interesting, as such we request that you send an official catalogue so we can 
send PO. Also be informed that our company charges 4% of the value of goods 
bought from the supplier which will be included in the proforma invoice.

Thanks and best regards. we await your earliest reply.

David Liu
IMEX Sourcing service 
E-mail: 

o-lightin...@ovovs.com mailto:o-lightin...@ovovs.com

Phone: +86 1326532 2461
Wechat: markkyyo

https://imexsourcingservices.com/