Re: clang and FSF's strategy
"Eric S. Raymond" writes: > Ian Lance Taylor : >> I'm sympathetic to our comments regarding GCC vs. clang. But I'm not >> sure I grasp your proposed solution. GCC does support plugins, and >> has supported them for a few releases now. > > Then I don't understand why David Kastrup's question was even > controversial. I must have missed the controversy. > If I have failed to understand the background facts, I apologize and > welcome being corrected. I'll refrain from any comments about wiping the egcs off anybody's face. My reply to your "call to arms" was actually rooted in as much (or rather little) actual knowledge of the pertinent situation as your request appears to have been. But as you chose an enquiring mail of mine to justify your confrontational approach, I felt that I should mitigate the damage purportedly originating from me by addressing those points that I cannot consider a justifiable conclusion from what I wrote. -- David Kastrup
VEC_WIDEN_MULT_(LO|HI)_EXPR vs. VEC_WIDEN_MULT_(EVEN|ODD)_EXPR in vectorization.
Hi,
I noticed there is a regression of 4.8 against ancient 4.5 in vectorization on
our port. After a bit investigation, I found following code that prefer
even|odd version instead of lo|hi one. This is obviously the case for AltiVec
and maybe some other targets. But even|odd (expanding to a series of
instructions) versions are less efficient on our target than lo|hi ones.
Shouldn't there be a target-specific hook to do the choice instead of
hard-coded one here, or utilizing some cost-estimating technique to compare two
alternatives?
/* The result of a vectorized widening operation usually requires
two vectors (because the widened results do not fit into one vector).
The generated vector results would normally be expected to be
generated in the same order as in the original scalar computation,
i.e. if 8 results are generated in each vector iteration, they are
to be organized as follows:
vect1: [res1,res2,res3,res4],
vect2: [res5,res6,res7,res8].
However, in the special case that the result of the widening
operation is used in a reduction computation only, the order doesn't
matter (because when vectorizing a reduction we change the order of
the computation). Some targets can take advantage of this and
generate more efficient code. For example, targets like Altivec,
that support widen_mult using a sequence of {mult_even,mult_odd}
generate the following vectors:
vect1: [res1,res3,res5,res7],
vect2: [res2,res4,res6,res8].
When vectorizing outer-loops, we execute the inner-loop sequentially
(each vectorized inner-loop iteration contributes to VF outer-loop
iterations in parallel). We therefore don't allow to change the
order of the computation in the inner-loop during outer-loop
vectorization. */
/* TODO: Another case in which order doesn't *really* matter is when we
widen and then contract again, e.g. (short)((int)x * y >> 8).
Normally, pack_trunc performs an even/odd permute, whereas the
repack from an even/odd expansion would be an interleave, which
would be significantly simpler for e.g. AVX2. */
/* In any case, in order to avoid duplicating the code below, recurse
on VEC_WIDEN_MULT_EVEN_EXPR. If it succeeds, all the return values
are properly set up for the caller. If we fail, we'll continue with
a VEC_WIDEN_MULT_LO/HI_EXPR check. */
if (vect_loop
&& STMT_VINFO_RELEVANT (stmt_info) == vect_used_by_reduction
&& !nested_in_vect_loop_p (vect_loop, stmt)
&& supportable_widening_operation (VEC_WIDEN_MULT_EVEN_EXPR,
stmt, vectype_out, vectype_in,
code1, code2, multi_step_cvt,
interm_types))
return true;
Thanks,
Bingfeng Mei
Re: clang and FSF's strategy
On Tue, 2014-01-21 at 15:19 -0500, Eric S. Raymond wrote: > Therefore, I point out that FSF can no longer prevent proprietary > vendors from plugging into a free compiler to improve their tools. [snip] > I also think it bears noticing that nobody outside of Microsoft seems > to particularly want to write proprietary compilers any more. The FSF sure can prevent it, and proprietary compilers still thrive. Here is one that particularly bugs me as an Octave developer: we routinely see people being lured to use Nvidia's non-free nvcc for GPU computing, which they gleefully admit is based on clang and LLVM. And there is Xcode, of course, completely non-free and completely based on clang and LLVM. The fact that these non-free tools are not based on gcc are a testament to how proprietary software developers cannot plug into gcc, and how clang is fostering non-free software. The nvidia situation is particularly dire becuase today, free GPU computing is almost nonexistent. It's almost all based on CUDA and nvidia's massive pro-CUDA marketing campaign. Even most OpenCL implementations are non-free, and the scant few free implementations of OpenCL that exist are not fully functional. We also have technical reasons in Octave to not use LLVM, even though we are using it right now: its API is hugely unstable. Each new LLVM release has needed its own new, complicated autoconf checks. We have been chatting with Red Hat's David Malcolm who works on libgccjit to help us get something better and more stable. This thus proves that it is not impossible to use gcc for the same tasks as LLVM, and its pluggability is growing. - Jordi G. H.
Re: -Wformat-security warnings generated in gcc build
On Tue, Jan 21, 2014 at 11:20 PM, Joseph S. Myers
wrote:
> On Tue, 21 Jan 2014, Prathamesh Kulkarni wrote:
>
>> Souce of these warnings are typically calls to error() and friends.
>> In C and C++ front ends there are many calls of error (errmsg).
>> errmsg is in many cases, assigned the return value of targetm hooks
>> (tagetm.invalid_return_type(), etc.) Is it correct to replace error
>> (errmsg) by
>> error ("%s", errmsg) in these cases ?
>
> No. Typically the message returned by the hook may contain no-arguments
> format specifiers such as %< and %>. Instead, to avoid such warnings you
> need to add a new function error_at_no_args (location, message) that
> accepts and processes only formats taking no arguments (and probably
> aborts if given a format that needs arguments).
>
Here's an initial try:
void
error_at_no_args (location_t loc, const char *gmsgid)
{
diagnostic_info diagnostic;
diagnostic_set_info (&diagnostic, gmsgid, NULL, loc, DK_ERROR);
report_diagnostic (&diagnostic);
}
I guess this shall work fine for no-argument specifiers ? (I tested it
with %%, %m, %', %<, %>)
However this causes segmentation fault, when format string contains
argument specifier (which is anyways incorrect), I believe that's
because I am passing NULL in place of argument pointer.
Unfortunately, I am not clear on how to check for format specifiers in string.
Should I do it manually by checking the format string for specifiers
and call abort if found a no-argument specifier,
or is there a better way to do it ?
Thanks!
> --
> Joseph S. Myers
> jos...@codesourcery.com
Hurd: /lib/ld.so vs. /lib/ld.so.1 (was: Policy: Require new dynamic loader names for entirely new ABIs?)
Hi! On Wed, 22 Jan 2014 03:54:31 +, "Joseph S. Myers" wrote: > On Tue, 21 Jan 2014, Carlos O'Donell wrote: > > > x86 Hurd (32-bit, hard-float): /lib/ld.so (that is, GCC uses that name > > > with -dynamic-linker so in PT_INTERP; my understanding of > > > shlib-versions is that it gets the SONAME ld.so.1 by default). > > > > Is that a bug? > > I don't know. Thomas? For x86 Hurd, GCC has been specifying »-dynamic-linker /lib/ld.so« in LINK_SPEC since forever (1995, or earlier), and Debian glibc has had the following since forever (2002, or earlier): ifeq ($(DEB_HOST_GNU_SYSTEM),gnu) # Why doesn't the glibc makefile install this? ln -sf ld.so.1 $(tmpdir)/$@/lib/ld.so endif Roland, do you have any recollection of this? Assuming that /lib/ld.so.1 is the "official" name, I suppose GCC should be changed, and then Debian could drop the symbolic link after a transition period (full archive rebuilt, etc.). Grüße, Thomas pgp3Xd3MdfZpo.pgp Description: PGP signature
[gomp4] Questions about "declare target" and "target update" pragmas
Hi Jakub,
I have 2 questions concerning OpenMP 4.0 specification.
1. Do I understand correctly that every "declare target" directive should be
closed with "end declare target"? E.g. in this example GCC marks both foo1 and
foo2 with "omp declare target" attribute:
#pragma omp declare target
int foo1 () { return 1; }
int foo2 () { return 2; }
/* EOF */
Shouldn't the frontend issue an error message that there is "declare target"
without corresponding "end declare target"?
2. Do I understand correctly that the "target update" directive can be used
outside the "target" or "target data" regions? E.g. this example should
print '2' (and it prints '2' while building with icc):
#pragma omp declare target
int G = 1;
#pragma omp end declare target
int main ()
{
G = 2;
#pragma omp target update to(G)
G = 3;
int x = 0;
#pragma omp target
{
x = G;
}
printf ("%d\n", x);
}
If it is acceptable, then GOMP_target_update should also map variables that
wasn't mapped.
Thanks,
-- Ilya
Re: [gomp4] Questions about "declare target" and "target update" pragmas
On Wed, Jan 22, 2014 at 07:51:51PM +0400, Ilya Verbin wrote:
> I have 2 questions concerning OpenMP 4.0 specification.
>
>
> 1. Do I understand correctly that every "declare target" directive should be
> closed with "end declare target"? E.g. in this example GCC marks both foo1
> and
> foo2 with "omp declare target" attribute:
>
> #pragma omp declare target
> int foo1 () { return 1; }
> int foo2 () { return 2; }
> /* EOF */
Yes, this is invalid.
> Shouldn't the frontend issue an error message that there is "declare target"
> without corresponding "end declare target"?
I guess so, e.g. the C FE has current_omp_declare_target_attribute,
supposedly it could check it after parsing the whole file and if it is
non-zero at the end, complain.
> 2. Do I understand correctly that the "target update" directive can be used
> outside the "target" or "target data" regions? E.g. this example should
> print '2' (and it prints '2' while building with icc):
>
> #pragma omp declare target
> int G = 1;
> #pragma omp end declare target
>
> int main ()
> {
> G = 2;
> #pragma omp target update to(G)
> G = 3;
> int x = 0;
> #pragma omp target
> {
> x = G;
> }
> printf ("%d\n", x);
> }
This can print 3 (if doing host fallback or device shares address space
with host), or 2 (otherwise). It shouldn't print 1 ever, and yes,
the target update is then well defined. All variables from omp declare
target are allocated on the device sometime before
the first target data/target update/target region; given that they will
be allocated in the data section of the target DSO, they actually just need
to be registered with the mapping data structure when the DSO is loaded.
> If it is acceptable, then GOMP_target_update should also map variables that
> wasn't mapped.
No, the target DSO initialization should use the tables we've talked about
to initialize the mapping.
Jakub
Re: -Wformat-security warnings generated in gcc build
On Wed, 22 Jan 2014, Prathamesh Kulkarni wrote: > Unfortunately, I am not clear on how to check for format specifiers in string. > Should I do it manually by checking the format string for specifiers > and call abort if found a no-argument specifier, > or is there a better way to do it ? I'll leave it to Dodji as diagnostics maintainer to advise on the best way to implement error_at_no_args. -- Joseph S. Myers jos...@codesourcery.com
tsan tests randomly failing
Hi, a couple of tsan tests: c-c++-common/tsan/simple_race.c g++.dg/tsan/default_options.C relatively often fail for me at various optimization levels (eg, in my last run the former at -O2: no WARNING: ThreadSanitizer... thus the test failed). Is this a known issue? The machine I'm talking about is otherwise very stable (i980x, glibc2.18, nothing special) Thanks, Paolo.
Re: tsan tests randomly failing
On Wed, Jan 22, 2014 at 07:05:23PM +0100, Paolo Carlini wrote: > a couple of tsan tests: > > c-c++-common/tsan/simple_race.c > g++.dg/tsan/default_options.C > > relatively often fail for me at various optimization levels (eg, in > my last run the former at -O2: no WARNING: ThreadSanitizer... thus > the test failed). > > Is this a known issue? The machine I'm talking about is otherwise > very stable (i980x, glibc2.18, nothing special) Yes, this is known, unfortunately the implementation of libtsan is in itself racy, thus it sometimes doesn't report a problem when it should. See https://groups.google.com/forum/#!topic/thread-sanitizer/KIok3F_b1oI We have yet to decide what to do with the tests, either kill them altogether, add some nanosleeps to increase probability of succeeding, run the test internally several times until the problem is reported, etc. Jakub
Re: bootstrap broken for '-O3'
On Sun, Jan 19, 2014 at 07:39:12PM +0100, Winfried Magerl wrote: > Hi, > > since "trunk revision 206525" I'm unable to bootstrap > gcc with '-O3' as optimisation. No problem until > revision 2065250. > > From the diff-output it looks like this entry from > ChangeLog is the only candidate: > > --- > diff -urN -x.svn gcc-head-206520/LAST_UPDATED gcc-head-206525/LAST_UPDATED > --- gcc-head-206520/LAST_UPDATED2014-01-19 17:54:07.053340903 +0100 > +++ gcc-head-206525/LAST_UPDATED2014-01-19 18:58:54.049008110 +0100 > @@ -1,2 +1,2 @@ > -Sun Jan 19 17:54:07 CET 2014 > -Sun Jan 19 16:54:07 UTC 2014 (revision 206520) > +Sun Jan 19 18:58:54 CET 2014 > +Sun Jan 19 17:58:54 UTC 2014 (revision 206525) > diff -urN -x.svn gcc-head-206520/gcc/ChangeLog gcc-head-206525/gcc/ChangeLog > --- gcc-head-206520/gcc/ChangeLog 2014-01-19 17:54:03.620441749 +0100 > +++ gcc-head-206525/gcc/ChangeLog 2014-01-19 18:58:51.113097157 +0100 > @@ -1,3 +1,15 @@ > +2014-01-10 Richard Biener > + > + PR tree-optimization/59374 > + * tree-vect-slp.c (vect_slp_analyze_bb_1): Move dependence > + checking after SLP discovery. Mark stmts not participating > + in any SLP instance properly. > + > +2014-01-10 Kyrylo Tkachov > + > + * config/arm/arm.c (arm_new_rtx_costs): Use destination mode > + when handling a SET rtx. > + > 2014-01-10 Kyrylo Tkachov > > * config/arm/arm-cores.def (cortex-a53): Specify FL_CRC32. > --- > > gcc is built with the following commands: > > --- > CFLAGS="-O3"; export CFLAGS > CXXFLAGS="$CFLAGS"; export CXXFLAGS > CFLAGS="$CFLAGS" CXXFLAGS="$CFLAGS" XCFLAGS="$CFLAGS" TCFLAGS="$CFLAGS" \ > ../gcc-head-206525/configure --enable-shared --prefix=/usr > --enable-multilib=no --enable-checking=release --enable-werror=no > --enable-languages='c,c++' >& configure.out > make -j6 BOOT_CFLAGS="-O3" >& make.out || exit 1 > --- > > and results in the following error: > > -- > # make compare > Comparing stages 2 and 3 > warning: gcc/cc1-checksum.o differs > warning: gcc/cc1plus-checksum.o differs > Bootstrap comparison failure! > gcc/bitmap.o differs > gcc/bt-load.o differs > gcc/emit-rtl.o differs > libiberty/pic/md5.o differs > libiberty/md5.o differs > Makefile:20642: recipe for target 'compare' failed > make: *** [compare] Error 1 > -- > > I've verified the behaviour on opensuse 13.1 too to ensure > it's not caused by local tool-chain. reverting the patch for tree-vect-slp.c fixes the build with -O3 for current trunk (revision 206934). I've verified this on openSUSE 13.1 (x86_64). regards winfried
Re: Enable -Wreturn-type by default ?
On 16/01/2014 03:45, Jonathan Wakely wrote:
> On 16 January 2014 11:11, Sylvestre Ledru wrote:
>> Hello,
>>
>> On 17/11/2013 17:47, Jonathan Wakely wrote:
>>> On 17 November 2013 15:40, Sylvestre Ledru wrote:
For "control reaches end of non-void function", I haven't activated by
default and I called the option -Wfalloff-nonvoid-function
Of course, that is just a proposal! :) Better names are welcome.
>>> It was nearly called -Wmissing-return a decade ago, but got bundled
>>> with -Wreturn-type, see
>>> http://gcc.gnu.org/ml/gcc-patches/2002-02/msg02002.html
>> As discussed on this mailing list, I proposed a patch on the gcc-patches
>> mailing list.
>> http://gcc.gnu.org/ml/gcc-patches/2014-01/msg00820.html
>>
>> Any chance one of you could review it?
> I like the change in principle, but it's not up to me, I can't approve
> front-end patches. I can comment on the docs and ChangeLog but I'm
> not subscribed to gcc-patches so didn't get the mail. I'll send some
> comments, could you please reply to your gcc-patches mail and include
> my comments? Thanks.
Following the comments you sent me, here it is:
> Does -Wreturn-type enable -Wmissing-return? If not, users who
> currently use -Werror=return-type might be surprised when "missing
> return" warnings are no longer errors., because they are controlled by
> a different option. That would require users to add
> -Werror=missing-return to their makefiles, which would not be
> compatible with older versions of GCC.
Actually, I wonder if -Wmissing-return should not be included by default ...
If you do not agree, could you tell me how I could enable
-Wmissing-return with both
-Wreturn-type and -Wall?
Now, the code (I haven't touched the testsuite, the archive remains the
same).
gcc/ChangeLog:
2014-01-23 Sylvestre Ledru
PR other/PR55189
* doc/invoke.texi: Update of the documentation (-Wreturn-type
-Wmissing-return enabled by default)
* tree-cfg.c: Likewise
gcc/c-family/ChangeLog:
2014-01-23 Sylvestre Ledru
* c.opt: Extract -Wmissing-return from -Wreturn-type to return
a warning when a return statement is missing.
gcc/fortran/ChangeLog:
2014-01-23 Sylvestre Ledru
* options.c: Extract -Wmissing-return from -Wreturn-type to return
a warning when a return statement is missing.
Index: gcc/c-family/c.opt
===
--- gcc/c-family/c.opt(révision 206953)
+++ gcc/c-family/c.opt(copie de travail)
@@ -673,9 +673,13 @@
Warn about returning a pointer/reference to a local or temporary variable.
Wreturn-type
-C ObjC C++ ObjC++ Var(warn_return_type) Warning LangEnabledBy(C ObjC
C++ ObjC++,Wall)
+C ObjC C++ ObjC++ Var(warn_return_type) Init(1) Warning
Warn whenever a function's return type defaults to \"int\" (C), or
about inconsistent return types (C++)
+Wmissing-return
+C ObjC C++ ObjC++ Var(warn_missing_return) Init(1) Warning
LangEnabledBy(C ObjC C++ ObjC++, Wreturn-type)
+Warn whenever control may reach end of non-void function
+
Wselector
ObjC ObjC++ Var(warn_selector) Warning
Warn if a selector has multiple methods
Index: gcc/doc/invoke.texi
===
--- gcc/doc/invoke.texi(révision 206953)
+++ gcc/doc/invoke.texi(copie de travail)
@@ -255,7 +255,7 @@
-Winvalid-pch -Wlarger-than=@var{len} -Wunsafe-loop-optimizations @gol
-Wlogical-op -Wlong-long @gol
-Wmain -Wmaybe-uninitialized -Wmissing-braces
-Wmissing-field-initializers @gol
--Wmissing-include-dirs @gol
+-Wmissing-include-dirs -Wmissing-return @gol
-Wno-multichar -Wnonnull -Wno-overflow -Wopenmp-simd @gol
-Woverlength-strings -Wpacked -Wpacked-bitfield-compat -Wpadded @gol
-Wparentheses -Wpedantic-ms-format -Wno-pedantic-ms-format @gol
@@ -3348,6 +3348,7 @@
-Wmain @r{(only for C/ObjC and unless} @option{-ffreestanding}@r{)} @gol
-Wmaybe-uninitialized @gol
-Wmissing-braces @r{(only for C/ObjC)} @gol
+-Wmissing-return @gol
-Wnonnull @gol
-Wopenmp-simd @gol
-Wparentheses @gol
@@ -3810,7 +3811,11 @@
message, even when @option{-Wno-return-type} is specified. The only
exceptions are @samp{main} and functions defined in system headers.
-This warning is enabled by @option{-Wall}.
+@item -Wmissing-return
+@opindex Wmissing-return
+@opindex Wno-missing-return
+Warn whenever falling off the end of the function body (i.e. without
+a return statement).
@item -Wswitch
@opindex Wswitch
Index: gcc/fortran/options.c
===
--- gcc/fortran/options.c(révision 206953)
+++ gcc/fortran/options.c(copie de travail)
@@ -717,6 +717,10 @@
warn_return_type = value;
break;
+case OPT_Wmissing_return:
+ warn_missing_return = value;
+ break;
+
case OPT_Wsurprising:
gfc_option.warn_surprising = value;
break;
Index: gcc/tree-cfg.c
