ot;"
| #define PACKAGE_URL "http://www.gnu.org/software/libgcc/";
| /* end confdefs.h. */
|
| int
| main ()
| {
|
| ;
| return 0;
| }
configure:3693: error: in
`/run/media/void/minnow/build/gcc-6.3.0/x86_64-lfs-linux-gnu/libgcc':
configure:3695: error: cannot compute suffix of object files: cannot compile
See `config.log' for more details.
Marek
files: cannot compile
See `config.log' for more details.
make[1]: *** [Makefile:12068: configure-target-libgcc] Error 1
make: *** [Makefile:880: all] Error 2
If gcc is able to recognize between sources in one dir and objects in
another dir
Does a patch exist to fix this?
thanks,
Marek
critical. Check for the last error entry in the file.
I wonder where to find stdc-predef.h or whether it's generated by gcc
during compile time.
I'm also compiling against musl.
Marek
On Tue, Nov 28, 2017 at 12:19 AM, Jonathan Wakely wrote:
> N.B. the gcc@gcc.gnu.org mailing lis
ror: unrecognized command line option '-qversion'; did you mean
'--version'?
g++: fatal error: no input files
compilation terminated.
On Fri, Dec 1, 2017 at 11:23 AM, Kai Ruottu wrote:
> Kai Ruottu kirjoitti 1.12.2017 klo 12:02:
>>
>> Marek kirjoitti 1.12.201
the AVR anyway, because
return address is stored on the stack in the wrong byte order -
big endian, even though the AVR is little endian. Anything else?
Thanks,
Marek
moved to the low 64K words somehow).
Marek
piler, perhaps indirect_jump is needed for some other language?
Thanks,
Marek
:
ldi r30,pm_lo8(label)
ldi r31,pm_hi8(label)
/* ... */
ijmp; PC <- 0:r31:r30
Note that this adds two jumps around the label, so we only want to
do it infrequently - if the address of the label is loaded into
a register (not if the only users of the label are direct jumps).
Thanks,
Marek
ure how to do this in GCC. Any suggestions?
(The problem can be seen by adding something like "if (dest > 2) goto l3;"
above the goto in the original example: in the assembler output, there is
only one label corresponding to l3 which is both 1. referenced with pm()
and 2. target of a branch for which .text_low would be out of range.)
Marek
label)
and the linker can do the rest of the magic (add jumps in a section
below 64K words if the label is above).
Cc: to Denis, as I may need help actually implementing these changes
(you know binutils internals much better than I do).
Thanks,
Marek
Hello
I appreciate your work and do not want to bother you, but I hope, that
somebody will send me some helpful answer on my question. Is anyone can send
me his 'specs' file (contains configuration for working compiler) ??
(this is standard localization:
" /usr/lib/gcc-lib/name_of_compiler/lib/
I as sorry I repeat my appeal, but if really nobody works on Sparc or PowerPC
processors and nobody wants to send me 'specs' file from directory >
" /usr/lib/gcc-lib/name_of_compiler/lib/version/specs " or similar ???
One more time, thank you for help!
--
> > this create needless friction for folk working in both communities.
>
> +1 for "component: Summary [PRn]" FWIW.
>
> PR bz-component/n works well for C++. The problem is that so many
> other PRs come under tree-optimization and rtl-optimization, which
> eat up a lot of subject line characters without narrowing things down
> very much. "cselib: ... [PRn]" is both shorter and more descriptive
> than "PR rtl-optimization/n - ", etc.
Yeah, the cselib version definitely looks preferable to me.
What if a patch touches more than just the C++ FE, do we want "c,c++:"?
Though kernel uses
net: sched: act_ctinfo: fix memory leak
locking/rwsem: Fix kernel crash when spinning on RWSEM_OWNER_UNKNOWN
If a patch touches various spots in the optimizers, maybe we can
just go with "tree-opt:" or "rtl:"?
Further, I suppose multiple PRs fixed by a single patch would look like:
c++: Implement DR 666 [PR57, PR12345]
Marek
using and
> modifying in the same expression triggered?
This should be defined in C++17, with P0145 in particular:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0145r3.pdf
which says that the expression that names the function is sequenced before every
argument expression and every default argument.
Marek
clutter. If no
> one comments, I'll start enforcing that in patch reviews. Currently no one
> seems sure and everything is getting totally inconsistent.
FWIW, I also like the last version best.
Marek
ror: ‘b’ undeclared here (not in a function)
> int y = b;
> ^
>
> $
Started with r229884: Reimplement diagnostic_show_locus, introducing
rich_location classes. I think it is a bug and should be fixed.
Marek
FE does not. The reason for this is
probably to keep in sync with the C++ printer which doesn't put space before
'*'; in dump_type_prefix we have
741 if (TYPE_PTR_P (t))
742 pp_star (pp);
so there's no pp_cxx_whitespace before '*'.
I like the version with space more; maybe we could change this in the next
stage1.
Marek
sn't seem like a false positive to me, but maybe someone else feels
otherwise.
Marek
On Tue, Feb 16, 2016 at 11:11:21AM +0100, Jakub Jelinek wrote:
> On Tue, Feb 16, 2016 at 11:04:38AM +0100, Marek Polacek wrote:
> > On Tue, Feb 16, 2016 at 10:43:08AM +0100, Stefan Sobernig wrote:
> > > Under a recent gcc 6 [*], we run into -Wnonnull warnings using the
>
> - if (DECL_ALIGN (decl) >= alignment)
> -continue;
> + alignment = get_vec_alignment_for_decl (decl);
>
> - if (vect_can_force_dr_alignment_p (decl, alignment))
> + if (alignment && vect_can_force_dr_alignment_p (decl, alignment))
> {
> - vnode->increase_alignment (TYPE_ALIGN (vectype));
> + vnode->increase_alignment (alignment);
>dump_printf (MSG_NOTE, "Increasing alignment of decl: ");
>dump_generic_expr (MSG_NOTE, TDF_SLIM, decl);
>dump_printf (MSG_NOTE, "\n");
Marek
gt; If there's no strong interest in any of the above we can schedule
> stuf as needed at the Cauldron itself as well.
I'd be interested in all of them.
Marek
ent test results. Has anyone noticed this or am I missing
> something?
I'm seeing those too and it's very bothering. I think Andi Kleen
had some patches to fix these, but seems it needs to be fixed more.
Marek
ound this?
>
> Did you try -fpermissive ? Because that seems like it was listed ...
-fpermissive ought to help, but really best would be to use NULL instead
of '\0'...
Marek
I think you can learn a lot if you follow the Changes pages, so e.g.
<https://gcc.gnu.org/gcc-6/changes.html>, and go back down the history until
you reach the ancient <https://gcc.gnu.org/gcc-3.1/changes.html>.
Marek
> > +
>
> Why do we not want: -fmemory-model=safe? And should we not at the very
> least also disable packed-store-data-races?
Note that the option does not exist, even though it is mentioned in the
documentation.
Marek
ll go away if/when we fix:
https://gcc.gnu.org/ml/gcc-patches/2014-06/msg01624.html
But I'm only guessing.
Marek
e can
start adding new features there. Gerald?
Marek
;t call libubsan
routines at all.
Marek
preference too.
FWIW, me too. This way we'll get in a few years to 10.0 that was also
suggested.
So please, can we finally settle on something? :)
Marek
> only.
>
> So if we change to 5.1 (please not .0) then let's switch the default
> optimization level to -O2! _That's_ a user-visible change across
> the board.
I'm planning to move the default C standard from gnu90 to gnu11
(Currently it's blocked on the -Wc90-c99-compat warning).
That's a pretty big user-visible change as well, I suppose.
Marek
efault" options, and I
> cannot use -Werror because that would break other tests in the
> file.
For C, I recently added the -Wint-conversion option, so with recent
enough GCC you should be able to use -Werror=int-conversion.
Marek
this line
> https://sourceforge.net/p/open-axiom/code/HEAD/tree/trunk/src/include/storage.H#l273
Please provide a preprocessed source and file a bug.
https://gcc.gnu.org/bugs/
Marek
rrays do not decay to pointers, slightly different rules for
compatible types (?) might come in game as well.
In turn, you can use all C99 and C11 features even with -pedantic.
Comments?
Regtested/bootstrapped on powerpc64-linux and x86_64-linux.
2014-10-07 Marek Polacek
* doc/invoke.t
f course, C++ packages should be out of the picture here.
Marek
feel that
especially the inline semantics change should be addressed therein.
Marek
On Thu, Oct 09, 2014 at 02:34:51PM -0700, Mike Stump wrote:
> On Oct 7, 2014, at 2:07 PM, Marek Polacek wrote:
> > I'd like to kick off a discussion about moving the default standard
> > for C from gnu89 to gnu11.
>
> I endorse the change of default.
Thanks for chimi
On Tue, Oct 07, 2014 at 11:07:56PM +0200, Marek Polacek wrote:
> I'd like to kick off a discussion about moving the default standard
> for C from gnu89 to gnu11.
The consensus seems to be to go forward with this change. I will
commit the patch in 24 hours unless I hear objectio
On Tue, Oct 14, 2014 at 09:23:29AM +0200, Marek Polacek wrote:
> The consensus seems to be to go forward with this change. I will
> commit the patch in 24 hours unless I hear objections.
I made the change. Please report any fallout to me.
Enjoy.
Marek
> tonight or tomorrow.
Please don't force yourself into doing that, it's more up to me to fix
my fallout ;). Feel free to send me the partial patch and I will finish
it tomorrow mornings (reproducing is easy with --target_board=unix/-m32).
In any case, thanks.
Marek
target/i386/stackalign/return-2.c -mstackrealign (test for
> excess errors)
> FAIL: gcc.target/i386/vectorize4.c (test for excess errors)
Sorry about these, should be fixed now.
Marek
On Fri, Oct 17, 2014 at 09:55:28AM +0200, Krzesimir Nowak wrote:
> I was asking, because, in the beginning at least, somebody will have
> to commit the patch to trunk for me. I don't know if svn understands
> git patches.
No worries about that, we'll just apply the patch manually.
Marek
that because you
don't have a copyright assignment with FSF.
Marek
mments or
> objections?
Sounds good to me.
Marek
I feel the same way. More to type, worse readability, a lot
more of line-wrapping.
Sorry,
Marek
un with >-O2 and -Os.
> I wish we had some test to check that sanitizer optimizations are indeed
> conservative.
I think most of the tests we have are tested with various optimization
levels.
Marek
On Wed, Nov 12, 2014 at 01:04:58PM +0300, Marat Zakirov wrote:
>
> On 11/12/2014 11:45 AM, Marek Polacek wrote:
> >Yes, but as said above, VRP is only run with >-O2 and -Os.
> You meant >= -O2?
Yes.
Marek
eprocessed source if appropriate.
> See for instructions.
> Preprocessed source stored into /tmp/cc2RJY0y.out file, please attach this to
> your bugreport.
(If you need to create a BZ account, please mail overseers and I'll
take care of that.)
Thanks,
Marek
or a very long time (gcc 3.x at least)
I haven't read that in detail yet, but my patch just allowed the
initializing even for gnu99/gnu11 (formerly, it was only allowed in the
gnu89 mode).
Marek
Right: -fsanitize=nonnull-attribute is a GCC 5 only thing.
Marek
On Mon, Jan 12, 2015 at 10:23:16PM -0700, Jeff Law wrote:
> I'm pleased to announce that Marek Polacek has been appointed as a reviewer
> for the C front-end.
Thanks!
> Marek, please add yourself as a reviewer for the C front end in the
> MAINTAINERS file.
2015-01-
in Change Columns at
the bottom of the page.
Marek
27;static' which makes 'x' a proper array in the callee, e.g.
I think even the 'static in parameter array declarators' (ugly) C99 extension
isn't properly implemented yet (I don't think that the compiler makes
any optimization based on it).
So - if I understood this correctly - I think it's better to enhance
ubsan than to add any kind of language extensions.
Marek
t to do with the UBs on the library side - those 7.* ones.
> Does adding new forms of sanitization require upstream libsanitizer
> changes as well or can arbitrary ubsan checks be added without needing
> libsanitizer changes?
I think we also need libubsan changes. But it is usually just about
printing an error message along with some values - nothing terribly
complex.
Marek
the default is
gnu11. See https://gcc.gnu.org/gcc-5/porting_to.html for more info.
Marek
gned bOriginator;
> };
> } USB_WORD;
>
> is that expected behaviour ?
Yes.
Marek
fault (obviously... ;)).
Marek
On Fri, May 29, 2015 at 01:16:32PM +0530, Pritam Gharat wrote:
> How do we identify whether a function is a pure or a const function?
> Is there any flag associated with its cgraph_node or the tree node
> (decl of cgraph_node)?
You'll want to look into ipa-pure-const.c.
Marek
implement this (in libcpp + gcc/testsuite
> only so far).
> It needs to be parsed and handled in the C++ FE obviously, which is missing.
Thanks.
Tim, have you had any success with this, or should I (or somebody else) feel
free to take it over?
Marek
rning would
> just get removed by the standard unreachable code elimination optimization.
>
> This would allow us to avoid false positives due to the IL not being
> well enough optimized at the point where we discover something is
> potentially amiss.
FYI, I also raised the idea of delayed warnings in the C FE some time ago:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68193#c3
Marek
7;t this be Ignored?
Also, https://gcc.gnu.org/gcc-10/changes.html should be updated, both in
Caveats and the C++ section. But I can do that.
Marek
x/pr33930.C: Add dg-error.
* g++.dg/cpp0x/ref-bind1.C: New test.
* g++.dg/cpp0x/ref-bind2.C: New test.
* g++.dg/cpp0x/ref-bind3.C: New test.
* g++.old-deja/g++.pt/spec35.C: Remove dg-error.
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@276058
138bc75d-0d04-0410-961f-82ee72b054a4
Please open a bug.
Marek
t in gcc 10 ? Or gcc 11 ? However I fear doing that may break
> some tests in the testsuite, I hope not too many.
I plan to propose a switch to -std=gnu++17 in GCC 11. I think it's way
too late for GCC 10.
Dealing with the testsuite fallout, and rebuilding Fedora packages is
of course part o
On Fri, Nov 01, 2019 at 09:31:07AM -0600, Jeff Law wrote:
> On 11/1/19 9:08 AM, Marek Polacek wrote:
> > On Fri, Nov 01, 2019 at 04:01:12PM +0100, Romain Geissler wrote:
> >> Le mar. 22 oct. 2019 à 14:53, Richard Biener a écrit :
> >>>
> >>> Please mak
box.
>
> > My mail to the libstdc++ list should have noted that [PATCH] tags in
> > the email subject should be omitted from the summary in the first line
> > of the commit log.
>
> And git format-patch/git am automatically add and remove [PATCH]
> appropriately.
Wrt [PATCH]: if we keep it, do we want to have a system to distinguish
C/C++/... patches? Do we want [C++ PATCH] or [PATCH][C++] or [C++][PATCH],
something else? (I find the latter two a bit ugly.)
Marek
rter (and less meaningful) names.
> Adding line breaks or picking shorter names doesn't help readability.
> So I end up not using the feature.
>
> I'm loosely in favour of relaxing the rule for libstdc++ code. I don't
> really care what the rest of GCC looks like ;-)
Not using such a nice feature just because of formatting sounds really
shameful. Would the compromise of 100 chars make things any better here?
Marek
I disagree, it is a nice feature, without quotes. It's Good Style not to
leak variables into enclosing scopes.
> If you have issues with scoping your functions are WAY too long already.
I don't think that's the case here.
--
Marek Polacek • Red Hat, Inc. • 300 A St, Boston, MA
a,
> even though this is still on a branch? (with me as default assignee)
I think so, we have it for e.g. JIT already, and it's probably just a matter
of time before the analyzer is merged.
--
Marek Polacek • Red Hat, Inc. • 300 A St, Boston, MA
7;,': case '/': case '\n': \
> case '\t': case '\r': case ';'
>
> /* This macro assumes that we're operating on a variable. */
>
> Indeed before applying this patch, someone will have to check that the
> warnings do not occur because of missing breaks.
>
> Note that putting /* Fall through. */ before the use of the macro
> CASE_SEPARATORS does not work. Is it a (known) bug?
Yes, it's known that the "falls through" comments don't work if they're
preceding a macro.
Marek
fixed it if I'd hit it.
The warning had been discussed extensively on the ML, and you had the chance to
chime in, too. There's a reason why the warning is only enabled by -Wextra and
not by -Wall.
> But that's okay. I now understand that it is acceptable for
> a developer to commit a change that causes issues for other
> developers, and said developer can turn a blind eye.
Nonsense.
Marek
On Mon, Mar 27, 2017 at 07:33:05PM +0200, Toon Moene wrote:
> On 03/27/2017 06:45 PM, Marek Polacek wrote:
>
> > On Mon, Mar 27, 2017 at 09:27:34AM -0700, Steve Kargl wrote:
>
> > > But that's okay. I now understand that it is acceptable for
> > > a de
On Mon, Mar 27, 2017 at 07:59:01PM +0200, Thomas Koenig wrote:
> Am 27.03.2017 um 19:41 schrieb Marek Polacek:
>
> > Of course "the person" had bootstrapped and tested all the languages before
> > adding the warning. If only any of you bothered to check the fortr
On Mon, Mar 27, 2017 at 11:16:32AM -0700, Steve Kargl wrote:
> On Mon, Mar 27, 2017 at 07:41:12PM +0200, Marek Polacek wrote:
> > On Mon, Mar 27, 2017 at 07:33:05PM +0200, Toon Moene wrote:
> > > On 03/27/2017 06:45 PM, Marek Polacek wrote:
> > >
> > > > O
ement requests for this in Bugzilla, because some
> compilers are already more catholic in what they accept in constant
> expressions (notably, Clang).
Right, at least:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69960
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66618
Marek
gt; or check-acats to cope with being run in parallel (i.e., will they ever see
> > GCC_RUNTEST_PARALLELIZE_DIR set?)
>
> I don't usually build Ada, but testing with "make -j check" works for me
> where is the parallelism I want
I have
export MAKEFLAGS='-j4'
in my environment.
Marek
r -j loads, but it's unclear if it's enough
> to address the problems with higher loads like you're using.
I'm still seeing spurious tree-prof failures there (with -j48).
Marek
On Thu, May 18, 2017 at 05:22:50PM -0600, Martin Sebor wrote:
> On 05/17/2017 11:19 PM, Andi Kleen wrote:
> > Marek Polacek writes:
> >
> > > On Wed, May 17, 2017 at 09:13:40AM -0600, Jeff Law wrote:
> > > > On 05/17/2017 04:23 AM, Aldy
t to be on the
> > operator token, and for the start/finish to range from the start of the
> > lhs to the end of the rhs i.e. what we see for:
> >
> > ret = 999;
> > ^
>
> Yep, MODIFY_EXPRs created in FE go this way and it's fine.
>
> >
> >
> >> for return statements only a returned value is displayed.
> >
> > Is this running on SSA form? If so, I wonder if you're running into
> > something like this:
> >
> > retval_N = PHI ;
> > return retval_N;
> >
> > where it's using the location of that "return retval_N;" for all of the
> > return statements in the function, rather than the individual source
> > locations.
>
> Yep, but we properly assign each assignment to a SSA name that's going to
> be merged in exit BB by PHI node:
>
> _8 = ret_2;
> /tmp/m2.c:7:8: note: output_location
> return ret; }
> ^~~
>
> Here the location comes from c_finish_return function where location
> comes from a value that's returned.
>
> >
> >> For conditions, only condition beginning is showed.
> >> Is this known behavior or do I miss
> >> something?
> >
> > c_parser_if_statement has:
> >
> > loc = c_parser_peek_token (parser)->location;
> >
> > which is that of the open-paren. Maybe we should build a location
> > covering the range of the "if ( expression )" part of the if-statement?
>
> Adding Marek as C FE maintainer to reply the question.
I suppose we could do better and I'd probably highlight just the expression
part of "if ( expression )". But not sure how many use cases this range
location would have.
Marek
ng long unsigned int'\[^\n\r]*(\n|\r\n|\r)" } */
/* { dg-output "\[^\n\r]*value \[0-9.e+-]* is outside the range of
representable values of type '__int128'\[^\n\r]*(\n|\r\n|\r)" { target { int128
} } } */
-/* { dg-output "\[^\n\r]*value -1 is outside the range of representable values
of type '__int128 unsigned'\[^\n\r]*(\n|\r\n|\r)" { target { int128 } } } */
+/* { dg-output "\[^\n\r]*value -1 is outside the range of representable values
of type '__int128 unsigned'" { target { int128 } } } */
Marek
On Tue, Jul 11, 2017 at 09:51:19AM -0700, Jonny Grant wrote:
> Hello
> https://gcc.gnu.org/gcc-7/changes.html
>
> snprintf (d, sizeof d, "%#02x", x & 0xff);
>
>^^
> Should be: sizeof(d) ?
Why? Both are correct.
Marek
weren't written to exercise the functions but
> rather the plugin interface). Would adding a plugin for
> this sort of thing be the right way to do it?
Isn't -fself-test the thing you're looking for?
Marek
h gcc-7) has been:
> memcpy(&d_point,
> p,
> sizeof(d_point));
>
> Does this make any sense to anybody?
Not without a stand-alone testcase. See <https://gcc.gnu.org/bugs/>
for more info.
Marek
304-obj/isl'
> make[2]: *** [Makefile:6155: all-stage2-isl] Error 2
> make[2]: Leaving directory '/home/don/src/gcc-8-20180304-obj'
> make[1]: *** [Makefile:25157: stage2-bubble] Error 2
> make[1]: Leaving directory '/home/don/src/gcc-8-20180304-obj'
> make: *** [Makefile:947: all] Error 2
I bet this is https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84670 which is
already
fixed.
Marek
>
> *It seems like a pretty brain damaged interpretation.*
We'd need to see the code but the warning seems legit. What's the problem?
Marek
eeds to be adjusted:
WARN_FLAGS='-Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi'
I guess to -Wabi=11?
Marek
Hello everybody,
On Friday 07 March 2008 Philipp Marek wrote:
> Here you are.
>
>
> code_overlap.pl - disassembles a binary, and outputs a list
> (address, name, instruction, bytes) to STDOUT.
>
> bytes_saved.pl - takes such a list, and tries to estimate
> the amoun
7709&w=2
--
Versioning your /etc, /home or even your whole installation?
Try fsvs (fsvs.tigris.org)!
--
Versioning your /etc, /home or even your whole installation?
Try fsvs (fsvs.tigris.org)!Redundancy Remover
==
(C)opyright 2009 by Ph. Marek, phili
Hello everybody,
I already asked that on gcc-help@ but got no answer, so I'm trying again here.
I'm looking for a way to get inbetween the assembler macro processor and the
assembler.
I'd like to get the assembler sources mostly as-is, but with the macros used
therein already expanded.
I've a
> gcc -S tmp.S for some reason prints to stdout, so gcc -S tmp.S > tmp.s
> is what you need
Thank you very much, I'll take a look.
Regards,
Phil
--
Versioning your /etc, /home or even your whole installation?
Try fsvs (fsvs.tigris.org)!
Philipp Marek marek.priv.at> writes:
> > gcc -S tmp.S for some reason prints to stdout, so gcc -S tmp.S > tmp.s
> > is what you need
> Thank you very much, I'll take a look.
I tried very hard to achieve that; and one time it seemed to work, but I cannot
make it work
downloaded repository and check if our programms if the changes work.
Could you write us what command we should use?
We'd like to emphasize that we don't want to recompile whole gcc on our
computer, we just want to make use of changes we did in the repository.
Thank you very much for a
downloaded repository and check if our programms if the changes work.
Could you write us what command we should use?
We'd like to emphasize that we don't want to recompile whole gcc on our
computer, we just want to make use of changes we did in the repository.
Thank you very much for a
s in the
easiest way?
Thank you very much for your help.
Marek Zuk
Paolo Bonzini wrote:
Could you write us what command we should use?
We'd like to emphasize that we don't want to recompile whole gcc on our
computer, we just want to make use of changes we did in the repository.
`__cxa_throw_bad_array_length'
> collect2: error: ld returned 1 exit status
> make[5]: *** [jv-convert] Error 1
Should be already fixed by Jason.
Marek
source tree.
Marek
ose this applies to ubsan, e.g. (Haven't commited
it to trunk yet, but so far the files still have the '.c'
extension.) Will rename it then, though I like '.c' more ;).
Marek
ke either. In gcc/, we
have 362 .c files and 0 .cc files, so every new .cc file will step out
of line... That might be pain for people who are used to do
'grep foo gcc/*.c' and suchlike.
Marek
On Tue, Jul 30, 2013 at 07:13:22AM -0400, Diego Novillo wrote:
> On Tue, Jul 30, 2013 at 5:04 AM, Marek Polacek wrote:
> > On Mon, Jul 29, 2013 at 10:08:26PM +0200, Martin Jambor wrote:
> >> I do not care very much but I disagree. Having some files with .c
> >> suff
On Tue, Jul 30, 2013 at 08:35:12AM -0400, Andrew MacLeod wrote:
> On 07/30/2013 08:27 AM, Marek Polacek wrote:
> >On Tue, Jul 30, 2013 at 07:13:22AM -0400, Diego Novillo wrote:
> >>On Tue, Jul 30, 2013 at 5:04 AM, Marek Polacek wrote:
> >>>On Mon, Jul 29, 2013 at 1
s, thus e.g.
if (bar ())
goto A;
/* ... */
A: __attribute__((cold))
/* ... */
I don't know whether that might be useful for what you want or not though...
Marek
GuiWindow(void const**)'
> collect2: error: ld returned 1 exit status
> make[2]: *** [src/k3b] Error 1
> make[1]: *** [src/CMakeFiles/k3b_bin.dir/all] Error 2
> make: *** [all] Error 2
It just seems the library containing the definition of
KXmlGuiWindow::KXmlGuiWindow isn't properly linked in.
Marek
1 - 100 of 144 matches
Mail list logo
