On 03/14/2015 08:34 AM, Segher Boessenkool wrote:
On Fri, Mar 13, 2015 at 03:54:57PM -0600, Martin Sebor wrote:
Attached is a patch that eliminates the unused stack frame
allocated by gcc 5 with -pg -mprofile-kernel on powepc64le
and brings the code into parity with previous gcc versions
I backported the fix to the 4.9 branch already, so it would be nice to
get the test cases fixes there as well.
Martin -- that's your cue ;-)
Sure. It's on my list of things to do.
Martin
/testsuite/ChangeLog
@@ -1,3 +1,11 @@
+2015-03-05 Martin Sebor mse...@redhat.com
+
+ * PR testsuite/63175
+ * gcc.dg/vect/costmodel/ppc/costmodel-bb-slp-9a.c (main1): Move
+ checking of results into main to prevent it from getting optimized
+ away.
+ * gcc.dg/vect/costmodel/ppc/costmodel-bb-slp-9a
On 03/06/2015 10:28 AM, Jeff Law wrote:
On 03/02/15 09:28, Martin Sebor wrote:
On 03/02/2015 06:58 AM, Richard Biener wrote:
On Fri, 27 Feb 2015, Martin Sebor wrote:
Given that Martin's fix to the testcase allowed it to succeed without
Richi's fix for the underlying problem
(ARGET_KEEP_LEAF_WHEN_PROFILED): Define.
* cc/config/rs6000/rs6000.c (rs6000_keep_leaf_when_profiled). New
function.
2015-03-13 Martin Sebor mse...@redhat.com
PR target/63354
* gcc.target/powerpc/pr63354.c: New test.
diff --git a/gcc/config/rs6000/linux64.h b/gcc/config/rs6000/linux64.h
index 0879e7e..f51e892
The attached patch adds tests to lib/target-supports.exp
to avoid unnecessarily invoking the compiler on non-ARM
targets to check for the support for a number of ARM
vectorization features.
Okay to commit to trunk?
Martin
2015-03-23 Martin Sebor mse...@redhat.com
* lib/target-supports.exp
On 03/02/2015 06:58 AM, Richard Biener wrote:
On Fri, 27 Feb 2015, Martin Sebor wrote:
Given that Martin's fix to the testcase allowed it to succeed without
Richi's fix for the underlying problem, is there a modification to the
testcase or a new testcase that would really test the optimization
On 02/27/2015 07:27 AM, David Edelsohn wrote:
On Tue, Feb 24, 2015 at 2:30 PM, Jeff Law l...@redhat.com wrote:
On 02/23/15 20:38, Martin Sebor wrote:
On 02/22/2015 11:45 AM, David Edelsohn wrote:
Does this patch really fix the problem? The PR notes that the
testcase fails and code quality
On 03/04/2015 09:19 AM, Jeff Law wrote:
On 03/04/15 06:43, Andreas Schwab wrote:
Martin Sebor mse...@redhat.com writes:
The attached patch resolves PR 65286 by adding --disable-multilib
when configuring for a ppc64le target.
If powerpc64le doesn't want multilib it should not set any
On 03/04/2015 10:17 AM, Andreas Schwab wrote:
Martin Sebor mse...@redhat.com writes:
The configure script explicitly adds --enable-multilib unless
--disable-multilib is specified. This then results in libraries
being built with the -m32 option, which fails with errors like
the one below:
/usr
The attached patch resolves PR 65286 by adding --disable-multilib
when configuring for a ppc64le target.
Martin
diff --git a/ChangeLog b/ChangeLog
index bd43281..46ec13d 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,9 @@
+2015-03-03 Martin Sebor mse...@redhat.com
+
+ PR target/65286
--- a/gcc/testsuite/ChangeLog
+++ b/gcc/testsuite/ChangeLog
@@ -1,3 +1,15 @@
+2015-02-27 Martin Sebor mse...@redhat.com
+
+ PR testsuite/63175
+ * gcc.dg/vect/costmodel/ppc/costmodel-bb-slp-9a.c (main1): Rename...
+ (copy_to_unaligned): ...to this and move checking of results
On 02/22/2015 11:45 AM, David Edelsohn wrote:
Does this patch really fix the problem? The PR notes that the
testcase fails and code quality has regressed. Has the code
generation been corrected but the testcase looks for the wrong string?
Presumably the message that basic block was
;
}
Index: ChangeLog
===
--- ChangeLog (revision 220801)
+++ ChangeLog (working copy)
@@ -1,3 +1,11 @@
+2015-02-21 Martin Sebor mse...@redhat.com
+
+ PR target/65109
+ * gcc.target/powerpc/ppc64-abi-1.c: Split test functions
+1,9 @@
+2015-02-21 Martin Sebor mse...@redhat.com
+
+ PR testsuite/63175
+ * gcc.dg/vect/costmodel/ppc/costmodel-bb-slp-9a.c: Correct
+ expected string.
+
2015-02-18 Jakub Jelinek ja...@redhat.com
PR gcov-profile/64634
Index: gcc.dg/vect/costmodel/ppc/costmodel-bb-slp
Forwarding the patch committed as instructed in
http://gcc.gnu.org/svnwrite.html#authenticated.
Martin
commit 7edb4add71279302fbe6e9df4bb1702af8f39c73
Author: Martin Sebor mse...@redhat.com
Date: Thu Feb 26 17:30:46 2015 -0700
Add self to Various Maintainers.
commit
(rs6000_keep_leaf_when_profiled): New
function.
2015-03-24 Martin Sebor mse...@redhat.com
PR target/63354
* gcc.target/powerpc/pr63354.c: New test.
diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
index 31b46ea..f1508b9 100644
--- a/gcc/config/rs6000/rs6000.c
+++ b/gcc/config
/ChangeLog b/gcc/testsuite/ChangeLog
index 884fb62..d781c02 100644
--- a/gcc/testsuite/ChangeLog
+++ b/gcc/testsuite/ChangeLog
@@ -1,3 +1,9 @@
+2015-03-23 Martin Sebor mse...@redhat.com
+
+ PR testsuite/63175
+ * gcc.dg/vect/costmodel/ppc/costmodel-bb-slp-9a-pr63175.c: Scan
On 03/21/2015 01:48 PM, Iain Sandoe wrote:
Hi Martin,
I've applied your latest patch to top of trunk and looked at the code gen on
powerpc-darwin9 (and a cross from x86-64-darwin12 = powerpc64-linux-gnu).
Thanks for the review!
2015-03-13 Anton Blanchard an...@samba.org
PR
-deref-1.c: Ditto.
+
2015-04-18 Martin Sebor mse...@redhat.com
* gfortran.dg/pr32627.f03 (strptr): Change size to match the number
diff --git a/gcc/testsuite/c-c++-common/asan/misalign-1.c b/gcc/testsuite/c-c++-common/asan/misalign-1.c
index f1cca16..833b82a 100644
--- a/gcc/testsuite/c-c++-common
On 04/21/2015 06:39 AM, Peter Bergner wrote:
On Tue, 2015-04-21 at 08:22 +0200, Jakub Jelinek wrote:
-#if defined(__powerpc__) || defined(__powerpc64__)
- // PCs are always 4 byte aligned.
- return pc - 4;
-#elif defined(__sparc__) || defined(__mips__)
- return pc - 8;
The SPARC/MIPS case
--- a/libsanitizer/ChangeLog
+++ b/libsanitizer/ChangeLog
@@ -1,3 +1,15 @@
+2015-04-19 Martin Sebor mse...@redhat.com
+
+ PR sanitizer/65479
+ * libsanitizer/sanitizer_common/sanitizer_stacktrace.h
+ (StackTrace::signaled, StackTrace::min_insn_bytes): New data members
.
Is this okay for trunk? For 5.1?
Martin
diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog
index b4052ef..18eede3 100644
--- a/gcc/testsuite/ChangeLog
+++ b/gcc/testsuite/ChangeLog
@@ -1,3 +1,12 @@
+2015-04-19 Martin Sebor mse...@redhat.com
+
+ PR sanitizer/65479
+ * gcc/testsuite/c
On 04/22/2015 12:36 PM, Marek Polacek wrote:
Currently, we warn if the right operand of a shift expression is negative,
or greater than or equal to the length in bits of the promoted left operand.
But we don't warn when we see a left shift of a negative value. That is
undefined behavior since
On 04/24/2015 10:27 AM, Marek Polacek wrote:
On Thu, Apr 23, 2015 at 09:11:39PM -0600, Martin Sebor wrote:
I wonder if the tests where the left shift operands are both
constants really do invoke undefined behavior in GCC. For
example, AFAICS, in (-1 0) and other constant expressions
gcc
On 04/24/2015 03:31 PM, Martin Sebor wrote:
On 04/24/2015 10:27 AM, Marek Polacek wrote:
On Thu, Apr 23, 2015 at 09:11:39PM -0600, Martin Sebor wrote:
I wonder if the tests where the left shift operands are both
constants really do invoke undefined behavior in GCC. For
example, AFAICS, in (-1
On 04/27/2015 11:30 AM, Marek Polacek wrote:
As reported in the PR, va_arg (ap, void) probably doesn't make any sense and
should be rejected thus. cc1plus and clang reject va_arg with an incomplete
type. This patch makes cc1 reject it as well.
Bootstrapped/regtested on x86_64-linux, ok for
-nul characters. Tested on
powerpc64.
Martin
2015-04-09 Martin Sebor mse...@redhat.com
* gfortran.dg/pr32627.f03 (strptr): Change size to match the number
of non-nul characters.
diff --git a/gcc/testsuite/gfortran.dg/pr32627.f03 b/gcc/testsuite/gfortran.dg/pr32627.f03
index f8695e0..d9e2b13
designed to post-process log files
(e.g., grep) that are intended to work with text files (i.e.,
files not containing nuls). Control characters can cause the
tools to fail in non-C locales (such as UTF-8).
On 04/09/2015 12:54 PM, Martin Sebor wrote:
We've been debugging a problem where nul (and other
Now that I know a bit more from Jakub Yuri's comments, I don't think
we should be turning that flag on for all the targets in the testsuite.
I was primarily trying to avoid someone else having to go through the
same analysis and reach the same conclusion for another port. But I'm
less
* include/std/tuple
In the hunk below, should the sizes_match template parameter
be privatized (since it isn't part of the public interface)?
Or perhaps even removed if it's not used?
Martin
@ -457,6 +457,73 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
}
};
+
+ // Concept utility
On 06/08/2015 09:12 AM, Jonathan Wakely wrote:
The linker script assumes that std::mbstate_t has the name __mbstate_t
for linkage purposes, but that's not necessarily true. For mingw32
it's just a typedef for int, so the patterns don't match.
This adds a new mingw32-specific pattern for
On 06/23/2015 04:29 AM, Jakub Jelinek wrote:
On Tue, Jun 23, 2015 at 12:18:30PM +0200, Marek Polacek wrote:
Is it intended that programs be able to take the address of
the builtins that correspond to libc functions and make calls
to the underlying libc functions via such pointers? (If so,
the
;
int main () { return r (0); }
/build/tmp/u.cpp:1:34: error: invalid initialization of a reference with
a builtin function
static constexpr int (r)(int) = __builtin_ffs;
^
2015-06-21 Martin Sebor mse...@redhat.com
PR c/66516
* c/c-typeck.c
Are there any concerns with or suggestions for changes to
the following patch?
https://gcc.gnu.org/ml/gcc-patches/2015-06/msg00886.html
Thanks
Martin
It seems like this patch regresess pr59630.c testcase; I don't see
the testcase being addressed in this patch.
Thanks for the review and for pointing out this regression!
I missed it among all the C test suite failures (I see 157
of them in 24 distinct tests on x86_64.)
pr59630 is marked
Is this patch okay for trunk?
On 06/18/2015 11:15 AM, Martin Sebor wrote:
Are there any concerns with or suggestions for changes to
the following patch?
https://gcc.gnu.org/ml/gcc-patches/2015-06/msg00886.html
Thanks
Martin
function (since
every function has main as its direct or indirect caller).
Tested on powerpc64le and x86_64 Linux.
Martin
The ChangeLog entries for gcc and testsuite:
2015-06-11 Martin Sebor mse...@redhat.com
* c-family/c.opt (-Wbuiltin-address): New warning option.
* doc
OK. You can go ahead and commit the libbacktrace fix.
Committed in r224402.
Let's hold off on the testsuite fixes until we've got the sanitizer
libbacktrace fixes installed.
Okay.
Martin
2015-07-04 Martin Sebor mse...@redhat.com
pr c/66516
* tree.h (DECL_IS_GCC_BUILTIN): New macro.
* doc/extend.texi (Other Builtins): Document when the address of
a built-in function can be taken.
gcc/c/ChangeLog
2015-07-04 Martin Sebor mse...@redhat.com
pr c/66516
* c-tree.h
This is a small change to diagnose unsafe calls to
__builtin_{frame,return}_address (with an argument 2) than
tend to return bogus values or lead to crashes at runtime.
A review would be appreciated.
Thanks
Martin
On 06/26/2015 05:49 PM, Martin Sebor wrote:
Is this patch okay for trunk
.
Bootstrapped and tested on x86_64-unknown-linux-gnu.
Martin
2015-06-28 Martin Sebor mse...@redhat.com
pr c/66516
* tree.h (DECL_IS_GCC_BUILTIN): New macro.
* doc/extend.texi (Other Builtins): Document when the address of
a builtin function can be taken.
2015-06-28 Martin Sebor mse
On 05/21/2015 02:05 PM, Sandra Loosemore wrote:
On 05/21/2015 01:19 PM, Martin Sebor wrote:
2015-05-21 Martin Sebor mse...@redhat.com
* extend.texi (Return Address): Clarify possible effects
of calling the functions with non-zero arguments.
diff --git a/gcc/doc/extend.texi b/gcc
me to figure out this is by design.
Does anyone have any concerns with this update or is it okay
to check in?
Thanks
Martin
2015-05-21 Martin Sebor mse...@redhat.com
* extend.texi (Return Address): Clarify possible effects
of calling the functions with non-zero arguments.
diff
On 05/22/2015 09:13 AM, Jakub Jelinek wrote:
On Fri, May 22, 2015 at 03:59:47PM +0100, Jonathan Wakely wrote:
+ alignas(alignof(_Tp2)) unsigned char _M_storage[sizeof(_Tp)];
Is alignof(_Tp2) always the same as alignof(_Tp2::_M_t) on all targets
(I mean, won't some target align the
On 08/03/2015 05:55 AM, Jan-Benedict Glaw wrote:
On Sun, 2015-08-02 17:15:27 -0600, Martin Sebor mse...@gmail.com wrote:
OK for the trunk. Sorry for the delay.
Thank you. Committed in revision 226480.
...und breaks native builds. When doing builds using config-list.mk, I
first build a GCC
In the debian reproducible builds project we have considered several
options to address this issue. We considered redefining the __DATE__ and
__TIME__ defines by command line flags passed to gcc, but as you say,
that triggers warnings, which could become errors when building with
-Werror and thus
On 07/28/2015 09:38 PM, Jason Merrill wrote:
Sorry about the slow response on IRC today, I got distracted onto
another issue and forgot to check back. What I started to write:
No problem.
I'm exploring your suggestion to see if the back end could emit the
diagnostics. But I'm not sure it
OK for the trunk. Sorry for the delay.
Thank you. Committed in revision 226480.
Martin
I suspect the back end or even the middle end route isn't going to
work even if there was enough context to diagnose the problem
expressions because some of them will have been optimized away by then
(e.g., 'if ( __builtin_foo != 0)' is optimized into if (1) by gimple).
I was thinking that if
gcc/ChangeLog
2015-07-27 Martin Sebor mse...@redhat.com
* c-family/c.opt (-Wbuiltin-address): New warning option.
* doc/invoke.texi (Wbuiltin-address): Document it.
* doc/extend.texi (__builtin_frame_addrress, __builtin_return_addrress):
Typoes (rr).
Fixed.
- rtx
On 08/05/2015 10:02 AM, Jiong Wang wrote:
On 28/07/15 16:44, Martin Sebor wrote:
Attached is an updated patch with the changes above.
gcc/testsuite/ChangeLog
2015-07-28 Martin Sebormse...@redhat.com
* g++.dg/Wframe-address-in-Wall.C: New test.
* g++.dg/Wframe-address.C: New
patch
to issue a warning for all builtin_xxx_address calls with any
non-zero argument.
Martin
gcc/ChangeLog
2015-07-27 Martin Sebor mse...@redhat.com
* c-family/c.opt (-Wbuiltin-address): New warning option.
* doc/invoke.texi (Wbuiltin-address): Document it.
* doc/extend.texi
On 07/14/2015 09:18 AM, Marek Polacek wrote:
Code such as if (i == i) is hardly ever desirable, so we should be able
to warn about this to prevent dumb mistakes.
I haven't tried the patch or even studied it very carefully but
I wonder if this is also the case when i is declared volatile.
I.e.,
On 07/22/2015 01:06 PM, Marek Polacek wrote:
On Wed, Jul 22, 2015 at 12:43:53PM -0600, Martin Sebor wrote:
On 07/14/2015 09:18 AM, Marek Polacek wrote:
Code such as if (i == i) is hardly ever desirable, so we should be able
to warn about this to prevent dumb mistakes.
I haven't tried
[CC Jason since the patch also touches the C++ front end]
The updated patch is here:
https://gcc.gnu.org/ml/gcc-patches/2015-07/msg00258.html
Thanks
Martin
On 07/04/2015 04:32 PM, Martin Sebor wrote:
I don't think c_validate_addressable is a good name - given that it's
called for lots
Still looking for a review of this small patch to help detect
potentially unsafe calls to __builtin_{frame,return}_address
(with an argument 2) that tend to either return bogus values
or lead to crashes at runtime.
The problem the function can cause was originally reported in
pr8743 and
Ping #5.
On 07/13/2015 09:33 PM, Martin Sebor wrote:
Still looking for a review of this small patch to help detect
potentially unsafe calls to __builtin_{frame,return}_address
(with an argument 2) that tend to either return bogus values
or lead to crashes at runtime.
The problem the function
On 07/14/2015 09:01 AM, Jason Merrill wrote:
I wonder if it would make sense to handle this when we actually try to
emit a reference to one of these functions in the back end, rather than
in many places through the front end.
If it's going to stay in the front end, the C and C++ front-ends
On 10/22/2015 03:47 PM, Joseph Myers wrote:
On Thu, 22 Oct 2015, Martin Sebor wrote:
While fixing up the ChangeLogs for the commit (as requested below)
I noticed that a number of new options have been added with help
text with no period at the end. The attached patch fixes those
up and adds
://gcc.gnu.org/ml/gcc-patches/2015-10/msg02224.html
gcc/ChangeLog:
2015-10-22 Martin Sebor <mse...@redhat.com>
PR driver/68043
* config/i386/i386.opt: Add missing periods to the ends of sentences.
* config/msp430/msp430.opt: Same.
gcc/testsuite/ChangeLog:
2015-10-22 Martin Sebor <mse...@r
[CC Jason]
When you have a chance, the patch is at the link below for review:
https://gcc.gnu.org/ml/gcc-patches/2015-10/msg02001.html
On 10/20/2015 01:57 PM, Martin Sebor wrote:
Attached is a slightly updated patch that tweaks the diagnostic
messages to avoid assuming the English punctuation
[CC Jason]
The patch is at the link below:
https://gcc.gnu.org/ml/gcc-patches/2015-10/msg01803.html
Thanks
On 10/19/2015 12:50 PM, Martin Sebor wrote:
This is a patch for two C++ bugs:
67913 - new expression with negative size not diagnosed
67927 - array new expression with excessive
On 10/23/2015 11:45 AM, Bernd Schmidt wrote:
On 10/23/2015 06:50 PM, Joseph Myers wrote:
On Fri, 23 Oct 2015, Martin Sebor wrote:
But now that I'm re-reading the answer above I see that Joseph
was suggesting that a5_7[5][0] should be diagnosed when the patch
accepts it as an extension. I
[Sending to the right list this time]
The documentation of the -Q --help=optimizers options leads some
to expect that when options are reported as enabled imply the
corresponding optimization will take place. (See the following
question on gcc-help:
in this
message.
Attached is patch 1 with the changes to opts.c you mention
below, adding periods to the help output printed by the driver,
and some tweaks to the test suite, plus changelogs for both
sets.
Martin
gcc/ChangeLog:
2015-10-21 Martin Sebor <mse...@redhat.com>
PR driver
On 10/23/2015 05:13 AM, Bernd Schmidt wrote:
On 10/21/2015 12:10 AM, Joseph Myers wrote:
On Tue, 20 Oct 2015, Bernd Schmidt wrote:
How about
[2].a
and
[2].b
I don't think either is valid.
typedef struct FA5_7 {
int i;
char a5_7 [5][7];
} FA5_7;
__builtin_offsetof
On 10/22/2015 04:24 AM, Eric Botcazou wrote:
Martin,
some subdirectories have their own ChangeLog file so you need to move...
2015-10-21 Martin Sebor <mse...@redhat.com>
PR driver/68043
* opts.c (undocumented_msg, use_diagnosed_msg): New g
On 11/10/2015 09:36 AM, Marek Polacek wrote:
While both C and C++ FEs are able to reject e.g.
int a[__SIZE_MAX__ / sizeof(int)];
they are accepting code such as
int (*a)[__SIZE_MAX__ / sizeof(int)];
As Joseph pointed out, any construction of a non-VLA type whose size is half or
more of the
On 11/06/2015 05:50 AM, Andreas Schwab wrote:
I see this failure on m68k:
FAIL: g++.dg/warn/Wplacement-new-size.C -std=gnu++11 (test for excess errors)
Excess errors:
/daten/aranym/gcc/gcc-20151106/gcc/testsuite/g++.dg/warn/Wplacement-new-size.C:189:19:
warning: placement new constructing an
Oh, and we could also be more informative and print the size of an array,
or the number of elements, as clang does.
Yes, that's pretty nice. It helps but the diagnostic must point at
the right dimension. GCC often just points at the whole expression
or some token within it.
void* foo ()
{
On 11/13/2015 08:21 AM, Martin Sebor wrote:
On 11/13/2015 05:56 AM, Jonathan Wakely wrote:
This is a non-conforming implementation of
https://rawgit.com/cplusplus/fundamentals-ts/v2/fundamentals-ts.html#reflection.src_loc
It doesn't provide any column numbers, and fails to meet
On 11/13/2015 05:56 AM, Jonathan Wakely wrote:
This is a non-conforming implementation of
https://rawgit.com/cplusplus/fundamentals-ts/v2/fundamentals-ts.html#reflection.src_loc
It doesn't provide any column numbers, and fails to meet the
requirement that using current() in a NSDMI will refer
On 11/11/2015 02:48 AM, Jonathan Wakely wrote:
As described in the PR, we have operator~ overloads defined for
enumeration types which produce values outside the range of valid
values for the type. In C++11 that can be trivially solved by giving
the enumeration types a fixed underlying type, but
On 11/12/2015 10:08 AM, Jonathan Wakely wrote:
On 12/11/15 08:48 -0700, Martin Sebor wrote:
On 11/11/2015 02:48 AM, Jonathan Wakely wrote:
As described in the PR, we have operator~ overloads defined for
enumeration types which produce values outside the range of valid
values for the type. In C
Martin Sebor <mse...@redhat.com>
PR c++/68208
* init.c (perform_member_init): Use location of member-initializer
in -Wself-init rather than that of the ctor.
gcc/testsuite/
2015-11-11 Martin Sebor <mse...@redhat.com>
PR c++/68208
* b/gcc/testsuite/g++.dg/warn/Winit-self-4.C: New
Attached is a patch fixing the ICE caused by a prior change of mine:
https://gcc.gnu.org/viewcvs/gcc?view=revision=230081
Tested on x86_64, committing to trunk as per Jason via IRC.
Martin
gcc/ChangeLog:
2015-11-17 Martin Sebor <mse...@redhat.com>
PR c++/68308
* cp/
On 11/07/2015 04:38 PM, Segher Boessenkool wrote:
On Tue, Oct 20, 2015 at 10:10:44PM +, Joseph Myers wrote:
typedef struct FA5_7 {
int i;
char a5_7 [5][7];
} FA5_7;
__builtin_offsetof (FA5_7, a5_7 [0][7]), // { dg-warning "index" }
__builtin_offsetof (FA5_7, a5_7
other cleanup. Attached is an updated
patch.
Tested on x86_64 by botstrapping C and C++ and running make check.
Martin
gcc ChangeLog
2015-11-04 Martin Sebor <mse...@redhat.com>
PR c++/67942
* invoke.texi (-Wplacement-new): Document new option.
* gcc/testsuite/g++.dg/warn/Wpla
On 11/03/2015 03:19 AM, Alexander Monakov wrote:
On Thu, 22 Oct 2015, Martin Sebor wrote:
[Sending to the right list this time]
The documentation of the -Q --help=optimizers options leads some
to expect that when options are reported as enabled imply the
corresponding optimization will take
I guess this is a case where I could say either "I wrote the patch" or
"I requested changes to a patch in review"; in the latter case I can
approve it. Joseph seems on board with what we've discussed, so I'd say
please wait until Tuesday for objections then commit.
I didn't get to committing
On 11/04/2015 06:09 PM, Sandra Loosemore wrote:
On 11/04/2015 04:52 PM, Martin Sebor wrote:
gcc/ChangeLog:
2015-11-04 Martin Sebor <mse...@redhat.com>
* opts.c (print_filtered_help): Indicate when an optimization option
is disabled as a result of -O0.
* doc/invoke.texi: F
On 11/05/2015 10:10 AM, Joseph Myers wrote:
On Thu, 5 Nov 2015, Martin Sebor wrote:
optimiziation. We seem to have consensus that even though there
might be exceptions (do we know what some of them are?) the vast
majority optimizations that have -fxxx options are in fact not
performed at -O0
On 11/05/2015 03:48 AM, Alexander Monakov wrote:
On Thu, 5 Nov 2015, Joseph Myers wrote:
On Wed, 4 Nov 2015, Martin Sebor wrote:
Improving the compiler output is a good idea. The attached patch
prints "[disabled by -O0]" instead of "[enabled]" when an optimization
option i
If we use gcc_checking_assert it won't fire in release builds; let's go
with that.
Okay. Attached is an updated patch with that change.
Martin
gcc ChangeLog
2015-11-05 Martin Sebor <mse...@redhat.com>
PR c++/67942
* invoke.texi (-Wplacement-new): Document new option.
On 11/05/2015 11:07 AM, Joseph Myers wrote:
On Thu, 5 Nov 2015, Martin Sebor wrote:
There are several options marked Optimization that are actually matters of
language semantics that I don't think have anything to do with -O options,
e.g. -fexceptions and -fcx-limited-range. The Optimization
On 11/02/2015 09:55 PM, Jason Merrill wrote:
On 10/26/2015 10:06 PM, Martin Sebor wrote:
+ if (TREE_CONSTANT (maybe_constant_value (outer_nelts)))
+{
+ if (tree_int_cst_lt (max_outer_nelts_tree, outer_nelts))
maybe_constant_value may return a constant, but that doesn't mean
I share your concerns, but I'm also sympathetic to the changes that
the Taller Technologies team are trying to make, to allow libstdc++ to
be more useful in exception-free systems.
At the very least the patch to doc/xml/manual/configure.xml must
document that this option enables behaviour that
Besides violating the requirement of the C++ standard, replacing
Could you please point us to the relevant section where this behavior
is enforced? We couldn't find it so far.
The Required behavior of the nothrow operator new reads:
This nothrow version of operator new returns a pointer
On 11/03/2015 05:35 AM, Aurelio Remonda wrote:
Currently, whenever operator new (std::nothrow) fails to allocate memory, it'll
check if there is a new-handler function available. If there is, it'll call
the handler and then try to allocate again. Otherwise, it'll return a null
pointer.
This
On 11/03/2015 04:08 PM, Mike Stump wrote:
On Nov 3, 2015, at 1:10 PM, Martin Sebor <mse...@gmail.com> wrote:
The "as if" requirement implies that any observable effects of
"the (possibly replaced) ordinary version" must be preserved.
The repeated calls to the new hand
On 11/02/2015 07:40 PM, Jason Merrill wrote:
On 10/26/2015 09:48 PM, Martin Sebor wrote:
+ while (TREE_CODE (oper) == NOP_EXPR)
+oper = TREE_OPERAND (oper, 0);
This is STRIP_NOPS.
+ to placement new is not checked since it's unknownwhat it might
Missing space.
+ else
Ping. Thanks in advance for a review.
On 10/22/2015 08:12 PM, Martin Sebor wrote:
[Sending to the right list this time]
The documentation of the -Q --help=optimizers options leads some
to expect that when options are reported as enabled imply the
corresponding optimization will take place
On 11/05/2015 10:09 AM, Segher Boessenkool wrote:
On Thu, Nov 05, 2015 at 08:58:25AM -0700, Martin Sebor wrote:
I don't think that reiterating in a condensed form what the manual
doesn't make clear in many more words will help. First, even users
who do find the relevant text in the manual often
On 11/05/2015 11:13 AM, Jason Merrill wrote:
OK, thanks.
I'm afraid the last patch that I just committed breaks libstdc++
bootstrap with the following error:
/home/msebor/scm/fsf/gcc-svn/libstdc++-v3/src/c++98/ios_init.cc: In
static member function ‘static bool
On 11/05/2015 04:41 PM, Martin Sebor wrote:
On 11/05/2015 11:13 AM, Jason Merrill wrote:
OK, thanks.
I'm afraid the last patch that I just committed breaks libstdc++
bootstrap with the following error:
I committed a slightly more robust fix that avoids assuming that
either the size
On 11/05/2015 04:30 PM, Segher Boessenkool wrote:
On Thu, Nov 05, 2015 at 02:04:47PM -0700, Martin Sebor wrote:
On 11/05/2015 10:09 AM, Segher Boessenkool wrote:
On Thu, Nov 05, 2015 at 08:58:25AM -0700, Martin Sebor wrote:
I don't think that reiterating in a condensed form what the manual
On 11/04/2015 09:27 PM, Jason Merrill wrote:
On 11/04/2015 07:15 PM, Martin Sebor wrote:
There was a lot of discussion of C++ aliasing rules at the recent
meeting; we really seem to be moving in the direction of being stricter
about which union member is active. So I think we do want
On 11/06/2015 05:55 AM, Rainer Orth wrote:
Martin Sebor <mse...@gmail.com> writes:
If we use gcc_checking_assert it won't fire in release builds; let's go
with that.
Okay. Attached is an updated patch with that change.
Unfortunately, this breaks i386-pc-solaris2.10 bootstrap:
/vol/g
in the future. If there is a page
on the Wiki or somewhere with best practices or recommended steps
that someone knows about, I'd be grateful for a pointer.
Again, sorry for the breakage.
Martin
2015-11-05 Martin Sebor <mse...@redhat.com>
PR c++/67942
* invok
1 - 100 of 3587 matches
Mail list logo
