Axway users
Hi there, Greetings! Trust this mail finds you well! Would you be interested in the following users, clients, and customers for your marketing initiatives? * Eclipse users * Visual Studio Code users * Netbeans users * Axway users * CoffeeCup HTML Editor users Currently, we hold 3200+ user types for technology industry databases. Let us know your targeted technology users and location so that we can provide you with more information. Looking forward to your response. Best regards, Annie Nicholson Demand Generation Manager To remove, simply reply with "no".
[RISCV] RISC-V GNU Toolchain Biweekly Sync-up call (April 5, 2023)
Hi all, Here is the agenda for tomorrow's RISC-V GNU toolchain meeting. If you have any topics want to discuss or share, please change the angenda/notes doc or let me know and I will update them, thanks. https://docs.google.com/document/d/1JSs-BSlPJ3QYbAb-Add1TlbYx0nOT1ur3jcsITIJ01U/edit# P.S. The meeting calendar .ics file has updated, please check and update it,thanks. Agenda: - RVV gcc support status - Profile toolchain implementation draft - Sub-extensions support status - CI status of currently toolchain - Open discuss Wei Wu - PLCT Lab is inviting you to a scheduled Zoom meeting. Topic: RISC-V GNU Toolchain Biweekly Sync-up Time: Feb 9, 2023 UTC+0 15:00 / PST 07:00 / CST 23:00 Please download and import the following iCalendar (.ics) files to your calendar system. Weekly: https://calendar.google.com/calendar/ical/lm5bddk2krcmtv5iputjgqvoio%40group.calendar.google.com/public/basic.ics Join Zoom Meeting https://zoom.us/j/89393600951?pwd=ZFpWMkZ6Tm1TbUFXT1hZZjZZMHhRQT09 Meeting ID: 893 9360 0951 Passcode: 899662 BEIJING, China 23:00pThu, Apr 6 2023 24:00a Fri, Apr 6 2023 PST/PDT, Pacific Standard Time (US) 8:00aThu, Apr 6 2023 9:00aThu, Apr 6 2023 PHILADELPHIA, United States, Pennsylvania 11:00aThu, Apr 6 2023 12:00aThu, Apr 6 2023 Paris, France 17:00pThu, Apr 6 2023 18:00pThu, Apr 6 2023BEGIN:VCALENDAR PRODID:-//zoom.us//iCalendar Event//EN VERSION:2.0 CALSCALE:GREGORIAN METHOD:PUBLISH CLASS:PUBLIC BEGIN:VTIMEZONE TZID:Asia/Singapore LAST-MODIFIED:20230104T023643Z TZURL:https://www.tzurl.org/zoneinfo-outlook/Asia/Singapore X-LIC-LOCATION:Asia/Singapore BEGIN:STANDARD TZNAME:+08 TZOFFSETFROM:+0800 TZOFFSETTO:+0800 DTSTART:19700101T00 END:STANDARD END:VTIMEZONE BEGIN:VEVENT DTSTAMP:20230215T105933Z DTSTART;TZID=Asia/Singapore:20230223T23 DTEND;TZID=Asia/Singapore:20230224T00 SUMMARY:RISC-V GNU Toolchain Biweekly Sync-up RRULE:FREQ=WEEKLY;WKST=SU;UNTIL=20231228T16;INTERVAL=2;BYDAY=TH UID:ZOOM89393600951 TZID:Asia/Singapore DESCRIPTION:Wei Wu - PLCT Lab is inviting you to a scheduled Zoom meeting .\n\nJoin Zoom Meeting\nhttps://us02web.zoom.us/j/89393600951?pwd=ZFpWMk Z6Tm1TbUFXT1hZZjZZMHhRQT09\n\nMeeting ID: 893 9360 0951\nPasscode: 89966 2\nOne tap mobile\n+6531294892\,\,89393600951#\,\,\,\,*899662# Singapore \n+6531587288\,\,89393600951#\,\,\,\,*899662# Singapore\n\nDial by your location\n+65 3129 4892 Singapore\n+65 3158 7288 Singapo re\n+65 3165 1065 Singapore\n+65 3129 4891 Singapore\n +1 669 900 9128 US (San Jose)\n+1 669 444 9171 US\n +1 253 215 8782 US (Tacoma)\n+1 346 248 7799 US (Houston)\n +1 719 359 4580 US\n+1 253 205 0468 US\n+1 386 347 5 053 US\n+1 507 473 4847 US\n+1 564 217 2000 US\n +1 646 558 8656 US (New York)\n+1 646 931 3860 US\n+1 68 9 278 1000 US\n+1 301 715 8592 US (Washington DC)\n+1 30 5 224 1968 US\n+1 309 205 3325 US\n+1 312 626 6799 US (C hicago)\n+1 360 209 5623 US\nMeeting ID: 893 9360 0951\nPasscode : 899662\nFind your local number: https://us02web.zoom.us/u/kk9cyIPNJ\n\ n LOCATION:https://us02web.zoom.us/j/89393600951?pwd=ZFpWMkZ6Tm1TbUFXT1hZZj ZZMHhRQT09 BEGIN:VALARM TRIGGER:-PT10M ACTION:DISPLAY DESCRIPTION:Reminder END:VALARM END:VEVENT END:VCALENDAR
-Wanalyzer-use-of-uninitialized-value always shadows -Wanalyzer-out-of-bounds
Hi David,
I used the below code snippet to experiment with out-of-bounds (OOB) on
trunk. Three things occurred that I believe could see some improvement. See
https://godbolt.org/z/57n459cEs for the warnings.
int consecutive_oob_in_frame ()
{
int arr[] = {1,2,3,4,5,6,7};
int y1 = arr[9]; // only this one get warnings (3*2 actually), expect
only 1 OOB though
int y2 = arr[10]; // expect a warning too, despite fooling with asm
int y3 = arr[50]; // expect a warning for that one too (see asm)
return (y1+y2+y3);
}
int goo () {
int x = consecutive_oob_in_frame (); // causes another pair of warnings
return 2 * x;
}
int main () {
goo (); // causes another pair of warning
consecutive_oob_in_frame (); // silent
int x [] = {1,2};
x[5]; /* silent, probably because another set of OOB warnings
has already been issued with this frame being the source */
return 0;
}
First, as the subject line reads, I get a
-Wanalyzer-use-of-uninitialized-value for each -Wanalyzer-out-of-bounds. I
feel it might be too much, as fixing the OOB would fix the former.
So maybe only OOB could result in a warning here ?
Second, it seems that if a frame was a cause for a OOB (either by
containing the spurious code or by being a caller to such code), it will
only emit one set of warning, rather than at each unique compromising
statements.
Finally, I think the diagnostic path should only go at deep as the
declaration of the injurious index.
What do you think ? If they also make sense to you I will open a RFE and
try my hands at fixing them.
Also, have you considered extending the current call summaries model
(symbolic execution from what you told me), to implement a partial VASCO
model ? There would still be no need for distributive problems.
Maybe a start could be that functions without parameters working on
non-mutable global data should not generate EN more than once, rather than
at each call sites.
Best,
Benjamin.
[RFC PATCH] driver: unfilter default library path [PR 104707]
Currently, gcc delibrately filters out default library paths "/lib/" and "/usr/lib/", causing some linkers like mold fails to find libraries. This behavior was introduced at least 31 years ago in the initial revision of the git repo, personally I think it's obsolete because: 1. The less than 20 bytes of saving is negligible compares to the command line argument space of most hosts today. 2. The driver program should provide adequate information for workers There might be some hosts with such a small argv space that the 20-byte saving really matters. If so, we can make this filter compiles conditionally in these targets. Related issue: https://github.com/rui314/mold/issues/358 --- gcc/gcc.cc | 11 --- 1 file changed, 11 deletions(-) diff --git a/gcc/gcc.cc b/gcc/gcc.cc index 16bb07f2cdc..1beb23ba279 100644 --- a/gcc/gcc.cc +++ b/gcc/gcc.cc @@ -7904,17 +7904,6 @@ is_directory (const char *path1, bool linker) *cp++ = '.'; *cp = '\0'; - /* Exclude directories that the linker is known to search. */ - if (linker - && IS_DIR_SEPARATOR (path[0]) - && ((cp - path == 6 - && filename_ncmp (path + 1, "lib", 3) == 0) - || (cp - path == 10 - && filename_ncmp (path + 1, "usr", 3) == 0 - && IS_DIR_SEPARATOR (path[4]) - && filename_ncmp (path + 5, "lib", 3) == 0))) -return 0; - return (stat (path, &st) >= 0 && S_ISDIR (st.st_mode)); } -- 2.40.0
Re: -Wanalyzer-use-of-uninitialized-value always shadows -Wanalyzer-out-of-bounds
On Wed, 2023-04-05 at 19:50 +0200, Benjamin Priour wrote:
> Hi David,
>
> I used the below code snippet to experiment with out-of-bounds (OOB)
> on
> trunk. Three things occurred that I believe could see some
> improvement. See
> https://godbolt.org/z/57n459cEs for the warnings.
>
> int consecutive_oob_in_frame ()
> {
> int arr[] = {1,2,3,4,5,6,7};
> int y1 = arr[9]; // only this one get warnings (3*2 actually),
> expect
> only 1 OOB though
> int y2 = arr[10]; // expect a warning too, despite fooling with
> asm
> int y3 = arr[50]; // expect a warning for that one too (see asm)
> return (y1+y2+y3);
> }
>
> int goo () {
> int x = consecutive_oob_in_frame (); // causes another pair of
> warnings
> return 2 * x;
> }
>
> int main () {
> goo (); // causes another pair of warning
> consecutive_oob_in_frame (); // silent
> int x [] = {1,2};
> x[5]; /* silent, probably because another set of OOB warnings
> has already been issued with this frame being the source */
> return 0;
> }
There's quite a bit of duplication here. My recollection is that
there's code in the analyzer that's meant to be eliminating some of
this e.g. we want to show the OOB when consecutive_oob_in_frame is
called directly; we *don't* want to show it when
consecutive_oob_in_frame is called by goo. Perhaps this deduplication
code isn't working? Can you reproduce similar behavior with C, or is
it specific to C++?
>
> First, as the subject line reads, I get a
> -Wanalyzer-use-of-uninitialized-value for each -Wanalyzer-out-of-
> bounds. I
> feel it might be too much, as fixing the OOB would fix the former.
> So maybe only OOB could result in a warning here ?
Yes, that's a good point. Can you file a bug about this in bugzilla
please? (and feel free to assign it to yourself if you want to have a
go at fixing it)
Maybe we could fix this by having region_model::check_region_bounds
return a bool that signifies if the access is valid, and propagating
that value up through callers so that we can return a non-
poisoned_svalue at the point where we'd normally return an
"uninitialized" poisoned_svalue.
Alternatively, we could simply terminate any analysis path in which an
OOB access is detected (by implementing the
pending_diagnostic::terminate_path_p virtual function for class
out_of_bounds).
>
> Second, it seems that if a frame was a cause for a OOB (either by
> containing the spurious code or by being a caller to such code), it
> will
> only emit one set of warning, rather than at each unique compromising
> statements.
Maybe. There's a pending_diagnostic::supercedes_p virtual function
that perhaps we could implement for out_of_bounds (or its subclasses).
>
> Finally, I think the diagnostic path should only go at deep as the
> declaration of the injurious index.
I'm not quite sure what you mean by this, sorry.
>
> What do you think ? If they also make sense to you I will open a RFE
> and
> try my hands at fixing them.
Please do.
>
> Also, have you considered extending the current call summaries model
> (symbolic execution from what you told me), to implement a partial
> VASCO
> model ? There would still be no need for distributive problems.
> Maybe a start could be that functions without parameters working on
> non-mutable global data should not generate EN more than once, rather
> than
> at each call sites.
Please forgive my ignorance; do you have a link to a paper describing
this?
Thanks
Dave
[GSoC] gcc-rs - Unicode Support or Metadata
Dear GCC members,
I understand that I am late in submitting this proposal. However, I found
out about gcc-rust and Google of Code three hours ago, and instead of doing
nothing, I decided that it is in my best interest to apply nonetheless. I'm
interested in Rust and the GCC frontend for many reasons, and I would like
to be considered for this involvement. I can be fully committed to the
project if any of my proposals are accepted.
# General Information
Name: Carlos "Charlie Cruz" Hernandez
Email: cj...@rice.edu
University: Rice University '2026
Major/Focus: Mathematics and Linguistics
Country/Timezone: United States / Eastern Standard Time
What is your Open Source Experience so far?
Online I go by "SeniorMars," (https://github.com/SeniorMars), and I have
contributed to the following significant projects: Rust-analyzer, Neovim,
Coc-rust-analyzer, and the Rust compiler for documentation. I'm highly
active in the Neovim, Latex community and working on several Neovim plugins
for the Typst markup language. Additionally, at Rice, I taught.
https://lazy.rice.edu/ (website is outdated due to University policies --
for now) that aims to teach open source concepts to students. Finally, I
have a youtube channel dedicated to open-source concepts:
https://www.youtube.com/@SeniorMarsTries. For the sake of this project, I
have taken my University's programming class as a Freshman. Also, notably,
I'm working on a tree-sitter parser for the Typst markup language that
deals with Unicode. In Neovim, I'm also trying to tackle "concealed text"
with virtual text. Although I have yet to work with gcc-rs, I'm confident I
can help.
# Project Information
I wish to tackle one of the three projects suggested in the gcc-rust
section: Unicode support, Metadata, or Improving user errors.
## Unicode support
While working on the Typst tree-sitter project, I've learned how extensive
Unicode is and the difficulty of correctly parsing such a language. In
particular, I learned how to work with all the weird cases of Unicode,
i.e., emojis, different types of Whitespace, and identifiers.
My main goal is to apply all the concepts I've learned with Typst to gcc-rs.
Thus, the main difficulties will be dealing with modifying the lexer to
handle \p{Whitespace}, \p{XID_Start}, and \p{XID_Continue} properly without
introducing complications in parsing in other areas of the project. Reusing
code from libcpp/ucnid.h from the CPP frontend may help with this part.
Finally, we must introduce a new Rust::String class that represents rust
identifiers, strings, and `create_name` instead of the old implementation.
Of course, I also need to define the v0 mangling scheme that Rust uses to
parse Unicode correctly. I can take a lot of inspiration from Tree-sitter.
The timeline is very close to the two proposals before me. However, I would
first start implementing punycode earlier as it would give me a checklist
on everything I must test to make the lexer fully support Unicode. As the
rest is then shifted, it makes it easier to implement tests for cases I
know will be difficult to deal with.
# Metadata
While working on the typst.nvim, I decided to use Rust to communicate to
Neovim's API and Lua by linking binary to something neovim can use. This
piqued my interest, and from the looks of it, the work I would be doing in
this project would porting all the requirements of
`rustc_metadata::rmeta::CrateRoot` to `rust-export-metadata.cc`, whose spec
is detailed in `src/rustc_metadata/rmeta/encoder.rs`. In particular, I
would ensure that we support Strict Version Hash (SVH), Stable Crate Id,
and encoded MIR.
My timeline then is based on modifying and implementing the fields in
`CrateRoot.`
However generally:
Week 1-2:
- Modify rust-export-metadata.cc to include the "basic" fields in
CrateRoot, such as edition, panic_in_drop_strategy
- MetaItem
Week 3:
- Implement a testing method to load only specific metadata in case of
identical hashes correctly.
- Document all the functions I created
Week 4-5:
- Implement CrateDep
- Implement Strict Version Hash, which also needs:
- proper StableCrateId, which needs
- proper basic metadata support
Week 5-7:
- Implment `SourceFile`, `ForeignModule`, `NativeLib`, and the rest.
Week 8:
- Testing and documentation plus start a write-up.
Week 9-10:
- Pipelining and Crate loading
Week 11-12:
- Modify our rlib and add dylib support with compression
I would appreciate any mentor. I understand I am still late, and this
email could be more robust; however, I would love to work on gcc-rs this
summer.
Thank you,
Charlie
--
Charlie Cruz -- Going through a name change!
Math & Linguistics @ Rice University '26
