IT help is on its way.
.auto-style1 {
color: #80;
}
Please forward to whom concerned,
We have managed to turn a full time job to a few clicks job.
No more walking from workstation to workstation, or
worse, office to office.
Remotely configure your classifing/spam filters
with our new device(RSF). 1 remote stop configuration and
all your
users are instantly configured without leaving your desk.
* 1u or 2u rack mount
server chassis.
* 1 stop remote
email configuration for all user(s) and/or group(s)
* Set rules per
user(s) and/or group(s)
Classification by Sender, Subject, reciever or the whole body content.
* Black / white list access to RSF
device as wished
* SNMP traps on
potential problems.
* Email/SMS on trap
trigger.
* Built in intrution
detection.
* Antivirus, malware
protection and phishing.* Get
notified on any kind of attempt by email or SMS.
and
much more.
Get all the details at
https://gbjade.com/ReSieve-email-classifier-spam-control.asp";>https://GbJade.com
This e-mail has been sent to gcc@gcc.gnu.org, https://gbjade.com/unsubscribe.asp?E=gcc@gcc.gnu.org";
style="color:inherit;text-decoration:none;" target="_blank"> click
here to unsubscribe.
Re: Cortex M0 Floating Point Library
Hi Richard, I've only used custom linker scripts with my embedded work, so I don't know much about the GCC default. Presently, every library function is already in its own section to facilitate --gc-sections optimization. However, I #include every file together to ensure that all of the sections are still built into a single object file. So far the linker has done what I've expected (i.e., placed all of the used functions/sections in a contiguous block of memory and discarded the unused functions). Is the linker aware of section hierarchy, such that using a common section prefix (e.g. ".text.m0fp.*") would gather the appropriate sections together from multiple object files? I didn't think it was so aware; rather, that such prefixes were just a convention to help organize custom linker scripts. Adding such rules to the default linker script wouldn't be ideal, as everyone using a custom script might then have library breakage unless they knew to add equivalent rules. If the consensus is to split the library, it might help to add a set of intermediate branches (trampolines?) in the libm portion. This would add execution cycles, but not require as many extra bytes. Regards, Daniel On Thu, Nov 8, 2018, at 11:19 PM, Richard Henderson wrote: > On 11/7/18 6:10 PM, Daniel Engel wrote: > > Also, loss of control of linking order would require all short branches in > > the libm section to be replaced with long branches. This particularly > > impacts the exception handling in almost every function. > > You could partially remedy this by placing all the code into a unique section, > e.g. ".text.m0fp". The default linker script would place all instances of > this > section together. Additional tricks can be played if we're willing to modify > the linker scripts further. > > > r~
gcc-8-20181109 is now available
Snapshot gcc-8-20181109 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/8-20181109/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 8 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-8-branch revision 265997 You'll find: gcc-8-20181109.tar.xzComplete GCC SHA256=f0f211406f3e5a05b6c15dccadd1830970fa6ecb569b131d6e23ce92a6850436 SHA1=76ee97c3f425147e1cbb838059145547e742af06 Diffs from 8-20181102 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-8 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.
