> Examples of warnings (many of them occuring many up to several dozens of
> times):
> warning: @anchor should not appear in @heading
> warning: @title missing argument
> warning: @itemize has text but no @item
> warning: node `XXX' is next for `YYY' in menu but not in sectioning
> warning: node `X
Janus Weil wrote:
here is a straightforward patch which fixes a regression with
procedure-pointer components which have an allocatable result.
Regtests cleanly on x86_64-unknown-linux-gnu. Ok for trunk/4.7/4.6?
OK thanks for the patch.
Tobias
2013-02-20 Janus Weil
PR fortran/56385
"Maciej W. Rozycki" writes:
> This issue was originally raised here:
>
> http://gcc.gnu.org/ml/gcc-patches/2012-12/msg00863.html
>
> We have a shortcoming in GCC in that we only allow the use half of the FP
> MADD instruction subset (MADD.fmt and MSUB.fmt) in the 64-bit/32-register
> mode (CP0
On Thu, 21 Feb 2013, Jakub Jelinek wrote:
> Hi!
>
> If an input operand of inline-asm doesn't allow registers, but allows
> memory, we expand it with EXPAND_MEMORY modifier (the only case of using
> that modifier). But the movmisalign code added for 4.6 and especially
> the extract_bit_field cod
On Thu, 21 Feb 2013, Jakub Jelinek wrote:
> Hi!
>
> Currently it is not possible to bootstrap gcc with texinfo 5.0.
> This patch attempts to fix the errors that prevent bootstrap, there are tons
> of warnings this doesn't address and would be good if somebody more TeXinfo
> knowledgeable looked a
Motivated by Jakub's email at
http://gcc.gnu.org/ml/gcc-patches/2013-02/msg00966.html
The problem was that the order in @menu didn't match the order of the
@node (@section/@chapter).
I have committed the attached patch as obvious (Rev. 196194).
fortran/*.texi is now warning free for "make in
On Thu, Feb 21, 2013 at 10:07:56AM +0100, Richard Biener wrote:
> > Ok for trunk?
>
> Ok. Should we fix the error on branches as well?
The patch applied cleanly to both 4.7 and 4.6, so I've committed it there,
but as I don't have texinfo 5.0 installed on my devel WS (we have it just
for Fedora 1
On Thu, Feb 21, 2013 at 1:10 AM, Steven Bosscher wrote:
> Hello,
>
> The attached patch splits a new function df_insn_info_delete from
> df_insn_delete. The original motivation was to get rid of the silly
> "deleting insn with uid = ..." messages when re-scanning an insn,
> because the mentioned i
This adds a reduced testcase for PR56398. Ok for trunk?
2013-02-21 Marek Polacek
PR tree-optimization/56398
* g++.dg/torture/pr56398.C: New test.
--- gcc/g++.dg/torture/pr56398.C.mp 2013-02-21 10:58:14.388913070 +0100
+++ gcc/g++.dg/torture/pr56398.C2013-02-21 10
On Thu, Feb 21, 2013 at 11:05 AM, Marek Polacek wrote:
> This adds a reduced testcase for PR56398. Ok for trunk?
Ok.
Thanks,
Richard.
> 2013-02-21 Marek Polacek
>
> PR tree-optimization/56398
> * g++.dg/torture/pr56398.C: New test.
>
> --- gcc/g++.dg/torture/pr56398.C.mp
Hunting for the "we're getting slower" bits I noticed that
TODO_remove_unused_locals is a big part of execute_function_todo
(and accounts for 1% of compile-time of ac.f90).
The following patch removes most of the remove_unused_locals
calls based on the fact that with anonymous SSA names now avai
On Thu, Feb 21, 2013 at 10:59 AM, Richard Biener wrote:
> On Thu, Feb 21, 2013 at 1:10 AM, Steven Bosscher wrote:
> +/* Delete all of the refs information from the insn with UID.
> + Internal helper for df_insn_info_delete, df_insn_rescan, and other
>
> df_insn_delete I suppose
Right.
> + df
On Thu, 21 Feb 2013, Jan Hubicka wrote:
>
> > > Hunting for the "we're getting slower" bits I noticed that
> > > TODO_remove_unused_locals is a big part of execute_function_todo
> > > (and accounts for 1% of compile-time of ac.f90).
> > > The following patch removes most of the remove_unused_loca
On Thu, Feb 21, 2013 at 02:16:19PM +0400, Konstantin Serebryany wrote:
> The attached patch is the libsanitizer merge from upstream r175042.
>
> A few changes. Among other things:
> - a second attempt to change the shadow offset to 0x7fff8000 (~5%
> speedup). x86_64-linux-only
I've been applying
On Wed, Feb 20, 2013 at 4:41 PM, Yuri Rumyantsev wrote:
> Richard,
>
> First of all, your proposal to move type sinking to the end of
> function does not work since we handle each statement in function and
> we want that 1st type folding of X & C will not happen.
> Note that we have the following
> > so it needs someone DF aware to review
> > and that makes it stage1 material as well I think.
>
> Also good. I think the patch is quite safe but it's obviously not a
> bug fix (except perhaps for making the dumps less confusing). Let's
> consider this queued for GCC 4.9.
> FWIW, I like to thi
>> here is a straightforward patch which fixes a regression with
>> procedure-pointer components which have an allocatable result.
>> Regtests cleanly on x86_64-unknown-linux-gnu. Ok for trunk/4.7/4.6?
>
>
> OK thanks for the patch.
Thanks, Tobias! Committed to trunk as r196202. Will apply to 4.7
Richard,
As we know Kai is working on this problem for 4.9 and I assume that
type sinking will be deleted from forwprop pass. Could we stay on this
fix but more common fix will be done.
I also can propose to introduce new hook for it but need to know your
opinion since we don't went to waste our t
On Thu, Feb 21, 2013 at 1:39 PM, Yuri Rumyantsev wrote:
> Richard,
>
> As we know Kai is working on this problem for 4.9 and I assume that
> type sinking will be deleted from forwprop pass. Could we stay on this
> fix but more common fix will be done.
Well, unless you show it is a regression the
On Thu, Feb 21, 2013 at 05:15:51PM +0400, Konstantin Serebryany wrote:
> This commit breaks the build if the BFD linker is used (I have gold on
> my box, so I missed it).
>
> Short repro:
> % cat preinit.cc
> void foo() {}
> __attribute__((section(".preinit_array"))) void (*xxx)(void) = foo;
> %
On Thu, Feb 21, 2013 at 02:21:36PM +0100, Jakub Jelinek wrote:
> Here is a different fix, so libasan.so will not have .preinit_array, but
> libasan.a will have it. Ideally, that hunk should go into a separate
> source file (asan_preinit.cc ?), be just compiled into an object file,
> rather than sh
On Thu, Feb 21, 2013 at 5:21 PM, Jakub Jelinek wrote:
> On Thu, Feb 21, 2013 at 05:15:51PM +0400, Konstantin Serebryany wrote:
>> This commit breaks the build if the BFD linker is used (I have gold on
>> my box, so I missed it).
>>
>> Short repro:
>> % cat preinit.cc
>> void foo() {}
>> __attribut
On Thu, Feb 21, 2013 at 05:26:30PM +0400, Konstantin Serebryany wrote:
> May I ask you to commit this to gcc (I have to run away now)?
I'll get it through bootstrap/regtest cycle first, commit if that succeeds.
Jakub
Richard,
This regression was introduced by Kai
http://gcc.gnu.org/ml/gcc-patches/2011-06/msg01988.html
2011-06-27 Kai Tietz
* tree-ssa-forwprop.c (simplify_bitwise_binary): Improve
type sinking.
* tree-ssa-math-opts.c (execute_optimize_bswap): Separate
search
On Thu, Feb 21, 2013 at 2:41 PM, Yuri Rumyantsev wrote:
> Richard,
>
> This regression was introduced by Kai
>
> http://gcc.gnu.org/ml/gcc-patches/2011-06/msg01988.html
>
> 2011-06-27 Kai Tietz
>
> * tree-ssa-forwprop.c (simplify_bitwise_binary): Improve
> type sinking.
>
An auto generated program with a 6.4mio line asm statement gave
with 4.7 and 4.8:
xxx.c:6400017:1: internal compiler error: in account_size_time, at
ipa-inline-analysis.c:601
The problem is that the inliner counts the number of lines in the asm
statement and multiplies that with a weight. With th
This commit (r196201) causes a lot of bootstrap failures
(including x86_64-apple-darwin10), see
http://gcc.gnu.org/ml/gcc-regression/2013-02/
TIA
Dominique
Richard,
I double checked that with and without my fix compiler produces the
same output with -fdump-tree-optimized.
What patch did you apply? I think that you should apply the second one
- 56175.diff.
Yuri.
2013/2/21 Richard Biener :
> On Thu, Feb 21, 2013 at 2:41 PM, Yuri Rumyantsev wrote:
>
The failure on x86_64-apple-darwin10 is
...
true "AR_FLAGS=rc" "CC_FOR_BUILD=gcc"
"CC_FOR_TARGET=/opt/gcc/build_w/./gcc/xgcc -B/opt/gcc/build_w/./gcc/"
"CFLAGS=-g -O2 -m32" "CXXFLAGS=-g -O2 -m32" "CFLAGS_FOR_BUILD=-g -O2"
"CFLAGS_FOR_TARGET=-g -O2" "INSTALL=/sw64/bin/ginstall -c"
"INSTALL_DA
On Thu, Feb 21, 2013 at 03:29:40PM +0100, Dominique Dhumieres wrote:
> The failure on x86_64-apple-darwin10 is
>
> ...
> true "AR_FLAGS=rc" "CC_FOR_BUILD=gcc"
> "CC_FOR_TARGET=/opt/gcc/build_w/./gcc/xgcc -B/opt/gcc/build_w/./gcc/"
> "CFLAGS=-g -O2 -m32" "CXXFLAGS=-g -O2 -m32" "CFLAGS_FOR_BUILD
On 21/02/13 14:05, Andi Kleen wrote:
An auto generated program with a 6.4mio line asm statement gave
with 4.7 and 4.8:
xxx.c:6400017:1: internal compiler error: in account_size_time, at
ipa-inline-analysis.c:601
The problem is that the inliner counts the number of lines in the asm
statement and
On Thu, Feb 21, 2013 at 3:26 PM, Yuri Rumyantsev wrote:
> Richard,
>
> I double checked that with and without my fix compiler produces the
> same output with -fdump-tree-optimized.
For what testcase?
Richard.
> What patch did you apply? I think that you should apply the second one
> - 56175.dif
On Thu, Feb 21, 2013 at 03:45:04PM +0100, Jakub Jelinek wrote:
> On Thu, Feb 21, 2013 at 03:29:40PM +0100, Dominique Dhumieres wrote:
> > The failure on x86_64-apple-darwin10 is
> >
> > ...
> > true "AR_FLAGS=rc" "CC_FOR_BUILD=gcc"
> > "CC_FOR_TARGET=/opt/gcc/build_w/./gcc/xgcc -B/opt/gcc/build_w
On Thu, Feb 21, 2013 at 10:06:12AM -0500, Jack Howarth wrote:
> Index: libsanitizer/asan/Makefile.am
> ===
> --- libsanitizer/asan/Makefile.am (revision 196205)
> +++ libsanitizer/asan/Makefile.am (working copy)
> @@ -37,7 +37
Richard,
Sorry for my previous message - I did not undersatnd it properly.
Anyway I proposed another fix that avoid (type) x & c --> (type) (x &
(type-x) c) transformation if x has short type:
+++ gcc/tree-ssa-forwprop.c (working copy)
@@ -1789,8 +1789,11 @@
defcodefor_name (arg1, &def1_
On Thu, Feb 21, 2013 at 4:16 PM, Yuri Rumyantsev wrote:
> Richard,
>
> Sorry for my previous message - I did not undersatnd it properly.
>
> Anyway I proposed another fix that avoid (type) x & c --> (type) (x &
> (type-x) c) transformation if x has short type:
>
> +++ gcc/tree-ssa-forwprop.c
On Thu, Feb 21, 2013 at 04:11:56PM +0100, Jakub Jelinek wrote:
> On Thu, Feb 21, 2013 at 10:06:12AM -0500, Jack Howarth wrote:
>
> > Index: libsanitizer/asan/Makefile.am
> > ===
> > --- libsanitizer/asan/Makefile.am (revision 196205
Richard,
This does not fit to my fix since if we have another pattern like
t = (u8)((x & 1) ^ ((u8)y & 1));
where y has short type, for rhs operand type sinkning (or hoisting as
you prefer) still will be performed but I don't see any reason for
converting (u8)y & 1 --> (u8)(y & 1) if y has u
> That doesn't sound enough, unless there is already code out there
> that respects this count. 1000 at 4 bytes per instruction is only
> 4k. More that small enough for the rest of the compiler to think
> that it could jump around such blocks cheaply.
>
> I think a limit of 1M or more might be
The attached patch fixes the broken bootstrap on darwin in libsanitizer due
to the
deprecation of the dynamic/asan_interceptors_dynamic.cc file. The patch also
eliminates
the merge of the deprecated subdirectory in merge.sh. Bootstrap and asan.exp
regression
tested on x86_64-apple-darwin12. Ok
This is a follow up to Jakub's patch.
With texinfo 5.0 one gets a bunch of warnings. This patch reduces the
number of warnings – but there are still warnings to be fixed.
This patch solves most of the issues related to mismatches between the
item order in the @menu and the actual @nodes. As a
How about the attached file as a start for . I used the
constexpr approach (instead of function calls) and replicated the
constants that are available in in Unix.
What other constants to add?
math
Description: Binary data
Tobias Burnus writes:
> PS: I tried the following libiberty patch; it fixes a warning with texinfo
> 5.0. But I do not include it as it fails for some reason with an error
> with texinfo 4.13:
> ../../libiberty/libiberty.texi:250: Prev field of node `Functions' not
> pointed to.
> ../../libiberty
On Thu, 21 Feb 2013, Richard Sandiford wrote:
> > This issue was originally raised here:
> >
> > http://gcc.gnu.org/ml/gcc-patches/2012-12/msg00863.html
> >
> > We have a shortcoming in GCC in that we only allow the use half of the FP
> > MADD instruction subset (MADD.fmt and MSUB.fmt) in the 6
Hi!
This patch teaches lower-subreg pass to also handle ASHIFTRTs with
BITS_PER_WORD to 2*BITS_PER_WORD-1 constant shift counts, like it already
handles similar LSHIFTRTs.
While for LSHIFTRT we should zero the upper half, for ASHIFTRT we either
should set it to upper source half >> (BITS_PER_WORD-
> From: Hans-Peter Nilsson
> Date: Mon, 28 Jan 2013 23:14:21 +0100
> * doc/rtl.texi (vec_concat, vec_duplicate): Mention that
> scalars are valid operands.
Finally committed as obvious after brief check of generated dvi
and info.
brgds, H-P
2013/2/21 Ulrich Drepper :
> How about the attached file as a start for . I used the
> constexpr approach (instead of function calls) and replicated the
> constants that are available in in Unix.
1) In this case I miss the corresponding variable definitions, because
you violate the ODR, when you
> This was not for jump shortening, but the inliner heuristics.
>
> In the worst case we could separate the two, would be a larger
> patch though.
Actually it's already separated, I don't affect the jump shortening
at all. Only the inliner code adds the limit.
So it would depend whether 1000 * w
On 21/02/13 16:32, Ulrich Drepper wrote:
How about the attached file as a start for . I used the
constexpr approach (instead of function calls) and replicated the
constants that are available in in Unix.
What other constants to add?
Pi/3
ln(3)
ln(10) (for base conversions)
sqrt(3)
sqrt(5)
sqr
Adding myself as Write After Approval maintainer.
Andrew Sutton
andrew.n.sut...@gmail.com
Index: ChangeLog
===
--- ChangeLog (revision 196207)
+++ ChangeLog (working copy)
@@ -1,3 +1,7 @@
+2013-02-20 Andrew Sutton
+
+ *
> > How about the attached file as a start for . I used the
> > constexpr approach (instead of function calls) and replicated the
> > constants that are available in in Unix.
then this should really be
ext/cmath
>
> 1) In this case I miss the corresponding variable definitions, because
> yo
Thanks!
Does this need to regenerate libsanitizer/asan/Makefile.in ?
(It'll take a while for me to do this on Mac)
--kcc
On Thu, Feb 21, 2013 at 8:04 PM, Jack Howarth wrote:
> The attached patch fixes the broken bootstrap on darwin in libsanitizer due
> to the
> deprecation of the dynamic/as
On 02/20/2013 07:35 AM, Aldy Hernandez wrote:
> In the following test, the first statement of a relaxed transaction is
> an inline asm:
>
> __transaction_relaxed { __asm__(""); }
>
> Since we bypass inserting BUILT_IN_TM_IRREVOCABLE at the beginning of
> transactions that are sure to be irrevoc
> > This was not for jump shortening, but the inliner heuristics.
> >
> > In the worst case we could separate the two, would be a larger
> > patch though.
>
> Actually it's already separated, I don't affect the jump shortening
> at all. Only the inliner code adds the limit.
>
> So it would depen
> So I am fine with the cutoff. We may need to add more overflow guards (we
> already have quite few for time) that makes me wonder if all this should not
> be
> done all in saturating arithmetic now when it can be done theoretically with
> one
> C++ class?
Sounds like a good idea, although I d
On 21/02/13 15:59, Andi Kleen wrote:
That doesn't sound enough, unless there is already code out there
that respects this count. 1000 at 4 bytes per instruction is only
4k. More that small enough for the rest of the compiler to think
that it could jump around such blocks cheaply.
I think a li
On 02/21/13, Alec Teal wrote:
On 21/02/13 16:32, Ulrich Drepper wrote:
> How about the attached file as a start for . I used the
> constexpr approach (instead of function calls) and replicated the
> constants that are available in in Unix.
>
> What other constants to add?
Pi/3
ln(3)
ln(10) (fo
On 02/21/2013 08:42 AM, Jakub Jelinek wrote:
> @@ -1243,12 +1258,20 @@ resolve_shift_zext (rtx insn)
>dest_reg = simplify_gen_subreg_concatn (word_mode, SET_DEST (set),
>GET_MODE (SET_DEST (set)),
>offset1);
On Thu, Feb 21, 2013 at 10:40:18AM -0800, Richard Henderson wrote:
> Am I missing something? This looks like it would clobber the input too
> early in the case of
>
> (set (reg:DI x) (ashiftrt (reg:DI x) (const_int 60)))
>
> where src_reg and dest_upper could resolve to the same concatn, a
On 02/21/2013 10:58 AM, Jakub Jelinek wrote:
> So, do you prefer e.g. the following, or would you instead prefer
> that I just set some rtx to copy_rtx (src_reg) before the
> if (GET_CODE (op) != ZERO_EXTEND)
> {
> ...
> }
> block and do the >> (BITS_PER_WORD - 1) shift only after this (the
On Thu, 2013-02-21 at 17:14 +, Alec Teal wrote:
> On 21/02/13 16:32, Ulrich Drepper wrote:
> > How about the attached file as a start for . I used the
> > constexpr approach (instead of function calls) and replicated the
> > constants that are available in in Unix.
> >
> > What other constant
On 07/11/2012 00:14, Magnus Granberg wrote:
> 2012-11-07 Magnus Granberg Pavel Labushev
>* configure.ac: Add --enable-pax_emutramp for PaX enable kernels.
>* src/closures.c: Add emutramp_enabled_check. Don't mmap with PROT_EXEC
> on PaX enable Ke
On Thu, Feb 21, 2013 at 08:06:02PM +0100, Oleg Endo wrote:
> On Thu, 2013-02-21 at 17:14 +, Alec Teal wrote:
> > On 21/02/13 16:32, Ulrich Drepper wrote:
> > > How about the attached file as a start for . I used the
> > > constexpr approach (instead of function calls) and replicated the
> > >
On Thu, Feb 21, 2013 at 2:22 PM, Dave Korn wrote:
> Gcc-patches: Assuming AG approves, can we commit this without waiting for an
> upstream libffi release and doing a full merge? Currently GCC HEAD won't
> build libffi (and hence libjava) without it.
This patch looks fine, thanks. I don't pla
"Moore, Catherine" writes:
>> Looks good otherwise, but please post an updated patch. It's probably
>> stating the obvious, but the patch is too invasive for this late stage
>> of 4.8, so
>> it'll need to wait until 4.9.
>>
>
> The updated patch is attached. How's it looking this time?
Almost
Hi!
I've committed the following fix for the following testcase.
When scalar_op1 is 0x8000 with 64-bit HWI,
it matches EXACT_POWER_OF_2_OR_ZERO_P, but we should expand it as
negation of the << 63 shift rather than the << 63 shift alone.
The patch also improves multipli
On Feb 20, 2013, at 3:50 PM, Maciej W. Rozycki wrote:
> BTW, do you happen to know a way to reliable force all our testsuites NOT
> to delete executables after run? Personally I think it's missing the
> point to have them deleted -- how can one debug any regressions then?
So, I go into the sou
It has come to my attention, by..ahem...you, that in handling the
testcase from my previous patch:
__transaction_relaxed { __asm__(""); }
...if we avoid instrumentation altogether, we shouldn't lie to the
run-time and pass PR_INSTRUMENTEDCODE.
I suppose we could cheat and avoid passing PR_
2013/2/21 Benjamin De Kosnik :
>
>> > How about the attached file as a start for . I used the
>> > constexpr approach (instead of function calls) and replicated the
>> > constants that are available in in Unix.
>
> then this should really be
>
> ext/cmath
>
>>
>> 1) In this case I miss the corres
>> What do other people do?
>
> We usually can cut and paste the one line and run the one case by hand. Test
> cases that don't fall into this category, well, suck, I mean, are more
> annoying.
>
These days I find contrib/repro_fail
file.log.useful to rebuild the failing test(s).
regards
Rama
On Mon, Feb 18, 2013 at 12:50:59PM -0600, Aldy Hernandez wrote:
> OK pending tests?
> PR target/52555
> * genopinit.c (raw_optab_handler): Use this_fn_optabs.
> (swap_optab_enable): Same.
> (init_all_optabs): Use argument instead of global.
> * tree.h (struct tree_op
Have you gotten any reports of problems with this patch? It seems to be
sending cc1 into an infinite
loop during the GCC testsuite for me. I am testing the mips-mti-linux-gnu
target and tests like
gcc.target/mips/call-saved-1.c are causing cc1 to suck up all my memory and
swap space before
On Thu, Feb 21, 2013 at 4:18 PM, Daniel Krügler
wrote:
> 2013/2/21 Benjamin De Kosnik :
>>
>>> > How about the attached file as a start for . I used the
>>> > constexpr approach (instead of function calls) and replicated the
>>> > constants that are available in in Unix.
>>
>> then this should r
On Thu, Feb 21, 2013 at 07:19:10PM +0100, Andi Kleen wrote:
> > So I am fine with the cutoff. We may need to add more overflow guards (we
> > already have quite few for time) that makes me wonder if all this should
> > not be
> > done all in saturating arithmetic now when it can be done theoretic
Jakub, thanks again for cleaning up my mess.
Here is a question regarding your fix:
> -#if ASAN_USE_PREINIT_ARRAY
> +#if ASAN_USE_PREINIT_ARRAY && !defined (PIC)
The PIC macro is an artifact of the GCC build system and is not
directly related the the -fPIC flag?
As I can see, in the gcc build we
75 matches
Mail list logo
