RE: Quickbase Software Potential Clients
Hi, Apologies for intriguing your privacy again. Following up to see if you happen to check my below email which could help you to gain more customers to your company. Let me know if you would like me to schedule a quick call this week or the coming week or if you want me to share some samples, I could send them over. Await to hear from you. Regards, Fluorine From: Fluorine Jordan Sent: Friday, October 7, 2022 8:01 AM To: gcc@gcc.gnu.org Subject: Quickbase Software Potential Clients Hi, I hope you are staying healthy! Would you be interested in our 3D Architecture Software Contact sets? Few 3D Architecture Software Counts as below: Competitors Counts AutoCAD 15 3ds Max 11 Autodesk Revit 85000 V-Ray 30900 MicroStation 28500 Bluebeam Revu 18700 If you're looking for any other Software Users or Competitors datasets Share with me what you are looking for so that I can provide you with few samples accordingly. Awaiting a reply from you. Regards, Fluorine
Local type inference with auto is in C2X
So apparently auto was voted in to the committee draft of C2X at the last minute. I wonder how this aligns with the WG14 charter, given the lack of implementation experience with this feature, but it looks like we are now stuck with it. My main worry is that both Clang and GCC still enable implicit ints by default. This means that auto variables have type int always, and that can subtly alter the meaning of programs. The only indication that this has happened in a code base is a warning that went away (!). I don't like that. My original plan was to port upstreams & distributions away from implicit ints (again, configure scripts are problematic), and then have at least one GCC release that disables implicit ints in the default language mode. But I'm not sure if that's now possible: the porting will not have propagated widely once GCC 13 releases, so rejecting implicit ints in GCC 13 might be too early. GCC 14 might want to switch to C23/C24 mode by default, activating auto support, if the standard comes out in 2023 (which apparently is the plan). Then we would go from warning to changed semantics in a single release. Comments? Thanks, Florian
Re: Local type inference with auto is in C2X
Hello, On Thu, 3 Nov 2022, Florian Weimer via Gcc wrote: > will not have propagated widely once GCC 13 releases, so rejecting > implicit ints in GCC 13 might be too early. GCC 14 might want to switch > to C23/C24 mode by default, activating auto support, if the standard > comes out in 2023 (which apparently is the plan). > > Then we would go from > warning to changed semantics in a single release. > > Comments? I would argue that changing the default C mode to c23 in the year that comes out (or even a year later) is too aggressive and early. Existing sources are often compiled with defaults, and hence would change semantics, which seems unattractive. New code can instead easily use -std=c23 for a time. E.g. c99/gnu99 (a largish deviation from gnu90) was never default and gnu11 was made default only in 2014. Ciao, Michael.
Re: Local type inference with auto is in C2X
On Thu, 3 Nov 2022, Florian Weimer via Gcc wrote: > My main worry is that both Clang and GCC still enable implicit ints by > default. This means that auto variables have type int always, and that > can subtly alter the meaning of programs. The only indication that this > has happened in a code base is a warning that went away (!). I don't > like that. My expectation is that the old use of auto as a storage class specifier is actually very rare in C code, so this particular sub-case (auto with no type specifier meaning implicit int) is even rarer and there isn't much porting to be done for it (unlike for the rest of implicit int). -- Joseph S. Myers jos...@codesourcery.com
Re: Local type inference with auto is in C2X
* Joseph Myers: > On Thu, 3 Nov 2022, Florian Weimer via Gcc wrote: > >> My main worry is that both Clang and GCC still enable implicit ints by >> default. This means that auto variables have type int always, and that >> can subtly alter the meaning of programs. The only indication that this >> has happened in a code base is a warning that went away (!). I don't >> like that. > > My expectation is that the old use of auto as a storage class specifier is > actually very rare in C code, so this particular sub-case (auto with no > type specifier meaning implicit int) is even rarer and there isn't much > porting to be done for it (unlike for the rest of implicit int). Hmm, that's certainly a reassuring perspective. Maybe I'm worrying about nothing after all. Thanks, Florian
gcc-10-20221103 is now available
Snapshot gcc-10-20221103 is now available on https://gcc.gnu.org/pub/gcc/snapshots/10-20221103/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 10 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch releases/gcc-10 revision ad30cedebe3cabb9ac12a9834f231ff9fbc8c242 You'll find: gcc-10-20221103.tar.xz Complete GCC SHA256=2858690fbf210dbef4dc68dbf324d318aa30740ecc7cc364bf0176cfc47cadea SHA1=e29028fcf0aaee1216e8165d0e6a161086771dd8 Diffs from 10-20221027 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-10 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
DWZ 0.15 released
DWZ 0.15 has been released.
dwz - DWARF optimization and duplicate removal tool
dwz is a program that attempts to optimize DWARF debugging
information contained in ELF shared libraries and ELF executables
for size, by replacing DWARF information representation with
equivalent smaller representation where possible and by reducing the
amount of duplication using techniques from DWARF standard appendix
E - creating DW_TAG_partial_unit compilation units (CUs) for
duplicated information and using IDW_TAG_imported_unit to import it
into each CU that needs it.
You can download dwz from the sourceware FTP server here:
https://sourceware.org/ftp/dwz/releases/
ftp://sourceware.org/pub/dwz/releases/
The vital stats:
Sizemd5sumName
188KiB f99770d7d176001951a592fdcb0a788c dwz-0.15.tar.gz
147KiB d2867986d0df78bfbc22587628873fae dwz-0.15.tar.xz
There is a web page for DWZ at:
https://sourceware.org/dwz/
DWZ 0.15 includes the following changes and enhancements:
* Uses xxHash hashing algorithm. A 8% ~ 14% speedup.
* Set endianity of multifile using -e, --multifile-endian.
* Set pointer size of multifile using -p, --multifile-pointer-size
* Process files in parallel using -j N --jobs N. The default is
processors / 2. Disabled when multifile is used.
* Prints abbrev or DIE offset for Unknown DWARF error messages.
* All testcases have been updated to work against the binutils 2.39.
= git shortlog =
Lv Ying (1):
Fix handling readelf following links by default
Mark Wielaard (11):
Mark and init shstrtab[_len] and const in optimize_multifile
Workaround binutils readelf following and printing alt file.
Print abbrev or DIE offset for Unknown DWARF error message.
Remove double semicolon
Always assign svalue when checking and reporting negative values
Redirect stder in gdb-add-index.sh test
do-release.sh: Create signed annotated tags
gen-copyright-years.sh skip native.c
Check -DXXH_INLINE_ALL works, otherwise link against libxxhash
Add .note.GNU-stack in dwarf.exp generated files
Bump version to 0.15
Martin Liška (6):
Fix UBSAN reported for Libreoffice so files
testsuite: verify directly merged DW_AT_declarations
testsuite: remove leading spaces
Use xxHash hashing algorithm.
Use grep -E instead of egrep.
Fix executable stack warning from linker
Tom de Vries (56):
Add --devel-no-checksum-cycle-opt
Add --devel-progress-mem
Release process improvements
Break up main
Make some variables and functions static
Remove USED and UNUSED annotations
Fix ubsan triggered in gdb-add-index.sh
Fix another reference from PU to CU for odr
Handle reordered dup chains in create_import_tree
Print cu_offset for --devel-dump-pus
Add --devel-skip-producer
Make main more readable
[testsuite] Fix pr27463.sh on riscv64
Factor out args.c and args.h
Change files var in main to char **
[testsuite] Handle readelf following links by default
Make smaller-than.sh match dwz heuristic
[testsuite] Remove smaller-than.sh test in pr24747.sh
Factor out dwz_files_1
Factor out dwz_with_low_mem
[testsuite] Show error output in twice-multifile.sh
Fix low-mem memory leak
Fix memory leak in write_multifile
Fix memory leak in build_abbrevs
Move hardlink handling out of dwz function
Fix uninitialized var in dwz_one_file
Add check-valgrind
Don't use argv[0] in usage
Add -5 to usage header
Add --multifile-pointer-size and --multifile-endian
Process files in parallel
Add -p auto and -e auto
Factor out {encode,decode}_child_exit_status
Run two-files-low-mem-die-limit-0.sh with -j1
Add low_mem_p to struct file_result
Factor out wait_child_exit
Initialize pids in dwz_files_1
Factor out wait_children_exit
Use goto in dwz_files_1
Do finalize-multifile in parallel
Minimize struct file_result
Calculate workset before serial/parallel code in dwz_files_1
Fix incorrect res arg for wait_child_exit
Add ret to struct file_result
Handle skip_multifile in encode/decode_child_exit_status
Apply multifile_force_{ptr_size,endian} ASAP
Use vars to name parallel parts in dwz_files_1
Enable parallel multifile with -e -p
[testsuite] Fix handling of missing section in smaller-than.sh
Ensure help message lines end with dot
Factor out common flags between dwz and dwz-for-test
Eliminate sed usage in building dwz-for-test
Add util.h
Factor out pool.{c,h}
Add -p native and -e native
Introduce struct pipe
