Re: Implementing OpenACC's Fortran module
Hi! On Wed, 20 Aug 2014 00:57:53 +0200, I wrote: > On Wed, 20 Aug 2014 00:05:22 +0200, Tobias Burnus wrote: > > James Norris wrote: > > > I think the files are ready for upstream submitting unless you can > > > think of other things > > > that should done. Yes? No? > > > > What do you mean by upstream? I assume gomp-4_0-branch and not yet GCC-5 > > trunk. > > > > I think the patch is fine for the gomp-4_0-branch. > > Good, thanks. (Submission for trunk inclusion to follow "soon".) > > If you want to go beyond dumping the file there, you should also edit > > the Makefile to install the .mod and .h file, and link the .o file. Regarding linking the object file produced by Fortran openacc.f90 into libgomp: (with the version that Jim already has internally checked in) I find that libgomp then has undefined references to _gfortran_internal_unpack and _gfortran_internal_pack. How to solve this? Link libgomp against libgfortran? (Not a suitable solution in my opinion: every non-Fortran libgomp user doesn't want Fortran stuff linked in.) Link the object file into libgfortran instead of libgomp? (Will have undefined references to a lot of libgomp symbols, and don't want to unconditionally link libgfortran against libgomp.) Include weak definitions for these two symbols in libgomp? (Probably fragile?) Avoid need for these two symbols? (Might not be possible, might be fragile?) Is there a Fortran compilation mode so that instead of shipping this object code in libgomp, it will be built "on the fly" from the openacc.f90, and then included in a user's executable? (Would not work if a user uses the openacc_lib.h header file instead of the openacc.f90 module?) Or, is it an option to build the object file form openacc.f90, but not link it into libgomp, but instead install the non-PIC openacc.o and PIC .libs/openacc.o into GCC's installation tree, and then have the driver link in these files additionally to libgomp only if compiling for Fortran? Anything else? Grüße, Thomas pgpRgwsNITTRH.pgp Description: PGP signature
gcc 4.7.4 lto build failure
/home/rogelio/gcc-build/./prev-gcc/g++ -B/home/rogelio/gcc-build/./prev-gcc/ -B/x86_64-unknown-linux-gnu/bin/ -nostdinc++ -B/home/rogelio/gcc-build/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs -B/home/rogelio/gcc-build/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -I/home/rogelio/gcc-build/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu -I/home/rogelio/gcc-build/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include -I/home/rogelio/gcc-4.7.4/libstdc++-v3/libsupc++ -L/home/rogelio/gcc-build/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs -L/home/rogelio/gcc-build/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -g -O2 -flto=jobserver -frandom-seed=1 -fprofile-use -DIN_GCC -fno-exceptions -fno-rtti -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -static-libstdc++ -static-libgcc -o cc1 c-lang.o c-family/stub-objc.o attribs.o c-errors.o c-decl.o c-typeck.o c-convert.o c-aux-info.o c-objc-common.o c-parser.o tree-mudflap.o c-family/c-common.o c-family/c-cppbuiltin.o c-family/c-dump.o c-family/c-format.o c-family/c-gimplify.o c-family/c-lex.o c-family/c-omp.o c-family/c-opts.o c-family/c-pch.o c-family/c-ppoutput.o c-family/c-pragma.o c-family/c-pretty-print.o c-family/c-semantics.o c-family/c-ada-spec.o i386-c.o default-c.o \ cc1-checksum.o main.o libbackend.a libcommon-target.a libcommon.a ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a libcommon.a ../libcpp/libcpp.a ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a-lmpc -lmpfr -lgmp -rdynamic -ldl -lz c-family/c-format.o (symbol from plugin): warning: memset used with constant zero length parameter; this could be due to transposed parameters collect2: error: ld returned 1 exit status Any pointers how to debug this? I configured with: ../gcc-4.7.4/configure --prefix= --libexecdir=/lib --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale --enable-languages=c,lto --disable-multilib --with-system-zlib --enable-lto --with-build-config=bootstrap-lto then did a profiledbootstrap make Thanks in advance
Re: gcc 4.7.4 lto build failure
On 2014.09.19 at 13:15 +0100, Rogelio Serrano wrote: > /home/rogelio/gcc-build/./prev-gcc/g++ > -B/home/rogelio/gcc-build/./prev-gcc/ -B/x86_64-unknown-linux-gnu/bin/ > -nostdinc++ > -B/home/rogelio/gcc-build/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs > -B/home/rogelio/gcc-build/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs > -I/home/rogelio/gcc-build/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu > -I/home/rogelio/gcc-build/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include > -I/home/rogelio/gcc-4.7.4/libstdc++-v3/libsupc++ > -L/home/rogelio/gcc-build/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs > -L/home/rogelio/gcc-build/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs > -g -O2 -flto=jobserver -frandom-seed=1 -fprofile-use -DIN_GCC > -fno-exceptions -fno-rtti -W -Wall -Wno-narrowing -Wwrite-strings > -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long > -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H > -static-libstdc++ -static-libgcc -o cc1 c-lang.o c-family/stub-objc.o > attribs.o c-errors.o c-decl.o c-typeck.o c-convert.o c-aux-info.o > c-objc-common.o c-parser.o tree-mudflap.o c-family/c-common.o > c-family/c-cppbuiltin.o c-family/c-dump.o c-family/c-format.o > c-family/c-gimplify.o c-family/c-lex.o c-family/c-omp.o > c-family/c-opts.o c-family/c-pch.o c-family/c-ppoutput.o > c-family/c-pragma.o c-family/c-pretty-print.o c-family/c-semantics.o > c-family/c-ada-spec.o i386-c.o default-c.o \ > cc1-checksum.o main.o libbackend.a libcommon-target.a libcommon.a > ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a libcommon.a > ../libcpp/libcpp.a ../libiberty/libiberty.a > ../libdecnumber/libdecnumber.a-lmpc -lmpfr -lgmp -rdynamic -ldl > -lz > c-family/c-format.o (symbol from plugin): warning: memset used with > constant zero length parameter; this could be due to transposed > parameters > collect2: error: ld returned 1 exit status > > > Any pointers how to debug this? > > I configured with: > > ../gcc-4.7.4/configure --prefix= --libexecdir=/lib --enable-shared > --enable-threads=posix --enable-__cxa_atexit --enable-clocale > --enable-languages=c,lto --disable-multilib --with-system-zlib > --enable-lto --with-build-config=bootstrap-lto > > then did a profiledbootstrap make When using profiledbootstrap you should add --disable-werror to the configuration flags. -- Markus
Re: gcc 4.7.4 lto build failure
On 2014.09.19 at 14:55 +0200, Markus Trippelsdorf wrote: > On 2014.09.19 at 13:15 +0100, Rogelio Serrano wrote: > > /home/rogelio/gcc-build/./prev-gcc/g++ > > -B/home/rogelio/gcc-build/./prev-gcc/ -B/x86_64-unknown-linux-gnu/bin/ > > -nostdinc++ > > -B/home/rogelio/gcc-build/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs > > -B/home/rogelio/gcc-build/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs > > -I/home/rogelio/gcc-build/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu > > -I/home/rogelio/gcc-build/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include > > -I/home/rogelio/gcc-4.7.4/libstdc++-v3/libsupc++ > > -L/home/rogelio/gcc-build/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs > > -L/home/rogelio/gcc-build/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs > > -g -O2 -flto=jobserver -frandom-seed=1 -fprofile-use -DIN_GCC > > -fno-exceptions -fno-rtti -W -Wall -Wno-narrowing -Wwrite-strings > > -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long > > -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H > > -static-libstdc++ -static-libgcc -o cc1 c-lang.o c-family/stub-objc.o > > attribs.o c-errors.o c-decl.o c-typeck.o c-convert.o c-aux-info.o > > c-objc-common.o c-parser.o tree-mudflap.o c-family/c-common.o > > c-family/c-cppbuiltin.o c-family/c-dump.o c-family/c-format.o > > c-family/c-gimplify.o c-family/c-lex.o c-family/c-omp.o > > c-family/c-opts.o c-family/c-pch.o c-family/c-ppoutput.o > > c-family/c-pragma.o c-family/c-pretty-print.o c-family/c-semantics.o > > c-family/c-ada-spec.o i386-c.o default-c.o \ > > cc1-checksum.o main.o libbackend.a libcommon-target.a libcommon.a > > ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a libcommon.a > > ../libcpp/libcpp.a ../libiberty/libiberty.a > > ../libdecnumber/libdecnumber.a-lmpc -lmpfr -lgmp -rdynamic -ldl > > -lz > > c-family/c-format.o (symbol from plugin): warning: memset used with > > constant zero length parameter; this could be due to transposed > > parameters > > collect2: error: ld returned 1 exit status > > > > > > Any pointers how to debug this? > > > > I configured with: > > > > ../gcc-4.7.4/configure --prefix= --libexecdir=/lib --enable-shared > > --enable-threads=posix --enable-__cxa_atexit --enable-clocale > > --enable-languages=c,lto --disable-multilib --with-system-zlib > > --enable-lto --with-build-config=bootstrap-lto > > > > then did a profiledbootstrap make > > When using profiledbootstrap you should add --disable-werror to the > configuration flags. Hmm, I think this is actually a linker bug. Could you try gold? See: https://sourceware.org/bugzilla/show_bug.cgi?id=16746 -- Markus
Re: Fwd: Building gcc-4.9 on OpenBSD
On Thu, Sep 18, 2014 at 10:35 PM, Thomas Preud'homme wrote: >> From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of >> Ian Grant >> >> And can anyone tell me what are the 'non-vanilla' sources? > > "Vanilla source" refers to unmodified source (as distributed on gcc.gnu.org > for the case of gcc). This is in contrast to modified source from distribution > for instance that will usually add some patches. Hi Thomas, Thanks. But I asked what the non-vanilla sources were. I know what the vanilla sources are, because I'm using them! I thought you were referring to some particular OpenBSD patches that would make it easier for me to do this. I'm not aware of any: the OpenBSD people have a v. 4.2.1 GCC fork that they use, but it is 4.9 I am interested in building on OpenBSD, to get a 'cross reference' which I hope might tell me something about the file sizes I see, Thanks, Ian > Best regards, > > Thomas > > > >
Dijkstra's Methodology for Secure Systems Development
I hope this will provoke some new ideas about how to develop secure systems software. Thesis: The Software Development Process Itself is THE Major Security Vulnerability in Current Computing and Communications Practices This is because feasibility of the process depends entirely on re-use of concrete implementations of algorithms, and so software developers must routinely download and run code, because it is absolutely necessary if they are to do their work. The quantity of code that they download and run is far, far greater than they could possibly inspect, even cursorily. Therefore software developers are constantly running unknown code. Any such code they run as part of their work typically has both read and write access to all the other code they work on, because they typically use the same machine user account for all their work. On Unix systems, this is practically mandated by the fact that account setups are not easy to duplicate, and switching from one account to another is not easy, because it is almost impossible to transfer the 'desktop' setups and running applications from one user account to another, without stopping and restarting them. Of course, if this switching of running programs from one account to another were made automatic, then there would be no point in switching accounts when working on different projects. The security situation is further aggravated by the fact that software developers have a "trusted status" amongst the computer-using community, on account of their specialist skills. Because of this perception, there is a greater tendency to _actually trust_ the words and deeds of software developers. Thus the general public are on the whole _far less_ likely to question the actions, intentional or unintentional, of software developers. This tendency is inversely proportional to the perceived status of the software developer, which is in turn proportional to the extent to which the results of their work are distributed. So this is contrary (doubly so) to the healthier purely rational attitude, which would be to treat the actions of _all_ software developers with the utmost suspicion, and the better known they are, the more so! Since the products of software developers are frequently duplicated _en masse_ and then widely distributed, the developers own vulnerability is yet further exaggerated when it extends transitively to the consumers of their software. Problem: Clearly then, the fewer software developers there are, the better, and also, the the less those few developers do, the better. But many people seem to _enjoy_ developing software. Should they be deprived of that right? The first question is whether it is really software development itself that they find enjoyable, and not just some particular aspects of it which are not so much evident in any other activity? The fact that software developers often have other interests in common indicates that this is probably not so. The second question is related to the first. We must ask _why_ they enjoy software development. If software development were practised differently, would they still enjoy it? For example, if software developers had to pay constant attention to issues of security, in order to ameliorate the vulnerability we have identified, would they find it equally enjoyable? Every indication is that most would not. Software projects which have high-security criteria are not as popular with developers as others which are typically more relaxed, and where developers perceive they have far greater freedom, and therefore many more opportunities to be creative. This accords with our tentative answer to the first question, because the interests that software developers have most in common seem to do with creative use of imagination in areas where people can exercise intelligence. So if we could only find a way to re-employ all the people who enjoy "coding," in an area where they have far more freedom and opportunity to express creative intelligence, then everyone will be better off, except those people who rely on the products of software developers, because they need software in order to be able to express _their_ creative intelligence! Therefore we need at the same time to find a way to produce software without using human "coders". Solution: It is widely held that "human coders" are absolutely necessary, because machines simply aren't intelligent enough to write programs. This is probably true: machines cannot be programmed to be creative, because creativity is, almost by definition, NOT mechanical. But this is an error, and that it is so is clear as soon as one recalls that the difficulty we identified, that people have with producing _secure_ software, is that there are _fewer_ opportunities to creatively express intelligence: production of secure software requires a formal discipline, and the results must be in some sense more reproducible and predictable than those of imaginative and creative expression of int
Global Value Numbering on SSA representation based on Redundancy Class
Hello All:
Please find the different Global Value numbering techniques on SSA
representation and proposing in GCC Global Value Numbering on SSA
representation based on Redundancy Class. Can this be proposed.
SSA representation with control graph can be formulated with Global Value
Numbering Algorithm. The GVN Algorithm assigns the value numbers for the
expression based on hashing, value partitioning, SCC on SSA Graph and
Dominator. Value partitioning is based on congruent classes and the Dominator
is based on traversing the dominator tree in reverse post order and assign the
values to the expression. The SCC based on SSA graph is based on traversing the
SSA graph in reverse post order and assign the value numbers based on
optimistic and valid table.
Different optimization based on GVN are useful like redundant expression
elimination, redundant load and stores , Common Sub expression elimination,
reassociation and value redundancy.
Global value numbering is proposed on redundancy class assign to expression
based on renaming scheme on SSA representation. The variable renaming scheme is
extended to expressions in the SSA representation. The redundancy class along
with the SSA graph and the SCC representation of the SSA Graph is proposed in
this paper. The redundancy class concept is taken from the Fred Chow paper on
PRE on SSA. Based on the redundancy class new set of nodes like phi are
inserted which takes the operands as redundancy class and this set of phi nodes
are used along with redundancy class number are used using the optimistic table
and the valid table as suggested by Simpson on value numbering on SCC based SSA
Graphs.
This will help to perform the optimization as mentioned above in the SSA
representation.
Value based partitioning:
Value based partitioning assigns the values based on partitoning the congruent
classes. Two expressions are congruent if they have same opcode and each
operand has to be congruent. This is the recursive based definition. Based on
the congruency initial partition is created which keep on growing with
different iterations till the partitions became stable.
For the expressions given below:
A= x - y
B = y - x
C = A + B
For the expressions above the initial partition created with {x}, {y}, { A, B,
C}. Then the algorithm will work as follows. The worklist will be the set of
the congruence class. For each class like {x} is selected. For x the derivation
is A and the position of A is subset of the class {A,B,C} then the new
partition will be created{A}. Similarly the {B} and {C} partition are created
and added to the worklist and the above algorithm continues till the partitions
become stable. So the final partitions will be {x},{y},{A},{B},{C}.
SCC based value numbering on SSA Graph
The SCC(strongly connected component) is found on the SSA graph with cycle. The
Set of nodes in each SCC will be a single node in the cycle. For such strongly
connected component mapped to single nodes, each node will be traversed and the
value numbers are assigned.
For following SSA representation of the control flow graph
i0 = 1
j0 = 1
while(..)
{
i1 = phi(i0, i2)
j1 = phi(j0,j2)
i2 = i1 +1
j2 = j1 +1
}
For the above example the SSA graph will be formed with Strongly connected
component with the cycle and the each node of the SCC will be traversed.
Traversing the SSA graph in reverse post order for variable i the initial value
is 1 which will be added to optimistic table so the lattice initial value is 1.
At the point of i1 = phi(i0,i2) 1 will be added to optimistic table and assign
the value of i1. At the first iteration i2 will be 2 as the initial value of i1
is propagated. In the second iteration the i1 = phi(i0,i2) will be added to the
optimistic table and assign the value i1.
Traversing the SSA graph in reverse post order for variable j the initial value
is 1 and j1 will be 1 at the first iteration. Since the value of i1 is assigned
1 and j is hashed to same value j1 will be equal to i1. At the first iteration
j2 will be 2 and j2 will be i2 as same value is hashed. In the second iteration
the j1 = phi(j0,j2) will become i1 = phi(i0,i2) and this entry is already
mapped to optimistic table. This leads to i is congruent to j . so the same
value is assigned to i and j and the optimization will remove the jth entry and
related phi node for jth entry.
Global Value Numbering based on redundancy class
The redundancy class is formed as given in PRE on SSA by Fred Chow using SSA
variable renaming. The SSA variables used to form the expressions is assigned
the redundancy class similar to renaming scheme of SSA variables.
For the following example:
i0 = 1
j0 = 1
while(..)
{
i1 = phi(i0, i2)
j1 = phi(j0,j2)
i2 = i1 +1
j2 = j1 +1
}
The above SSA program is represented with redundancy class and the new phi node
based on the redundancy class.
The above SSA program is modified as follows
i0 = 1
j0 = 1
while(..)
{
Re: gcc 4.7.4 lto build failure
On Fri, Sep 19, 2014 at 2:03 PM, Markus Trippelsdorf wrote: >> >> When using profiledbootstrap you should add --disable-werror to the >> configuration flags. > > Hmm, I think this is actually a linker bug. Could you try gold? See: > https://sourceware.org/bugzilla/show_bug.cgi?id=16746 > > -- > Markus Hi Its the ld bug. I backported the fix to my binutils (2.21.1)and it seems fine. Im rebuilding my system. Lets see how it goes. Thanks Markus!
Re: [RFC] Add asm constraint modifier to mark strict memory accesses
On Thu, Sep 18, 2014 at 10:42 PM, Yury Gribov wrote:
> On 09/18/2014 09:33 PM, Dmitry Vyukov wrote:
>>
>> What is the number of cases it will fix for kasan?
>
>
> Re-added kernel people again.
>
> AFAIR silly instrumentation that assumed all memory accesses in inline asm
> are must-accesses (instead of may-accesses) resulted in only one false
> positive. We haven't performed an extensive testing though.
>
>> It won't fix the memchr function because the size is indeed not known
>> statically. So it's a bad example.
>
>
> Sure, we will _not_ be able to instrument memchr. But being able to identify
> "safe" inline asms would allow us to instrument those (and my gut feeling is
> that they are a vast majority).
>
>> My impression was that kernel has relatively small amount of assembly,
>
>
> Well,
> $ grep -r '"[=+]\?[moVv<>]" *(' ~/src/linux-stable/ | wc -l
> 1133
>
> And also
> $ grep -r '"[=+]\?[moVv<>]" *(' ~/src/ffmpeg-2.2.2/ | wc -l
> 211
>
>> And the rest is just not interesting enough.
>
> Now that may be the case. But how do we know without trying?
Well, we can look at some instances at least before committing new code to gcc.
Here are results of your grep with removed "prefetch" and removed
archs except x86:
2 ./arch/x86/boot/bitops.h:
12 ./arch/x86/boot/boot.h:
1 ./arch/x86/boot/compressed/eboot.c:
1 ./arch/x86/boot/cpuflags.c:
3 ./arch/x86/boot/pm.c:
2 ./arch/x86/include/asm/apic.h:
8 ./arch/x86/include/asm/atomic.h:
8 ./arch/x86/include/asm/atomic64_64.h:
1 ./arch/x86/include/asm/bitops.h:
2 ./arch/x86/include/asm/bitops.h:#define
13 ./arch/x86/include/asm/cmpxchg.h:
3 ./arch/x86/include/asm/cmpxchg_32.h:
4 ./arch/x86/include/asm/desc.h:
3 ./arch/x86/include/asm/desc.h:#define
1 ./arch/x86/include/asm/edac.h:
20 ./arch/x86/include/asm/fpu-internal.h:
2 ./arch/x86/include/asm/futex.h:
1 ./arch/x86/include/asm/io.h:"m"
1 ./arch/x86/include/asm/io.h::"m"
26 ./arch/x86/include/asm/kexec.h:
9 ./arch/x86/include/asm/linkage.h:
5 ./arch/x86/include/asm/local.h:
2 ./arch/x86/include/asm/mutex_64.h:
38 ./arch/x86/include/asm/percpu.h:
8 ./arch/x86/include/asm/percpu.h:#define
1 ./arch/x86/include/asm/perf_event.h:
2 ./arch/x86/include/asm/rmwcc.h:
8 ./arch/x86/include/asm/rwsem.h:
3 ./arch/x86/include/asm/signal.h:
11 ./arch/x86/include/asm/special_insns.h:
2 ./arch/x86/include/asm/spinlock.h:
7 ./arch/x86/include/asm/switch_to.h:
6 ./arch/x86/include/asm/sync_bitops.h:
8 ./arch/x86/include/asm/uaccess.h:
1 ./arch/x86/include/asm/word-at-a-time.h:
18 ./arch/x86/include/asm/xor_avx.h:
3 ./arch/x86/include/asm/xsave.h:
2 ./arch/x86/kernel/cpu/bugs.c:
2 ./arch/x86/kernel/i387.c:
2 ./arch/x86/kernel/machine_kexec_64.c:
1 ./arch/x86/kernel/reboot.c:
1 ./arch/x86/kernel/vm86_32.c:
50 ./arch/x86/kvm/emulate.c:
3 ./arch/x86/kvm/vmx.c:
1 ./arch/x86/lib/csum-partial_64.c:
6 ./arch/x86/math-emu/fpu_trig.c:
1 ./arch/x86/mm/init_32.c:
2 ./arch/x86/pci/pcbios.c:
5 ./arch/x86/power/cpu.c:
1 ./drivers/char/hw_random/via-rng.c:
8 ./drivers/char/mwave/smapi.c:
2 ./drivers/hv/hv.c:
1 ./drivers/input/misc/wistron_btns.c:
1 ./drivers/lguest/x86/core.c:
1 ./drivers/pci/hotplug/cpqphp_nvram.c:
2 ./drivers/s390/block/dasd_diag.c:
8 ./drivers/s390/cio/ioasm.h:
2 ./drivers/s390/crypto/ap_bus.c:
2 ./drivers/scsi/ultrastor.c:
1 ./drivers/video/fbdev/platinumfb.c:
28 ./lib/raid6/avx2.c:
14 ./lib/raid6/mmx.c:
47 ./lib/raid6/recov_avx2.c:
49 ./lib/raid6/recov_ssse3.c:
15 ./lib/raid6/sse1.c:
28 ./lib/raid6/sse2.c:
1 ./lib/sha1.c:
2 ./net/iucv/iucv.c:
It seems that it is mostly synchronization primitives and raid6
driver. Boot and s390 drivers are probably not very interesting.
Synchronization primitives are definitely interesting for asan
(because of racy use-after-free's). The rest looks very mildly
interesting.
I do not see a very strong need for doing this for asan. There can be
other reasons, of course.
Re: Fwd: Building gcc-4.9 on OpenBSD
On 19 September 2014 16:21, Ian Grant wrote: > Thanks. But I asked what the non-vanilla sources were. I know what > the vanilla sources are, because I'm using them! The non-vanilla sources are everything else. That should be pretty obvious. Are you just intentionally trying to waste everyone's time?
Re: Fwd: Building gcc-4.9 on OpenBSD
On 20 September 2014 00:01, Jonathan Wakely wrote: > On 19 September 2014 16:21, Ian Grant wrote: >> Thanks. But I asked what the non-vanilla sources were. I know what >> the vanilla sources are, because I'm using them! > > The non-vanilla sources are everything else. That should be pretty obvious. Or as it says in the text you quoted: "This is in contrast to modified source from distribution for instance that will usually add some patches" Vanilla source == unmodified source Non-vanilla source == modified source Any modified source. If OpenBSD modifies the source, it's non-vanilla. If Debian modifies the source, it's non-vanilla. Personally I don't like the terms vanilla and non-vanilla but I think their meanings are fairly clear.
Re: Fwd: Building gcc-4.9 on OpenBSD
None of this is useful to me. I'm trying to make a case for why people should have confidence in GNU software. You are NOT helping me in that, I assure you, We need to publish some simple steps that people can take to reassure themselves that the 64MB binaries that GCC 4.9 produces on Linux systems are normal and nothing to worry about, Why is that so hard? Where are the GCC experts on this list. Where are the people that actually care about the reputation of the FSF? Ian On Fri, Sep 19, 2014 at 7:15 PM, Jonathan Wakely wrote: > On 20 September 2014 00:01, Jonathan Wakely wrote: >> On 19 September 2014 16:21, Ian Grant wrote: >>> Thanks. But I asked what the non-vanilla sources were. I know what >>> the vanilla sources are, because I'm using them! >> >> The non-vanilla sources are everything else. That should be pretty obvious. > > Or as it says in the text you quoted: > > "This is in contrast to modified source from distribution for instance > that will usually add some patches" > > Vanilla source == unmodified source > > Non-vanilla source == modified source > > Any modified source. If OpenBSD modifies the source, it's non-vanilla. > If Debian modifies the source, it's non-vanilla. > > Personally I don't like the terms vanilla and non-vanilla but I think > their meanings are fairly clear.
Re: Fwd: Building gcc-4.9 on OpenBSD
On Fri, Sep 19, 2014 at 4:52 PM, Ian Grant wrote: > None of this is useful to me. I'm trying to make a case for why people > should have confidence in GNU software. You are NOT helping me in > that, I assure you, Again, try stripping out debugging information and look at the numbers again. Or better yet use size printing out all of the sections rather than the default output which combines some section and does not show the debugging information, >From a different email: > > BTW, if "size" is reporting much smaller size than the executable > > file itself and that motivates this concern, most of the difference > > is likely to be debug info, which is bigger since gcc switched to > > C++. Might want to try "strip". > Great. As I said, the exercise we are here engaged in is to convince > as many people as possible that GCC does NOT suffer from this problem > on any OS, either OS, Windows, OpenBSD, FreeBSD, Solaris, or Linux on > any arch., including IBM System z. Then don't use size with the default options but rather with the sysv style output (-A) and look at all of the sections. > > We need to publish some simple steps that people can take to reassure > themselves that the 64MB binaries that GCC 4.9 produces on Linux > systems are normal and nothing to worry about, Debugging information is increasing a lot. Writing GCC in C++ has caused this issue because there is no removing of debugging information yet in dwarf2/3/4, I think there is plans for it but I can't remember if it made it into dwarf5 or not. Thanks, Andrew Pinski > > Why is that so hard? Where are the GCC experts on this list. Where are > the people that actually care about the reputation of the FSF? > > Ian > > > On Fri, Sep 19, 2014 at 7:15 PM, Jonathan Wakely > wrote: >> On 20 September 2014 00:01, Jonathan Wakely wrote: >>> On 19 September 2014 16:21, Ian Grant wrote: Thanks. But I asked what the non-vanilla sources were. I know what the vanilla sources are, because I'm using them! >>> >>> The non-vanilla sources are everything else. That should be pretty obvious. >> >> Or as it says in the text you quoted: >> >> "This is in contrast to modified source from distribution for instance >> that will usually add some patches" >> >> Vanilla source == unmodified source >> >> Non-vanilla source == modified source >> >> Any modified source. If OpenBSD modifies the source, it's non-vanilla. >> If Debian modifies the source, it's non-vanilla. >> >> Personally I don't like the terms vanilla and non-vanilla but I think >> their meanings are fairly clear.
Re: Fwd: Building gcc-4.9 on OpenBSD
Thanks Andrew! You get first prize for most informative intelligent answer so far! Careful, you might get second prize too :-) The problem is that we need to find a way to tell people _what_ is in that "dwarf" code. Open BSD's gcc ignores it, prints a warning, and goes about its business. That's probably why OpenBSD gcc 4.9 binaries are 17MB against the 64MB compiled by gcc 4.9. But that is a really fucking big dwarf they're stuffing in threre. What is the data, really? We can't just say "it's dwarf" because that doesn't really mean a whole lot, does it? Thanks again for your helpful response. This is progress. Ian On Fri, Sep 19, 2014 at 8:04 PM, Andrew Pinski wrote: > On Fri, Sep 19, 2014 at 4:52 PM, Ian Grant > wrote: >> None of this is useful to me. I'm trying to make a case for why people >> should have confidence in GNU software. You are NOT helping me in >> that, I assure you, > > Again, try stripping out debugging information and look at the numbers > again. Or better yet use size printing out all of the sections rather > than the default output which combines some section and does not show > the debugging information, > > From a different email: >> > BTW, if "size" is reporting much smaller size than the executable >> > file itself and that motivates this concern, most of the difference >> > is likely to be debug info, which is bigger since gcc switched to >> > C++. Might want to try "strip". > >> Great. As I said, the exercise we are here engaged in is to convince >> as many people as possible that GCC does NOT suffer from this problem >> on any OS, either OS, Windows, OpenBSD, FreeBSD, Solaris, or Linux on >> any arch., including IBM System z. > > Then don't use size with the default options but rather with the sysv > style output (-A) and look at all of the sections. > > >> >> We need to publish some simple steps that people can take to reassure >> themselves that the 64MB binaries that GCC 4.9 produces on Linux >> systems are normal and nothing to worry about, > > Debugging information is increasing a lot. Writing GCC in C++ has > caused this issue because there is no removing of debugging > information yet in dwarf2/3/4, I think there is plans for it but I > can't remember if it made it into dwarf5 or not. > > Thanks, > Andrew Pinski > >> >> Why is that so hard? Where are the GCC experts on this list. Where are >> the people that actually care about the reputation of the FSF? >> >> Ian >> >> >> On Fri, Sep 19, 2014 at 7:15 PM, Jonathan Wakely >> wrote: >>> On 20 September 2014 00:01, Jonathan Wakely wrote: On 19 September 2014 16:21, Ian Grant wrote: > Thanks. But I asked what the non-vanilla sources were. I know what > the vanilla sources are, because I'm using them! The non-vanilla sources are everything else. That should be pretty obvious. >>> >>> Or as it says in the text you quoted: >>> >>> "This is in contrast to modified source from distribution for instance >>> that will usually add some patches" >>> >>> Vanilla source == unmodified source >>> >>> Non-vanilla source == modified source >>> >>> Any modified source. If OpenBSD modifies the source, it's non-vanilla. >>> If Debian modifies the source, it's non-vanilla. >>> >>> Personally I don't like the terms vanilla and non-vanilla but I think >>> their meanings are fairly clear.
