Re: Builtin expansion versus headers optimization: Reductions
05.06.2015 1:34, Andi Kleen writes:
> Ondřej Bílka writes:
>
>> As I commented on libc-alpha list that for string functions a header
>> expansion is better than builtins from maintainance perspective and also
>> that a header is lot easier to write and review than doing that in gcc
>> Jeff said that it belongs to gcc. When I asked about benefits he
>> couldn't say any so I ask again where are benefits of that?
>
> It definitely has disadvantages in headers. Just today I was prevented
> from setting a conditional break point with strcmp in gdb because
> it expanded to a macro including __extension__ which gdb doesn't
> understand.
>
There are other issues with macros in glibc headers (well, not as
significant as performance-related concerns, but never the less).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24016#c3
> #include
> int foo(void *x) {
> return strcmp(x + 1, "test");
> }
>
> does not cause warnings when compiled with -Wpointer-arith -O1
> (glibc v. 2.17). It can be reduced to:
>
> int foo(void *x) {
> return __extension__({ __builtin_strcmp(x + 1, "test"); });
> }
In this case __extension__ inhibits -Wpointer-arith, because void*
arithmetics is a valid GNU extension, but the user does not even know
that he is using it.
I came across this issue while working with some legacy code and was
rather surprised, that cppcheck (it did not perform the expansion) was
able to find this problem, but GCC was not.
Original case in the bug (Missing warning for unspecified evaluation order):
> Take the following example:
> void f(int *a)
> {
> *a++ = __extension__ ({ int bb = *a; bb; });
> }
> ---
> We don't warn for the operation on a.
[snip]
> If I remove the declation of bb, it works,
[snip]
> This was reduced from the following code with glibc and -O1:
> #include
> void strtolower(char *data) { while (*data != '\0') *data++ = tolower(*data);
> }
Though in this case it seems to be a problem with GCC rather than
headers, absence of macros and block expressions would allow to give a
warning already in current version.
Another issue: strncmp is a macro and it requires exactly 3 arguments.
Arguments are expanded after substitution, So this code does not work
(with -O1+):
/* string literal with length */
#define STRSZ(x) x, (sizeof(x) - 1)
...
bool starts_with_test(const char *s)
{
return strncmp(s, STRSZ("test")) == 0;
}
One has to write something like this:
#define strncmp_const(s1, s2c) strncmp(s1, s2c, sizeof(s2c) - 1)
> The compiler has much more information than the headers.
> - It can do alias analysis, so to avoid needing to handle overlap
> and similar.
> - It can (sometimes) determine alignment, which is important
> information for tuning.
> - With profile feedback it can use value histograms to determine the
> best code.
Value range information is also passed to, for example, memcpy expander.
Even if exact length of data being copied is not known at compile time,
the known range can help the compiler to select a subset of available
algorithms a choose one of them at run time without using several
branches and a huge jumptable (which is unavoidable in library code,
because it has to deal with general case).
BUT comparison functions (like str[n]cmp, memcmp) expand to something
like "repz cmpsb", which is definitely suboptimal. IMHO, a quick and
dirty (but working) solution would be to use library call instead of
relying on HAVE_cmpstr[n]si, (except short strings). A better solution
would be to implement something like movmem pattern (which is aware of
value ranges, alignment, etc.) but for comparison patterns. I could try
to write at least some prototype for this (if no one else has already
started working on it).
--
Regards,
Mikhail Maltsev
Re: Builtin expansion versus headers optimization: Reductions
05.06.2015 13:02, Ondřej Bílka writes:
> Also as I mentioned bugs before gcc now doesn't handle alignment well so
> it doesn't optimize following to zero for aligned code.
>
> align = ((uintptr_t) x) % 16;
>
That is because GCC is conservative and supports some non-ABI-compliant
memory allocators which only guarantee 8-byte alignment, but
char *bar()
{
char *data = __builtin_malloc(64);
return data + ((unsigned long)data) % 8;
}
does get optimized to
bar:
.LFB1:
.cfi_startproc
movl$64, %edi
jmp malloc
.cfi_endproc
--
Regards,
Mikhail Maltsev
gcc@gcc.gnu.org
On 07.06.2015 0:15, steven...@gmail.com wrote: > Dear GCC developers, > > I have successfully compiled & installed GCC 4.9.2. Could you comment on the > results of 'make check' (see below). Here is the relevant information: > You can verify it against published test results: https://www.gnu.org/software/gcc/gcc-4.9/buildstat.html > === gfortran tests === > > > Running target unix > FAIL: gfortran.dg/guality/pr41558.f90 -O2 line 7 s == 'foo' > FAIL: gfortran.dg/guality/pr41558.f90 -O3 -fomit-frame-pointer line 7 s == > 'foo' > FAIL: gfortran.dg/guality/pr41558.f90 -O3 -fomit-frame-pointer > -funroll-loops line 7 s == 'foo' > FAIL: gfortran.dg/guality/pr41558.f90 -O3 -fomit-frame-pointer > -funroll-all-loops -finline-functions line 7 s == 'foo' > FAIL: gfortran.dg/guality/pr41558.f90 -O3 -g line 7 s == 'foo' > FAIL: gfortran.dg/guality/pr41558.f90 -Os line 7 s == 'foo' > guality testsuite checks generated debug information. It's a functional test, i.e. it performs real GDB invocation, so the result might also depend on your version of GDB, it's settings, etc. There are similar issues on CentOS 6 in this test report https://gcc.gnu.org/ml/gcc-testresults/2015-03/msg03335.html (though it's i686). BTW, this failure also reproduces for me on current trunk. -- Regards, Mikhail Maltsev
Re: parallel make check: duplicated test results
On 24.06.2015 13:41, Manuel López-Ibáñez wrote:
> Is nobody seeing this? Is it a known problem with parallel make check?
> If so, can we work-around it in compare_tests?
>
> Cheers,
>
> Manuel.
>
Actually I don't get such problem, but I run the testsuite in a slightly
different way, so you might want to try it in order to see, if that
works for you:
#!/bin/bash
# (... snip ...)
# Check multilib configuration
if "${BUILD_DIR}/gcc/xgcc" --print-multi-lib | fgrep -q 'm32'; then
TARGET_BOARD_PARAM='unix\{-m32,\}'
else
TARGET_BOARD_PARAM='unix'
fi
rm -rf "${TEST_DIR}"
mkdir -p "${TEST_DIR}"
cd "${BUILD_DIR}"
make -k -j${NUM_JOBS} check
RUNTESTFLAGS="--target_board=${TARGET_BOARD_PARAM}" \
> >(tee "${TEST_DIR}/test.log") 2> >(tee
"${TEST_DIR}/test_err.log"
>&2) || true
"${SRC_DIR}/contrib/test_summary" -t | tail -n+2 | head -n-3 >
"${TEST_DIR}/test_summary.log"
"${SRC_DIR}/contrib/testsuite-management/validate_failures.py"
"--build_dir=${BUILD_DIR}" --produce_manifest
--manifest="${TEST_DIR}/manifest.xfail"
for FNAME in "${TEST_DIR}/test_summary.log" "${TEST_DIR}/manifest.xfail"; do
if [ -f "${FNAME}" ]; then
sed -i'' -e 's/==[0-9]\+==/==[PID]==/g' "${FNAME}"
fi
done
${SRC_DIR} is the directory where GCC repository is checked out.
${BUILD_DIR} is build root, and ${TEST_DIR} is the destination for reports.
Now, the two differences: I don't have a slash in RUNTESTFLAGS (and I
probably even recall that I used to have a slash but removed it for some
reason). Second, I don't use compare_tests, but instead produce test
summaries and manifests and then use diff.
Notice that there is a couple of other nice tricks here:
1. The two "tee" commands allow to save separate stdout and stderr logs
(the build log is also processed in a similar manner) and at the same
time copy them to stdout (in my case - to Jenkins console output).
2. test_summary is convenient because it groups the list of failures by
component and architecture. But is also contains some statistics like
the total number of tests and current date (which will differ from build
to build). In contrast, manifest contains only the list of failures,
i.e. it is more diff-friendly.
3. Address sanitizer prints process ID in failure message. I replace it
by "[PID]", so it does not change across builds.
By the way, what is the policy of test results mailing list? I actually
run nightly builds of GCC trunk and could post them if that makes sense.
(though it's plain old x86_64-unknown-linux-gnu multilib; I build and
test C, C++, LTO, Fortran, Objective C and Go).
--
Regards,
Mikhail Maltsev
Re: C++ coding style inconsistencies
On 06/25/2015 09:28 PM, Richard Sandiford wrote:
> Sorry in advance for inviting a bikeshed discussion, but while making
> the hashing changes that I just committed, I noticed that the C++ification
> has been done in a variety of different styles. I ended up having to follow
> the "do what the surrounding code does" principle that some code bases have,
> but to me that's always seemed like an admission of failure. One of the
> strengths of the GCC code base was always that it was written in a very
> consistent style.
Perhaps one disappointing exception is mixed space/tabs indentation. It
is often inconsistent (i.e. some parts use space-only indentation).
That's rather annoying because changes in such line trigger warnings in
the checker script. I hope that I'll find some free time to address this
problem (I mean, I'll write a script which will fix indentation in the
GCC source tree, but will only change the lines affected by a given
patch. So that we will have not just check_GNU_style, but also a kind of
fix_GNU_style :) ).
Of course the "ideal" solution would be to rewrite the whole repository
(will full history), but that would break many things like MD5 sums of
released versions and commit hashes in GIT mirror :(.
> (2) Is there supposed to be a space before a template parameter list?
> I.e. is it:
>
>foo
>
> or:
>
>foo
>
> ? Both are widely used.
There is a wiki page about coding conventions
https://gcc.gnu.org/wiki/CppConventions and it mentions that the latter
form should be used, but for some reason that rule did not get into
official guide.
> If this message does generate any discussion, I'm happy to write up
> the result in the coding conventions and try to make the code base
> consistent with it.
My personal wishlist w.r.t. clarifications in coding conventions. I
would be glad if someone explained this at least briefly, I could then
document it and submit a patch for web site:
1. GCC has some common naming conventions. For example there are macros
and functions ending with "_P" (or "_p"), they check for some property
of their arguments (and my guess is that "p" stands for "predicate", but
I still don't know for sure). There is also an "_r" suffix, which is
used in callbacks for various traversals (reentrant? recursive?),
foo/foo_1 pairs (wrappermain logic?). It would be nice to know the
correct and intended use of such suffixes/prefixes/etc.
2. Is this C legacy or a convention:
typedef struct some_name
{
...
} some_name_t;
3. Provided that we have a definition of "struct other_name", which is
correct: "void foo (struct other_name *)" or "void foo (other_name *)"?
4. "int" is the universal type for induction variables and lots of other
stuff in GCC. Isn't it better to use "unsigned" where semantics does not
imply negative values?
5. In general: which is better: to support consistency with surrounding
code or to use the new conventions? Particularly, the rule about
declaring variables at the place of first use (in a function where all
other variables are declared in the beginning)?
P.S. Sorry in advance for continuing a bikeshed discussion :).
--
Regards,
Mikhail Maltsev
Re: New build warning: implicit declaration of function ‘asprintf’ when building lto-plugin.o
On 29.06.2015 14:24, Uros Bizjak wrote:
> Hello!
>
> Recent commit introduced following build warning:
>
> /home/uros/gcc-svn/trunk/lto-plugin/lto-plugin.c: In function
> ‘claim_file_handler’:
> /home/uros/gcc-svn/trunk/lto-plugin/lto-plugin.c:930:16: warning:
> implicit declaration of function ‘asprintf’
> [-Wimplicit-function-declaration]
> t = hi ? asprintf (&objname, "%s@0x%x%08x", file->name, lo, hi)
Are you sure that it is recent? It started appearing in my builds since
r223590 (about a month ago), the previous build was r223502 (it did not
contain this warning). Also, there is another warning in libiberty
(started in the same commit):
/home/jenkins/workspace/build-gcc-trunk/src/libiberty/getruntime.c: In
function 'get_run_time':
/home/jenkins/workspace/build-gcc-trunk/src/libiberty/getruntime.c:98:14:
warning:
enum conversion when passing argument 1 of 'getrusage' is invalid in C++
[-Wc++-compat]
getrusage (0, &rusage);
^
In file included from
/home/jenkins/workspace/build-gcc-trunk/src/libiberty/getruntime.c:47:0:
/usr/include/x86_64-linux-gnu/sys/resource.h:88:12: note: expected
'__rusage_who_t {aka enum __rusage_who}' but argument is of type 'int'
extern int getrusage (__rusage_who_t __who, struct rusage *__usage)
__THROW;
^
/home/jenkins/workspace/build-gcc-trunk/src/lto-plugin/lto-plugin.c: In
function 'claim_file_handler':
/home/jenkins/workspace/build-gcc-trunk/src/lto-plugin/lto-plugin.c:930:16:
warning: implicit declaration of function 'asprintf'
[-Wimplicit-function-declaration]
t = hi ? asprintf (&objname, "%s@0x%x%08x", file->name, lo, hi)
This change seems somewhat related:
https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=223589
--
Regards,
Mikhail Maltsev
times(2) used in timevars.c introduces significant measurement error
Hi, all. Recently I found out that internal GCC timing measurement is rather expensive. On my desktop (x86_64-linux, Debian 8) GCC uses times(2) to query performance information (note that this function is considered the default and used whenever available) and it introduces up to 8% change in wallclock run time. I compared two invocations of cc1plus: with -ftime-report switch and without it (both use -quiet): TraMP3d v.4 (-fpermissive -O3) normal run: 19.18 user0.18 system0:19.34 wall -ftime-report:19.59 user1.58 system0:21.15 wall As you see, the difference is rather significant. I would say that it makes the "system time" counter useless. What is even worse, is that this overhead is spread non-uniformly across the code. To get some estimate I replaced current time measurement code with rdtsc instruction (affinity was set using taskset; CPU clock rate was hard-coded). Some results: Using times(2): phase setup : 0.01 ( 0%) wall phase parsing : 1.33 ( 6%) wall phase lang. deferred: 1.65 ( 8%) wall phase opt and generate : 18.14 (86%) wall |name lookup: 0.27 ( 1%) wall |overload resolution: 0.83 ( 4%) wall garbage collection : 0.71 ( 3%) wall dump files : 0.09 ( 0%) wall ... 19.59 user 1.58 system 0:21.15 wall Using rdtsc: phase setup : 0.00 ( 0%) wall phase parsing : 0.94 ( 5%) wall phase lang. deferred: 1.47 ( 7%) wall phase opt and generate : 17.24 (88%) wall |name lookup: 0.18 ( 1%) wall |overload resolution: 0.73 ( 4%) wall garbage collection : 0.73 ( 4%) wall dump files : 0.04 ( 0%) wall ... 19.46 user 0.22 system 0:19.68 wall For example, we can see that GC time is not affected, for "opt and generate" the difference is 5.2% and for parsing it is 41%! The majority of calls comes from the frontend: C++ FE tries to measure time spent in rather frequently used routines like overload resolution and template instantation. The lexer calls timer::push and timer::pop once per token. More detailed profiling results: https://docs.google.com/spreadsheets/d/1icH6KZo88FvXkOMW2stP7qujPLqHDOeC0WBCJ_92DJU/edit?usp=sharing Some ideas about fixing this: 1. Do not use times for some cases. That is, add a second kind of timers which do not measure user/system time separately but are relatively cheap. Use clock_gettime(CLOCK_MONOTONIC, ...) for these timers, if available (on modern Linux'es it is implemented as a VDSO, i.e., does not require syscall, at least for x86_64). This does not solve the problem completely (I tried to replace times with clock_gettime but it's still ~0.5 seconds slower than normal run). Using rdtsc is, IMHO, not an option (performance is OK, but it's too hard to make it portable and reliable). 2. Reduce the total number of calls somehow (figure out which are not really needed). During tramp3d compilation, get_time is called 13172693 times. Thoughts? -- Regards, Mikhail Maltsev
Re: Moving to git
On 08/20/2015 11:09 PM, Jason Merrill wrote: > > Absolutely, a non-fast-forward push is anathema for anything other people > might > be working on. The git repository already prohibits this; people that want to > push-rebase-push their own branches need to delete the branch before pushing > again. > > There are many opinions about best practices, but I don't think any of them > are > enough better than what we already do to justify a change. Regardless of what the non-fast-forward-push policy will be (please don't get me wrong - I'm not trying to meddle into development of policies), why is deleting and pushing a branch again better than pushing with force? AFAIK, git tracks remote branches just by their names, so, for example if user A checked out user B's branch, and B later deleted it and pushed again after, perhaps, rebasing locally, then user A will get a conflict, if he tries to pull (same result as with "git push -f"). -- Regards, Mikhail Maltsev
Re: Acceptance criteria for the git conversion
On 09/01/2015 01:54 PM, Eric S. Raymond wrote: > With the machinery for the git conversion now in reasonable shape, it's > time to ask GCC's developers in general: what do you want this > conversion to accomplish? There was some discussion concerning file renaming: https://gcc.gnu.org/ml/gcc/2015-04/msg00175.html I think using different extensions for C and C++ code is a good thing (because having C++ code in ".c" files is confusing both for humans and for tools), and probably moving to git is a good occasion for such rename. I could take care of performing this change (i.e. make a list of C++ files with .c extension, fix build scripts, run some tests), if it is acceptable. -- Regards, Mikhail Maltsev
Re: Acceptance criteria for the git conversion
On 09/01/2015 08:11 PM, Joseph Myers wrote: > On Tue, 1 Sep 2015, Richard Earnshaw wrote: > >> Renaming the files during the conversion is clearly *not* the right >> thing to do: it would break all builds of old code. > > Indeed. Ideally the tree objects in the git conversion should have > exactly the same contents as SVN commits, and so be shared with the > git-svn history to reduce the eventual repository size (except where there > are defects in the git-svn history, or the git conversion fixes up cvs2svn > artifacts and so some old revisions end up more accurately reflecting old > history than the SVN repository does). Actually, I did not propose to alter the repository history. I just meant to say that if .c -> .cc renaming is still planned, it could be done right after conversion, as a normal commit, or, perhaps series of commits on trunk and active development (feature) branches. -- Regards, Mikhail Maltsev
Re: Help with gcc-plugin (Traverse all loops inside function)
On 09/15/2015 03:38 PM, Aditya K wrote: > I started with one of the test cases in the plugin testsuite "def_plugin.c". > Pasted the code for convenience. > I want to traverse all the loops in a function. > > Maybe use, loops_for_fn (DECL_STRUCT_FUNCTION (fndef)), but this does not > seem to work. > > > /* Callback function to invoke after GCC finishes a function definition. */ I guess, loop structure is initialized much later within the optimization pipeline. I.e., PLUGIN_FINISH_PARSE_FUNCTION is invoked before all optimizers, and (natural) loops are discovered by the "loopinit" pass. Perhaps, you could try registering a pass using register_callback (..., PLUGIN_PASS_MANAGER_SETUP, ...) and make it run within pass_tree_loop (see gcc/passes.def for details). You should also specify 'PROP_loops' in 'properties_required' of your 'pass_data' structure. Then 'loops_for_fn' should work. 'selfassign.c' is a good example of a plugin which creates an optimization pass (and 'dumb_plugin.c' is a good minimal example). -- Regards, Mikhail Maltsev
Re: Understand GCC test process
On 10/07/2015 09:43 PM, Sabrina Souto wrote:
> I'm understanding that the major of code that I instrumented (in the
> first level of ..gcc-version-x.x/gcc/ and the dirs related to C/C++)
> is part of the 'gcc' driver. If so, this explains the great amount of
> common function calls across the tests.
Which binaries did you instrument? If you refer to xgcc and xg++ - they are
indeed drivers (they will be named gcc and g++ resp. when installed). But most
of code in the 'gcc' directory is related to the compiler proper (cc1 for C,
cc1plus for C++).
>
>
>>> Do you mean, for example, that the compiler will always build the AST,
>>> translate to intermediary code representations, etc., regardless of
>>> the compilation option... and it corresponds to a lot of common code
>>> across all tests?
>>
Yes, for the majority of tests (with some exceptions like the preprocessor tests
mentioned by Jonathan). Thus, nonuniform coverage is unsurprising. See also
https://gcc.gnu.org/ml/gcc-patches/2015-06/msg00765.html - a proposal to add
unit tests to GCC.
> I ran
> make RUNTESTFLAGS='dg.exp=c90-float-1.c -v -v' check-gcc
> And I saw in the log:
> ...
> doing compile
> Invoking the compiler as
> ../gcc-r227092/objdir/gcc/testsuite/g++/../../xg++ -B/...
> ...
>
> The test ../testsuite/gcc.dg/c90-float-1.c contains the action: /* {
> dg-do preprocess } */
> So, why "doing compile" was in the execution log? I thought that the
> compiler would not be called in this case.
> Am I running the test in a wrong way?
Probably the message is wrong. Nevertheless, IIRC, the preprocessor is also run
as xg++. xg++ will invoke the compiler proper (cc1plus), which will perform
preprocessing.
> Where can I find all the code that implements the compiler and
> preprocessor? In libcpp, libcc1, boehm-gc ?
Mostly in gcc and libcpp directories. Code from include and libiberty is also
used.
> Please, help me.
Consider looking at https://gcc.gnu.org/onlinedocs/gccint/Source-Tree.html and
gcc/Makefile.in in more detail.
Finally, note that GCC has some means of test coverage analysis: you can
configure/build it with "--disable-bootstrap --enable-coverage", run the tests
and then use gcov.
--
Regards,
Mikhail Maltsev
Understanding GCC test results published by SUSE
Hi! SUSE performs periodic testing of GCC and publishes the results on their site: http://gcc.opensuse.org/ (many thanks for this great job!). I'm trying to perform some analysis of these results and asking for help with understanding them. I would be grateful, if you answer some of my questions: 1. For SPEC benchmarks there are update logs (e.g. http://gcc.opensuse.org/SPEC/CFP/sb-frescobaldi.suse.de-head-64/201508061619.fp/update-201508061619.log) which allow to see which revision of GCC was used in the test. For other benchmarks there is only date (http://gcc.opensuse.org/c++bench/boost/boost-summary.txt). Is it possible to extract the revision number? Or, is it the same for all tests run on a specific test server during one day? 2. What does the number after date mean (i.e. what is "34228681" in "151011.34228681")? 3. There was (is?) a bug which caused the string "FILESIZE:" to be output into test results. (see, for example, http://gcc.opensuse.org/c++bench/boost/boost-summary.txt). Is it fixed now? 4. What are the columns for Tramp3D benchmark? (the comment in the beginning is somewhat obsolete: lots of new columns were added). 5. Likewise, for libstdc++ benchmark. -- Regards, Mikhail Maltsev
Re: http access to ftp://gcc.gnu.org
On 10/23/2015 02:39 AM, Frank Ch. Eigler wrote: > Hi - > > At the request of tbsaunders, we're experimenting with > provinding http[s] access to parts of the ftp://gcc.gnu.org/ > contents. Please see http://gcc.gnu.org/ftp/ . > > - FChE > Got 403: $ nslookup gcc.gnu.org <...> Non-authoritative answer: Name: gcc.gnu.org Address: 209.132.180.131 $ http http://gcc.gnu.org/ftp/ HTTP/1.1 403 Forbidden Connection: close Content-Encoding: gzip Content-Length: 224 Content-Type: text/html; charset=iso-8859-1 Date: Fri, 23 Oct 2015 15:39:18 GMT Server: Apache Vary: Accept-Encoding 403 Forbidden Forbidden You don't have permission to access /ftp/ on this server. Apache Server at gcc.gnu.org Port 80 Just in case, my IP is 185.6.245.180. -- Regards, Mikhail Maltsev
GCC XML diagnostics
Hi all! I'm pleased to say that two students of Lomonosov Moscow State University, Yuri Kemaev and Pavel Adamenko decided to work on a project related to GCC and hopefully will become new contributors. I'll be assisting them with this project. We have chosen to work on PR19165: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19165 (machine-readable diagnostics output). Could any of maintainers please confirm that it is still a desired feature (the PR is marked as NEW, but just in case...)? We are aware of GCC development schedule and thus aiming at GCC 7. Also we have seen David's series of patches related to diagnostics and will probably work on top of them, i.e. with those patches applied (because most of them are already approved). I created several test cases which exhibit various entities (such as locations in files, includes, macro expansions, notes, etc.), which can occur in GCC diagnostics (which are worth keeping in mind when designing the XML diagnostics format): https://github.com/miyuki-chan/gcc-xml-diagn/tree/master/examples Any advices about other test cases which are worth taking into account and the format itself? -- Regards, Mikhail Maltsev
Re: Hi! New to GCC
On 01/09/2016 06:10 PM, Prasad Ghangal wrote: > Hi, > I am Prasad Ghangal, a BTech student and I really want to contribute > in gcc, but I am new to open source community. > I can code in C,C++ and know little python. I have successfully built > gcc on my local machine as instructed. > > So can someone please help me getting started? > Hi! Here is a list of first steps to start with: https://gcc.gnu.org/wiki/GettingStarted Also, you might want to take a look at these video lectures: https://www.cse.iitb.ac.in/grc/index.php?page=videos, they are slightly outdated (~2012), but still give a good overview of GCC internals. There is a list of bugs and enhancement requests, which were marked by GCC developers as "easy hacks", i.e. something that should be easy enough for new contributors to start with: https://gcc.gnu.org/bugzilla/buglist.cgi?keywords=easyhack&list_id=135581&resolution=--- -- Regards, Mikhail Maltsev
Re: Hi! New to GCC
On 01/21/2016 09:06 AM, Prasad Ghangal wrote: > Thanks Mikhail, > As you have suggested I have built gcc on my laptop and gone through > all the videos. The videos were very informative. > Can I use any IDE for browsing gcc source code ? Probably. Although IDE-s might have some performance and memory usage problems, because GCC is a fairly large project. I used Netbeans some time ago and it worked OK in most cases. Same caveats are: 1. Almost all source code is written in C++, even though files have extension '.c'. You should configure your IDE appropriately. 2. During build GCC generates some source code in the build directory (like gcc/insn-*.c files), so it is probably a good idea to include build directory in search path. If you decide to use a text editor like vim or emacs, there are some configuration files which set proper source code formatting options, like contrib/lvimrc. Settings for emacs are available here: https://gcc.gnu.org/wiki/FormattingCodeForGCC > Should I star looking at the "easy hacks" ? Yes, probably it's a good point to start with. -- Regards, Mikhail Maltsev
Re: Help! Regarding Bug 17896
On 01/25/2016 10:15 PM, Prasad Ghangal wrote: > Hi! > > I would like to solve "Bug 17896 - The expression (a>0 & b>0) should > give clearer warning message (-Wparentheses)" > (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=17896) but I am new to > gcc internals. > > Can someone please guide me how to do it? > Hi! A good starting point is probably this wiki page: https://gcc.gnu.org/wiki/GettingStarted. Note that there are some legal prerequisites (FSF has a policy of copyright consolidation, and thus requires all contributors to assign copyright on their work to FSF. I hope that you are OK with it). Right now GCC is in stage 4 of it's development cycle, that means only regression fixes are accepted. The trunk will be open again for new features and enhancements after release of GCC 6 (presumably in March, if nothing unusual happens), but you can still send your patch for review and discuss it with maintainers as soon as it is ready. As for the bug itself. Most of diagnostic reporting code is located in 'gcc/diagnostic.c' and 'gcc/diagnostic-show-locus.c'. You might want to set a breakpoint on, say, 'report_diagnostic' function and look at the backtrace to find out what code invokes it and how. Note that diagnostics API has been improved since 2004 (when this bug was reported). For example, Clang gives warnings like: test.c:17:17: warning: | has lower precedence than ==; == will be evaluated first [-Wparentheses] foo ((a == b) | b == c); ^~~~ test.c:17:17: note: place parentheses around the '==' expression to silence this warning foo ((a == b) | b == c); ^ ( ) test.c:17:17: note: place parentheses around the | expression to evaluate it first foo ((a == b) | b == c); ^ ( ) GCC says: test.c:17:21: warning: suggest parentheses around comparison in operand of '|' [-Wparentheses] foo ((a == b) | b == c); ~~^~~~ As I understand, the bug report suggests that we say "suggest || instead of | when joining booleans" instead. We now have the API to show fix-it hints, so it would be nice to output something like test.c:17:21: warning: suggest || instead of | when joining booleans foo ((a == b) | b == c); ^ || Grep 'set_fixit_hint' in the source code to see an example of it's usage. Good luck! P.S. I also CC'd this message to one of major contributors to GCC diagnostics module, maybe he could add something. -- Regards, Mikhail Maltsev
Re: GCC-Bridge: A Gimple Compiler targeting the JVM
On 02/01/2016 03:34 PM, Bertram, Alexander wrote: > I wanted to share a project we've been working on for sometime within > the context of Renjin, > a new interpreter for the R language running on the JVM. > > We basically needed a way to compile C and Fortran code to JVM > classes, and for the last year or two we've been working on tool chain > that's composed of a GCC plugin which dumps Gimple trees out to a JSON > file, and a Java program which reads the JSON and compiles it to Java > classfiles. > > I've written a bit more about it today here: > http://www.renjin.org/blog/2016-01-31-introducing-gcc-bridge.html > > And you can find the whole project here: > https://github.com/bedatadriven/renjin/tree/master/tools/gcc-bridge > > The compiler is part of the Renjin project, but can also be used in a > standalone way to compile arbitrary C/Fortran code to Java classfiles, > though the focus has been on pure scientific code, so we haven't > bothered with some rather obvious things like fopen(). > > Anyway, using the GCC plugin interface has been terrific, and the > gimple trees have been great to work with! Interesting project. It's great to see that the plugin interface is actually used by real-world projects. P.S. I noticed this comment in your source code: // GCC won't let us malloc and I don't want to mess // around with GCC's internal memory management stuff, // so we'll just use a fixed-size stack You actually don't need to use any complex memory management stuff. GCC provides a wrapper for malloc called 'xmalloc'. It works like normal malloc, but aborts in case of allocation failure. -- Regards, Mikhail Maltsev
Re: gengtype: conditional GTY ? (to add before GCC 6 release)
On 02/12/2016 04:38 PM, Richard Biener wrote:
> Sorry, no. The plugin API was never considered stable and thus plugins have
> to
> deal with incompatibilites as they arise.
>
> Help with picking up the partially completed work on a stable plugin
> (introspection) API
> is of course welcome.
>
> Richard.
When I had to write a rather simple plugin for GCC, it seemed very
convenient to use C++11 range-based for loops instead of GCC's
FOR_EACH_... macros, so I created several helper classes.
For example (for GCC 5.x) after implementing:
class const_stmt_iterator {
public:
const_stmt_iterator(const_basic_block bb, gimple_seq* seq,
gimple_seq_node node);
const_gimple operator*() const;
const_stmt_iterator & operator++();
bool operator == (const const_stmt_iterator &other);
bool operator != (const const_stmt_iterator &other);
private:
const_basic_block m_bb;
gimple_seq* m_seq;
gimple_seq_node m_node;
};
class each_stmt_bb
{
public:
each_stmt_bb(const_basic_block bb);
const_stmt_iterator begin() const;
const_stmt_iterator end() const;
private:
const_basic_block m_bb;
gimple_seq *m_seq;
};
Now, instead of
gimple_stmt_iterator gsi;
for (gsi = gsi_start_bb (bb); !gsi_end_p (gsi); gsi_next (&gsi))
{
gimple stmt = gsi_stmt (gsi);
...
}
one can write (in C++11):
for (gimple stmt : each_stmt_bb(bb))
{
...
}
Likewise, instead of:
basic_block bb;
FOR_EACH_BB_FN(bb, fn)
{
...
}
C++11 users can write:
for (basic_block bb : each_bb(*fn))
{
...
}
The problem is that iteration protocol is significantly different
between various collections in GCC. And none of them (IIRC) use C++
begin/end iterators.
Even without altering GCC sources I could provide some sort of wrapper
library, which will make life easier for plugin writers. Unfortunately,
as I understand, GCC developers are not motivated to accept refactoring
of iterators into GCC codebase, because more concise range-based for
loops are only available in C++11 (and as David Edelsohn told me, there
are no plans to migrate to C++11 because we need to keep compatibility
with some old compilers :( ).
Nevertheless, I think using idiomatic C++ iterators and ranges in GCC is
good because:
1. They decouple iteration logic for the object (i.e. if basic_blocks
for some reason will no longer store prev/next pointers, all
FOR_EACH_BB_ loops will need to be changed; this is not the case, if we
have separate iterators for them).
2. Such iterators will allow to use range-based for loops for plugins
without additional libraries.
3. C++98 limitation is hopefully not forever :).
What do you think about refactoring iterators in GCC 7?
--
Regards,
Mikhail Maltsev
Re: gengtype: conditional GTY ? (to add before GCC 6 release)
On 02/15/2016 06:34 PM, Michael Matz wrote: > Hi, > > On Fri, 12 Feb 2016, Richard Biener wrote: > >>> What do you think about refactoring iterators in GCC 7? >> >> I think refactoring towards STL style iterators would be welcome. It >> may be different for the actual instances though. > > Oh God, please, for the live of all kittens, no. Well, 'begin', 'end', 'operator++' and 'operator!=' are, unfortunately, hardwired into the core language (I mean, [stmt.ranged]/1). If anything, implement > and use a range idiom like in D. > Could you please elaborate on that? > > Ciao, > Michael. > -- Regards, Mikhail Maltsev
Re: [gimplefe] [gsoc16] Gimple Front End Project
On 03/08/2016 06:56 PM, Richard Biener wrote: >> The dumps contain a lot of (sometimes optional) unstructured >> information. For >> example, they show both the result of the pass and (arbitrarily >> unstructured) >> messages about what the pass is doing. >> >> Wouldn't it be better to get the dumps in a more structured form (e.g., >> >> separating IR from debug messages) before doing this? > > I'd say a dump modifier -il to make it dump IL only (maybe into a different > file) plus required global info such as types would be enough. Why not just support comments in GIMPLE FE and output all unstructured pass information inside them? In fact, some stuff is already wrapped into ";;"-style comments, like this: ;; Function fn1 (null) ;; enabled by -tree-original You could just change it to use C++-style comments (//), which C-family frontends already understand. > > Also note my suggestion that all GIMPLE sources should be valid C as well it > would be unfortunate to lose the option to torture unit tests. > I wonder how will this work with SSA form? -- Regards, Mikhail Maltsev
Re: CppCoreGuidelines warnings
On 05/17/2016 02:10 PM, Christopher Di Bella wrote: > >> I don't know the status of the static analysis tool the Microsoft were >> planning to release, which would do a lot of the checking. > > As far as I'm aware, this is a Visual Studio tool, and thus closed > source. I might be wrong! Some of the C++ Core Guidelines checks are already implemented in clang-tidy: http://reviews.llvm.org/diffusion/L/browse/clang-tools-extra/trunk/clang-tidy/cppcoreguidelines/ -- Regards, Mikhail Maltsev
Re: ROP and JOP attack protection
On 05/23/2016 08:50 PM, Roy Leblanc wrote: > Hello all, > > Does GCC's code generator at this point provide protection against ROP and > JOP attacks? This can be achieved by carefully controlling what opcode bytes > and immediate values are produced. It can also be achieved by rewriting > assembler output as you see with the AntiJOP project. > > More information: https://en.wikipedia.org/wiki/Return-oriented_programming > > -Roy > IIUC, this is still work in progress. Some initial support is available in GCC 6.1: https://gcc.gnu.org/ml/gcc-patches/2015-11/msg01773.html -- Regards, Mikhail Maltsev
Re: How to improve the location of a gcc diagnostic
On 06/23/2016 17:04, David Malcolm wrote: > A user filed a bug about a bad location in a warning. It was marked as > an "easyhack" in bugzilla, and I had a go at fixing it. > > I though it may be useful for new GCC developers if I document what I > did to fix it. Shouldn't this also go to the wiki? -- Mikhail Maltsev
Re: unhappiness with zero package security
On 02.07.2016 18:12, squidmob...@fastmail.fm wrote: 02 jul 2016 i tried to build and install gcc, and i ran into a problem. your docs suggest isl acts as an OPTIONAL package for optimizations. however, i could not build gcc without it. Try configuring GCC with '--disable-graphite' option. -- Mikhail Maltsev
Re: Should we import gnulib under gcc/ or at the top-level like libiberty?
On 07/10/2016 08:15 PM, Manuel López-Ibáñez wrote: > Moving all gnutools to a single git/svn repository that can still be > built piece-wise would help sharing gnulib and other useful libraries. > If LLVM can do it, there is no reason why gnutools can't. And they > have shown that it helps code reuse and modular design. All the manual > syncing between gnu projects is a waste of time. But LLVM does not keep everything in a single repository. In fact, it's quite the opposite: they have a separate repo for Clang (the frontend, ~ gcc/c, cp, ...), for compiler-rt (~ libgcc), for libc++ (~ libstdc++). All utilities (~ libiberty) live in the LLVM repo (include/llvm/ADT, include/llvm/Support, lib/Support). Other projects, like LLDB, are checked out into a subdirectory, and are always built from the combined tree. -- Regards, Mikhail Maltsev
Re: Lessons learned from compiler error/warnings tests
On 09.09.2016 21:15, Manuel López-Ibáñez wrote: > On 09/09/16 13:28, Florian Weimer wrote: >> For compile-time fortify checks (such as the wrappers for type-safe >> open/openat), we need to add tests in glibc which examine the compiler output >> for warnings and errors. >> >> I do not want to add Dejagnu as a dependency to the glibc test suite, but I >> wonder if you could share any lessons learned from the testing support >> facility >> in GCC. > > That seems wise. Ian words may be worth taking into account: > http://www.airs.com/blog/archives/499 > > and do not miss the comment by Joel Brobecker about what AdaCore uses > (internally?). > > And probably this talk is also somewhat relevant (Cauldron 2013 - DejaGNU BOF): https://www.youtube.com/watch?v=rjm-n9EgxiE -- Mikhail Maltsev
Re: Rename C files to .c in GCC source
31.01.2015 14:10, Florian Weimer writes: > Aren't current Windows file systems case-preserving? Then they > shouldn't have no problems with .C files. They are, but with some limitations: you can't create two files with names differing only by case. I didn't try API functions, but here is how it looks like in command line. Linux: $ touch a $ touch A $ touch B $ ls a A B Cygwin (Windows 8.1, x64, NTFS): $ touch a $ touch A $ touch B $ ls a B Windows command prompt (on same system): >echo 1 > a >echo 1 > A >echo 1 > B >dir (several non-relevant lines omitted) 31.01.2015 14:58 4 a 31.01.2015 14:58 4 B Renaming does work: Cygwin: $ mv ./a ./A $ ls A B Native: >rename a A >dir (...) 31.01.2015 14:58 4 A 31.01.2015 14:58 4 B -- Regards, Mikhail Maltsev
Re: Segmentation fault with unique_ptr
13.02.2015 16:04, tassos_souris writes: > Compile with: g++-4.9 -std=c++14 -g -o main main.cpp > and run with ./main. I get segfault. gdb in bt shows that the segfault > happens inside unique_ptr destructor. So it is not a memory issue. > Also since the code runs with less size (i.e size=1000 no problem) i assume > that something is wrong with unique_ptr and not my code. That's of course > only an assumption don't get me wrong :) The destructor of struct node calls the destructor of it's "next" member, which is std::unique_ptr, so you get a chain of recursive calls, and when it gets too deep, you simply run out of stack (you could check it by setting a breakpoint on node::~node and stepping through it several times, looking at the backtrace each time). Here is what I get with GCC 4.8.2, -std=c++11: #0 singly_linked_list_2::node::~node (this=0x6511b0, __in_chrg=) at ./stack_fail.cc:8 #1 0x00400db8 in std::default_delete::operator() (this=0x6511d8, __ptr=0x6511b0) at /usr/include/c++/4.8.2/bits/unique_ptr.h:67 #2 0x00400a07 in std::unique_ptr >::~unique_ptr (this=0x6511d8, __in_chrg=) at /usr/include/c++/4.8.2/bits/unique_ptr.h:184 #3 0x00400d94 in singly_linked_list_2::node::~node (this=0x6511d0, __in_chrg=) at ./stack_fail.cc:8 #4 0x00400db8 in std::default_delete::operator() (this=0x6511f8, __ptr=0x6511d0) at /usr/include/c++/4.8.2/bits/unique_ptr.h:67 #5 0x00400a07 in std::unique_ptr >::~unique_ptr (this=0x6511f8, __in_chrg=) at /usr/include/c++/4.8.2/bits/unique_ptr.h:184 #6 0x00400d94 in singly_linked_list_2::node::~node (this=0x6511f0, __in_chrg=) at ./stack_fail.cc:8 #7 0x00400db8 in std::default_delete::operator() (this=0x651218, __ptr=0x6511f0) at /usr/include/c++/4.8.2/bits/unique_ptr.h:67 #8 0x00400a07 in std::unique_ptr >::~unique_ptr (this=0x651218, __in_chrg=) at /usr/include/c++/4.8.2/bits/unique_ptr.h:184 #9 0x00400d94 in singly_linked_list_2::node::~node (this=0x651210, __in_chrg=) at ./stack_fail.cc:8 #10 0x00400db8 in std::default_delete::operator() (this=0x7fffe410, __ptr=0x651210) at /usr/include/c++/4.8.2/bits/unique_ptr.h:67 #11 0x00400a07 in std::unique_ptr >::~unique_ptr (this=0x7fffe410, __in_chrg=) at /usr/include/c++/4.8.2/bits/unique_ptr.h:184 #12 0x00400962 in singly_linked_list_2::~singly_linked_list_2 (this=0x7fffe400, __in_chrg=) at ./stack_fail.cc:19 #13 0x004007ae in main () at ./stack_fail.cc:40 As we see, the recursion depth is linear WRT list size. At higher optimization levels the tail call gets optimized, and this problem does not occur, but in general it's better not to rely on this. -- Regards, Mikhail Maltsev
Re: GSoc-2015: Modular GCC
05.03.2015 18:46, Jeff Law wrote: > Certainly still useful, the trick is finding a hunk of that work that > can be tackled via GSoc. > > jeff Though I'm not participating in GSoC, I would be glad to get involved in GCC development. Could you please give some comments on current status of the following part: "Before GCC can be modularized properly, it is necessary to make clear what interfaces and declarations are actually needed in each source file. This will, no doubt, be a huge job. It is unclear at the moment whether there are tools available that could help (Dehydra perhaps, or a dedicated plugin, or Ctags? Or turn this patch into a proper plugin? Maybe create a symbols database and identify dependencies to break?)." -- Regards, Mikhail Maltsev
Examples of GCC plugins
Hi, all. When I first tried to write a simple plugin for GCC, it turned out that existing docs on plugins (https://gcc.gnu.org/onlinedocs/gccint/Plugins.html#Plugins) are rather brief, so I had to refer to the GCC source code. When I grepped the source looking for one of plugin API functions, I found this directory: gcc/testsuite/gcc.dg/plugin. Plugins in that directory were very helpful as a starting point. I think, they are definitely worth being mentioned in documentation (maybe I was inattentive and missed some link to them?) or perhaps even separated from testsuite (of course, I don't mean removing something from testsuite, but rather adding a separate Makefile, not dependent on DejaGNU). Any thoughts on this? -- Regards, Mikhail Maltsev
Re: Proposal for the coarse grain unrolling heuristics and renaming for the enablement of better fine grain Loop transformation.
15.03.2015 17:44, Ajit Kumar Agarwal writes:
>
> Hello All:
>
> The below example is taken from the article by Albert Cohen et.al.
>
> "Deep Jam : Conversion of Coarse grain Parallelism to Fine grain vector
> parallelism"
It is not clear from this article, whether such optimization can be
implemented in practice (i.e. automatically and within reasonable time).
Authors implemented some proof-of-concept, but from their description it
looks like they had to tweak their algorithm in each particular case
(and they hope, that later this could be automated using FDO). Also
nothing definite is said about compilation time.
> I would like to propose the above heuristics for unroll and jam and renaming
> which enables the loop fusion and the IF-merging
> to achieve the optimize code.
AFAIK, most of loop transformations in GCC are applicable to rather
simple loops, which, at least have an induction variable. So, loops like
while (q)
{
...
}
for some arbitrary condition q, e.g.
while (*a++ = *b++)
;
are unlikely to be optimized well. The proposed transformation
> For ( I = 0 ; I < 10; i++)
> a1 = phi(a1,a2);
> If ( p1 && p2)
> a1 = ...;
> a2 = ...;
> Else
>If (p1)
> a1= ;
> Else
> If (p2)
>a2 = ...;
>
>While (q1 && q2)
>{
>... = a1 + ...;
>... = a2 + .;
>}
> While (q1)
> = a1 + ...;
> While ( q2)
> . = a2 + ..;
involves some sort of unroll-and-jam, nontrival code motion, loop
fusion. And it obviously requires analysis of loop-carried data
dependence, that can deal with nested loops having complex conditions
inside them, which GCC does not yet provide.
GCC includes Graphite framework - it allows to perform rather complex
transformations of loops (perhaps similar to what you described), but it
only works for loops which have canonical induction variables and
involve only affine memory access (i.e. addresses must be represented as
linear combinations of induction variables and constants) - no if's, no
while's with non-trivial exit conditions.
So, I think this idea is, unfortunately, not very realistic in terms of
required efforts.
P.S. I'm new in GCC community, but I hope that in general terms my
description is close to reality. Please correct me, if something is wrong.
--
Regards,
Mikhail Maltsev
Proposal: implement API for registering custom built-in functions from dynamic plugins
Hi, all. Currently GCC allows dynamic plugins to register custom attributes and pragmas. I would like to propose to add API for registering custom built-in functions. AFAIK, current plugin API can be used to emulate this feature, for example by creating a function declaration in PLUGIN_START_UNIT and then replacing calls to such function in a custom lowering pass. But this solution seems inelegant: it would be better, if user-defined built-in functions could use the same "machinery" as normal ones, i.e. use common classification and flags (RTL-level vs GIMPLE-level; external library equivalents vs compiler-generated entities), and have unified API for creating declarations, GIMPLE (or even RTL) expansion, inlining (callback for is_inexpensive_builtin), etc. Possible applications of this plugin API include: * Generating optimized pattern matching functions (e.g. precomputing tables for Boyer-Moore matcher). * Generating functions for parsing (compile-time regular expressions). * Marshalling functions with compile-time type checking (something like binary printf/scanf with custom format specifiers). * String formatting and conversion. By the way, there is a guy, who has written a perl wrapper for GCC, which preprocesses calls to snprintf to make it work faster: https://github.com/h2o/qrintf... though it's probably worth enhancing snprintf in GCC, rather than reimplementing it in plugin - but that's a different story. * (to some extent): lazy evaluation. * Custom instrumentation of source code (user or framework-specific fortification or performance profiling). Any thoughts on this? Is such API useful for GCC? -- Regards, Mikhail Maltsev
Re: GSoc-2015: Modular GCC (RFC on refactoring)
07.03.2015 18:41, Jeff Law wrote: > One potentially easy project there would be to take David Malcolm's work to > turn the RTL EXPR & INSN lists into standard C++ forward lists. Started working on this. I need to understand, if I'm moving in the right direction (i.e. whether my understanding of what needs to be done is correct). I got some basic grasp of GCC internals, but the code base is huge, and I still have a lot of questions :( 1. The list of INSNs is non-intrusive, i.e. nodes of such list no longer need to be subclasses of struct rtx_def and/or members of rtunion, right? 2. Lists, list nodes and list iterators should be objects of distinct types. In this case, header file function.h gets additional dependency, because struct rtldata contains insn/expr lists as members; currently they are pointers, so a forward declaration is sufficient. A possible workaround is to create an opaque type like it's done with struct initial_value_struct (at a cost of one additional level of indirection). Which is better? 3. List nodes can be allocated in a separate pool rather than garbage-collected memory. Not sure, what should be done with reg_notes. They use insn lists, but it seems to me that insn lists in reg_notes are a different concept than, say, lists used by scheduler and register allocator), according to rtlanal.c: /* These types of register notes use an INSN_LIST rather than an EXPR_LIST, so that copying is done right and dumps look better. */ So, should this be changed somehow? 4. I don't understand precisely, how all this stuff will interact with garbage collector. Is it possible, for example, to register an insn_list object as a GC root with custom marking function in it's constructor, and remove it, when the list is destroyed? 5. EXPR lists seem to be harder to separate from other RTL objects, because they are owned by GC-managed RTL objects. Maybe we need to have both pool-allocated and GC-managed lists? > One that's harder would be pushing the rtx_insn * class further. Basically > most of the places where we have a as-a cast between rtx_insn * and an > rtx is a good candidate for removal and further propagation of rtx_insn > * types. I'll try to figure out, if it's possible to automate this. Perhaps, by writing a plugin, which traverses C++ AST (in PLUGIN_PRE_GENERICIZE) and searches for such casts. -- Regards, Mikhail Maltsev
Re: gcc wiki project
On Tue, 24 Mar 2015 13:16:26 +0100 Martin Jambor wrote: > Yes, I think that even just moving hopelessly outdated stuff to some > "Archive" section, looking at what is left and then perhaps > re-organizing the sections on the main page (and perhaps a few similar > ones) would be great, if you have the time and energy to do it. When I was trying to get some kind of "table of contents" of wiki, I ran into problem, that the relevant pages (i.e. the list of all pages, categories and several others) reply with timeout error. To workaround this, I wrote a simple crawler, which creates such list (it includes page title, last edit date, author and URL). Unfortunately, I the attached file was rejected by spam filter, so instead I'm posting a link to bitbucket repository: https://bitbucket.org/miyuki-chan/gcc_wiki_toc/downloads The list contains ~500 pages. It is an HTML file with several js-scripts, which allow to sort the list by columns mentioned above (title, last edit date and author). I hope it will help working on wiki. When I get some more free time, I'll also add a list of broken links. -- Regards, Mikhail Maltsev
Re: Q.: inconsistent (?) warnings about functions called through non-compatible types
29.03.2015 23:18, Godmar Back writes:
> Thanks. I'm a bit confused then what constitutes defined & undefined behavior.
>
> The actual situation I encountered is best described by this example:
>
> --
> /* Tested with gcc 4.4.7 and 4.8.2 -m32 */
> #include
> #include
>
> bool boolFunctionThatReturnsFalse() {
> // I'm faking this here, but a real 'bool' function could
> // place 0x100 in $eax when meaning to return false.
> register bool r asm("%eax");
> asm("mov $0x100, %eax");
> return r;
> }
>
> typedef int (*intFunction)(void);
>
> int
> main()
> {
> if ( boolFunctionThatReturnsFalse() )
> printf("true\n");
> else
> printf("false\n");
>
> intFunction f = (intFunction) boolFunctionThatReturnsFalse;
> if ( f() )
> printf("true\n");
> else
> printf("false\n");
> }
> --
>
> (I'm faking the return value of boolFunctionThatReturnsFalse here, but
> I have observed this behavior in actual code.)
>
> Is this defined or undefined behavior that my problem invokes?
>
> - Godmar
>
According to C99 standard:
1. A pointer to a function of one type may be converted to a pointer to
a function of another type and back again; the result shall compare
equal to the original pointer. If a converted pointer is used to call a
function whose type is not compatible with the pointed-to type, the
behavior is undefined. (6.3.2.3)
2. For two function types to be compatible, both shall specify
compatible return types. (6.7.5.3).
3. Two types have compatible type if their types are the same. (6.2.7)
4. The type char, the signed and unsigned integer types, and the
floating types are collectively called the basic types. Even if the
implementation defines two or more basic types to have the same
representation, they are nevertheless different types. (6.2.5)
Thus, the call of f() invokes undefined behavior.
--
Regards,
Mikhail Maltsev
Re: Connecting to gcc.gnu.org - keygen_fail
14.04.2015 9:28, j...@aptnsw.org.au writes:
> Hi,
>
> If I try to browse to pages like http://gcc.gnu.org/bugs/segfault.html I get
> the following Mozilla alert:
>
>>
>> An error occurred during a connection to gcc.gnu.org:443. Unable to
>> generate public/private key pair. (Error code: sec_error_keygen_fail)
>>
>
> Advice, please?
>
The server replies with status code "307 Temporary Redirect" and
redirects to HTTPS version ("Location:
https://gcc.gnu.org/bugs/segfault.html";). Recent versions of Chrome and
Firefox (well, Iceweasel actually) handle it correctly. SSL certificate
is OK.
Though it's strange. Why not "301 Moved Permanently"?...
--
Regards,
Mikhail Maltsev
Re: is it time to mass change from .c to .cc in gcc/ ?
On 15.04.2015 3:09, Trevor Saunders wrote: > On Tue, Apr 14, 2015 at 10:46:19AM +0200, Richard Biener wrote: >> I see no value in doing this but making branch maintainance awkward. > > I think its mostly valuable to cause less confusion of new people, and > though it is a simpler thing every little thing can be the thing that > breaks the cammel's back. Yes its not all that hard to configure > editors and what not to handle it properly, but every new person needs > to do it, and looking up configuration options takes time that can more > profitably be spent. Well, for me, as a newcomer, configuring the editor and getting used to non-standard file extensions was, perhaps, one of the easiest parts (but yes, that's a bit confusing). You mentioned that you are planning to do reorganization of the directory structure. That would be really helpful. LLVM has two separate directories for utility classes, functions and custom datatypes (llvm/include/llvm/ADT and llvm/include/llvm/Support). In GCC all those useful things are scattered among 771 files in gcc directory, some are in libiberty. There is no need to wait for reorganization to at least create a list of such support data structures and functions (something like this: http://llvm.org/docs/ProgrammersManual.html). The good thing is that we already have excellent documentation for some of them in source code (for example vec.h and is-a.h), but we are missing the list. > > That said keeping backports as easy as possible is also certainly > important. I'm curious why renames hurt doing backports, I'm pretty > confident git cherry-pick will handle it for you, and if you like patch > files for some reason I'd think its easy to fix up with sed though > running that for each backport by hand would get a little old. > IIRC, SVN can dump the whole repository and import it again. So, if it's really desired, it's possible to rename the files "in the past" without loosing the history by filtering the dump (but git mirror must be rebuilt in this case). -- Regards, Mikhail Maltsev
[RFC] Documenting support functions and data structures
Hi, all! I think GCC documentation is missing a description of commonly used data structures and support functions. For example, "GCC internals" document contains information about, say, GIMPLE IR and functions for manipulating it. But it does not describe general data structures, such as hash maps or vectors. In fact, these structures are documented rather well in the source code, but I could not find a list of them. I mean something like this: http://llvm.org/docs/ProgrammersManual.html#important-and-useful-llvm-apis So, I want to create a similar page in GCC's internal docs, but I don't know what should be included (i.e. did I miss something important, or did I include something obsolete), so I ask for some assistance. Here is a draft (a list of relevant files from ./gcc, ./include and ./libiberty directories). This list does not yet include functions for interacting with host OS (it's a separate issue) and does not include compiler-specific structures (like, say, control flow graph or varpool) and algorithms. Ordering is somewhat random. === Memory management === gcc/alloc-pool.c - pool allocator gcc/ggc* - mark-and-sweep garbage collector (includes sources of gengtype, a program which generates traversal routines from annotated C++ code) gcc/ggc-page.c - size-class based allocator (used by garbage collector). (?? isn't it the same as "slab allocator") gcc/hash-table.h - contains some simple allocator templates libiberty/xmalloc.c - wrappers for malloc and friends with checking === Data structures === gcc/bitmap.c - sparse integer set (based on linked lists of chunks) gcc/sbitmap.c - "simple bitmap" - vector-based bitmap gcc/et-forest.c - ET-forest data structure (used for efficient solution of dynamic least common ancestor problem) gcc/fibonacci_heap.h (header-only) - mergeable priority queues gcc/graphds.c - graph representation and manipulation functions gcc/hash-table.c - hash table implementation (base for hash-set and hash-map) gcc/hash-map.h (header-only) - hash map gcc/hash-set.h (header-only) - hash set gcc/sparse-set.c - another sparse set implementation (I think, I'll make a table, with comparison of different implementations w.r.t. size, available operations and their run time) gcc/vec.c - vector template, implements several different memory allocation strategies include/obstack.h - object stack libiberty/splay-tree.c - splay tree === RTTI, type manipulation === gcc/is-a.h (header-only) - customizable low-overhead RTTI and dynamic casts gcc/system.h (header-only) - several implementations of const_cast === Algorithms === libiberty/md5.c, sha1.c - corresponding hash functions libiberty/crc32.c - CRC32 checksum (BTW, why is bitwise implementation from tree.c used everywhere instead of table algorithm?) gcc/inchash.c - incremental hashing libiberty/bsearch.c - binary search (and other stuff reimplementing libc functions - is this a workaround for broken system libc?) === Multiprecision arithmetics === gcc/hwint.c - "host wide int" - macros for representing host system's int64_t/uint64_t in a portable way and some related functions gcc/wide-int.cc, namespace hw - generic finite precision integers (including variable-precision and target-dependent precision integers + traits) gcc/double-int.c - 128-bit fixed precision integer type gcc/fixed-value.c - fixed precision real arithmetics, uses target-dependent representation gcc/real.c - floating-point arithmetics, including target-dependent representation gcc/mpfr.c - conversion routines from GCC internal float representation to MPFR gcc/sreal.c - simple software floating-point arithmetics === Debugging, statistics === gcc/dbgcnt.c - debug counters gcc/errors.c - diagnostics for internal use (in generator programs) gcc/statistics.c - arbitrary statistics counters and histograms gcc/timevar.c - timing variables and timing stacks gcc/system.h (header) - assertions, static_assert === Text manipulation === gcc/pretty-print.c - text formatting and output libiberty/concat.c - multiple string concatenation libiberty/regex.c - regular expressions === Serialization === gcc/data-streamer*.c - general marshalling routines gcc/ggc* - marshalling routines, which use code generated by gengtype; used for precompiled headers I'm asking for advice on correct categorization, missing stuff, etc. -- Regards, Mikhail Maltsev
Re: is it time to mass change from .c to .cc in gcc/ ?
On 15.04.2015 19:21, Manuel López-Ibáñez wrote: > The "right" steps to see progress: > > 1. You think that some concrete change may improve GCC, for example, to > move vec.h and is-a.h to some gcc/include/core. Ask if the key people > (Global Reviewers in this case) will accept this change. <...> > 2.1 If not, then goto 1 and think about something else (or perhaps > people misunderstood what you meant? Well, sort of :). I did not mean that I want to try to design the structure for GCC source code tree. I was talking about documentation issues only. > Just do it. Hmm, indeed... > Sent a patch for gccint.texi or create a webpage in the wiki > to draft it or just draft it in plain-text and send it to the mailing > list. Started with the latter. By the way, what is the policy concerning getting write access to the wiki? Regards, Mikhail Maltsev
Re: ANN: gcc-python-plugin 0.14
On 06.05.2015 21:43, David Malcolm wrote:
> gcc-python-plugin is a plugin for GCC 4.6 onwards which embeds the
> CPython interpreter within GCC, allowing you to write new compiler
> warnings in Python, generate code visualizations, etc.
>
> It ships with "gcc-with-cpychecker", which implements static analysis
> passes for GCC aimed at finding bugs in CPython extensions. In
> particular, it can automatically detect reference-counting errors:
> http://gcc-python-plugin.readthedocs.org/en/latest/cpychecker.html
>
> This release adds support for GCC 5.
I tried to compile it with current trunk on x86_64-unknown-linux-gnu
(CentOS7) with Python 2.7.5 (It's default in CentOS7), but unfortunately
the build failed. The reason is that the plugin #include's
before GCC's headers.
gcc/system.h #define's __STDC_FORMAT_MACROS in order to get PRId64 and
other similar macros defined by inttypes.h. Probably Python.h includes
it earlier without this definition. The recommended way
(https://gcc.gnu.org/onlinedocs/gccint/Plugin-API.html#Plugin-API) is
always include gcc-plugin.h first.
But I don't know, whether it's possible to do it without breaking
something else. So I attached a "quick and dirty" patch which simply
defines __STDC_FORMAT_MACROS in all files which require it. (disclaimer:
I looked into gcc-python-plugin sources for the first time yesterday). I
can't tell for sure that it works, but the testsuite which is run when I
run "make" passes without failures.
--
Regards,
Mikhail Maltsev
diff --git a/.gitignore b/.gitignore
index 09559f8..a34acf4 100644
--- a/.gitignore
+++ b/.gitignore
@@ -34,6 +34,6 @@ docs/_build
# Logfiles generated during the selftest suite:
*.c.cpychecker-log.txt
-*.c.*-refcount-errors.html
-*.c.*-refcount-traces.html
+# Changed this to make it work with Python 2 and a C++ test
+tests/**/*.c*-refcount-*.html
tests/plugin/dumpfiles/input.c.*t.test-pass
diff --git a/cpybuilder.py b/cpybuilder.py
index 8d8cab7..7e64936 100644
--- a/cpybuilder.py
+++ b/cpybuilder.py
@@ -418,9 +418,11 @@ class CompilationUnit:
self._definitions += text
def as_str(self):
-return ('/* Autogenerated by cpybuilder */\n' +
+# Note: added a crutch to preserve line numbers (they are hardcoded in
tests)
+return ('/* Autogenerated by cpybuilder */\n'
+'#define __STDC_FORMAT_MACROS\n' +
self._includes +
-self.make_header('Prototypes') +
+self.make_header('Prototypes').lstrip() +
self._prototypes +
self.make_header('Definitions') +
self._definitions)
diff --git a/gcc-python-attribute.c b/gcc-python-attribute.c
index 2b528b4..e8f6473 100644
--- a/gcc-python-attribute.c
+++ b/gcc-python-attribute.c
@@ -17,6 +17,7 @@
<http://www.gnu.org/licenses/>.
*/
+#define __STDC_FORMAT_MACROS
#include
#include "gcc-python.h"
#include "gcc-python-wrappers.h"
diff --git a/gcc-python-callbacks.c b/gcc-python-callbacks.c
index e8a42aa..6613042 100644
--- a/gcc-python-callbacks.c
+++ b/gcc-python-callbacks.c
@@ -17,6 +17,7 @@
<http://www.gnu.org/licenses/>.
*/
+#define __STDC_FORMAT_MACROS
#include
#include "gcc-python.h"
diff --git a/gcc-python-callgraph.c b/gcc-python-callgraph.c
index b22b7b0..e05fb93 100644
--- a/gcc-python-callgraph.c
+++ b/gcc-python-callgraph.c
@@ -17,6 +17,7 @@
<http://www.gnu.org/licenses/>.
*/
+#define __STDC_FORMAT_MACROS
#include
#include "gcc-python.h"
#include "gcc-python-wrappers.h"
diff --git a/gcc-python-cfg.c b/gcc-python-cfg.c
index 84fc4fe..c9aef2a 100644
--- a/gcc-python-cfg.c
+++ b/gcc-python-cfg.c
@@ -17,6 +17,7 @@
<http://www.gnu.org/licenses/>.
*/
+#define __STDC_FORMAT_MACROS
#include
#include "gcc-python.h"
#include "gcc-python-wrappers.h"
diff --git a/gcc-python-closure.c b/gcc-python-closure.c
index 8df8a47..c0916b1 100644
--- a/gcc-python-closure.c
+++ b/gcc-python-closure.c
@@ -17,6 +17,7 @@
<http://www.gnu.org/licenses/>.
*/
+#define __STDC_FORMAT_MACROS
#include
#include
diff --git a/gcc-python-diagnostics.c b/gcc-python-diagnostics.c
index fd6f57a..7c87e34 100644
--- a/gcc-python-diagnostics.c
+++ b/gcc-python-diagnostics.c
@@ -17,6 +17,7 @@
<http://www.gnu.org/licenses/>.
*/
+#define __STDC_FORMAT_MACROS
#include
#include "gcc-python.h"
diff --git a/gcc-python-function.c b/gcc-python-function.c
index 96dedda..26b901f 100644
--- a/gcc-python-function.c
+++ b/gcc-python-function.c
@@ -17,6 +17,7 @@
<http://www.gnu.org/licenses/>.
*/
+#define __STDC_FORMAT_MACROS
#include
#include "gcc-python.h"
#include "gcc-python-wrappers.h"
diff --git a/gcc-python
Problems with GCC Wiki
Hi, all! Recently I tried to log into my (read-only) account on https://gcc.gnu.org/wiki, but got an error message, saying that the password is incorrect. It could not be the case that I forgot my password, because it was saved in a browser plugin. Nevertheless, I tried to restore the password using the corresponding form, but did not receive any reply. I tried to register again, and surprisingly I could use the same login and same email to create a new account. Several days later the situation repeated (I can't login) Is it the intended behavior (i.e. accounts that are not members of EditorGroup get deleted periodically)? -- Regards, Mikhail Maltsev
Re: LCOV of current GCC
Hi all! I noticed that you started to publish GCC test coverage data. About a year ago I also experimented with GCC's coverage and would like to share some possible improvement ideas for your scripts. I postprocess the coverage data with this script: https://gist.github.com/miyuki-chan/943efe7d8e0eb72fdd74997c8a10d6c5 It has the following features: 1. removes gengtype routines from coverage data 2. removes code from system headers (e.g., the host libstdc++) 3. it outputs a summary (which can be used for building graphs, like you do for benchmarks) I hope, you might find some of these ideas helpful. On Tue, May 30, 2017 at 9:21 AM, Martin Liška wrote: > On 04/28/2017 06:53 PM, David Malcolm wrote: >> On Fri, 2017-04-28 at 11:38 +0200, Richard Biener wrote: >>> On Fri, Apr 28, 2017 at 11:07 AM, Martin Liška >>> wrote: >>>> Hello. >>>> >>>> I've been working on some patches for GCOV and lcov was of my test >>>> scenarios. >>>> I'm sending link to static HTML pages made by the tool which are >>>> recorded >>>> for GCC (w/o bootstrap) build + running test-suite on x86_64-linux >>>> -gnu. >>>> I'm planning to set up a periodic build of that that will >>>> eventually rsync >>>> content to a public website: >>>> >>>> I guess it can be interesting for instance to see which folding >>>> branches are >>>> not used, or which files (functionality) is basically not much >>>> tested via >>>> the testsuite. >>>> >>>> https://drive.google.com/open?id=0B0pisUJ80pO1X0s3eEpuQ25GTG8 >>>> >>>> P.S. I've noticed David fixed doxygen of the project, I can rsync >>>> also that >>>> to public website. >>> >>> Nice! Results look better than anticipated ;) >>> >>> Richard. >>> >>>> Martin >> >> Excellent; thanks. > > Hello. > > I've just done that, periodically built LCOV can be found here: > > http://gcc.opensuse.org/gcc-lcov/ > >> >> For your periodic builds, please can you add "jit" to the enabled >> languages (it will also need --enable-host-shared). > > Done that and will be seen in next build. I do it every weekend. > >> >> Would be nice to add libiberty and libcpp to this, but maybe that needs >> extra work? > > Yep, it's currently done for gcc subfolder. Can be done in the future. > > Martin > >> >> Dave >> > -- Regards, Mikhail Maltsev
Re: Killing old dead bugs
Hi. Yes, bug maintenance is appreciated. See this message and replies to it: https://gcc.gnu.org/ml/gcc/2016-04/msg00258.html . I'm not sure that there is a documented policy, but I might be wrong. -- Regards, Mikhail Maltsev
Re: GCC contribution
On Wed, Mar 28, 2018 at 11:15 PM, Katsunori Kumatani < katsunori.kumat...@gmail.com> wrote: > For example, I wanted to add some plugin processing (actually a top-level > asm statement) at the end of a translation unit (with gathered data) to add > some special symbols / GAS directives (not instructions). But there's no > "normal" plugin event for this. > > So instead I simply saved the original lang_hooks.parse_file hook > (pointer), overrode the hook with the plugin's, which calls the original > first and then does whatever plugin does. And it works fine. This kind of > thing wouldn't be easily changed with virtual methods I believe. > I think this would be pretty straightforward: you will need a single plugin event, which would allow you to provide your own instance of a class derived from lang_hooks. You could then inherit a new class from the lang_hooks class in the frontend and override any of its virtual methods. -- Regards, Mikhail Maltsev
