On 04/27/2017 10:43 AM, Tom de Vries wrote:
On 04/26/2017 01:57 PM, Jakub Jelinek wrote:
On Wed, Apr 26, 2017 at 01:48:03PM +0200, Tom de Vries wrote:
[ reposting with patch removed, was too big for gcc-patches@ ]
I see in various tests you've ended up with ... { target ... } . }
I think it w
Dear Thomas,
Thanks for doing the testing. Since we are now into 8-branch, I intend
to fix PR34640 completely, using what I learned with this patch.
Cheers
Paul
On 27 April 2017 at 20:33, Thomas Koenig wrote:
> Hello Paul,
>
>> The attached fixes the problem withPR51218 and bootstraps and regt
On 27 Apr, Martin Sebor wrote:
> On 04/27/2017 01:29 AM, Volker Reichelt wrote:
>> Hi,
>>
>> the following two patches aim at improving GCC's diagnostics to help
>> the user to get rid of old-style casts. While old-style pointer casts
>> are really bad and need to be weeded out quickly, old-style c
On Thu, 27 Apr 2017, Alexander Monakov wrote:
> On Thu, 27 Apr 2017, Richard Biener wrote:
> > struct q { int n; long o[100]; };
> > struct r { int n; long o[0]; };
> >
> > union {
> > struct r r;
> > struct q q;
> > } u;
> >
> > int foo (int i, int j)
> > {
> > long *q = u.r.o;
> >
On 27/04/17 21:27 +0200, François Dumont wrote:
On 27/04/2017 20:32, Jonathan Wakely wrote:
On 27/04/17 20:12 +0200, François Dumont wrote:
Hi
Here is the patch to registers Printers depending on activation
of versioned namespace.
2017-04-27 François Dumont
* python/Makefile.am [ENA
Committed.
Richard.
2017-04-28 Richard Biener
* lto-streamer.h (LTO_major_version): Bump to 7.
Index: gcc/lto-streamer.h
===
--- gcc/lto-streamer.h (revision 247362)
+++ gcc/lto-streamer.h (working copy)
@@ -128,7 +12
On Fri, Apr 28, 2017 at 07:56:23AM +0200, Richard Biener wrote:
> On April 27, 2017 10:20:57 PM GMT+02:00, Jakub Jelinek
> wrote:
> >This is something that fails bootstrap newly in GCC 7 and only with
> >(now on the branch default --enable-checking=release (or
> >--disable-checking)). The proble
On Fri, 28 Apr 2017, Jakub Jelinek wrote:
> On Fri, Apr 28, 2017 at 07:56:23AM +0200, Richard Biener wrote:
> > On April 27, 2017 10:20:57 PM GMT+02:00, Jakub Jelinek
> > wrote:
> > >This is something that fails bootstrap newly in GCC 7 and only with
> > >(now on the branch default --enable-chec
On Thu, 27 Apr 2017, Richard Biener wrote:
> On April 27, 2017 4:06:48 PM GMT+02:00, "Bin.Cheng"
> wrote:
> >On Thu, Apr 27, 2017 at 2:49 PM, Richard Biener
> >wrote:
> >>
> >> The following makes intersecting [-INF, +10] and [a + -1, +INF]
> >> to [10, a + -1] possible with the chance that for
Hi,
Thank you for your comments. I edited my patch accordingly. As for some of your
doubts:
- REX is the opcode prefix to access 64-bit register extensions introduced in
IA-32e mode.
- EVEX is the encoding prefix which applies to SIMD operating instructions
operating on XMM, YMM and ZMM regist
gcc/ChangeLog:
2017-04-19 Martin Liska
PR driver/56469
* coverage.c (coverage_remove_note_file): New function.
* coverage.h: Declare the function.
* toplev.c (finalize): Clean if an error has been seen.
---
gcc/coverage.c | 12
gcc/coverage.h | 1
Hi.
Following patch series improves the infrastructure, fixes couple of issues
and hopefully improves also documentation of the functionality.
I decided to split the changes into various patches to make it easier
for reviewers.
Bootstraps and survives regression tests on ppc64le-linux-gnu and can
gcc/ChangeLog:
2017-04-26 Martin Liska
* gcov.c (struct block_location_info): New struct.
(process_file): Fill up the new structure.
(read_graph_file): Replace usage of encoding by the newly added
struct.
(add_line_counts): Likewise.
(accumulate_
gcc/ChangeLog:
2017-03-13 Martin Liska
PR gcov-profile/80031
* gcov-dump.c (tag_blocks): Just print number of basic blocks.
* gcov-io.h (GCOV_TAG_BLOCKS_NUM): Remove unused macro.
* gcov.c (read_graph_file): Read just number of blocks.
* profile.c (branc
gcc/ChangeLog:
2017-04-27 Martin Liska
PR gcov-profile/53915
* gcov.c (format_gcov): Print 'NAN %' when top > bottom.
---
gcc/gcov.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/gcc/gcov.c b/gcc/gcov.c
index 0adb4466f70..22378583c5c 100644
--- a/gcc/gcov.c
+++ b/
gcc/ChangeLog:
2017-04-26 Martin Liska
PR gcov-profile/79891
* gcov.c (add_line_counts): Assign BBs to lines just if the BB
is marked by compiler as living on a line.
(get_cycles_count): Remove usage of the union.
(output_intermediate_file): Likewise.
gcc/ChangeLog:
2017-04-26 Martin Liska
* gcov.c (process_args): Handle new argument 'w'.
(read_graph_file): Assign ID to BBs.
(output_branch_count): Display BB # if verbose flag is set.
(output_lines): Likewise for arcs.
(print_usage): Add '--verbose' op
gcc/ChangeLog:
2017-04-27 Martin Liska
* doc/gcov.texi: Sort options in alphabetic order.
* doc/gcov-dump.texi: Likewise.
* doc/gcov-tool.texi: Likewise.
* gcov.c (print_usage): Likewise.
* gcov-dump.c (print_usage): Likewise.
* gcov-tool.c (prin
gcc/ChangeLog:
2017-04-27 Martin Liska
* doc/gcov.texi: Enhance documentation of gcov.
---
gcc/doc/gcov.texi | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/gcc/doc/gcov.texi b/gcc/doc/gcov.texi
index 1befb5a3e08..c96f86df830 100644
--- a/gcc/doc/gcov.texi
++
Hi,
now that 7.1.0 is almost out of the door, I'm sending a few simple
patches which I have been testing for a while in my trees. This one is
about an error recovery regression: I think it's correct to handle it by
simply returning unconditionally error_mark_node upon "too many
initializers"
On 04/27/2017 05:02 AM, marxin wrote:
gcc/ChangeLog:
2017-04-27 Martin Liska
* doc/gcov.texi: Sort options in alphabetic order.
* doc/gcov-dump.texi: Likewise.
* doc/gcov-tool.texi: Likewise.
* gcov.c (print_usage): Likewise.
* gcov-dump.c (print_usage
On 04/27/2017 05:24 AM, marxin wrote:
gcc/ChangeLog:
2017-04-27 Martin Liska
* doc/gcov.texi: Enhance documentation of gcov.
ok
--
Nathan Sidwell
On 04/27/2017 06:04 AM, marxin wrote:
gcc/ChangeLog:
2017-04-27 Martin Liska
PR gcov-profile/53915
* gcov.c (format_gcov): Print 'NAN %' when top > bottom.
ok
--
Nathan Sidwell
On 04/25/2017 08:05 AM, marxin wrote:
gcc/ChangeLog:
2017-04-26 Martin Liska
* gcov.c (process_args): Handle new argument 'w'.
(read_graph_file): Assign ID to BBs.
(output_branch_count): Display BB # if verbose flag is set.
(output_lines): Likewise for arcs.
Hello,
surprisingly, this did not cause any Wstrict-overflow failure. Some of it
sounds more like reassoc's job, but it is convenient to handle simple
cases in match.pd. I think we could wait until there are reports of
regressions related to register pressure before adding single_use tests.
On 28/04/17 09:41 +0100, Jonathan Wakely wrote:
On 27/04/17 21:27 +0200, François Dumont wrote:
Oh, I thought it was obviously better to not register useless
Printers. But if you need a bug report or an explicit test showing
that it is better then I don't have it. Maybe a gdb guy could tell
us
On 04/25/2017 09:08 AM, marxin wrote:
gcc/ChangeLog:
2017-04-26 Martin Liska
PR gcov-profile/79891
* gcov.c (add_line_counts): Assign BBs to lines just if the BB
is marked by compiler as living on a line.
(get_cycles_count): Remove usage of the union.
On 04/21/2017 08:40 AM, marxin wrote:
gcc/ChangeLog:
2017-03-13 Martin Liska
PR gcov-profile/80031
* gcov-dump.c (tag_blocks): Just print number of basic blocks.
* gcov-io.h (GCOV_TAG_BLOCKS_NUM): Remove unused macro.
* gcov.c (read_graph_file): Read just numb
On 28/04/17 12:38 +0100, Jonathan Wakely wrote:
On 28/04/17 09:41 +0100, Jonathan Wakely wrote:
On 27/04/17 21:27 +0200, François Dumont wrote:
Oh, I thought it was obviously better to not register useless
Printers. But if you need a bug report or an explicit test showing
that it is better the
On 04/21/2017 10:02 AM, marxin wrote:
gcc/ChangeLog:
2017-04-26 Martin Liska
* gcov.c (struct block_location_info): New struct.
(process_file): Fill up the new structure.
(read_graph_file): Replace usage of encoding by the newly added
struct.
(add_line
On 04/19/2017 03:56 AM, marxin wrote:
gcc/ChangeLog:
2017-04-19 Martin Liska
PR driver/56469
* coverage.c (coverage_remove_note_file): New function.
* coverage.h: Declare the function.
* toplev.c (finalize): Clean if an error has been seen.
ok
nathan
--
Nat
On 04/28/2017 05:26 AM, marxin wrote:
Hi.
Following patch series improves the infrastructure, fixes couple of issues
and hopefully improves also documentation of the functionality.
I decided to split the changes into various patches to make it easier
for reviewers.
thanks for doing this. I th
On 04/28/2017 01:49 PM, Nathan Sidwell wrote:
> On 04/28/2017 05:26 AM, marxin wrote:
>> Hi.
>>
>> Following patch series improves the infrastructure, fixes couple of issues
>> and hopefully improves also documentation of the functionality.
>> I decided to split the changes into various patches to
Hello, gentle maintainer.
This is a message from the Translation Project robot. (If you have
any questions, send them to .)
A new POT file for textual domain 'gcc' has been made available
to the language teams for translation. It is archived as:
http://translationproject.org/POT-files/gcc-
On 03/17/2017 02:51 AM, David Malcolm wrote:
Hello.
I've just tested you patches and I can confirm that they work :)
I've got couple of related questions:
> It's possible to run GCC's sources through Doxygen by setting
> INPUT_FILTER = contrib/filter_gcc_for_doxygen
> within cont
Hi.
First follow-up patch changes comment style in couple of locations
so that filter_params.py can transform them to Doxygen style.
I verified that there's no compilation error caused by the patch.
Ready for trunk,
Martin
>From 3867980352bd1a666395470c5ff138d1d545b311 Mon Sep 17 00:00:00 2001
F
Hi.
As mentioned in the subject, another 2 transformations. With David's patch
applied and
my 2 hunks, I can see just these 3 warnings related to verbatim/end verbatim
decoration:
/home/marxin/Programming/gcc/gcc/gcov-io.c:464: warning: unexpected command
endverbatim
/home/marxin/Programming/g
On Fri, Apr 28, 2017 at 1:35 PM, Marc Glisse wrote:
> Hello,
>
> surprisingly, this did not cause any Wstrict-overflow failure. Some of it
> sounds more like reassoc's job, but it is convenient to handle simple cases
> in match.pd. I think we could wait until there are reports of regressions
> rel
On Fri, Apr 28, 2017 at 02:25:55PM +0200, Richard Biener wrote:
> On Fri, Apr 28, 2017 at 1:35 PM, Marc Glisse wrote:
> > Hello,
> >
> > surprisingly, this did not cause any Wstrict-overflow failure. Some of it
> > sounds more like reassoc's job, but it is convenient to handle simple cases
> > in
On 04/28/2017 01:41 PM, Nathan Sidwell wrote:
> On 04/25/2017 09:08 AM, marxin wrote:
>> gcc/ChangeLog:
>>
>> 2017-04-26 Martin Liska
>>
>> PR gcov-profile/79891
>> * gcov.c (add_line_counts): Assign BBs to lines just if the BB
>> is marked by compiler as living on a line.
>> (ge
A tiny tweak to Tom's patch from yesterday.
* testsuite/17_intro/headers/c++1998/stdc++_assert_neg.cc: Remove
superfluous "" in dg-error.
Committed to trunk.
commit 5e7a406584889993b204ff640e3891ea5ca72a34
Author: Jonathan Wakely
Date: Fri Apr 28 13:25:52 2017 +0100
Remo
We optimize _Destroy and _Destroy_n to do nothing when the type has a
trivial destructor, which means we do nothing (instead of giving an
error) when trying to destroy types with deleted destructors.
Because deleted destructors are trivial. Because C++.
This adds static assertions to reject atte
Hi,
this is a second part of conversion which converts the interfaces form
ipa-inline-analysis to inliner and ipa-cp. Again modulo the roundoff
differences and compile time slowdown (caused by use of sreal) this patch
should not have effect on code quality. Adjustments of time metrics will come
n
On Fri, 28 Apr 2017, Richard Biener wrote:
> On Thu, 27 Apr 2017, Alexander Monakov wrote:
>
> > On Thu, 27 Apr 2017, Richard Biener wrote:
> > > struct q { int n; long o[100]; };
> > > struct r { int n; long o[0]; };
> > >
> > > union {
> > > struct r r;
> > > struct q q;
> > > } u;
> >
This fixes some of the remaining warnings that appear in a compiler bootstrap.
The above ones are false positives of -Wmaybe-uninitialized and most are fixed
by initializing the variable in case the control flow is fairly complicated; a
couple of very local cases are fixed by just adding pragma War
The expresion in an expression function that is a completion freezes. This
is implemented by first freezing the return type of the function, and then
traversing the analyzed expression and freezing explicitly all type references
within. If the expression includes a type conversion between access to
This fixes some of the remaining warnings that appear in a compiler bootstrap.
The above ones are false positives of -Wmaybe-uninitialized and most are fixed
by initializing the variable in case the control flow is fairly complicated; a
couple of very local cases are fixed by just adding pragma War
This patch fixes a bug where a protected procedure that propagates an
exception can cause deadlock. This can happen if all of these checks are
suppressed: Access_Check, Discriminant_Check, Range_Check, Index_Check,
and Stack_Check (possibly by -gnatp), and the protected procedure calls
something th
This patch ensures that info messages are not treated as errors when
warnings must be treated as errors due to -gnatwe.
-- Source --
-- pack.ads
package Pack is
procedure Proc_1;
procedure Proc_2;
end Pack;
-- pack.adb
package body Pack is
procedure Proc_1
This fixes some of the remaining warnings that appear in a compiler bootstrap.
The above ones are false positives of -Wmaybe-uninitialized and some are fixed
by initializing the variable in case the control flow is complicated; the rest
is fixed by just adding pragma Warnings.
No functional change
On 04/27/2017 02:02 PM, Paolo Carlini wrote:
... replying to myself, in practice we could do the below, which
certainly passes testing, and in fact now seems to me even more obvious
than I thought a couple of days ago...
I'm insufficiently conceptified to know whether this is safe (but lack
On 04/28/17 00:52, Martin Sebor wrote:
>>> I suggest avoiding "element size" because the pointed-to argument
>>> need not be an array. Mentioning the types should help users better
>>> understand the problem (especially in C++ where types are often
>>> obscured by layers of templates). It might a
On 2017-04-25 09:30 -0600, Jeff Law wrote:
> Given Richi's general agreement around the in_lto_p, let's go with the
> patch on the trunk only.
Should I prepare (re-diff) a patch for current trunk?
> If you get positive feedback from Jan, then this can be backported to
> gcc-7 after it's been o
On 04/28/2017 06:58 AM, Paolo Carlini wrote:
Hi,
now that 7.1.0 is almost out of the door, I'm sending a few simple
patches which I have been testing for a while in my trees. This one is
about an error recovery regression: I think it's correct to handle it by
simply returning unconditionally
On 04/28/2017 08:31 AM, Xi Ruoyao wrote:
On 2017-04-25 09:30 -0600, Jeff Law wrote:
Given Richi's general agreement around the in_lto_p, let's go with the
patch on the trunk only.
Should I prepare (re-diff) a patch for current trunk?
If you want for the trunk, yes.
If you get positive fe
While either of the last two operands can be in memory, they can't be
swapped.
gcc/
2017-04-28 Jan Beulich
* config/i386/sse.md (xop_vpermil23): Use alternatives.
--- a/gcc/config/i386/sse.md
+++ b/gcc/config/i386/sse.md
@@ -17092,12 +17092,12 @@
(set_attr "mode" "TI")])
(defin
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'gcc' has been submitted
by the German team of translators. The file is available at:
http://translationproject.org/latest/gcc/de.po
(This file, 'gcc-7.1-b20170427.de.po', h
On 04/28/2017 08:12 AM, Bernd Edlinger wrote:
On 04/28/17 00:52, Martin Sebor wrote:
I suggest avoiding "element size" because the pointed-to argument
need not be an array. Mentioning the types should help users better
understand the problem (especially in C++ where types are often
obscured by
On 04/27/2017 04:04 PM, Tom de Vries wrote:
On 04/26/2017 01:57 PM, Jakub Jelinek wrote:
I guess those should be decided case by case
whether we want relative, absolute or saved line numbers. If the
diagnostic is within the same function or code block as the stuff it is
relative to, relative is
On 04/27/2017 03:05 PM, Martin Sebor wrote:
On 04/26/2017 04:34 PM, Jakub Jelinek wrote:
Also, can't there be a way to shortcut all this processing if the
charsets are the same? And is it a good idea if every pass that needs
to do
something with the exec charset chars caches its own results
On Fri, Apr 28, 2017 at 10:22:29AM -0600, Jeff Law wrote:
> So the initialization could be done once per translation unit rather than
> once per function -- assuming the target character set doesn't change within
> a translation unit.
>
> That seems like it ought to be easy.
>
> The table-lookup
On 04/28/2017 05:47 AM, Nathan Sidwell wrote:
On 04/21/2017 10:02 AM, marxin wrote:
gcc/ChangeLog:
2017-04-26 Martin Liska
* gcov.c (struct block_location_info): New struct.
(process_file): Fill up the new structure.
(read_graph_file): Replace usage of encoding by the newly adde
On 04/25/2017 09:55 PM, Martin Sebor wrote:
On 04/25/2017 04:05 PM, Jeff Law wrote:
On 04/21/2017 03:33 PM, Martin Sebor wrote:
Bug 77671 - missing -Wformat-overflow warning on sprintf overflow
with "%s", is caused by gimple-fold.c transforming s{,n}printf
calls with a plain "%s" format string
On 04/28/2017 10:27 AM, Jakub Jelinek wrote:
On Fri, Apr 28, 2017 at 10:22:29AM -0600, Jeff Law wrote:
So the initialization could be done once per translation unit rather than
once per function -- assuming the target character set doesn't change within
a translation unit.
That seems like it ou
On 04/27/2017 07:35 PM, Martin Sebor wrote:
On 04/25/2017 09:55 PM, Martin Sebor wrote:
On 04/25/2017 04:05 PM, Jeff Law wrote:
On 04/21/2017 03:33 PM, Martin Sebor wrote:
I think I may have included the (partial) the fix for 79062 to
get some tests to pass but I'm not 100% sure.
The follow
On 04/23/2017 05:54 AM, Bernd Edlinger wrote:
Hi Jeff,
this patch tries to fix the handling of pic_offset_rtx +
const(unspec(symbol_ref)+ const_int) in may_trap_p,
and restores the original state of affairs in update_equiv_regs.
What do you think is it OK to extract the symbol_ref out
of the
On 04/28/17 17:29, Martin Sebor wrote:
> On 04/28/2017 08:12 AM, Bernd Edlinger wrote:
>>
>> Do you want me to change the %qT format strings to %T ?
>
> Yes, with the surrounding %< and %> the nested directives should
> use the unquoted forms, otherwise the printer would end up quoting
> both the w
This patch, for the "gcn" branch, does three things:
1. Add specs to drive the LLVM assembler and linker. It requires them to
be installed as "as" and "ld", under $target/bin, but then the compiler
Just Works with these specs.
2. Switch to HSACO format version 2, and have the assembler auto-s
On Fri, 28 Apr 2017, Andrew Stubbs wrote:
> 3. Add -mgpu option and corresponding --with-gpu. I've deliberately used "gpu"
> instead of "cpu" because I want offloading compilers to be able to say
> "-mcpu=foo -foffload=-mgpu=bar", or even have the host compiler just
> understand -mgpu and DTRT.
C
On 04/25/2017 10:50 AM, Iain Buclaw wrote:
On 20 April 2017 at 20:58, Iain Buclaw wrote:
Hmm, it seems like D compilers until 3 years ago infact used to mangle
in this way. Better keep it around then for a little while longer for
compatibility. I'll follow-up with an amendment which doesn't r
On 04/28/2017 12:28 PM, Martin Sebor wrote:
Unless it's some other kind of vector, the patch adds a vector
member to the class, which makes it not a PoD.(*)
oh, well double ew. Your code is bad and you should feel bad.
Write proper member initializers please.
[*] Strictly speaking using m
On 04/28/17 18:48, Jeff Law wrote:
> On 04/23/2017 05:54 AM, Bernd Edlinger wrote:
>> Hi Jeff,
>>
>>
>> this patch tries to fix the handling of pic_offset_rtx +
>> const(unspec(symbol_ref)+ const_int) in may_trap_p,
>> and restores the original state of affairs in update_equiv_regs.
>>
>>
>> What d
Ping...
I attached a rebased patch file, with the doc changes and
merge conflicts with trunk of today fixed, but otherwise
identical.
Thanks
Bernd.
On 04/21/17 22:26, Bernd Edlinger wrote:
>
>
> On 04/21/17 21:50, Joseph Myers wrote:
>> On Fri, 21 Apr 2017, Bernd Edlinger wrote:
>>
>>> So I wou
This patch adds support for the compare bytes instruction, which has
been available in the rs6000 architecture since Power6.
The patch has been bootstrapped and tested on powerpc64le-unknown-linux
and powerpc-unknown-linux (big-endian, with both -m32 and -m64 target
options) with no regressions.
On 04/28/2017 10:22 AM, Jeff Law wrote:
On 04/27/2017 03:05 PM, Martin Sebor wrote:
On 04/26/2017 04:34 PM, Jakub Jelinek wrote:
Also, can't there be a way to shortcut all this processing if the
charsets are the same? And is it a good idea if every pass that
needs to do
something with the exe
On 04/24/2017 03:05 AM, Prathamesh Kulkarni wrote:
On 1 March 2017 at 13:24, Richard Biener wrote:
On Tue, 28 Feb 2017, Jeff Law wrote:
On 02/28/2017 05:59 AM, Prathamesh Kulkarni wrote:
On 28 February 2017 at 15:40, Jakub Jelinek wrote:
On Tue, Feb 28, 2017 at 03:33:11PM +0530, Prathamesh
On 04/25/2017 01:31 PM, Jakub Jelinek wrote:
Hi!
The following patch is a partial fix for PR80491, an improvement for
if-conversion if there is empty else_bb.
What we do right now is in that case we only look at the immediately
preceeding (non-debug/non-note) instruction before cond_earliest
an
On 04/26/2017 05:25 AM, Jakub Jelinek wrote:
On Tue, Apr 25, 2017 at 09:31:00PM +0200, Jakub Jelinek wrote:
This patch let us search for x's setter earlier in the bb.
During testing I found that modified_in_p/modified_in_between_p don't
actually take into account calls that could change MEMs, so
On 04/26/2017 11:05 AM, Martin Sebor wrote:
On 04/24/2017 03:35 PM, Jeff Law wrote:
On 04/11/2017 12:57 PM, Martin Sebor wrote:
In a review of my fix for bug 80364 Jakub pointed out that to
determine whether an argument to an integer directive is of
an integer type the gimple-ssa-sprintf pass t
On 04/28/2017 11:27 AM, Bernd Edlinger wrote:
Yes I agree, that is probably not worth it. So I could try to remove
the special handling of PIC+const and see what happens.
However the SYMBOL_REF_FUNCTION_P is another story, that part I would
like to keep: It happens quite often, already w/o -
Hello,
I've been asked to send the patch against trunk here.
Best,
christos
Index: cpuid.h
===
--- cpuid.h (revision 247395)
+++ cpuid.h (working copy)
@@ -235,6 +235,16 @@
return __eax;
}
+/* Return non-zero if we
On 04/20/2017 01:11 PM, Bernd Edlinger wrote:
Hi!
This is my new attempt to clean up the different cross compiler
configurations. It turned out to be a very complicated matter,
so I thought it would be better to postpone it to the stage1.
In a canadian cross compiler setup we have a different
On 04/28/2017 05:28 PM, Martin Sebor wrote:
> On 04/28/2017 05:47 AM, Nathan Sidwell wrote:
>>> @@ -427,9 +429,31 @@ static void output_lines (FILE *, const source_t
>>> *);
>>> static char *make_gcov_file_name (const char *, const char *);
>>> static char *mangle_name (const char *, char *);
On 04/28/2017 12:05 PM, Martin Sebor wrote:
So the initialization could be done once per translation unit rather
than once per function -- assuming the target character set doesn't
change within a translation unit.
That seems like it ought to be easy.
It is easy. I was going to respond by sa
On 04/28/2017 01:01 PM, Pedro Alves wrote:
On 04/28/2017 05:28 PM, Martin Sebor wrote:
On 04/28/2017 05:47 AM, Nathan Sidwell wrote:
@@ -427,9 +429,31 @@ static void output_lines (FILE *, const source_t
*);
static char *make_gcov_file_name (const char *, const char *);
static char *mangle
On 04/28/2017 08:01 PM, Pedro Alves wrote:
> On 04/28/2017 05:28 PM, Martin Sebor wrote:
>> On 04/28/2017 05:47 AM, Nathan Sidwell wrote:
>
@@ -427,9 +429,31 @@ static void output_lines (FILE *, const source_t
*);
static char *make_gcov_file_name (const char *, const char *);
On 04/28/17 20:46, Jeff Law wrote:
> On 04/28/2017 11:27 AM, Bernd Edlinger wrote:
>>>
>>
>> Yes I agree, that is probably not worth it. So I could try to remove
>> the special handling of PIC+const and see what happens.
>>
>> However the SYMBOL_REF_FUNCTION_P is another story, that part I would
>
On 04/28/17 21:14, Bernd Edlinger wrote:
> On 04/28/17 20:46, Jeff Law wrote:
>> On 04/28/2017 11:27 AM, Bernd Edlinger wrote:
>>>
>>> Yes I agree, that is probably not worth it. So I could try to remove
>>> the special handling of PIC+const and see what happens.
>>>
>>> However the SYMBOL_
On 04/25/2017 12:06 AM, Prathamesh Kulkarni wrote:
On 25 April 2017 at 02:41, Jeff Law wrote:
On 02/25/2017 01:40 AM, Prathamesh Kulkarni wrote:
Hi,
The attached patch deletes calls to strdup, strndup if it's
return-value is unused,
and same for realloc if the first arg is NULL.
Bootstrap+tes
On Fri, 28 Apr 2017, Richard Biener wrote:
On Fri, Apr 28, 2017 at 1:35 PM, Marc Glisse wrote:
Hello,
surprisingly, this did not cause any Wstrict-overflow failure. Some of it
sounds more like reassoc's job, but it is convenient to handle simple cases
in match.pd. I think we could wait until
On 02/22/2017 04:01 AM, Xi Ruoyao wrote:
This patch moves prototype of char_type_p into c-common.h, so we can
use it in c-family/*.
gcc/ChangeLog:
2017-02-22 Xi Ruoyao
* c-family/c-common.h (char_type_p): New prototype
* c/c-typeck.c (char_type_p): Make the function extern
On 02/22/2017 04:01 AM, Xi Ruoyao wrote:
This patch adds warning option -Wstring-plus-int for C.
gcc/ChangeLog:
2017-02-22 Xi Ruoyao
* c/c-typeck.c (parser_build_binary_op, build_modify_expr): checking
for -Wstring-plus-int
---
gcc/c/c-typeck.c | 28
On 02/22/2017 04:01 AM, Xi Ruoyao wrote:
This patch adds document of -Wstring-plus-int.
gcc/ChangeLog:
2017-02-22 Xi Ruoyao
* doc/invoke.texi (Warning Options): Document -Wstring-plus-int
This is OK for the trunk once all 5 are approved.
jeff
On 02/22/2017 04:01 AM, Xi Ruoyao wrote:
This patch adds tests for -Wstring-plus-int.
gcc/ChangeLog:
2017-02-22 Xi Ruoyao
* testsuite/c-c++-common/Wstring-plus-int.c: New test
* testsuite/g++.dg/Wstring-plus-int-1.C: New test
* testsuite/g++.dg/Wstring-plus-int-2.C:
On 02/22/2017 04:01 AM, Xi Ruoyao wrote:
This patch adds warning option -Wstring-plus-int for C++.
gcc/ChangeLog:
2017-02-22 Xi Ruoyao
* c-family/c-common.h (maybe_warn_string_plus_int): new prototype
* c-family/c-warn.h (maybe_warn_string_plus_int): new function
* c
On 11/29/2016 12:54 PM, Wilco Dijkstra wrote:
Jeff Law wrote:
On 11/29/2016 11:39 AM, Wilco Dijkstra wrote:
I forgot to ask, would it be reasonable to add an assert to check we're not in
a sequence in leaf_function_p? I guess this will trigger on several targets
(leaf_function_p is used in seve
On 01/24/2017 08:36 PM, Martin Sebor wrote:
In implementing the -Wstringop-overflow warning I missed stpcpy.
The attached patch adds the required checking. Given how simple
it is, does it qualify for GCC 7 despite stage 4?
Martin
gcc-79222.diff
PR middle-end/79222 - missing -Wstringop-overfl
On 02/03/2017 01:03 PM, Walter Lee wrote:
Hi,
In looking at PR 79365 I found that the problem is actually in the
combiner. The combiner sometimes applies scalar optimizations to
vector context where they are invalid. i.e. (a > b) >> 1 can optimize
to 0 if ">" is a scalar op but not if it is a
Hi Kelvin,
On Fri, Apr 28, 2017 at 11:48:03AM -0600, Kelvin Nilsen wrote:
> --- gcc/config/rs6000/rs6000.h(revision 247069)
> +++ gcc/config/rs6000/rs6000.h(working copy)
> @@ -2717,6 +2717,7 @@ extern int frame_pointer_needed;
> aren't in target_flags. */
> #define RS6000_BT
The two options were included in -Wall and enabled for all front
ends but only made to be recognized by the driver for the C family
of compilers. That made it impossible to suppress those warnings
when compiling code for those other front ends (like Fortran).
The attached patch adjusts the warni
1 - 100 of 105 matches
Mail list logo
