hout testing on hardware, either for treewide
changes, or by code inspection. The only notable exceptions I could
find are from Andreas Oetken and Bernd Weiberg at Siemens and
from Marek Vasut (all added to Cc in case they have something to add).
I might still have the 10M50 board, but it wasn'
On 4/18/24 7:53 AM, Thomas Huth wrote:
On 18/04/2024 05.27, Sandra Loosemore wrote:
Tomorrow I plan to push patches to mark the nios2 target as obsolete
in GCC 14.
Background: Intel has EOL'ed the Nios II processor IP and is now
directing their FPGA customers to a RISC-V platform instead.
h
l compiler error: in decl_attributes, at
attribs.cc:776
which crashes with both cc1{,plus}. The problem happens when the attribute
is both in std_attributes and c_common_gnu_attributes, it seems.
Marek
On Wed, Jan 10, 2024 at 04:24:42PM -0500, Jason Merrill wrote:
> On 1/10/24 15:59, Marek Polacek wrote:
> > On Wed, Jan 10, 2024 at 02:58:03PM -0500, Jason Merrill via Gcc wrote:
> > > What formatting style do we want for non-trivial lambdas in GCC sources?
> > > I
in function
> argument lists, e.g.
>
> algorithm ([] (parms)
> {
> return foo;
> });
And what about lambdas in conditions:
if (foo ()
&& [&] (params) mutable
{
return 42;
} ())
should the { go just below [?
Marek
should be
> rejected. The request is for a warning, because for *some* uses of enums
> duplicates are not wanted.
And as I said in the other thread about the very same issue, it's
<https://gcc.gnu.org/PR16186> which is assigned to me and I hope to
implement it for GC 14.
Marek
; generates no warning even with -Wextra. That hit me today, because I
> had a large enum with many explicitly assigned constants and I
> accidentally used the same value twice, which is an obvious source of
> problems.
This is https://gcc.gnu.org/PR16186.
Marek
accept that, I can try to implement that. (That would be my first
> contribution to this project and I do not know gcc codebase, but it
> looks like a relatively simple change.) Do you think that it would need
> a copyright assignment?
I think it would.
Thanks,
Marek
yntax rule or constraint.
IIRC, the only case where the compiler _must_ emit a hard error is for #error.
> Is this interpretation correct?
>
> Sorry if this questions this is more appropriate for the gcc-help list.
>
> Thanks,
> Florian
>
Marek
e parallel “C89isms in the test suite” thread.
>
> I wonder if anything went into the default C2X language mode already
> that could be similarly disruptive as the removal of implicit ints? In
> that case, I should probably backport that change into my GCC test
> version. (To avoid chasing ghosts, it's based off GCC 12, I've decided
> to decouple it from our planned switch to GCC 13.)
>
> Thanks,
> Florian
>
Marek
ly better off using a hash_map; std::unordered_map
has efficiency issues as described in
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p2028r0.pdf
Marek
which seems a buggy error message to me: I wrote "p", not "*p"; also the
> compiler suggests replacing "->" with itself.
Yes, this is https://gcc.gnu.org/PR91134
Marek
On Thu, Mar 17, 2022 at 12:21:36PM -0400, James K. Lowden wrote:
> On Wed, 16 Mar 2022 14:45:33 -0400
> Marek Polacek wrote:
>
> Hi Marek,
>
> > Let's avoid -f-foo; use -ffoo instead, like the rest of GCC.
>
> Sure. I hadn't noticed the distinction
eric", "-march=x86-64", "-auxbase",
> "SG105A", "-f-flex-debug", "-f-yacc-debug", "-o", "/tmp/ccIBQZv1.s"],
> 0x1578290 /* 40 vars */
>
> The stanza in cobol/lang.opt looks similar to others in
> fortran/lang.opt. The gcc internals don't mention anything else that I
> could find that needs to be done. I've done a complete rebuild after
> "make distclean". And still no joy.
doc/options.texi describes options relative well, I think.
> We are working with a gcc fork of 10.2. Our log message says (in part):
>
> The "tiny" branch was started with the 10.2.1
> origin/releases/gcc-10 branch> c806314b32987096d79de21e72dc0cf783e51d57)
>
> What am I missing, please?
>
> --jkl
>
Marek
un, 0))
to replace the previous macro FOR_EACH_LOOP
FOR_EACH_LOOP (loop, 0)
which shows a number of examples like
- loop_p loop;
- FOR_EACH_LOOP_FN (fn, loop, LI_INCLUDE_ROOT)
+ for (auto loop : loops_list (fn, LI_INCLUDE_ROOT))
Marek
t releases/gcc-11.2.0
>
> Can someone tell me how to run the C++ IPA tests? I'm sure there is
> something silly that I'm doing wrong, but can't find out what it is.
There's no ipa.exp in gcc/testsuite/g++.dg/ipa. Instead you probably
want
make check-c++ RUNTESTFLAGS=dg.exp=ipa/*
Marek
gt; > >
> > >
> > > On Tue, 6 Jul 2021, 22:45 Martin Sebor via Gcc, > <mailto:gcc@gcc.gnu.org>
> > > <mailto:gcc@gcc.gnu.org <mailto:gcc@gcc.gnu.org>>> wrote:
> > >
> > > On 7/6/21 3
ined to update refs/heads/master
> To git+ssh://gcc.gnu.org/git/gcc.git
> ! [remote rejected] master -> master (hook declined)
> error: failed to push some refs to
> 'git+ssh://mse...@gcc.gnu.org/git/gcc.git'
>
Marek
e is allocated
> via BITMAP_ALLOC() with a bitmap_obstack variable defined alongside
> the map.
My sense is that this is the problem. What happens if you use
BITMAP_GGC_ALLOC?
Marek
owed that we
> can make changes with GCC’s social organization. If we fail to do so, it
> will continue to be harder and harder to attract new talent to GCC
> development.
I support this and believe we ought to act now.
Marek
nts this might mater?)
See libiberty/pex-common.c.
Marek
not like it
Because CWG 727 isn't implemented yet:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85282
Marek
ing:
That manual is for version 3.2, which is ancient. See
https://gcc.gnu.org/onlinedocs/gcc-10.2.0/gcc/Attribute-Syntax.html#Attribute-Syntax
Marek
it on the website but couldn’t find anything.
You can add Co-authored-by: name to your commit.
If we don't already document it, we should.
Marek
On Tue, May 19, 2020 at 01:03:09PM -0600, Martin Sebor via Gcc wrote:
> I'm having trouble with the commit hook that tries to enforce
> ChangeLog contents. It fails with an error that doesn't make
> sense to me: the file it complains isn't mentioned clearly is
> listed there and I can't tell what
On Fri, May 15, 2020 at 03:12:27PM +0200, Martin Liška wrote:
> On 5/15/20 2:42 PM, Marek Polacek wrote:
> > I actually use mklog -i all the time. But I can work around it if it
> > disappears.
>
> Ah, I can see a consumer.
> There's an updated version that suppo
uthor nor date stamp is used - that all can be get from git
This is good.
> - --inline option is not supported - I don't see a use-case for it now
I actually use mklog -i all the time. But I can work around it if it
disappears.
--
Marek Polacek • Red Hat, Inc. • 300 A St, Boston, MA
On Fri, Mar 13, 2020 at 09:56:58AM -0600, Martin Sebor wrote:
> On 3/13/20 9:50 AM, Marek Polacek wrote:
> > On Fri, Mar 13, 2020 at 09:46:40AM -0600, Martin Sebor via Gcc wrote:
> > > It looks as though commits with bug fixes appear in Bugzilla comments
> > > made
thers so maybe Martin's account got messed
> up in the migration somehow?
The authors of those commits are correct, it's just that the commit-to-Bugzilla
sync is broken at the moment and Martin L. was doing it manually.
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
> > 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
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
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
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
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
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
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
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
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
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
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
eeds to be adjusted:
WARN_FLAGS='-Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi'
I guess to -Wabi=11?
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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 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
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
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
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
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
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
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
> - 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
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
>
sn't seem like a false positive to me, but maybe someone else feels
otherwise.
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
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
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
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
fault (obviously... ;)).
Marek
gned bOriginator;
> };
> } USB_WORD;
>
> is that expected behaviour ?
Yes.
Marek
the default is
gnu11. See https://gcc.gnu.org/gcc-5/porting_to.html for more info.
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
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
in Change Columns at
the bottom of the page.
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-
Right: -fsanitize=nonnull-attribute is a GCC 5 only thing.
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
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
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
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
I feel the same way. More to type, worse readability, a lot
more of line-wrapping.
Sorry,
Marek
mments or
> objections?
Sounds good to me.
Marek
that because you
don't have a copyright assignment with FSF.
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
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
> 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
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
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 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
feel that
especially the inline semantics change should be addressed therein.
Marek
f course, C++ packages should be out of the picture here.
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
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
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
> 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
1 - 100 of 144 matches
Mail list logo
