Spam again
> I again disabled account creation on GCC Bugzilla due to spammers being > still very active. 117 user accounts have been created since yesterday. Please immediately disable account creation on Bugzilla until an effective solution to prevent spam is found. There is another spam attack going on where thousands of users are created automatically. Without some CAPTCHA or approval process, gcc bugzilla is sitting duck. Uros.
Re: Spam again
On Tue, Sep 2, 2014 at 12:01 AM, Uros Bizjak wrote: >> I again disabled account creation on GCC Bugzilla due to spammers being >> still very active. 117 user accounts have been created since yesterday. > > > Please immediately disable account creation on Bugzilla until an > effective solution to prevent spam is found. There is another spam > attack going on where thousands of users are created automatically. > Without some CAPTCHA or approval process, gcc bugzilla is sitting > duck. Also all accounts from the wowring.ru domain has been spam. Thanks, Andrew > > Uros.
Re: selective linking of floating point support for *printf / *scanf
On Sat, Aug 30, 2014 at 12:26 PM, Thomas Preud'homme wrote: >> From: Grissiom [mailto:chaos.pro...@gmail.com] >> Sent: Friday, August 29, 2014 11:51 PM >> >> Yes, it does. The namespace reserved for the implementation is _[_A-Z]. > > The namespace _[a-z] is still available for the user. Which means the >> user can declare their own _printf_float, and WE (as the implementation) >> MUST NOT INTERFERE with it. Since WE are the implementation, we should >> use the namespace reserved for us, namely __printf_float. > > Mmmh indeed. I checked C99 and section 7.1.3 paragraph 1 third clause states: > > "All identifiers that begin with an underscore and either an uppercase letter > or > another underscore are always reserved for any use." > > Next clause express how single underscore not followed by a capital letter is > reserved: > > "All identifiers that begin with an underscore are always reserved for use as > identifiers > with file scope in both the ordinary and tag name spaces." Apparently newlib is not following this specification very well, as there are symbols like _abc_r defined every where in current newlib. I am not implying the spec should not be followed, but is newlib designed to have a loose spec for the single underscore? - Joey > > Since here we are talking about linkage, _printf_float is not safe according > to the > standard. > > Sigh. > > Ok I need to think about it. Thank you all for pointing out the problem with > the > current scheme. > > Best regards, > > Thomas > >
Visualizing Call Hierarchy In Chromium Browser
Hi, I use chrome://tracing to demonstrate the hierarchy of ira-color.c. And I think it's helpful to understand the code. If anyone feels interested in it, visit the project in github:https://github.com/linzj/gen-trace Its very easy to use, that's why I don't use the code of chromium. Just include the ctrace.h, add C_TRACE_0 to the functions you may interested, and load the trace.json file from chrome://tracing. Sorry I can't send the png attachment. The graph looks like this: | ira color | | | ... | color_allocnos | | | | form_..forest| | push.. | | | || ---- -- Lin Zuojian
Re: New anti-spam extension enabled on GCC Bugzilla
On Mon, Sep 1, 2014 at 12:50 AM, Frédéric Buclin wrote: > Hello, > > I just enabled an extension on GCC Bugzilla which automatically disables > reporter's account if their bugs are marked as INVALID and are in the > 'spam' component. So if you have enough privileges on GCC Bugzilla to > close a bug as INVALID and to move it in the 'spam' component (in the > 'gcc' product), you can help disabling these user accounts. It doesn't > matter if the bug is closed as RESOLVED or CLOSED. What matters is the > INVALID resolution. Note that you won't see any notification that the > account has been disabled. That's expected. :) > > I re-enabled user account creation a few minutes ago, and already 2 new > accounts have been created. Both are spammers. I have disabled them already. > > Note that my extension only disables reporters. It doesn't disable > commenters who are also spammers (because we have no way to mark a > comment as spam yet. This feature will come with Bugzilla 5.0). For > them, admins will have to disable these accounts manually: > > https://gcc.gnu.org/bugzilla/editusers.cgi > > You type the email address of the user you want to find, then click on > it and type some text in the "Disable text" field. You can also click > the "Bugmail Disabled" checkbox to prevent the spammer from getting any > new bugmail. Do not forget to click the "Save Changes" once you are done. I wonder what privileges are necessary to be able to do that. Certainly I don't see that "Disable text" field. And the spamming continues... Richard. > > Good luck! > > Frédéric > > > PS: Do not hesitate to email me if there is something wrong with my > extension.
Re: selective linking of floating point support for *printf / *scanf
On 09/02/2014 08:33 AM, Joey Ye wrote: > On Sat, Aug 30, 2014 at 12:26 PM, Thomas Preud'homme > wrote: >>> From: Grissiom [mailto:chaos.pro...@gmail.com] >>> Sent: Friday, August 29, 2014 11:51 PM >>> >>> Yes, it does. The namespace reserved for the implementation is _[_A-Z]. >> > The namespace _[a-z] is still available for the user. Which means the >>> user can declare their own _printf_float, and WE (as the implementation) >>> MUST NOT INTERFERE with it. Since WE are the implementation, we should >>> use the namespace reserved for us, namely __printf_float. >> >> Mmmh indeed. I checked C99 and section 7.1.3 paragraph 1 third clause states: >> >> "All identifiers that begin with an underscore and either an uppercase >> letter or >> another underscore are always reserved for any use." >> >> Next clause express how single underscore not followed by a capital letter is >> reserved: >> >> "All identifiers that begin with an underscore are always reserved for use >> as identifiers >> with file scope in both the ordinary and tag name spaces." > > Apparently newlib is not following this specification very well, as > there are symbols like _abc_r defined every where in current newlib. newlib is part of the implementation, so it's allowed to do this. Andrew.
Re: Account creation disabled on GCC Bugzilla
On Tue, Sep 2, 2014 at 8:15 AM, Uros Bizjak wrote: > Hello! > >> 311 bugs have been created on GCC Bugzilla since yesterday. Only 2 are >> valid bugs. The remaining 309 ones are all spam and have been moved into >> the 'spam' component and marked as INVALID. > > We can also avoid archiving bugs with "spam" component to gcc-bugs@ ML. That would indeed remove one incentive of the spammers (bump up google search results by adding referers). But I think the ml archives of gcc-bugs@ are handled separately (but it would be nice to not send any mail for the bug change to spam/invalid). Richard. > Uros.
Re: Account creation disabled on GCC Bugzilla
Richard Biener writes: > On Tue, Sep 2, 2014 at 8:15 AM, Uros Bizjak wrote: >> Hello! >> >>> 311 bugs have been created on GCC Bugzilla since yesterday. Only 2 are >>> valid bugs. The remaining 309 ones are all spam and have been moved into >>> the 'spam' component and marked as INVALID. >> >> We can also avoid archiving bugs with "spam" component to gcc-bugs@ ML. > > That would indeed remove one incentive of the spammers (bump up > google search results by adding referers). You'd still get the initial bug creation message, so it wouldn't change much. Andreas. -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different."
Re: Account creation disabled on GCC Bugzilla
On Tue, Sep 02, 2014 at 11:49:33AM +0200, Andreas Schwab wrote: > Richard Biener writes: > > > On Tue, Sep 2, 2014 at 8:15 AM, Uros Bizjak wrote: > >> Hello! > >> > >>> 311 bugs have been created on GCC Bugzilla since yesterday. Only 2 are > >>> valid bugs. The remaining 309 ones are all spam and have been moved into > >>> the 'spam' component and marked as INVALID. > >> > >> We can also avoid archiving bugs with "spam" component to gcc-bugs@ ML. > > > > That would indeed remove one incentive of the spammers (bump up > > google search results by adding referers). > > You'd still get the initial bug creation message, so it wouldn't change > much. Well, we could remove (or replace with some different mail from a template telling the PR was a spam) even the initial mails for the spam/ component PRs in the archive afterwards. It is just the txt/ and html files plus perhaps adjusting the subject, or perhaps just adding one line to those msg*.html corresponding to spam/ bugs? or so? Are they ever regenerated or are they just created once and unmodified ever since? Jakub
Re: Account creation disabled on GCC Bugzilla
On 2 September 2014 11:01, Jakub Jelinek wrote: > On Tue, Sep 02, 2014 at 11:49:33AM +0200, Andreas Schwab wrote: >> Richard Biener writes: >> >> > On Tue, Sep 2, 2014 at 8:15 AM, Uros Bizjak wrote: >> >> Hello! >> >> >> >>> 311 bugs have been created on GCC Bugzilla since yesterday. Only 2 are >> >>> valid bugs. The remaining 309 ones are all spam and have been moved into >> >>> the 'spam' component and marked as INVALID. >> >> >> >> We can also avoid archiving bugs with "spam" component to gcc-bugs@ ML. >> > >> > That would indeed remove one incentive of the spammers (bump up >> > google search results by adding referers). >> >> You'd still get the initial bug creation message, so it wouldn't change >> much. > > Well, we could remove (or replace with some different mail from a template > telling the PR was a spam) even the initial mails for the spam/ component > PRs in the archive afterwards. It is just the txt/ and html files plus > perhaps adjusting the subject, or perhaps just adding one > line to those msg*.html corresponding to spam/ bugs? > > or so? Are they ever regenerated or are they just created once and > unmodified ever since? Would it be possible to give new accounts some probationary status such that the first bug report has to be confirmed as genuine before information is copied into archives etc. as spammers would want?
Re: GCC ARM: aligned access
On Mon, 1 Sep 2014 09:14:31 +0800 Peng Fan wrote: > On 09/01/2014 08:09 AM, Matt Thomas wrote: > > > > On Aug 31, 2014, at 11:32 AM, Joel Sherrill > > wrote: > >> I think this is totally expected. You were passed a u8 pointer > >> which is aligned for that type (no restrictions likely). You cast > >> it to a type with stricter alignment requirements. The code is > >> just flawed. Some CPUs handle unaligned accesses but not your ARM. > > > armv7 and armv6 arch except armv6-m support unaligned access. a u8 > pointer is casted to u32 pointer, should gcc take the align problem > into consideration to avoid possible errors? because > -mno-unaligned-access. Using -munaligned-access (or its inverse) isn't enough to make GCC generate code that can perform arbitrary unaligned accesses, because several instructions (e.g. VFP loads/stores or load/store multiple instructions IIRC) must still act on naturally-aligned data even when the hardware flag to enable unaligned accesses is on, and those instructions will still be generated by GCC when they are considered safe, i.e. when not doing explicitly-unaligned accesses in packed structures or similar. It would be *possible* to add an option to the backend to allow arbitrary alignment for any access, I think, but it's not at all clear that it's a good idea, and would certainly negatively affect performance. (If you need unaligned accesses, you can use e.g. memcpy, and that will probably generate good inline code.) Julian
[RFC] Don't inline builtin memory functions when ASan is enabled.
Hi, At this moment, most of GCC builtin memory functions (for example strcpy, stpcpy, wcpcpy, strdup, etc) are not instrumented by GCC, however some of them are rather dangerous. If GCC inlines these builtin functions, we will miss important checks for arguments, and possible overflow won't be detected. I know, that Clang ASan team simply disable inlining of builtin functions in Clang if -fsanitize=address is enabled and rely on libsanitizer's hooks. The main benefit of this approach is that we won't miss overflow in builtins, that can significantly increase target programs safety. Also, some redundant checks will be removed for builtin functions, that are instrumented and are not inlined for some reasons. The potential disadvantage of this approach is performance decreasing for sanitized programs. Does disabling of builtin functions inlining look sane in this case? If yes, I can provide performance investigation and prepare the patch. What do you think? -Maxim
Re: selective linking of floating point support for *printf / *scanf
On Tue, 2 Sep 2014, Joey Ye wrote: > Apparently newlib is not following this specification very well, as > there are symbols like _abc_r defined every where in current newlib. I > am not implying the spec should not be followed, but is newlib > designed to have a loose spec for the single underscore? Identifiers beginning with a single underscore are reserved with file scope. This means an application cannot provide an external definition of them, because such an external definition would have file scope. So it's fine for the implementation to define such identifiers and use them in the implementation of standard functions. You do still need to be more careful with them than with _[_A-Z]* identifiers. For example, you can't do #define standard_function(x) _standard_function(x) in your libc headers, because the user's application could legitimately define a variable called _standard_function at block scope, then try to call standard_function within that block. So in general it's safer to use the double underscore in the implementation, unless there is some clear reason to use the single underscore. -- Joseph S. Myers jos...@codesourcery.com
Re: Spam again
I added code to GCC Bugzilla last night to collect IP addresses from requests for new accounts. 80% - 90% of requests are coming from the following IP ranges: 62.122.72.x - 62.122.79.x 91.229.229.x 185.2.32.x 185.44.77.x - 185.44.79.x 188.72.126.x - 188.72.127.x 188.72.96.x 193.105.154.x 194.29.185.x 195.34.78.x - 195.34.79.x 195.78.108.x - 195.78.109.x All of them asked for a @wowring.ru account. If some of you want to play with these IP ranges, I would be curious to know where they are coming from. Maybe Russia? GCC Bugzilla is still under attack currently. Bugzilla reports 3-4 new user account creation attempts every *minute*, all for a @wowring.ru account. But @wowring.ru is blacklisted for the last 7 hours so all these attempts fail. Sorry for this morning, I wasn't around to blacklist this email domain sooner. So far, Bugzilla blocked 650 requests for a new account, mostly all for @wowring.ru. I also patched Bugzilla to no longer email the GCC mailing-list when a bug is moved into the 'spam' component. Frédéric
Re: Spam again
Frédéric Buclin writes: > All of them asked for a @wowring.ru account. If some of you want to play > with these IP ranges, I would be curious to know where they are coming > from. Maybe Russia? They come from all over Europe. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Fwd: Spam again
Hello! > I added code to GCC Bugzilla last night to collect IP addresses from > requests for new accounts. 80% - 90% of requests are coming from the > following IP ranges: > > 62.122.72.x - 62.122.79.x > 91.229.229.x > 185.2.32.x > 185.44.77.x - 185.44.79.x > 188.72.126.x - 188.72.127.x > 188.72.96.x > 193.105.154.x > 194.29.185.x > 195.34.78.x - 195.34.79.x > 195.78.108.x - 195.78.109.x > > All of them asked for a @wowring.ru account. If some of you want to play > with these IP ranges, I would be curious to know where they are coming > from. Maybe Russia? Please find GeoIP data for these IPs at [1], including location, ISP, organization and domain. [1] https://drive.google.com/file/d/0BzMiXQxzb9IOOHlFN3JPTE5jcmR6R1o4WlY4Y09BeUlGczZz/edit?usp=sharing Uros.
Bounded array type?
A recurring error in C (and to a lesser extent C++) is the lack of bounds checking in arrays. One famous instance of this error was the Heartbleed incident (which could also be blamed on messy code). I propose a GCC extension of a bounded array type. A bounded array is an array type that has a variable instead of a constant as its size parameter. For example, a function that writes to a buffer `buf` of size `sz` might have a prototype like this: buf *foo(char *buf, size_t sz); This is error-prone because even though a size parameter is given, the code in the function has no requirement to enforce it. With a bounded array type, the prototype looks like this: buf *foo(char buf[sz], size_t sz); The compiler now knows how large `buf` is, and it can put bounds checks into the code (which may be disabled with -O3). -James
Some questions about pass web
Hi I have following questions about web (pseudo register renaming) pass: 1. It is well known that register renaming is a big help to register allocation, but in gcc's backend, the web pass is far before RA, there are about 20 passes between them. Does it mean register renaming can also heavily benefit other optimizations? And the passes between them usually don't generate more register renaming chances? 2. It looks current web pass can't handle AUTOINC expressions, a reg operand is used as both use and def reference in an AUTOINC expression, so this def side should not be renamed. Pass web doesn't explicitly check this case, may rename the reg operand of AUTOINC expression. Is this expected because it is before auto_inc_dec pass? 3. Are AUTOINC expressions only generated by auto_inc_dec pass? All passes before auto_inc_dec including expand should not generate AUTOINC expressions, otherwise it will break web. Could anybody help to answer these questions? thanks a lot Guozhi Wei
Re: GCC ARM: aligned access
On 09/02/2014 09:25 PM, Julian Brown wrote: > On Mon, 1 Sep 2014 09:14:31 +0800 > Peng Fan wrote: > >> On 09/01/2014 08:09 AM, Matt Thomas wrote: >>> >>> On Aug 31, 2014, at 11:32 AM, Joel Sherrill >>> wrote: I think this is totally expected. You were passed a u8 pointer which is aligned for that type (no restrictions likely). You cast it to a type with stricter alignment requirements. The code is just flawed. Some CPUs handle unaligned accesses but not your ARM. >>> >> armv7 and armv6 arch except armv6-m support unaligned access. a u8 >> pointer is casted to u32 pointer, should gcc take the align problem >> into consideration to avoid possible errors? because >> -mno-unaligned-access. > > Using -munaligned-access (or its inverse) isn't enough to make GCC > generate code that can perform arbitrary unaligned accesses, because > several instructions (e.g. VFP loads/stores or load/store multiple > instructions IIRC) must still act on naturally-aligned data even when > the hardware flag to enable unaligned accesses is on, and those > instructions will still be generated by GCC when they are considered > safe, i.e. when not doing explicitly-unaligned accesses in packed > structures or similar. > > It would be *possible* to add an option to the backend to allow > arbitrary alignment for any access, I think, but it's not at all clear > that it's a good idea, and would certainly negatively affect > performance. > > (If you need unaligned accesses, you can use e.g. memcpy, and that will > probably generate good inline code.) Thanks for the reply. I've tried memcpy and all is fine. Regards, Peng. > > Julian >
Re: Some questions about pass web
For the relation between web and AUTOINC, I found the code in union_defs:
if (DF_REF_FLAGS (use) & DF_REF_READ_WRITE)
{
...
}
So web should handle AUTOINC in theory, but in an experiment, I added
a second web pass just before RA, web generated wrong code in the
presence of AUTOINC expressions. I will debug it more.
thanks
Guozhi Wei
On Tue, Sep 2, 2014 at 4:35 PM, Carrot Wei wrote:
> Hi
>
> I have following questions about web (pseudo register renaming) pass:
>
> 1. It is well known that register renaming is a big help to register
> allocation, but in gcc's backend, the web pass is far before RA, there
> are about 20 passes between them. Does it mean register renaming can
> also heavily benefit other optimizations? And the passes between them
> usually don't generate more register renaming chances?
>
> 2. It looks current web pass can't handle AUTOINC expressions, a reg
> operand is used as both use and def reference in an AUTOINC
> expression, so this def side should not be renamed. Pass web doesn't
> explicitly check this case, may rename the reg operand of AUTOINC
> expression. Is this expected because it is before auto_inc_dec pass?
>
> 3. Are AUTOINC expressions only generated by auto_inc_dec pass? All
> passes before auto_inc_dec including expand should not generate
> AUTOINC expressions, otherwise it will break web.
>
> Could anybody help to answer these questions?
>
> thanks a lot
> Guozhi Wei
RE: selective linking of floating point support for *printf / *scanf
> From: Joseph S. Myers [mailto:jos...@codesourcery.com] > Sent: Tuesday, September 02, 2014 11:29 PM > > Identifiers beginning with a single underscore are reserved with file > scope. This means an application cannot provide an external definition of > them, because such an external definition would have file scope. So it's > fine for the implementation to define such identifiers and use them in the > implementation of standard functions. Ah yes, I mistook file scope with file scope with internal linkage. So then there shouldn't be any problem since _printf_float and _scanf_float are only used for external linkage, no macro refer to them. Best regards, Thomas
