Extraneous newline emitted between error messages in GCC 6
GCC 6, compared to GCC 5, now emits an extra newline between error messages. Is this intended? $ cat error.c int x = a; int y = b; $ gcc-5 error.c error.c:1:9: error: ‘a’ undeclared here (not in a function) int x = a; ^ error.c:2:9: error: ‘b’ undeclared here (not in a function) int y = b; ^ $ gcc-6 error.c error.c:1:9: error: ‘a’ undeclared here (not in a function) int x = a; ^ error.c:2:9: error: ‘b’ undeclared here (not in a function) int y = b; ^ $
Re: Please, take '-Wmisleading-indentation' out of -Wall
I'm sad that this discussion died so soon without Antonio's points being adequately addressed.
Re: Please, take '-Wmisleading-indentation' out of -Wall
On Mon, May 30, 2016 at 1:06 PM, Jakub Jelinek wrote: > On Mon, May 30, 2016 at 01:01:09PM -0400, Patrick Palka wrote: >> I'm sad that this discussion died so soon without Antonio's points >> being adequately addressed. > > But how do you want to address that? His point is that it does not belong > into -Wall, while there seems to be a wide agreement that it should be part > of -Wall, it found lots of real bugs in wide range of code, and for projects > that just want to use weirdo formatting styles they always have option to > opt-out, using -Wno-misleading-indentation. > > Jakub Yeah, I guess you're right. There is nothing really left to address since the remaining points of contention are mostly subjective, like as to whether or not the warnings emitted by -Wmisleading-indentation are sufficiently easy to work around as required by the criteria of -Wall. (In some cases it may require re-indenting huge blocks of code, for example, but that's still mechanically easy I guess.) Though there are some inconsistencies regarding the inclusiveness of -Wall seeing as neither -Woverlength-strings nor -Wempty-body are enabled by -Wall even though they seemingly satisfy the criteria of -Wall more readily than -Wmisleading-indentation does.
Should the build system use ar rcs instead of ranlib + ar rc?
The build step that invokes "ranlib libbackend.a" (which immediately follows the invocation of "ar rc libbackend.a ...") takes over 7 seconds on my machine and causes the entire 450MB archive to be rewritten. By instead making the build system use ar rcs -- so that the archive and its index are built at once -- the time it takes for the compiler to get rebuilt gets reduced by 25%, from 27s to 20s (in a --disable-bootstrap tree after touching a random source file). This is a pretty significant reduction in compile time and disk io. Is this a good idea? Here's the patchlet I used: -- >8 -- diff --git a/Makefile.in b/Makefile.in index 117fbf5..5ebc3a3 100644 --- a/Makefile.in +++ b/Makefile.in @@ -393,7 +393,7 @@ MAKEINFOFLAGS = --split-size=500 AS = @AS@ AR = @AR@ -AR_FLAGS = rc +AR_FLAGS = rcs CC = @CC@ CXX = @CXX@ DLLTOOL = @DLLTOOL@ diff --git a/Makefile.tpl b/Makefile.tpl index 94a4f79..72ba24b 100644 --- a/Makefile.tpl +++ b/Makefile.tpl @@ -396,7 +396,7 @@ MAKEINFOFLAGS = --split-size=500 AS = @AS@ AR = @AR@ -AR_FLAGS = rc +AR_FLAGS = rcs CC = @CC@ CXX = @CXX@ DLLTOOL = @DLLTOOL@ diff --git a/gcc/Makefile.in b/gcc/Makefile.in index 0786fa3..1c3a637 100644 --- a/gcc/Makefile.in +++ b/gcc/Makefile.in @@ -236,7 +236,7 @@ BISONFLAGS = FLEX = @FLEX@ FLEXFLAGS = AR = @AR@ -AR_FLAGS = rc +AR_FLAGS = rcs NM = @NM@ RANLIB = @RANLIB@ RANLIB_FLAGS = @ranlib_flags@ @@ -1883,17 +1883,14 @@ compilations: $(BACKEND) libbackend.a: $(OBJS) -rm -rf libbackend.a $(AR) $(AR_FLAGS) libbackend.a $(OBJS) - -$(RANLIB) $(RANLIB_FLAGS) libbackend.a libcommon-target.a: $(OBJS-libcommon-target) -rm -rf libcommon-target.a $(AR) $(AR_FLAGS) libcommon-target.a $(OBJS-libcommon-target) - -$(RANLIB) $(RANLIB_FLAGS) libcommon-target.a libcommon.a: $(OBJS-libcommon) -rm -rf libcommon.a $(AR) $(AR_FLAGS) libcommon.a $(OBJS-libcommon) - -$(RANLIB) $(RANLIB_FLAGS) libcommon.a # We call this executable `xgcc' rather than `gcc' # to avoid confusion if the current directory is in the path
Re: Should the build system use ar rcs instead of ranlib + ar rc?
On Sat, Jul 16, 2016 at 4:27 AM, Andreas Schwab wrote: > Andrew Pinski writes: > >> On Fri, Jul 15, 2016 at 6:46 PM, Patrick Palka wrote: >>> The build step that invokes "ranlib libbackend.a" (which immediately >>> follows the invocation of "ar rc libbackend.a ...") takes over 7 seconds >>> on my machine and causes the entire 450MB archive to be rewritten. By >>> instead making the build system use ar rcs -- so that the archive and >>> its index are built at once -- the time it takes for the compiler to get >>> rebuilt gets reduced by 25%, from 27s to 20s (in a --disable-bootstrap >>> tree after touching a random source file). This is a pretty significant >>> reduction in compile time and disk io. >>> >>> Is this a good idea? >> >> Yes and no. Do we know if all ar support rcs now? > > It is easy to find out: run a configure check. I see, I was not aware that non-GNU ar is supported. I posted a patch on gcc-patches that uses a configure check at https://gcc.gnu.org/ml/gcc-patches/2016-07/msg00991.html > > Andreas. > > -- > Andreas Schwab, sch...@linux-m68k.org > GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 > "And now for something completely different."
GSoC Project Ideas
Hi everyone, I am very interested in working on GCC as part of GSoC this year. A few years ago I was a somewhat active code contributor[1] and unfortunately my contributing waned once I went back to school, but I'm excited to potentially have the opportunity to work on GCC again this summer. My contributions were mainly to the C++ frontend and to the middle end, and I've been thinking about potential projects in these areas of the compiler. Here are some project ideas related to parts of the compiler that I've worked on in the past: * Extend VRP to track unions of intervals (inspired by comment #2 of PR72443 [2]) Value ranges tracked by VRP currently are represented as an interval or its complement: [a,b] and ~[a,b]. A natural extension of this is to support unions of intervals, e.g. [a,b]U[c,d]. Such an extension would make VRP more powerful and at the same time would subsume anti-ranges, potentially making the code less complex overall. * Make TREE_NO_WARNING more fine-grained (inspired by comment #7 of PR74762 [3]) TREE_NO_WARNING is currently used as a catch-all marker that inhibits all warnings related to the marked expression. The problem with this is that if some warning routine sets the flag for its own purpose, then that later may inhibit another unrelated warning from firing, see for example PR74762. Implementing a more fine-grained mechanism for inhibiting particular warnings would eliminate such issues. * Make -Wmaybe-uninitialized more robust (Inspired by the recent thread to move -Wmaybe-uninitialized to -Wextra [4]) Right now the pass generates too many false-positives, and hopefully that can be fixed somewhat. I think a distinction could be made between the following two scenarios in which a false-positive warning is emitted: 1. the pass incorrectly proves that there exists an execution path that results in VAR being used uninitialized due to a deficiency in the implementation, or 2. the pass gives up on exhaustively verifying that all execution paths use VAR initialized (e.g. because there are too many paths to check). The MAX_NUM_CHAINS, MAX_CHAIN_LEN, etc constants currently control when this happens. I'd guess that a significant fraction of false-positives occur due to the second case, so maybe it would be worthwhile to allow the user to suppress warnings of this second type by specifying a warning level argument, e.g. -Wmaybe-uninitialized=1|2. Still, false-positives are generated in the first case too, see e.g. PR61112. These can be fixed by improving the pass to understand such control flow. * Bug fixing in the C++ frontend / general C++ frontend improvements There are 100s of open PRs about the C++ frontend, and the goal here would just be to resolve as many as one can over the summer. Would any of these ideas work as a GSoC project? Regards, Patrick Palka [1]: https://gcc.gnu.org/git/?p=gcc.git;a=search;s=ppalka;st=author [2]: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72443#c2 [3]: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=74762#c7 [4]: https://gcc.gnu.org/ml/gcc-patches/2019-02/msg00020.html
Re: GSoC Project Ideas
Hi Richard, Jakub and Martin,
First of all I'm sorry for the very late reply, and I will be more
punctual with my replies from now on.
On Fri, Mar 8, 2019 at 4:35 AM Richard Biener
wrote:
>
> On Thu, Mar 7, 2019 at 7:20 PM Martin Sebor wrote:
> >
> > On 3/4/19 6:17 AM, Richard Biener wrote:
> > > On Mon, Mar 4, 2019 at 1:23 PM Jakub Jelinek wrote:
> > >>
> > >> On Mon, Mar 04, 2019 at 01:13:29PM +0100, Richard Biener wrote:
> > >* Make TREE_NO_WARNING more fine-grained
> > > (inspired by comment #7 of PR74762 [3])
> > >TREE_NO_WARNING is currently used as a catch-all marker that
> > > inhibits all
> > >warnings related to the marked expression. The problem with
> > > this is that
> > >if some warning routine sets the flag for its own purpose,
> > >then that later may inhibit another unrelated warning from
> > > firing, see for
> > >example PR74762. Implementing a more fine-grained mechanism
> > > for
> > >inhibiting particular warnings would eliminate such issues.
> > Might be interesting. You'd probably need to discuss the details
> > further.
> > >>>
> > >>> I guess an implementation could use TREE_NO_WARNING (or
> > >>> gimple_no_warning_p)
> > >>> as indicator that there's out-of-bad detail information which could be
> > >>> stored as
> > >>> a map keyed off either a location or a tree or gimple *.
> > >>
> > >> I guess on tree or gimple * is better, there would need to be some hook
> > >> for
> > >> copy_node/gimple_copy that would add the info for the new copy as well if
> > >> the TREE_NO_WARNING or gimple_no_warning_p bit was set. Plus there
> > >> could be
> > >> some purging of this on the side information, e.g. once code is handed
> > >> over
> > >> from the FE to the middle-end (maybe do that only at free_lang_data
> > >> time),
> > >> for any warnings that are FE only there is no need to keep records in
> > >> the on
> > >> the side mapping that have info about those FE warnings only, as later on
> > >> the FE warnings will not be reported anymore.
> > >> The implementation could be e.g. a hash map from tree/gimple *
> > >> (pointers) to
> > >> bitmaps of warning numbers, with some hash table to ensure that the same
> > >> bitmap is used for all the spots that need to have the same set of
> > >> warnings
> > >> disabled.
This design makes a lot of sense, thank you for this!
> > >
> > > A possibly related project is to "defer" output of diagnostics until we
> > > know
> > > the stmt/expression we emit it for survived dead code elimination. Here
> > > there's
> > > the question what to key the diagnostic off and how to move it (that is,
> > > detect
> > > if the code causing it really fully went dead).
Interesting. Which diagnostics would you have in mind to defer in this way?
> >
> > Another (maybe only remotely related) aspect of this project might
> > be getting #pragma GCC diagnostic to work reliably with middle-end
> > warnings emitted for inlined code. That it doesn't work is one of
> > the frustrations for users who run into false positives with "late"
> > warnings like -Wstringop-overflow or -Wformat-overflow.
Thank you Martin for bringing this up!
>
> A similar issue is they are not carried along from compile-time to
> LTO link time. I'm not even sure how they are attached to anything
> right now ... certainly not in DECL_FUNCTION_SPECIFIC_OPTIMIZATION.
This is good to know too.
I know that there is only a week left to submit a proposal, but I am
thinking of a project proposal that can be summarized in one line as
"Improving the diagnostics infrastructure of GCC," which combines the
original proposal about a finer-grained
TREE_NO_WARNING/gimple_no_warning mechanism along with Richard's and
Martin's ideas of preserving diagnostic pragmas after inlining and for
LTO link time, and maybe Richard's idea of being able to defer
diagnostics until we know for sure that the code in question survives
DCE. Would such a proposal be well-defined and tractable enough for
GSoC? If so, would anyone volunteer to be a mentor for this project?
Regards,
Patrick
>
> > I'm sure there are bugs that track this but here's a test case
> > involving -Warray-bounds:
> >
> >int a[3];
> >
> >int f (int i)
> >{
> > return a[i];
> >}
> >
> >#pragma GCC diagnostic push
> >#pragma GCC diagnostic ignored "-Warray-bounds"
> >int g (void)
> >{
> > return f (7); // expect no -Warray-bounds
> >}
> >#pragma GCC diagnostic pop
> >
> >int h (void)
> >{
> > return f (7); // expect -Warray-bounds
> >}
> >
> > Martin
Re: GSoC Project Ideas
On Sun, Mar 3, 2019 at 5:16 PM Jeff Law wrote: > > On 3/3/19 4:06 PM, Patrick Palka wrote: > > Hi everyone, > > > > I am very interested in working on GCC as part of GSoC this year. A few > > years > > ago I was a somewhat active code contributor[1] and unfortunately my > > contributing waned once I went back to school, but I'm excited to > > potentially > > have the opportunity to work on GCC again this summer. My contributions > > were > > mainly to the C++ frontend and to the middle end, and I've been thinking > > about > > potential projects in these areas of the compiler. Here are some project > > ideas > > related to parts of the compiler that I've worked on in the past: > > > > * Extend VRP to track unions of intervals > > (inspired by comment #2 of PR72443 [2]) > > Value ranges tracked by VRP currently are represented as an interval > > or > > its complement: [a,b] and ~[a,b]. A natural extension of this is > > to support unions of intervals, e.g. [a,b]U[c,d]. Such an extension > > would make VRP more powerful and at the same time would subsume > > anti-ranges, potentially making the code less complex overall. > You should get in contact with Aldy and Andrew. I believe their work > already subsumes everything you've mentioned here. > > > > > > > * Make TREE_NO_WARNING more fine-grained > > (inspired by comment #7 of PR74762 [3]) > > TREE_NO_WARNING is currently used as a catch-all marker that inhibits > > all > > warnings related to the marked expression. The problem with this is > > that > > if some warning routine sets the flag for its own purpose, > > then that later may inhibit another unrelated warning from firing, > > see for > > example PR74762. Implementing a more fine-grained mechanism for > > inhibiting particular warnings would eliminate such issues. > Might be interesting. You'd probably need to discuss the details further. > > > > > > * Make -Wmaybe-uninitialized more robust > > (Inspired by the recent thread to move -Wmaybe-uninitialized to > > -Wextra [4]) > > Right now the pass generates too many false-positives, and hopefully > > that > > can be fixed somewhat. > > I think a distinction could be made between the following two > > scenarios in > > which a false-positive warning is emitted: > > 1. the pass incorrectly proves that there exists an execution path > > that > >results in VAR being used uninitialized due to a deficiency in > > the > >implementation, or > > 2. the pass gives up on exhaustively verifying that all execution > > paths > >use VAR initialized (e.g. because there are too many paths to > > check). > >The MAX_NUM_CHAINS, MAX_CHAIN_LEN, etc constants currently > > control > >when this happens. > > I'd guess that a significant fraction of false-positives occur due to > > the > > second case, so maybe it would be worthwhile to allow the user to > > suppress > > warnings of this second type by specifying a warning level argument, > > e.g. > > -Wmaybe-uninitialized=1|2. > > Still, false-positives are generated in the first case too, see e.g. > > PR61112. These can be fixed by improving the pass to understand such > > control flow. > I'd suggest you look at my proposal from 2005 if you want to improve > some of this stuff. > > You might also look at the proposal to distinguish between simple > scalars that are SSA_NAMEs and the addressable/aggregate cases. > > In general I'm not a fan of extending the predicate analysis as-is in > tree-ssa-uninit.c. I'd first like to see it broken into an independent > analysis module. The analysis it does has applications for other > warnings and optimizations. Uninit warnings would just be a client of > hte generic analysis pass. > > I'd love a way to annotate paths (or subpaths, or ssa-names) for cases > where the threaders identify a jump threading path, but don't actually > optimize it (often because it's a cold path or to avoid code bloat > problems). THese unexecutable paths that we leave in the CFG are often > a source of false positives when folks use -O1, -Os and profile directed > optimizations. Bodik has some thoughts in this space, but I haven't > really looked to see how feasible they are in the real world. Hi J
Building GCC with -Wmissing-declarations and addressing its warnings
Hi everyone, I noticed that the GCC build process currently only uses the -Wmissing-prototypes flag, and not the -Wmissing-declarations flag. It seems that the former flag only works on C source files, which means that GCC's source files no longer benefit from this flag as they are now C++ files. The right flag to use, in this case, is -Wmissing-declarations, which works on both C and C++ source files. I decided to build GCC with this flag to see what kinds of warnings popped up, and to use these warnings to clean up the GCC source. I sifted through all the new warnings generated by -Wmissing-declarations during the build process and fixed the ones whose fixes were obvious. Most of my fixes are on global (non-debug) functions that are only referenced in the compilation unit in which they are defined. To fix these functions and to silence their warnings I have simply gave them static linkage. The rest of the fixes are on global function definitions whose declaration exists in a header file that was not included by the source file. To fix up these functions I simply included the relevant header file. The -Wmissing-declarations warnings that I did _not_ address are those emitted from the autogenerated gengtype header files, because their fixes are not trivial to me. They look like: In file included from ../../gcc/gcc/c/c-parser.c:14162:0: ./gt-c-c-parser.h: In function 'void gt_ggc_mx(c_token&)': ./gt-c-c-parser.h:50:1: warning: no previous declaration for 'void gt_ggc_mx(c_token&)' [-Wmissing-declarations] gt_ggc_mx (struct c_token& x_r ATTRIBUTE_UNUSED) I have also not addressed some of such warnings in predict.c and config/i386/i386.c because their fixes are not trivial to me either. Furthermore, I was not able to mark "static" any function that was used as a template argument to hash_table::traverse() because it seems that C++98 requires template argument pointers to have external linkage. (The C++11 standard relaxes this restriction, it seems.) The file var-tracking.c has many of such functions. Since I do not yet have a copyright assignment filed for GCC, I have omitted an actual code patch and instead provide you with a changelog that could be used to reconstruct the patch 100% if anyone is so inclined. Once my copyright assignment is filed, I will properly submit this patch if it is not yet done so by somebody else. On a related note, would a patch to officially enable -Wmissing-declarations in the build process be well regarded? Since -Wmissing-prototypes is currently enabled, I assume it is the intention of the GCC devs to address these warnings, and that during the transition from a C to C++ bootstrap compiler a small oversight was made (that -Wmissing-prototypes is a no-op against C++ source files). If the answer to the previous question is "yes" then how would one go about addressing the above gengtype-related warnings, if at all? Thanks for your time, Patrick * asan.c (asan_mem_ref_get_end): Make static. * calls.c: Include calls.h. * cfgexpand.c: Include cfgexpand.h. * cfgloop.c: Include tree-ssa-loop-niter.h. * cfgraphunit.c (decide_is_symbol_needed): Make static. * config/i386/i386.c (make_pass_insert_vzeroupper): Likewise. (ix86_avx_emit_vzeroupper): Likewise. * dwarf2out.c (init_addr_table_entry): Likewise. * gimple-builder.c: Include gimple-builder.h. * gimple-ssa-isolate-paths.c (isolate_path): Make static. * graphite.c (graphite_transform_loops): Likewise. * internal-fn.c (ubsan_expand_si_overflow_addsub_check): Make static. (ubsan_expand_si_overflow_neg_check): Likewise. (ubsan_expand_si_overflow_mul_check): Likewise. * ipa-devirt.c (hash_type_name): Likewise. (likely_target_p): Likewise. * ipa-inline-analysis.c (simple_edge_hints): Likewise. * ipa-profile.c (cmp_counts): Likewise. (contains_hot_call_p): Likewise. * ipa-prop.c (ipa_alloc_node_params): Likewise. (write_agg_replacement_chain): Likewise. * ipa.c (can_replace_by_local_alias): Likewise. * lto-streamer-out.c (output_symbol_p): Likewise. * omp-low.c (simd_clone_vector_of_formal_parm_types): Likewise. * print-tree.c: Include print-tree.h. * stmt.c: Include stmt.h. * stringpool.c: Include stringpool.h. * tree-cfg-cleanup.c: Include tree-cfg-cleanup.h. * tree-inline.c (redirect_all_calls): Make static. (freqs_to_count): Likewise. * tree-nested.c: Include tree-nested.h. * tree-predcom.c (tree_predictive_commoning): Make static. * tree-sra.c (ipa_sra_modify_function_body): Likewise. * tree-ssa-loop-im.c (movement_possibility): Likewise. (tree_ssa_lim): Likewise. * tree-ssa-loop-ivcanon.c (canonicalize_induction_variables): Likewise. (tree_unroll_loops_completely): Likewise. * tree-ssa-loop-prefet
Re: Building GCC with -Wmissing-declarations and addressing its warnings
On Thu, Feb 20, 2014 at 2:16 AM, Jonathan Wakely wrote: > On 13 February 2014 20:47, Patrick Palka wrote: >> On a related note, would a patch to officially enable >> -Wmissing-declarations in the build process be well regarded? > > What would be the advantage? A missing declaration for an extern function definition likely means that the function should be marked static instead, so enabling the flag would help detect whether a function should otherwise be given static linkage. Isn't this especially important in libstdc++, where accidentally exposing an internal symbol in the library's ABI means having to keep the symbol around until the next ABI bump? > >> Since >> -Wmissing-prototypes is currently enabled, I assume it is the >> intention of the GCC devs to address these warnings, and that during >> the transition from a C to C++ bootstrap compiler a small oversight >> was made (that -Wmissing-prototypes is a no-op against C++ source >> files). > > The additional safety provided by -Wmissing-prototypes is already > guaranteed for C++. > > In C a missing prototype causes the compiler to guess, probably > incorrectly, how to call the function. > > In C++ a function cannot be called without a previous declaration and > the linker will notice if you declare a function with one signature > and define it differently. Good point.. -Wmissing-declarations does not provide additional safety to C++. Really the only benefit to the flag is the static thing mentioned above.
Re: Building GCC with -Wmissing-declarations and addressing its warnings
On Thu, Feb 20, 2014 at 7:42 AM, Jonathan Wakely wrote:
> On 20 February 2014 10:02, Patrick Palka wrote:
>> On Thu, Feb 20, 2014 at 2:16 AM, Jonathan Wakely
>> wrote:
>>> On 13 February 2014 20:47, Patrick Palka wrote:
>>>> On a related note, would a patch to officially enable
>>>> -Wmissing-declarations in the build process be well regarded?
>>>
>>> What would be the advantage?
>>
>> A missing declaration for an extern function definition likely means
>> that the function should be marked static instead, so enabling the
>> flag would help detect whether a function should otherwise be given
>> static linkage. Isn't this especially important in libstdc++, where
>> accidentally exposing an internal symbol in the library's ABI means
>> having to keep the symbol around until the next ABI bump?
>
> It's not really an issue for libstdc++. All symbols are internal by
> default and we only export specifically chosen symbols. If a new
> symbol accidentally matches an existing pattern in the linker script
> then it will be noticed by the testsuite ('make check-abi' in the
> $objdir/$target/libstdc++-v3 dir) and we will make the pattern more
> specific.
Ah, ok, that makes sense.
>
> Making some functions static might be worthwhile, but for the other
> ones referred to in this quote from your first email:
>
>> The rest of the
>> fixes are on global function definitions whose declaration exists in a
>> header file that was not included by the source file. To fix up these
>> functions I simply included the relevant header file.
>
> The only advantage of this change is that if the definition is changed
> without also changing the header then you might get a failure during
> compilation rather than linking, but even that isn't guaranteed as the
> new definition could be interpreted as an overload rather than an
> incompatible declaration.
Wouldn't the overload require a separate declaration, which would be
missing, and thus the compiler would still emit the warning?
>
> Otherwise, including the header isn't *wrong* but it doesn't really
> gain much, except silencing a warning, and that warning is only
> emitted because you turned it on :-) And as you also said, some files
> can't easily be fixed to avoid the warning. IMHO the simplest way to
> solve the problem is not turn the warnings on!
For what it's worth, I have fixed the files that I originally regarded
as not easily fixable. They were pretty easy to fix after a little
bit of thought.
>
> Maybe others will disagree and will think enabling
> -Wmissing-declarations would be a useful change, but I don't see the
> point.
In my novice opinion, I think the flag helps keep source files tidy
and modular, and their interfaces well-defined. Its biggest benefit
is having the compiler inform you when a function should have been
marked static: marking a function static facilitates better
optimization and static analysis, and it helps convey the intent of
the function to the reader. (I counted nearly 100 (non-debug)
functions that could be made static in gcc, and 4 in libstdc++, by the
way.)
Re: Building GCC with -Wmissing-declarations and addressing its warnings
On Thu, Feb 20, 2014 at 1:14 PM, Jonathan Wakely wrote: > On 20 February 2014 15:31, Patrick Palka wrote: >> (I counted nearly 100 (non-debug) >> functions that could be made static in gcc, and 4 in libstdc++, by the >> way.) > > Which were the four in libstdc++? > > I only see __gslice_on_index and __concat_size_t. Those two along with _Rb_tree_rotate_left and _Rb_tree_rotate_right.
Re: [GSoC][C++: Compiler Built-in Traits]: Example Impls & Small Patches
Hi Ken, On Mon, Feb 27, 2023 at 5:02 PM Ken Matsui via Gcc wrote: > > Hi, > > My name is Ken Matsui. I am highly interested in contributing to the > project idea, "C++: Implement compiler built-in traits for the > standard library traits." To understand how to implement those traits, > could you please give me some example implementations of the compiler > built-in traits, as well as some recommended traits to get started > with making small patches? Awesome, thanks for your interest in this project, and welcome! Most of the existing built-in traits are tabulated in gcc/cp/cp-trait.def, and their logic is defined in finish_trait_type or finish_trait_expr in gcc/cp/semantics.cc[2], and then the traits are conditionally used in the standard type trait definitions in libstdc++, e.g. std::remove_cv[3]. Take a look at the following commits that define (and add tests for) the built-in traits __remove_cv, __remove_reference and __remove_cvref and subsequently use them in libstdc++. Note that this first commit predates the new gcc/cp/cp-trait.def file which streamlined much of the boilerplate of adding a new built-in trait. In the new approach (that you would be using), only the semantics.cc change (which defines their logic) would be needed, alongside additions to cp-trait.def to declare each trait. https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=9ca147154074a0de548138b4e73477e94903a855 https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=6ddbbbffbb5759a6c1d56c191364a6bd021f733e To get started, I'd recommend implementing bulit-in traits for std::remove_pointer, std::add_pointer and std::is_reference[4]. Let me know if you have any questions :) [1]: https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/cp/cp-trait.def [2]: https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/cp/semantics.cc;h=79b7cc72f212cef780a3eea65af2b883bb4ec3c8;hb=HEAD#l12102 [3]: https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libstdc%2B%2B-v3/include/std/type_traits;h=2bd607a8b8ff52aba6fd205ab1af2bc4b92f78d0;hb=HEAD#l1539 [4]: As specified in https://en.cppreference.com/w/cpp/header/type_traits > > Also, I would appreciate receiving the contact information for the > project mentor, Patrick Palka. > > Sincerely, > Ken Matsui
Re: GSOC 2023 Contribution Request
Hi Kritika, On Wed, Feb 22, 2023 at 6:49 AM Kritika Rag via Gcc wrote: > > Hello Everyone! > > I’m Kritika Rag, a Computer Science pre-final year undergraduate > student from India. I’m quite passionate about web development and > competitive programming and now I’m looking forward to contributing to > open-source projects. I believe that GSOC 2023 would provide me with > the best way to start my open-source contribution journey. Since I’m a > competitive programmer, I have excellent command over Data Structures > & Algorithms and my primary language is C++, so C++ and GCC are > something that I use daily, therefore I would love to make my > contributions to GCC projects. I sincerely hope that this community > will provide me with the opportunity to do so and to work alongside > them. Great, thanks for your interest in contributing to GCC, and welcome! > > > I’m proficient in various coding languages like C/C++, HTML, CSS, > JavaScript, React, and Python, and have experimented with Git, Linux, > APIs, etc. I have also been fortunate enough to secure 3 internships, > 2 as a DSA problem setter and 1 as a research intern. I have also > participated in a few open-source programs like Hack October Fest 2022 > and GWoC 2022 and contributed to web development and data science > projects. > > I had been checking up on recent project proposals listed in GCC wiki > for the past 3 weeks and was interested in working either on the > project which aims to improve the utility routine library used by GCC > or related to Bug Patrol especially analyzing failing test cases (this > was present over the site a while ago but now I can't see it anywhere) > so I just wanted to ask can I choose it as my GSoC 2023 project? If > yes can anyone guide me to whom to connect to discuss it? > > And if I can't work on the above ideas then I have also gone through > the selected project ideas and want to work on the project "Implement > comp built-in traits for the standard library traits" so would be > grateful if anyone could guide me here also. I can't speak about the other projects, but I'm listed as the mentor for the built-in C++ trait project idea. On the frontend side most of the existing built-in traits are tabulated in gcc/cp/cp-trait.def, and their logic is defined in finish_trait_type or finish_trait_expr in gcc/cp/semantics.cc[2], and on library side the traits are conditionally used in the standard type trait definitions in libstdc++, e.g. std::remove_cv[3]. Take a look at the following commits that define (and add tests for) the built-in traits __remove_cv, __remove_reference and __remove_cvref and subsequently use them in libstdc++. Note that this first commit predates the new gcc/cp/cp-trait.def file which streamlined much of the boilerplate of adding a new built-in trait. In the new approach (that you would be using), only the semantics.cc change (which defines their logic) would be needed, alongside additions to cp-trait.def to declare each trait. https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=9ca147154074a0de548138b4e73477e94903a855 https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=6ddbbbffbb5759a6c1d56c191364a6bd021f733e If you haven't already I'd recommend going through the GCC for new contributors guide https://gcc-newbies-guide.readthedocs.io/en/latest/index.html which goes through checking out, building and debugging GCC. Let me know if you have any questions :) [1]: https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/cp/cp-trait.def [2]: https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/cp/semantics.cc;h=79b7cc72f212cef780a3eea65af2b883bb4ec3c8;hb=HEAD#l12102 [3]: https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libstdc%2B%2B-v3/include/std/type_traits;h=2bd607a8b8ff52aba6fd205ab1af2bc4b92f78d0;hb=HEAD#l1539 > > Thank you so much and I hope to hear from you soon. >
