Re: Where Are Release Signatures Located?
On August 11, 2017 6:23:01 PM GMT+02:00, R0b0t1 wrote: >I have checked a few of the mirrors listed on >https://gcc.gnu.org/mirrors.html. That page lists a few keys that >releases might be signed by, but on all of the mirrors I checked I do >not actually see any signed files. What am I missing? Only the tarballs on ftp.gnu.org and its mirrors are signed. Richard. >Thanks in advance, > R0b0t1.
Re: [PATCH] Write dependency information (-M*) even if there are errors
Joseph Myers writes: > I suppose a question for the present proposal would be making sure any > dependencies generated in this case do not include dependencies on files > that don't exist (so #include "some-misspelling.h" doesn't create any sort > of dependency on such a header). Good point. I've tested this and I believe everything is in order: unless -MG is specified, a non-existent header is treated as a fatal error so we don't even get to writing the dependency info. And if -MG is specified, then there is no error and we get the missing header in the dependency output, as requested. Boris
Re: [PATCH] Write dependency information (-M*) even if there are errors
Segher Boessenkool writes:
> Patches should go to gcc-patches.
Ok, will keep in mind for future (seeing that we have a discussion
already it probably doesn't make sense to move this patch).
> Two spaces after a full stop (all three times).
Fixed, new revision included.
Thanks,
Boris
Index: gcc/c-family/ChangeLog
===
--- gcc/c-family/ChangeLog (revision 250514)
+++ gcc/c-family/ChangeLog (working copy)
@@ -1,3 +1,8 @@
+2017-08-06 Boris Kolpackov
+
+ * c-opts.c (c_common_finish): Write dependency information even if
+ there are errors.
+
2017-07-14 David Malcolm
* c-common.c (try_to_locate_new_include_insertion_point): New
Index: gcc/c-family/c-opts.c
===
--- gcc/c-family/c-opts.c (revision 250514)
+++ gcc/c-family/c-opts.c (working copy)
@@ -1152,8 +1157,11 @@
{
FILE *deps_stream = NULL;
- /* Don't write the deps file if there are errors. */
- if (cpp_opts->deps.style != DEPS_NONE && !seen_error ())
+ /* Note that we write the dependencies even if there are errors. This is
+ useful for handling outdated generated headers that now trigger errors
+ (for example, with #error) which would be resolved by re-generating
+ them. In a sense, this complements -MG. */
+ if (cpp_opts->deps.style != DEPS_NONE)
{
/* If -M or -MM was seen without -MF, default output to the
output stream. */
Re: [PATCH] Write dependency information (-M*) even if there are errors
Hi Boris, On Sat, Aug 12, 2017 at 05:53:44PM +0200, Boris Kolpackov wrote: > Segher Boessenkool writes: > > > Patches should go to gcc-patches. > > Ok, will keep in mind for future (seeing that we have a discussion > already it probably doesn't make sense to move this patch). Please do move it; gcc-patches is where people look for patches, not here (say, a year from now, when someone want to look up history of this patch). Segher
Optimization breaks inline asm code w/ptrs
Environment:
gcc 6.1
compiling for 64bit i386
optimizations: -O2
Consider this simple bit of code (from
https://stackoverflow.com/a/45656087/2189500):
#include
int getStringLength(const char *pStr){
int len;
__asm__ (
"repne scasb\n\t"
"not %%ecx\n\t"
"dec %%ecx"
:"=c" (len), "+D"(pStr)
:"c"(-1), "a"(0)
);
return len;
}
int main()
{
char buff[50] = "hello world";
int a = getStringLength(buff);
printf("%s: %d\n", buff, a);
}
This code works as expected and prints out 11. Yay.
However, if you add "buff[4] = 0;" before the call to getStringLength,
it STILL prints out 11 (when optimizations are enabled), when it should
print 4.
I would expect this kind of behavior if the asm were in 'main.' But it
has always been my understanding that function calls performed an
implicit memory clobber. The fact that this clobber goes away during
inlining means that code can stop working any time the compiler makes a
different decision about whether or not to inline a function. Ouch.
And before somebody asks: Adding "+m"(pStr) does not help.
The result is that (apparently) you can NEVER safely pass a buffer
pointer to inline asm without using the memory clobber. If this is
true, I don't believe it is widely known.
Given how 'heavy' memory clobbers are, I would hope that only pointers
that have 'escaped' the function would get flushed before a function
call. But not flushing *anything* seems very bad.
dw
Re: Optimization breaks inline asm code w/ptrs
On Sat, Aug 12, 2017 at 10:08 PM, Andrew Pinski wrote:
> On Sat, Aug 12, 2017 at 9:21 PM, David Wohlferd
> wrote:
>> Environment:
>> gcc 6.1
>> compiling for 64bit i386
>> optimizations: -O2
>>
>> Consider this simple bit of code (from
>> https://stackoverflow.com/a/45656087/2189500):
>>
>> #include
>>
>> int getStringLength(const char *pStr){
>>
>> int len;
>>
>> __asm__ (
>> "repne scasb\n\t"
>> "not %%ecx\n\t"
>> "dec %%ecx"
>> :"=c" (len), "+D"(pStr)
>> :"c"(-1), "a"(0)
>> );
>>
>> return len;
>> }
>>
>> int main()
>> {
>>char buff[50] = "hello world";
>>int a = getStringLength(buff);
>>printf("%s: %d\n", buff, a);
>> }
>>
>> This code works as expected and prints out 11. Yay.
>>
>> However, if you add "buff[4] = 0;" before the call to getStringLength, it
>> STILL prints out 11 (when optimizations are enabled), when it should print
>> 4.
>>
>> I would expect this kind of behavior if the asm were in 'main.' But it has
>> always been my understanding that function calls performed an implicit
>> memory clobber. The fact that this clobber goes away during inlining means
>> that code can stop working any time the compiler makes a different decision
>> about whether or not to inline a function. Ouch.
>>
>> And before somebody asks: Adding "+m"(pStr) does not help.
>
> But does adding:
> "+m"(*pStr)
>
> Help?
>
>
> "+m"(pStr) Just says pStr variable changes, not what it points to.
I should ask why are you using inline-asm for this? strlen will have
the best optimized version for your processor anyways.
Thanks,
Andrew
> Thanks,
> Andrew Pinski
>
>>
>> The result is that (apparently) you can NEVER safely pass a buffer pointer
>> to inline asm without using the memory clobber. If this is true, I don't
>> believe it is widely known.
>>
>> Given how 'heavy' memory clobbers are, I would hope that only pointers that
>> have 'escaped' the function would get flushed before a function call. But
>> not flushing *anything* seems very bad.
>>
>> dw
>>
Re: Optimization breaks inline asm code w/ptrs
On Sat, Aug 12, 2017 at 9:21 PM, David Wohlferd wrote:
> Environment:
> gcc 6.1
> compiling for 64bit i386
> optimizations: -O2
>
> Consider this simple bit of code (from
> https://stackoverflow.com/a/45656087/2189500):
>
> #include
>
> int getStringLength(const char *pStr){
>
> int len;
>
> __asm__ (
> "repne scasb\n\t"
> "not %%ecx\n\t"
> "dec %%ecx"
> :"=c" (len), "+D"(pStr)
> :"c"(-1), "a"(0)
> );
>
> return len;
> }
>
> int main()
> {
>char buff[50] = "hello world";
>int a = getStringLength(buff);
>printf("%s: %d\n", buff, a);
> }
>
> This code works as expected and prints out 11. Yay.
>
> However, if you add "buff[4] = 0;" before the call to getStringLength, it
> STILL prints out 11 (when optimizations are enabled), when it should print
> 4.
>
> I would expect this kind of behavior if the asm were in 'main.' But it has
> always been my understanding that function calls performed an implicit
> memory clobber. The fact that this clobber goes away during inlining means
> that code can stop working any time the compiler makes a different decision
> about whether or not to inline a function. Ouch.
>
> And before somebody asks: Adding "+m"(pStr) does not help.
But does adding:
"+m"(*pStr)
Help?
"+m"(pStr) Just says pStr variable changes, not what it points to.
Thanks,
Andrew Pinski
>
> The result is that (apparently) you can NEVER safely pass a buffer pointer
> to inline asm without using the memory clobber. If this is true, I don't
> believe it is widely known.
>
> Given how 'heavy' memory clobbers are, I would hope that only pointers that
> have 'escaped' the function would get flushed before a function call. But
> not flushing *anything* seems very bad.
>
> dw
>
