Re: [GSoC] Elimination of CLooG library installation dependency
Thank you for the report! > (1) FAIL: gcc.dg/graphite/vect-pr43423.c scan-tree-dump-times vect > "vectorized 2 loops" 1 > > before I saw > > [Book15] f90/bug% grep vectorized vect-pr43423.c.114t.vect > /opt/gcc/p_work/gcc/testsuite/gcc.dg/graphite/vect-pr43423.c:14:17: note: === > vect_mark_stmts_to_be_vectorized === > /opt/gcc/p_work/gcc/testsuite/gcc.dg/graphite/vect-pr43423.c:14:17: note: > loop vectorized > /opt/gcc/p_work/gcc/testsuite/gcc.dg/graphite/vect-pr43423.c:12:17: note: === > vect_mark_stmts_to_be_vectorized === > /opt/gcc/p_work/gcc/testsuite/gcc.dg/graphite/vect-pr43423.c:12:17: note: > loop vectorized > /opt/gcc/p_work/gcc/testsuite/gcc.dg/graphite/vect-pr43423.c:6:6: note: > vectorized 2 loops in function. > > after I see > > [Book15] f90/bug% grep vectorized vect-pr43423.c.115t.vect > > /opt/gcc/p_work/gcc/testsuite/gcc.dg/graphite/vect-pr43423.c:14:17: note: not > vectorized: not suitable for gather load _55 = a[_56]; > /opt/gcc/p_work/gcc/testsuite/gcc.dg/graphite/vect-pr43423.c:12:17: note: not > vectorized: not suitable for gather load _36 = a[_37]; > /opt/gcc/p_work/gcc/testsuite/gcc.dg/graphite/vect-pr43423.c:6:6: note: > vectorized 0 loops in function. We’ve already met with this problem. https://gcc.gnu.org/ml/gcc-patches/2014-08/msg00118.html https://gcc.gnu.org/ml/gcc-patches/2014-08/msg00155.html https://gcc.gnu.org/ml/gcc-patches/2014-08/msg00173.html In our opinion, it requires help of the vectorizer people. Maybe it’ll disappear by itself, when the computation of types is finished. > (2) FAIL: gfortran.dg/graphite/pr42393.f90 -O (internal compiler error) > FAIL: gfortran.dg/graphite/pr42393.f90 -O (test for excess errors) > > The backtrace is > > * thread #1: tid = 0x13bd91f, 0x7fff8621aca0 > libsystem_malloc.dylib`tiny_malloc_from_free_list + 12, queue = > 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=2, > address=0x7fff5bc00ff8) > frame #0: 0x7fff8621aca0 > libsystem_malloc.dylib`tiny_malloc_from_free_list + 12 > libsystem_malloc.dylib`tiny_malloc_from_free_list + 12: > -> 0x7fff8621aca0: pushq %rbx >0x7fff8621aca1: pushq %rax >0x7fff8621aca2: movl %edx, %r12d >0x7fff8621aca5: movq %rsi, %r14 > (lldb) bt > * thread #1: tid = 0x13bd91f, 0x7fff8621aca0 > libsystem_malloc.dylib`tiny_malloc_from_free_list + 12, queue = > 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=2, > address=0x7fff5bc00ff8) > * frame #0: 0x7fff8621aca0 > libsystem_malloc.dylib`tiny_malloc_from_free_list + 12 > frame #1: 0x7fff8621b3c3 > libsystem_malloc.dylib`szone_malloc_should_clear + 320 > frame #2: 0x7fff8621d868 libsystem_malloc.dylib`malloc_zone_malloc + > 71 > frame #3: 0x7fff8621e27c libsystem_malloc.dylib`malloc + 42 > frame #4: 0x000141dbdc79 libgmp.10.dylib`__gmp_default_allocate + 9 > frame #5: 0x000141dd0148 libgmp.10.dylib`__gmpz_init + 24 > frame #6: 0x000141c180ef > libisl.10.dylib`isl_basic_map_normalize_constraints + 47 > frame #7: 0x000141c18f04 libisl.10.dylib`isl_basic_map_simplify + 68 > frame #8: 0x000141c2509b libisl.10.dylib`isl_basic_set_preimage + 619 > frame #9: 0x000141c4e146 > libisl.10.dylib`isl_basic_set_sample_with_cone + 150 > frame #10: 0x000141c4ea88 libisl.10.dylib`basic_set_sample + 744 > frame #11: 0x000141c4e849 libisl.10.dylib`basic_set_sample + 169 > frame #12: 0x000141c09978 libisl.10.dylib`isl_basic_map_is_empty + 136 > frame #13: 0x000141bb2870 libisl.10.dylib`domain_follows_at_depth + > 112 > frame #14: 0x000141c7cdba libisl.10.dylib`isl_tarjan_components + 154 > > getting to the ICE take ~19s compared to less than a second before r214069. This is a bug in ISL. They’ll fix it in a new version of ISL. https://groups.google.com/forum/#!topic/isl-development/SeNZf5IA-Lk -- Cheers, Roman Gareev.
Re: [patch, fortran] use vec<> in frontend-passes.c
On Sun, Aug 24, 2014 at 12:47:17AM +0200, Thomas Koenig wrote: > Hello world, > > the attached patch uses the vec<> templates instead of the > home-grown memory management. > > Did I get the style right? I was a bit confused because, with > the declarations used in the patch, using the vec_safe_truncate > function failed with a failure to find the right template. > I'm not an experienced C++ programmer, so I would appreciate a quick > look at what I did. > > Regression-tested. No test case because there is no new > OK for trunk? Any other comments? > Does this fix a bug in gfortran? "If it is not broken, don't fix it". -- Steve
Re: [wwwdocs] Buildstat update for 4.9
On Sun, 17 Aug 2014, Tom G. Christensen wrote: > Latest results for 4.9.x > > -tgc > > Testresults for 4.9.1: > arm-unknown-linux-gnueabihf > hppa2.0w-hp-hpux11.11 > hppa64-hp-hpux11.11 > i386-pc-solaris2.9 > i686-pc-linux-gnu > powerpc-apple-darwin8.11.0 > sparc-sun-solaris2.9 > sparc64-sun-solaris2.9 > x86_64-unknown-linux-gnu > x86_64-w64-mingw32 Applied, thank you, Tom! I am wondering, should we consider merging i686-pc-linux-gnu and i686-unknown-linux-gnu? It's practically the same, isn't it? Gerald
Re: [PATCH] make excessive template instantiation depth a fatal error
PING: https://gcc.gnu.org/ml/gcc-patches/2014-08/msg01709.html On 18 August 2014 00:03, Manuel López-Ibáñez wrote: > Following a suggestion in PR16564, this patch makes excessive template > instantiation depth a fatal error. In fact, this allows simplifying > the code a lot, just by printing first the context (like we do for > every other diagnostic) instead of printing it after (which is not > possible for a fatal error). > > This changes the output of quite a few testcases, so before modifying > those I would like to know whether the idea is OK. > > Examples of changed output are: > > [Before] > g++.dg/cpp0x/decltype26.C:6:15: error: template instantiation depth > exceeds maximum of 900 (use -ftemplate-depth= to increase the maximum) > substituting 'template decltype (f(T())) f(T) [with T = > ]' > g++.dg/cpp0x/decltype26.C:6:15: recursively required by substitution > of 'template decltype (f(T())) f(T) [with T = A]' > g++.dg/cpp0x/decltype26.C:6:15: required by substitution of > 'template decltype (f(T())) f(T) [with T = A]' > g++.dg/cpp0x/decltype26.C:13:8: required from here > > g++.dg/cpp0x/decltype26.C: In function 'int main()': > g++.dg/cpp0x/decltype26.C:13:8: error: no matching function for call to 'f(A)' > g++.dg/cpp0x/decltype26.C:6:18: note: candidate: template > decltype (f(T())) f(T) > g++.dg/cpp0x/decltype26.C:6:18: note: substitution of deduced > template arguments resulted in errors seen above > > [After] > > g++.dg/cpp0x/decltype26.C: In substitution of 'template > decltype (f(T())) f(T) [with T = A]': > g++.dg/cpp0x/decltype26.C:6:15: recursively required by substitution > of 'template decltype (f(T())) f(T) [with T = A]' > g++.dg/cpp0x/decltype26.C:6:15: required by substitution of > 'template decltype (f(T())) f(T) [with T = A]' > g++.dg/cpp0x/decltype26.C:13:8: required from here > g++.dg/cpp0x/decltype26.C:6:15: fatal error: template instantiation > depth exceeds maximum of 900 (use -ftemplate-depth= to increase the > maximum) > > > One interesting case is for operator->(). Here we have to adjust > the location of the template instantiations so we can point the > user to the point of recursion: > > [Before] > > g++.dg/template/arrow1.C:12:11: error: template instantiation depth > exceeds maximum of 900 (use -ftemplate-depth= to increase the maximum) > instantiating 'a<(n + 1)> a::operator->() [with int n = 900]' > g++.dg/template/arrow1.C:12:11: recursively required from 'a<(n + > 1)> a::operator->() [with int n = 0]' > g++.dg/template/arrow1.C:12:11: required from here > > g++.dg/template/arrow1.C:12:11: error: template instantiation depth > exceeds maximum of 900 (use -ftemplate-depth= to increase the maximum) > instantiating 'struct a<901>' > g++.dg/template/arrow1.C:12:11: recursively required from 'a<(n + > 1)> a::operator->() [with int n = 0]' > g++.dg/template/arrow1.C:12:11: required from here > > g++.dg/template/arrow1.C:12:11: error: invalid use of incomplete type > 'struct a<901>' > g++.dg/template/arrow1.C:5:8: note: declaration of 'struct a<901>' > > [After] > > g++.dg/template/arrow1.C: In instantiation of 'a<(n + 1)> > a::operator->() [with int n = 899]': > g++.dg/template/arrow1.C:7:2: recursively required from 'a<(n + 1)> > a::operator->() [with int n = 1]' > g++.dg/template/arrow1.C:7:2: required from 'a<(n + 1)> > a::operator->() [with int n = 0]' > g++.dg/template/arrow1.C:12:11: required from here > g++.dg/template/arrow1.C:12:11: fatal error: template instantiation > depth exceeds maximum of 900 (use -ftemplate-depth= to increase the > maximum) > > The rest of testcases follow the pattern: > > [Before] > > g++.dg/template/pr23510.C:9:1: error: expected ';' after struct definition > g++.dg/template/pr23510.C:6:27: error: template instantiation depth > exceeds maximum of 15 (use -ftemplate-depth= to increase the maximum) > instantiating 'struct Factorial<5u>' > g++.dg/template/pr23510.C:6:27: recursively required from 'struct > Factorial<19u>' > g++.dg/template/pr23510.C:6:27: required from 'struct Factorial<20u>' > g++.dg/template/pr23510.C:21:20: required from here > > [After] > > g++.dg/template/pr23510.C:9:1: error: expected ';' after struct definition > g++.dg/template/pr23510.C: In instantiation of 'struct Factorial<6u>': > g++.dg/template/pr23510.C:6:27: recursively required from 'struct > Factorial<19u>' > g++.dg/template/pr23510.C:6:27: required from 'struct Factorial<20u>' > g++.dg/template/pr23510.C:21:20: required from here > g++.dg/template/pr23510.C:6:27: fatal error: template instantiation > depth exceeds maximum of 15 (use -ftemplate-depth= to increase the > maximum) > > Apart from these changes, the patch bootstraps and passes the > regression suite on x86_64-linux. > > OK with the updated testcases? > > gcc/cp/ChangeLog: > > 2014-08-17 Manuel López-Ibáñez > > * error.c (print_instantiation_context): Delete. > * typeck2.c (build_x_arrow): Record location when pushing > template instantiation
Re: [wwwdocs] Buildstat update for 4.9
On 24/08/14 10:45, Gerald Pfeifer wrote: I am wondering, should we consider merging i686-pc-linux-gnu and i686-unknown-linux-gnu? It's practically the same, isn't it? I did consider it, but I don't think it's really a problem to have them both listed and since I don't really know what the difference is between the two, I decided not to merge them. It also makes the work simpler not to have to make such an editorial decision. -tgc
[SH][committed] Fix PR 61996
Hi,
The attached patch fixes PR 61996 and does some minor documentation
fixes. Committed to trunk (r214406), 4.9 (r214407) and 4.8 (r214408).
Tested with 'make all', verifying that the new test case passes for m1*
and m2* targets and with 'make info dvi pdf'.
Cheers,
Oleg
gcc/ChangeLog:
PR target/61996
* config/sh/sh.opt (musermode): Allow negative form.
* config/sh/sh.c (sh_option_override): Disable TARGET_USERMODE for
targets that don't support it.
* doc/invoke.texi (SH Options): Rename sh-*-linux* to sh*-*-linux*.
Document -mno-usermode option.
gcc/testsuite/ChangeLog:
PR target/61996
* gcc.target/sh/pr61996.c: New.
Index: gcc/config/sh/sh.opt
===
--- gcc/config/sh/sh.opt (revision 214396)
+++ gcc/config/sh/sh.opt (working copy)
@@ -343,7 +343,7 @@
Cost to assume for a multiply insn
musermode
-Target Report RejectNegative Var(TARGET_USERMODE)
+Target Var(TARGET_USERMODE)
Don't generate privileged-mode only code; implies -mno-inline-ic_invalidate if the inline code would not work in user mode.
;; We might want to enable this by default for TARGET_HARD_SH4, because
Index: gcc/config/sh/sh.c
===
--- gcc/config/sh/sh.c (revision 214396)
+++ gcc/config/sh/sh.c (working copy)
@@ -886,6 +886,12 @@
targetm.asm_out.aligned_op.di = NULL;
targetm.asm_out.unaligned_op.di = NULL;
}
+
+ /* User/priviledged mode is supported only on SH3*, SH4* and SH5*.
+ Disable it for everything else. */
+ if (! (TARGET_SH3 || TARGET_SH5) && TARGET_USERMODE)
+TARGET_USERMODE = false;
+
if (TARGET_SH1)
{
if (! strcmp (sh_div_str, "call-div1"))
Index: gcc/testsuite/gcc.target/sh/pr61996.c
===
--- gcc/testsuite/gcc.target/sh/pr61996.c (revision 0)
+++ gcc/testsuite/gcc.target/sh/pr61996.c (revision 0)
@@ -0,0 +1,12 @@
+/* Check that the option -musermode has no effect on targets that do not
+ support user/privileged mode and that it does not interfere with option
+ -matomic-model=soft-imask. */
+/* { dg-do compile } */
+/* { dg-options "-matomic-model=soft-imask" } */
+/* { dg-skip-if "" { "sh*-*-*" } { "*"} { "-m1*" "-m2*" } } */
+
+int
+test (void)
+{
+ return 0;
+}
Index: gcc/doc/invoke.texi
===
--- gcc/doc/invoke.texi (revision 214396)
+++ gcc/doc/invoke.texi (working copy)
@@ -20898,7 +20898,7 @@
@item -mieee
@itemx -mno-ieee
@opindex mieee
-@opindex mnoieee
+@opindex mno-ieee
Control the IEEE compliance of floating-point comparisons, which affects the
handling of cases where the result of a comparison is unordered. By default
@option{-mieee} is implicitly enabled. If @option{-ffinite-math-only} is
@@ -20938,14 +20938,14 @@
@item none
Disable compiler generated atomic sequences and emit library calls for atomic
-operations. This is the default if the target is not @code{sh-*-linux*}.
+operations. This is the default if the target is not @code{sh*-*-linux*}.
@item soft-gusa
Generate GNU/Linux compatible gUSA software atomic sequences for the atomic
built-in functions. The generated atomic sequences require additional support
from the interrupt/exception handling code of the system and are only suitable
for SH3* and SH4* single-core systems. This option is enabled by default when
-the target is @code{sh-*-linux*} and SH3* or SH4*. When the target is SH4A,
+the target is @code{sh*-*-linux*} and SH3* or SH4*. When the target is SH4A,
this option will also partially utilize the hardware atomic instructions
@code{movli.l} and @code{movco.l} to create more efficient code, unless
@samp{strict} is specified.
@@ -20964,7 +20964,7 @@
in privileged mode and is only suitable for single-core systems. Additional
support from the interrupt/exception handling code of the system is not
required. This model is enabled by default when the target is
-@code{sh-*-linux*} and SH1* or SH2*.
+@code{sh*-*-linux*} and SH1* or SH2*.
@item hard-llcs
Generate hardware atomic sequences using the @code{movli.l} and @code{movco.l}
@@ -21005,11 +21005,14 @@
the Global Offset Table instead of the Procedure Linkage Table.
@item -musermode
+@itemx -mno-usermode
@opindex musermode
-Don't generate privileged mode only code. This option
-implies @option{-mno-inline-ic_invalidate}
-if the inlined code would not work in user mode.
-This is the default when the target is @code{sh-*-linux*}.
+@opindex mno-usermode
+Don't allow (allow) the compiler generating privileged mode code. Specifying
+@option{-musermode} also implies @option{-mno-inline-ic_invalidate} if the
+inlined code would not work in user mode. @option{-musermode} is the default
+when the target is @code{sh*-*-linux*}. If the target is SH1* or SH2*
+@option{-musermode} has no effect,
[PATCH] PR fortran/62245 fix INT docs.
A doc change to refine wording for result value of int, avoiding the word range
and using magnitude as does the standard. Mentions undefined behavior.
2014-08-24 Joost VandeVondele
PR fortran/62245
* intrinsic.texi (INT): clarify result and undefined behavior.
Index: intrinsic.texi
===
--- intrinsic.texi (revision 214408)
+++ intrinsic.texi (working copy)
@@ -7371,8 +7371,10 @@ the following rules:
If @var{A} is of type @code{INTEGER}, @code{INT(A) = A}
@item (B)
If @var{A} is of type @code{REAL} and @math{|A| < 1}, @code{INT(A)} equals
@code{0}.
-If @math{|A| \geq 1}, then @code{INT(A)} equals the largest integer that does
not exceed
-the range of @var{A} and whose sign is the same as the sign of @var{A}.
+If @math{|A| \geq 1}, then @code{INT(A)} is the integer whose magnitude is the
largest
+integer that does not exceed the magnitude of @var{A} and whose sign is the
same as
+the sign of @var{A}. The result is undefined if it can not be represented as an
+@code{INTEGER} of the given @code{KIND}.
@item (C)
If @var{A} is of type @code{COMPLEX}, rule B is applied to the real part of
@var{A}.
@end table
Re: [PATCH] PR fortran/62245 fix INT docs.
On Sun, 24 Aug 2014, VandeVondele Joost wrote: > A doc change to refine wording for result value of int, avoiding the > word range and using magnitude as does the standard. Mentions undefined > behavior. > > 2014-08-24 Joost VandeVondele > > PR fortran/62245 > * intrinsic.texi (INT): clarify result and undefined behavior. Looks good to me, though better wait for a Fortran maintainer to be sure. One small ask: these lines are too long (already before your patch); can you please reformat those lines your patch touches to <80 columns? Thanks, gerald
RE: [PATCH] PR fortran/62245 fix INT docs.
> One small ask: these lines are too long (already before your patch);
> can you please reformat those lines your patch touches to <80 columns?
sure:
Index: intrinsic.texi
===
--- intrinsic.texi (revision 214408)
+++ intrinsic.texi (working copy)
@@ -7370,9 +7370,12 @@ the following rules:
@item (A)
If @var{A} is of type @code{INTEGER}, @code{INT(A) = A}
@item (B)
-If @var{A} is of type @code{REAL} and @math{|A| < 1}, @code{INT(A)} equals
@code{0}.
-If @math{|A| \geq 1}, then @code{INT(A)} equals the largest integer that does
not exceed
-the range of @var{A} and whose sign is the same as the sign of @var{A}.
+If @var{A} is of type @code{REAL} and @math{|A| < 1}, @code{INT(A)}
+equals @code{0}. If @math{|A| \geq 1}, then @code{INT(A)} is the integer
+whose magnitude is the largest integer that does not exceed the magnitude
+of @var{A} and whose sign is the same as the sign of @var{A}. The result
+is undefined if it can not be represented as an @code{INTEGER} of the
+given @code{KIND}.
@item (C)
If @var{A} is of type @code{COMPLEX}, rule B is applied to the real part of
@var{A}.
@end table
Re: [patch, fortran] use vec<> in frontend-passes.c
Hi,
Trevor Saunders wrote:
>> -static gfc_expr ***expr_array;
>> -static int expr_size, expr_count;
>> +static vec expr_array = vec();
>
> that's usually written as just static vec foo; vec doesn't actually
> have ctors, and 0 initialization works fine.
Fixed (also below).
>> + // doloop_list = ;
>
> what is this comment supposed to mean?
Leftover from a commented piece of code, removed.
>>doloop_warn (ns);
>> - XDELETEVEC (doloop_list);
>> + doloop_list.truncate (0);
>
> .release () would be more typical.
Changed (also below).
>> - for (i=1; i> + for (i=1; expr_array.iterate (i, &ei); i++)
>
> FOR_EACH_VEC_ELT, though Its not really clear to my why that's better
> than
> size_t length = vec.length ();
> for (size_t i = 0; i < length; i++)
Done in a slightly different way (see the patch).
>> + for (j=0; j
> the .iterate call is useless since j must be < i, and the vector is
> at least i long right?
I was using the iterate call to get the current value of the vector.
I have now replaced this with using expr_array[j] below.
Steve wrote:
> Does this fix a bug in gfortran? "If it is not broken,
> don't fix it".
It doesn't fix a bug by itself, but it clears up the code by
avoiding hand-rolled memory management in two places. I also
want to do some more things in front-end optimization which
require vectors, so I think it makes sense to have a consistent
style, in a single file at least :-)
Therefore: OK for trunk?
Thomas
2014-08-24 Thomas Koenig
* frontend_passes (expr_array): Replace by vec template.
(expr_size): Remove.
(expr_count): Remove.
(doloop_list): Replace by vec template.
(doloop_size): Remove.
(gfc_run_passes): Adjust to use of vec template.
(cfe_register_funcs): Likewise.
(cfe_expr_0): Likewise.
(doloop_code): Likewise.
Index: frontend-passes.c
===
--- frontend-passes.c (Revision 214281)
+++ frontend-passes.c (Arbeitskopie)
@@ -47,11 +47,9 @@ static int callback_reduction (gfc_expr **, int *,
static int count_arglist;
-/* Pointer to an array of gfc_expr ** we operate on, plus its size
- and counter. */
+/* Vector of gfc_expr ** we operate on. */
-static gfc_expr ***expr_array;
-static int expr_size, expr_count;
+static vec expr_array;
/* Pointer to the gfc_code we currently work on - to be able to insert
a block before the statement. */
@@ -81,9 +79,10 @@ static int iterator_level;
/* Keep track of DO loop levels. */
-static gfc_code **doloop_list;
-static int doloop_size, doloop_level;
+static vec doloop_list;
+static int doloop_level;
+
/* Vector of gfc_expr * to keep track of DO loops. */
struct my_struct *evec;
@@ -101,23 +100,18 @@ gfc_run_passes (gfc_namespace *ns)
/* Warn about dubious DO loops where the index might
change. */
- doloop_size = 20;
doloop_level = 0;
- doloop_list = XNEWVEC(gfc_code *, doloop_size);
doloop_warn (ns);
- XDELETEVEC (doloop_list);
+ doloop_list.release ();
if (gfc_option.flag_frontend_optimize)
{
- expr_size = 20;
- expr_array = XNEWVEC(gfc_expr **, expr_size);
-
optimize_namespace (ns);
optimize_reduction (ns);
if (gfc_option.dump_fortran_optimized)
gfc_dump_parse_tree (ns, stdout);
- XDELETEVEC (expr_array);
+ expr_array.release ();
}
}
@@ -420,13 +414,7 @@ cfe_register_funcs (gfc_expr **e, int *walk_subtre
return 0;
}
- if (expr_count >= expr_size)
-{
- expr_size += expr_size;
- expr_array = XRESIZEVEC(gfc_expr **, expr_array, expr_size);
-}
- expr_array[expr_count] = e;
- expr_count ++;
+ expr_array.safe_push (e);
return 0;
}
@@ -599,6 +587,7 @@ cfe_expr_0 (gfc_expr **e, int *walk_subtrees,
{
int i,j;
gfc_expr *newvar;
+ gfc_expr **ei, **ej;
/* Don't do this optimization within OMP workshare. */
@@ -608,36 +597,36 @@ cfe_expr_0 (gfc_expr **e, int *walk_subtrees,
return 0;
}
- expr_count = 0;
+ expr_array.truncate (0);
gfc_expr_walker (e, cfe_register_funcs, NULL);
/* Walk through all the functions. */
- for (i=1; iexpr_type == EXPR_VARIABLE)
+ if ((*ei)->expr_type == EXPR_VARIABLE)
continue;
newvar = NULL;
for (j=0; jop)
{
case EXEC_DO:
- /* Grow the temporary storage if necessary. */
- if (doloop_level >= doloop_size)
- {
- doloop_size = 2 * doloop_size;
- doloop_list = XRESIZEVEC (gfc_code *, doloop_list, doloop_size);
- }
-
- /* Mark the DO loop variable if there is one. */
if (co->ext.iterator && co->ext.iterator->var)
- doloop_list[doloop_level] = co;
+ doloop_list.safe_push (co);
else
- doloop_list[doloop_level] = NULL;
+ doloop_list.safe_push ((gfc_code *) NULL);
break;
case EXEC_CALL:
@@ -1708,14 +1695,14 @@ doloop_code (gfc_code **c, int *walk_subtrees ATTR
while (a &&
Re: [PATCH] PR fortran/62245 fix INT docs.
On Sun, Aug 24, 2014 at 12:47:18PM +, VandeVondele Joost wrote:
> > One small ask: these lines are too long (already before your patch);
> > can you please reformat those lines your patch touches to <80 columns?
>
> sure:
>
> +of @var{A} and whose sign is the same as the sign of @var{A}. The result
> +is undefined if it can not be represented as an @code{INTEGER} of the
> +given @code{KIND}.
The last sentence above is not needed. There is a general
prohibition in 13.7.1 against calling INT(A) with |A| > HUGE(1_4).
--
Steve
RE: [PATCH] PR fortran/62245 fix INT docs.
>> +of @var{A} and whose sign is the same as the sign of @var{A}. The result
>> +is undefined if it can not be represented as an @code{INTEGER} of the
>> +given @code{KIND}.
>
>The last sentence above is not needed.
but helpful for gfortran users ?
> There is a general
> prohibition in 13.7.1 against calling INT(A) with |A| > HUGE(1_4).
maybe you could prepare a patch to add something like that to the section on
intrinsics ?
Re: [PATCH] PR fortran/62245 fix INT docs.
On Sun, Aug 24, 2014 at 03:58:42PM +, VandeVondele Joost wrote:
> >> +of @var{A} and whose sign is the same as the sign of @var{A}. The result
> >> +is undefined if it can not be represented as an @code{INTEGER} of the
> >> +given @code{KIND}.
> >
> >The last sentence above is not needed.
>
> but helpful for gfortran users ?
>
The problem is that a similar sentence would then need to be
added to other intrinsic subroutines/functions where an actual
argument might produce a result that is out-of-range of the
representable entity. Note, that it isn't limited to just
the conversion functions. Consider IABS() and the asymetric
range of the INTEGERi type.
integer i
i = - huge(i) - 1
print *, iabs(i)
end
> > There is a general
> > prohibition in 13.7.1 against calling INT(A) with |A| > HUGE(1_4).
>
> maybe you could prepare a patch to add something like that to the
> section on intrinsics?
Sure, I'll come up with a statement to be added to Sec. 8.1 of
the gfortran manual.
--
Steve
RE: [PATCH] PR fortran/62245 fix INT docs.
>> but helpful for gfortran users ? >The problem is that a similar sentence would then need to be >added to other intrinsic subroutines/functions where an actual >argument might produce a result that is out-of-range of the >representable entity. So, I could remove the sentence if there is consensus. >> maybe you could prepare a patch to add something like that to the >> section on intrinsics? > >Sure, I'll come up with a statement to be added to Sec. 8.1 of >the gfortran manual. actually, it is more complicated, since gfortran does support things such as NaN, and Inf, depending on the hardware and the compilation options.
Re: [PATCH, DOC]: Fix for Options That Control Optimization section
On Fri, 11 Jul 2014, Martin Liška wrote:
2014-07-11 Martin Liska
* doc/invoke.texi: Added missing options to options
that control optimization. Missing -foptimize-strlen option
introduced.
I applied the following patch on top of yours, adding @code in
one, and @option in another case.
Gerald
2014-08-24 Gerald Pfeifer
* doc/invoke.texi (Optimize Options): Fix markup in two cases.
Index: doc/invoke.texi
===
--- doc/invoke.texi (revision 214408)
+++ doc/invoke.texi (working copy)
@@ -7232,7 +7232,7 @@
@opindex foptimize-strlen
Optimize various standard C string functions (e.g. @code{strlen},
@code{strchr} or @code{strcpy}) and
-their _FORTIFY_SOURCE counterparts into faster alternatives.
+their @code{_FORTIFY_SOURCE} counterparts into faster alternatives.
Enabled at levels @option{-O2}, @option{-O3}.
@@ -7401,7 +7401,7 @@
This option is only meaningful on architectures that support such
instructions, which include x86, PowerPC, IA-64 and S/390.
-Enabled by default at -O1 and higher.
+Enabled by default at @option{-O1} and higher.
The default is @option{-fbranch-count-reg}.
[PATCH] Refactor handle_section_attribute to reduce nesting and distinguish error cases
handle_section_attribute contains many levels of nested conditionals and
branching code flow paths, with the error cases sometimes in the else
case and sometimes in the if case. Simplify the code flow into a series
of potential failure cases ending with the successful path, with no
nesting and no else clauses.
---
I started to work on an extension to the section attribute, and found
myself cleaning up the logic in handle_section_attribute; I wanted to
send this cleanup patch separately.
I'm not a GCC committer, so I'm looking both for review and for someone
to commit this patch.
gcc/ChangeLog | 5 +++
gcc/c-family/c-common.c | 91 +
2 files changed, 51 insertions(+), 45 deletions(-)
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 703a489..0286bfb 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,8 @@
+2014-08-24 Josh Triplett
+
+ * c-family/c-common.c (handle_section_attribute): Refactor to reduce
+ nesting and distinguish between error cases.
+
2014-08-24 Oleg Endo
PR target/61996
diff --git a/gcc/c-family/c-common.c b/gcc/c-family/c-common.c
index 58b9763..a63eedf 100644
--- a/gcc/c-family/c-common.c
+++ b/gcc/c-family/c-common.c
@@ -7387,58 +7387,59 @@ handle_section_attribute (tree *node, tree ARG_UNUSED
(name), tree args,
{
tree decl = *node;
- if (targetm_common.have_named_sections)
+ if (!targetm_common.have_named_sections)
{
- user_defined_section_attribute = true;
+ error_at (DECL_SOURCE_LOCATION (*node),
+ "section attributes are not supported for this target");
+ goto fail;
+}
- if ((TREE_CODE (decl) == FUNCTION_DECL
- || TREE_CODE (decl) == VAR_DECL)
- && TREE_CODE (TREE_VALUE (args)) == STRING_CST)
- {
- if (TREE_CODE (decl) == VAR_DECL
- && current_function_decl != NULL_TREE
- && !TREE_STATIC (decl))
- {
- error_at (DECL_SOURCE_LOCATION (decl),
- "section attribute cannot be specified for "
- "local variables");
- *no_add_attrs = true;
- }
+ user_defined_section_attribute = true;
- /* The decl may have already been given a section attribute
-from a previous declaration. Ensure they match. */
- else if (DECL_SECTION_NAME (decl) != NULL
- && strcmp (DECL_SECTION_NAME (decl),
- TREE_STRING_POINTER (TREE_VALUE (args))) != 0)
- {
- error ("section of %q+D conflicts with previous declaration",
-*node);
- *no_add_attrs = true;
- }
- else if (TREE_CODE (decl) == VAR_DECL
- && !targetm.have_tls && targetm.emutls.tmpl_section
- && DECL_THREAD_LOCAL_P (decl))
- {
- error ("section of %q+D cannot be overridden", *node);
- *no_add_attrs = true;
- }
- else
- set_decl_section_name (decl,
- TREE_STRING_POINTER (TREE_VALUE (args)));
- }
- else
- {
- error ("section attribute not allowed for %q+D", *node);
- *no_add_attrs = true;
- }
+ if (TREE_CODE (decl) != FUNCTION_DECL && TREE_CODE (decl) != VAR_DECL)
+{
+ error ("section attribute not allowed for %q+D", *node);
+ goto fail;
}
- else
+
+ if (TREE_CODE (TREE_VALUE (args)) != STRING_CST)
{
- error_at (DECL_SOURCE_LOCATION (*node),
- "section attributes are not supported for this target");
- *no_add_attrs = true;
+ error ("section attribute argument not a string constant");
+ goto fail;
+}
+
+ if (TREE_CODE (decl) == VAR_DECL
+ && current_function_decl != NULL_TREE
+ && !TREE_STATIC (decl))
+{
+ error_at (DECL_SOURCE_LOCATION (decl),
+"section attribute cannot be specified for local variables");
+ goto fail;
}
+ /* The decl may have already been given a section attribute
+ from a previous declaration. Ensure they match. */
+ if (DECL_SECTION_NAME (decl) != NULL
+ && strcmp (DECL_SECTION_NAME (decl),
+ TREE_STRING_POINTER (TREE_VALUE (args))) != 0)
+{
+ error ("section of %q+D conflicts with previous declaration", *node);
+ goto fail;
+}
+
+ if (TREE_CODE (decl) == VAR_DECL
+ && !targetm.have_tls && targetm.emutls.tmpl_section
+ && DECL_THREAD_LOCAL_P (decl))
+{
+ error ("section of %q+D cannot be overridden", *node);
+ goto fail;
+}
+
+ set_decl_section_name (decl, TREE_STRING_POINTER (TREE_VALUE (args)));
+ return NULL_TREE;
+
+fail:
+ *no_add_attrs = true;
return NULL_TREE;
}
--
2.1.0
Re: [PATCH] Refactor handle_section_attribute to reduce nesting and distinguish error cases
On Sun, Aug 24, 2014 at 1:42 PM, Josh Triplett wrote:
> handle_section_attribute contains many levels of nested conditionals and
> branching code flow paths, with the error cases sometimes in the else
> case and sometimes in the if case. Simplify the code flow into a series
> of potential failure cases ending with the successful path, with no
> nesting and no else clauses.
> ---
>
> I started to work on an extension to the section attribute, and found
> myself cleaning up the logic in handle_section_attribute; I wanted to
> send this cleanup patch separately.
>
> I'm not a GCC committer, so I'm looking both for review and for someone
> to commit this patch.
>
> gcc/ChangeLog | 5 +++
> gcc/c-family/c-common.c | 91
> +
> 2 files changed, 51 insertions(+), 45 deletions(-)
>
> diff --git a/gcc/ChangeLog b/gcc/ChangeLog
> index 703a489..0286bfb 100644
> --- a/gcc/ChangeLog
> +++ b/gcc/ChangeLog
> @@ -1,3 +1,8 @@
> +2014-08-24 Josh Triplett
> +
> + * c-family/c-common.c (handle_section_attribute): Refactor to reduce
> + nesting and distinguish between error cases.
> +
> 2014-08-24 Oleg Endo
>
> PR target/61996
> diff --git a/gcc/c-family/c-common.c b/gcc/c-family/c-common.c
> index 58b9763..a63eedf 100644
> --- a/gcc/c-family/c-common.c
> +++ b/gcc/c-family/c-common.c
> @@ -7387,58 +7387,59 @@ handle_section_attribute (tree *node, tree ARG_UNUSED
> (name), tree args,
> {
>tree decl = *node;
>
> - if (targetm_common.have_named_sections)
> + if (!targetm_common.have_named_sections)
> {
> - user_defined_section_attribute = true;
> + error_at (DECL_SOURCE_LOCATION (*node),
> + "section attributes are not supported for this target");
> + goto fail;
Why not move this to a different function and then do:
if (function(...))
set_decl_section_name (decl, TREE_STRING_POINTER (TREE_VALUE (args)));
else
*no_add_attrs = true;
return NULL_TREE;
This is a way to get away from using gotos.
Thanks,
Andrew
> +}
>
> - if ((TREE_CODE (decl) == FUNCTION_DECL
> - || TREE_CODE (decl) == VAR_DECL)
> - && TREE_CODE (TREE_VALUE (args)) == STRING_CST)
> - {
> - if (TREE_CODE (decl) == VAR_DECL
> - && current_function_decl != NULL_TREE
> - && !TREE_STATIC (decl))
> - {
> - error_at (DECL_SOURCE_LOCATION (decl),
> - "section attribute cannot be specified for "
> - "local variables");
> - *no_add_attrs = true;
> - }
> + user_defined_section_attribute = true;
>
> - /* The decl may have already been given a section attribute
> -from a previous declaration. Ensure they match. */
> - else if (DECL_SECTION_NAME (decl) != NULL
> - && strcmp (DECL_SECTION_NAME (decl),
> - TREE_STRING_POINTER (TREE_VALUE (args))) != 0)
> - {
> - error ("section of %q+D conflicts with previous declaration",
> -*node);
> - *no_add_attrs = true;
> - }
> - else if (TREE_CODE (decl) == VAR_DECL
> - && !targetm.have_tls && targetm.emutls.tmpl_section
> - && DECL_THREAD_LOCAL_P (decl))
> - {
> - error ("section of %q+D cannot be overridden", *node);
> - *no_add_attrs = true;
> - }
> - else
> - set_decl_section_name (decl,
> - TREE_STRING_POINTER (TREE_VALUE (args)));
> - }
> - else
> - {
> - error ("section attribute not allowed for %q+D", *node);
> - *no_add_attrs = true;
> - }
> + if (TREE_CODE (decl) != FUNCTION_DECL && TREE_CODE (decl) != VAR_DECL)
> +{
> + error ("section attribute not allowed for %q+D", *node);
> + goto fail;
> }
> - else
> +
> + if (TREE_CODE (TREE_VALUE (args)) != STRING_CST)
> {
> - error_at (DECL_SOURCE_LOCATION (*node),
> - "section attributes are not supported for this target");
> - *no_add_attrs = true;
> + error ("section attribute argument not a string constant");
> + goto fail;
> +}
> +
> + if (TREE_CODE (decl) == VAR_DECL
> + && current_function_decl != NULL_TREE
> + && !TREE_STATIC (decl))
> +{
> + error_at (DECL_SOURCE_LOCATION (decl),
> +"section attribute cannot be specified for local variables");
> + goto fail;
> }
>
> + /* The decl may have already been given a section attribute
> + from a previous declaration. Ensure they match. */
> + if (DECL_SECTION_NAME (decl) != NULL
> + && strcmp (DECL_SECTION_NAME (decl),
> + TREE_STRING_POINTER (TREE_VALUE (args))) != 0)
> +{
> + error ("section of %q+D conflicts with previous declaration", *node);
> + goto fail;
> +}
> +
> + if (TREE_
Re: [PATCH] Refactor handle_section_attribute to reduce nesting and distinguish error cases
On Sun, Aug 24, 2014 at 01:58:52PM -0700, Andrew Pinski wrote:
> On Sun, Aug 24, 2014 at 1:42 PM, Josh Triplett wrote:
> > handle_section_attribute contains many levels of nested conditionals and
> > branching code flow paths, with the error cases sometimes in the else
> > case and sometimes in the if case. Simplify the code flow into a series
> > of potential failure cases ending with the successful path, with no
> > nesting and no else clauses.
> > ---
> >
> > I started to work on an extension to the section attribute, and found
> > myself cleaning up the logic in handle_section_attribute; I wanted to
> > send this cleanup patch separately.
> >
> > I'm not a GCC committer, so I'm looking both for review and for someone
> > to commit this patch.
> >
> > gcc/ChangeLog | 5 +++
> > gcc/c-family/c-common.c | 91
> > +
> > 2 files changed, 51 insertions(+), 45 deletions(-)
> >
> > diff --git a/gcc/ChangeLog b/gcc/ChangeLog
> > index 703a489..0286bfb 100644
> > --- a/gcc/ChangeLog
> > +++ b/gcc/ChangeLog
> > @@ -1,3 +1,8 @@
> > +2014-08-24 Josh Triplett
> > +
> > + * c-family/c-common.c (handle_section_attribute): Refactor to reduce
> > + nesting and distinguish between error cases.
> > +
> > 2014-08-24 Oleg Endo
> >
> > PR target/61996
> > diff --git a/gcc/c-family/c-common.c b/gcc/c-family/c-common.c
> > index 58b9763..a63eedf 100644
> > --- a/gcc/c-family/c-common.c
> > +++ b/gcc/c-family/c-common.c
> > @@ -7387,58 +7387,59 @@ handle_section_attribute (tree *node, tree
> > ARG_UNUSED (name), tree args,
> > {
> >tree decl = *node;
> >
> > - if (targetm_common.have_named_sections)
> > + if (!targetm_common.have_named_sections)
> > {
> > - user_defined_section_attribute = true;
> > + error_at (DECL_SOURCE_LOCATION (*node),
> > + "section attributes are not supported for this target");
> > + goto fail;
>
> Why not move this to a different function and then do:
>
> if (function(...))
> set_decl_section_name (decl, TREE_STRING_POINTER (TREE_VALUE (args)));
> else
> *no_add_attrs = true;
>
> return NULL_TREE;
>
> This is a way to get away from using gotos.
I can certainly do so; I hadn't in this patch because the file in
question already contains dozens of instances of the same goto-based
error-handling pattern.
I'll send a second version of this patch with a separate function
returning bool.
- Josh Triplett
Re: [PATCH] Refactor handle_section_attribute to reduce nesting and distinguish error cases
On Sun, Aug 24, 2014 at 01:58:52PM -0700, Andrew Pinski wrote:
> On Sun, Aug 24, 2014 at 1:42 PM, Josh Triplett wrote:
> > handle_section_attribute contains many levels of nested conditionals and
> > branching code flow paths, with the error cases sometimes in the else
> > case and sometimes in the if case. Simplify the code flow into a series
> > of potential failure cases ending with the successful path, with no
> > nesting and no else clauses.
> > ---
> >
> > I started to work on an extension to the section attribute, and found
> > myself cleaning up the logic in handle_section_attribute; I wanted to
> > send this cleanup patch separately.
> >
> > I'm not a GCC committer, so I'm looking both for review and for someone
> > to commit this patch.
> >
> > gcc/ChangeLog | 5 +++
> > gcc/c-family/c-common.c | 91
> > +
> > 2 files changed, 51 insertions(+), 45 deletions(-)
> >
> > diff --git a/gcc/ChangeLog b/gcc/ChangeLog
> > index 703a489..0286bfb 100644
> > --- a/gcc/ChangeLog
> > +++ b/gcc/ChangeLog
> > @@ -1,3 +1,8 @@
> > +2014-08-24 Josh Triplett
> > +
> > + * c-family/c-common.c (handle_section_attribute): Refactor to reduce
> > + nesting and distinguish between error cases.
> > +
> > 2014-08-24 Oleg Endo
> >
> > PR target/61996
> > diff --git a/gcc/c-family/c-common.c b/gcc/c-family/c-common.c
> > index 58b9763..a63eedf 100644
> > --- a/gcc/c-family/c-common.c
> > +++ b/gcc/c-family/c-common.c
> > @@ -7387,58 +7387,59 @@ handle_section_attribute (tree *node, tree
> > ARG_UNUSED (name), tree args,
> > {
> >tree decl = *node;
> >
> > - if (targetm_common.have_named_sections)
> > + if (!targetm_common.have_named_sections)
> > {
> > - user_defined_section_attribute = true;
> > + error_at (DECL_SOURCE_LOCATION (*node),
> > + "section attributes are not supported for this target");
> > + goto fail;
>
> Why not move this to a different function and then do:
>
> if (function(...))
> set_decl_section_name (decl, TREE_STRING_POINTER (TREE_VALUE (args)));
> else
> *no_add_attrs = true;
>
> return NULL_TREE;
>
> This is a way to get away from using gotos.
or you could just set no_add_attrs to true at the start of the function
and only set it to false when you know the attr is valid, which saves
the weirdness of a second function.
Trev
>
> Thanks,
> Andrew
>
>
> > +}
> >
> > - if ((TREE_CODE (decl) == FUNCTION_DECL
> > - || TREE_CODE (decl) == VAR_DECL)
> > - && TREE_CODE (TREE_VALUE (args)) == STRING_CST)
> > - {
> > - if (TREE_CODE (decl) == VAR_DECL
> > - && current_function_decl != NULL_TREE
> > - && !TREE_STATIC (decl))
> > - {
> > - error_at (DECL_SOURCE_LOCATION (decl),
> > - "section attribute cannot be specified for "
> > - "local variables");
> > - *no_add_attrs = true;
> > - }
> > + user_defined_section_attribute = true;
> >
> > - /* The decl may have already been given a section attribute
> > -from a previous declaration. Ensure they match. */
> > - else if (DECL_SECTION_NAME (decl) != NULL
> > - && strcmp (DECL_SECTION_NAME (decl),
> > - TREE_STRING_POINTER (TREE_VALUE (args))) != 0)
> > - {
> > - error ("section of %q+D conflicts with previous declaration",
> > -*node);
> > - *no_add_attrs = true;
> > - }
> > - else if (TREE_CODE (decl) == VAR_DECL
> > - && !targetm.have_tls && targetm.emutls.tmpl_section
> > - && DECL_THREAD_LOCAL_P (decl))
> > - {
> > - error ("section of %q+D cannot be overridden", *node);
> > - *no_add_attrs = true;
> > - }
> > - else
> > - set_decl_section_name (decl,
> > - TREE_STRING_POINTER (TREE_VALUE (args)));
> > - }
> > - else
> > - {
> > - error ("section attribute not allowed for %q+D", *node);
> > - *no_add_attrs = true;
> > - }
> > + if (TREE_CODE (decl) != FUNCTION_DECL && TREE_CODE (decl) != VAR_DECL)
> > +{
> > + error ("section attribute not allowed for %q+D", *node);
> > + goto fail;
> > }
> > - else
> > +
> > + if (TREE_CODE (TREE_VALUE (args)) != STRING_CST)
> > {
> > - error_at (DECL_SOURCE_LOCATION (*node),
> > - "section attributes are not supported for this target");
> > - *no_add_attrs = true;
> > + error ("section attribute argument not a string constant");
> > + goto fail;
> > +}
> > +
> > + if (TREE_CODE (decl) == VAR_DECL
> > + && current_function_decl != NULL_TREE
> > + && !TREE_STATIC (decl))
> > +{
> > + error_at (DECL_SOURCE_LOCATION (decl),
> > +
Re: [PATCH] Refactor handle_section_attribute to reduce nesting and distinguish error cases
On Sun, Aug 24, 2014 at 05:47:23PM -0400, Trevor Saunders wrote:
> On Sun, Aug 24, 2014 at 01:58:52PM -0700, Andrew Pinski wrote:
> > On Sun, Aug 24, 2014 at 1:42 PM, Josh Triplett
> > wrote:
> > > handle_section_attribute contains many levels of nested conditionals and
> > > branching code flow paths, with the error cases sometimes in the else
> > > case and sometimes in the if case. Simplify the code flow into a series
> > > of potential failure cases ending with the successful path, with no
> > > nesting and no else clauses.
> > > ---
> > >
> > > I started to work on an extension to the section attribute, and found
> > > myself cleaning up the logic in handle_section_attribute; I wanted to
> > > send this cleanup patch separately.
> > >
> > > I'm not a GCC committer, so I'm looking both for review and for someone
> > > to commit this patch.
> > >
> > > gcc/ChangeLog | 5 +++
> > > gcc/c-family/c-common.c | 91
> > > +
> > > 2 files changed, 51 insertions(+), 45 deletions(-)
> > >
> > > diff --git a/gcc/ChangeLog b/gcc/ChangeLog
> > > index 703a489..0286bfb 100644
> > > --- a/gcc/ChangeLog
> > > +++ b/gcc/ChangeLog
> > > @@ -1,3 +1,8 @@
> > > +2014-08-24 Josh Triplett
> > > +
> > > + * c-family/c-common.c (handle_section_attribute): Refactor to
> > > reduce
> > > + nesting and distinguish between error cases.
> > > +
> > > 2014-08-24 Oleg Endo
> > >
> > > PR target/61996
> > > diff --git a/gcc/c-family/c-common.c b/gcc/c-family/c-common.c
> > > index 58b9763..a63eedf 100644
> > > --- a/gcc/c-family/c-common.c
> > > +++ b/gcc/c-family/c-common.c
> > > @@ -7387,58 +7387,59 @@ handle_section_attribute (tree *node, tree
> > > ARG_UNUSED (name), tree args,
> > > {
> > >tree decl = *node;
> > >
> > > - if (targetm_common.have_named_sections)
> > > + if (!targetm_common.have_named_sections)
> > > {
> > > - user_defined_section_attribute = true;
> > > + error_at (DECL_SOURCE_LOCATION (*node),
> > > + "section attributes are not supported for this target");
> > > + goto fail;
> >
> > Why not move this to a different function and then do:
> >
> > if (function(...))
> > set_decl_section_name (decl, TREE_STRING_POINTER (TREE_VALUE (args)));
> > else
> > *no_add_attrs = true;
> >
> > return NULL_TREE;
> >
> > This is a way to get away from using gotos.
>
> or you could just set no_add_attrs to true at the start of the function
> and only set it to false when you know the attr is valid, which saves
> the weirdness of a second function.
Though that would then duplicate the "return NULL_TREE" in many places,
which seems suboptimal (and not much different than "goto fail").
Andrew, any preference between those two approaches?
- Josh Triplett
> Trev
>
> >
> > Thanks,
> > Andrew
> >
> >
> > > +}
> > >
> > > - if ((TREE_CODE (decl) == FUNCTION_DECL
> > > - || TREE_CODE (decl) == VAR_DECL)
> > > - && TREE_CODE (TREE_VALUE (args)) == STRING_CST)
> > > - {
> > > - if (TREE_CODE (decl) == VAR_DECL
> > > - && current_function_decl != NULL_TREE
> > > - && !TREE_STATIC (decl))
> > > - {
> > > - error_at (DECL_SOURCE_LOCATION (decl),
> > > - "section attribute cannot be specified for "
> > > - "local variables");
> > > - *no_add_attrs = true;
> > > - }
> > > + user_defined_section_attribute = true;
> > >
> > > - /* The decl may have already been given a section attribute
> > > -from a previous declaration. Ensure they match. */
> > > - else if (DECL_SECTION_NAME (decl) != NULL
> > > - && strcmp (DECL_SECTION_NAME (decl),
> > > - TREE_STRING_POINTER (TREE_VALUE (args))) !=
> > > 0)
> > > - {
> > > - error ("section of %q+D conflicts with previous
> > > declaration",
> > > -*node);
> > > - *no_add_attrs = true;
> > > - }
> > > - else if (TREE_CODE (decl) == VAR_DECL
> > > - && !targetm.have_tls && targetm.emutls.tmpl_section
> > > - && DECL_THREAD_LOCAL_P (decl))
> > > - {
> > > - error ("section of %q+D cannot be overridden", *node);
> > > - *no_add_attrs = true;
> > > - }
> > > - else
> > > - set_decl_section_name (decl,
> > > - TREE_STRING_POINTER (TREE_VALUE
> > > (args)));
> > > - }
> > > - else
> > > - {
> > > - error ("section attribute not allowed for %q+D", *node);
> > > - *no_add_attrs = true;
> > > - }
> > > + if (TREE_CODE (decl) != FUNCTION_DECL && TREE_CODE (decl) != VAR_DECL)
> > > +{
> > > + error ("section attribute not allowed for %q+D", *node);
> > > + goto fail;
> > > }
> > > - else
[SH] Fix PR target/62111
I've applied the attached patch to fix PR target/62111 which
is a sh64 specific 4.9/5 regression.
It seems that *zero_extendhisi2_media makes reload unhappy
with permitting (truncate (pseudo_reg)) when pseudo_reg can
be substituted by mem. See
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62111
for details. Tested on sh64-elf and sh4-unknown-linux-gnu with
no new failures. I'll backport this to 4.9 in a week or so.
Regards,
kaz
--
2014-08-25 Kaz Kojima
PR target/62111
* config/sh/predicates.md (general_extend_operand): Disable
TRUNCATE before reload completes.
--- gcc/config/sh/predicates.md.orig2014-08-02 11:55:29.228875715 +0900
+++ gcc/config/sh/predicates.md 2014-08-17 08:30:20.439326569 +0900
@@ -398,7 +398,7 @@
(define_predicate "general_extend_operand"
(match_code "subreg,reg,mem,truncate")
{
- if (GET_CODE (op) == TRUNCATE)
+ if (reload_completed && GET_CODE (op) == TRUNCATE)
return arith_operand (op, mode);
if (MEM_P (op) || (GET_CODE (op) == SUBREG && MEM_P (SUBREG_REG (op
Re: [PING PATCH] demangler, only access valid fields for DEMANGLE_COMPONENT_FIXED_TYPE.
Jason, can you take a look? Thanks.
Ian
On Tue, Aug 19, 2014 at 3:46 AM, Gary Benson wrote:
> Hi all,
>
> I just retested this patch. The crash it fixes is still there,
> and the patch still fixes it. Is this ok to commit?
>
> Cheers,
> Gary
>
> Andrew Burgess wrote:
>> In two places when a struct demangle_component is of type
>> DEMANGLE_COMPONENT_FIXED_TYPE we fall back to accessing the default
>> s_binary member of the union rather than the s_fixed member. This
>> is incorrect and can cause the demangler to crash.
>>
>> In d_dump I've changed the code to only access the s_fixed member of
>> the union, and also added printing of the remaining parts of the
>> s_fixed struct, this felt like the most useful thing to do.
>>
>> I've added a new test, this causes a SIGSEGV for me before the
>> patch, and is fine afterwords, however, this undefined, so might not
>> cause a crash on all platforms.
>>
>> If this is approved then please could someone commit it for me, I
>> don't have gcc write access.
>>
>> Thanks,
>> Andrew
>>
>> libiberty/ChangeLog:
>>
>> * cp-demangle.c (d_dump): Only access field from s_fixed part of
>> the union for DEMANGLE_COMPONENT_FIXED_TYPE.
>> (d_count_templates_scopes): Likewise.
>> * testsuite/demangle-expected: New test case.
>> ---
>> libiberty/cp-demangle.c | 10 +-
>> libiberty/testsuite/demangle-expected | 6 ++
>> 2 files changed, 15 insertions(+), 1 deletion(-)
>>
>> diff --git a/libiberty/cp-demangle.c b/libiberty/cp-demangle.c
>> index 68d8ee1..a31dad4 100644
>> --- a/libiberty/cp-demangle.c
>> +++ b/libiberty/cp-demangle.c
>> @@ -710,7 +710,9 @@ d_dump (struct demangle_component *dc, int indent)
>>printf ("pointer to member type\n");
>>break;
>> case DEMANGLE_COMPONENT_FIXED_TYPE:
>> - printf ("fixed-point type\n");
>> + printf ("fixed-point type, accum? %d, sat? %d\n",
>> + dc->u.s_fixed.accum, dc->u.s_fixed.sat);
>> + d_dump (dc->u.s_fixed.length, indent + 2)
>>break;
>> case DEMANGLE_COMPONENT_ARGLIST:
>>printf ("argument list\n");
>> @@ -3869,7 +3871,13 @@ d_count_templates_scopes (int *num_templates, int
>> *num_scopes,
>> case DEMANGLE_COMPONENT_FUNCTION_TYPE:
>> case DEMANGLE_COMPONENT_ARRAY_TYPE:
>> case DEMANGLE_COMPONENT_PTRMEM_TYPE:
>> + goto recurse_left_right;
>> +
>> case DEMANGLE_COMPONENT_FIXED_TYPE:
>> + d_count_templates_scopes (num_templates, num_scopes,
>> +dc->u.s_fixed.length);
>> + break;
>> +
>> case DEMANGLE_COMPONENT_VECTOR_TYPE:
>> case DEMANGLE_COMPONENT_ARGLIST:
>> case DEMANGLE_COMPONENT_TEMPLATE_ARGLIST:
>> diff --git a/libiberty/testsuite/demangle-expected
>> b/libiberty/testsuite/demangle-expected
>> index 453f9a3..0e2bb12 100644
>> --- a/libiberty/testsuite/demangle-expected
>> +++ b/libiberty/testsuite/demangle-expected
>> @@ -4343,3 +4343,9 @@
>> cereal::detail::InputBindingMap::Serializers
>> cereal::p
>> --format=gnu-v3
>> _ZNSt9_Any_data9_M_accessIPZ4postISt8functionIFvvEEEvOT_EUlvE_EERS5_v
>> void post >(std::function> ()>&&)::{lambda()#1}*& std::_Any_data::_M_access> post >(void post
>> >(std::function&&)::{lambda()#1}*&&)::{lambda()#1}*>()
>> +# The following input symbol was found during random, it caused a fault
>> +# within the demangler, it's not a symbol we'd expect in the real world.
>> +--format=auto --no-params
>> +_Z3xxxDFyuVb
>> +xxx(unsigned long long _Fract, bool volatile)
>> +xxx
>> --
>> 1.8.1.3
Re: [C++ RFC/Patch] PR 34938
OK. Jason
Re: C++ PATCH to support non-constexpr variable templates
On 08/23/2014 06:29 PM, Ville Voutilainen wrote: Based on my quick tests with it, it seems to me that we need more tests for static member variable templates. My first attempt at something like that gave an ICE... Yeah, I figured there would be more to do. More tests are welcome. :) Jason
Re: [GOOGLE, AUTOFDO] Assign different discriminators to calls with the same lineno
To avoid the unused new discriminator value, I added a map
"found_call_this_line" to track whether a call is the first call in a
source line seen when assigning discriminators. For the first call in
a source line, its discriminator is 0. For the following calls in the
same source line, a new discriminator will be used everytime. The new
patch is attached. Internal perf test and regression test are ok. Is
it ok for google-4_9?
Thanks,
Wei.
On Thu, Aug 7, 2014 at 2:10 PM, Wei Mi wrote:
> Yes, that is intentional. It is to avoid assiging a discriminator for
> the first call in the group of calls with the same source lineno.
> Starting from the second call in the group, it will get a different
> discriminator with previous call in the same group.
>
> Thanks,
> Wei.
>
> On Thu, Aug 7, 2014 at 12:17 PM, Cary Coutant wrote:
>>> static int
>>> -next_discriminator_for_locus (location_t locus)
>>> +increase_discriminator_for_locus (location_t locus, bool return_next)
>>> {
>>>struct locus_discrim_map item;
>>>struct locus_discrim_map **slot;
>>> @@ -934,8 +936,10 @@ next_discriminator_for_locus (location_t
>>>(*slot)->locus = locus;
>>>(*slot)->discriminator = 0;
>>> }
>>> +
>>>(*slot)->discriminator++;
>>> - return (*slot)->discriminator;
>>> + return return_next ? (*slot)->discriminator
>>> +: (*slot)->discriminator - 1;
>>> }
>>
>> Won't this have the effect of sometimes incrementing the next
>> available discriminator without actually using the new value? That is,
>> if you call it once with return_next == false, and then with
>> return_next == true.
>>
>> -cary
ChangeLog:
2014-08-24 Wei Mi
* tree-cfg.c (assign_discriminators): Assign different discriminators
for calls belonging to the same source line.
Index: tree-cfg.c
===
--- tree-cfg.c (revision 213402)
+++ tree-cfg.c (working copy)
@@ -992,7 +992,13 @@ static void
assign_discriminators (void)
{
basic_block bb;
+ /* If there is a location saved in the hash_table, it means that we
+ already found a call in the source line before. For the calls which
+ are not the first call found in the same source line, we don't assign
+ new discriminator for it, so that .debug_line section will be smaller. */
+ hash_table found_call_this_line;
+ found_call_this_line.create (13);
FOR_EACH_BB_FN (bb, cfun)
{
edge e;
@@ -1009,23 +1015,31 @@ assign_discriminators (void)
for (gsi = gsi_start_bb (bb); !gsi_end_p (gsi); gsi_next (&gsi))
{
gimple stmt = gsi_stmt (gsi);
- if (curr_locus == UNKNOWN_LOCATION)
- {
- curr_locus = gimple_location (stmt);
- }
- else if (!same_line_p (curr_locus, gimple_location (stmt)))
+ if (gimple_code (stmt) == GIMPLE_CALL)
{
+ struct locus_discrim_map item;
+ struct locus_discrim_map **slot;
+
curr_locus = gimple_location (stmt);
- curr_discr = 0;
- }
- else if (curr_discr != 0)
- {
- gimple_set_location (stmt, location_with_discriminator (
- gimple_location (stmt), curr_discr));
+ item.locus = curr_locus;
+ item.discriminator = 0;
+ slot = found_call_this_line.find_slot (&item, INSERT);
+ /* If the current call is not the first call seen in curr_locus,
+assign the next discriminator to it, else keep its
discriminator
+unchanged. */
+ if (*slot != HTAB_EMPTY_ENTRY)
+ {
+ curr_discr = next_discriminator_for_locus (curr_locus);
+ gimple_set_location (stmt, location_with_discriminator (
+ gimple_location (stmt), curr_discr));
+ }
+ else
+ {
+ *slot = XNEW (struct locus_discrim_map);
+ (*slot)->locus = curr_locus;
+ (*slot)->discriminator = 0;
+ }
}
- /* Allocate a new discriminator for CALL stmt. */
- if (gimple_code (stmt) == GIMPLE_CALL)
- curr_discr = next_discriminator_for_locus (curr_locus);
}
if (locus == UNKNOWN_LOCATION)
@@ -1047,6 +1061,7 @@ assign_discriminators (void)
}
}
}
+ found_call_this_line.dispose ();
}
/* Create the edges for a GIMPLE_COND starting at block BB. */
Re: [PATCH, C++, CPP] Add C++1z to the preprocessor. Rename C++1y to C++14.
Adding a few more tweaks:
commit bf054f32b165fda6e90c52a57a31538e5ae24678
Author: Jason Merrill
Date: Mon Aug 25 00:48:17 2014 -0400
* c.opt: Change -std=c++1y and -std=gnu++1y to be aliases for
-std=c++14 and -std=gnu++14, rather than the reverse.
* c-opts.c (c_common_handle_option): Change OPT_std_c__1y and
OPT_std_gnu__1y to OPT_std_c__14 and OPT_std_gnu__14.
* c-common.h (cxx_dialect): Remove cxx1y.
diff --git a/gcc/c-family/c-common.h b/gcc/c-family/c-common.h
index f621a3a..d1cc810 100644
--- a/gcc/c-family/c-common.h
+++ b/gcc/c-family/c-common.h
@@ -640,9 +640,8 @@ enum cxx_dialect {
/* C++11 */
cxx0x,
cxx11 = cxx0x,
- /* C++14 */
- cxx1y,
- cxx14 = cxx1y,
+ /* C++14 */
+ cxx14,
/* C++1z (C++17?) */
cxx1z
};
diff --git a/gcc/c-family/c-opts.c b/gcc/c-family/c-opts.c
index 42f1759..1b01b4f 100644
--- a/gcc/c-family/c-opts.c
+++ b/gcc/c-family/c-opts.c
@@ -698,12 +698,12 @@ c_common_handle_option (size_t scode, const char *arg, int value,
}
break;
-case OPT_std_c__1y:
-case OPT_std_gnu__1y:
+case OPT_std_c__14:
+case OPT_std_gnu__14:
if (!preprocessing_asm_p)
{
- set_std_cxx14 (code == OPT_std_c__1y /* ISO */);
- if (code == OPT_std_c__1y)
+ set_std_cxx14 (code == OPT_std_c__14 /* ISO */);
+ if (code == OPT_std_c__14)
cpp_opts->ext_numeric_literals = 0;
}
break;
@@ -1587,7 +1587,7 @@ set_std_cxx11 (int iso)
cxx_dialect = cxx11;
}
-/* Set the C++ 201y draft standard (without GNU extensions if ISO). */
+/* Set the C++ 2014 draft standard (without GNU extensions if ISO). */
static void
set_std_cxx14 (int iso)
{
diff --git a/gcc/c-family/c.opt b/gcc/c-family/c.opt
index cb7bb3e..d619250 100644
--- a/gcc/c-family/c.opt
+++ b/gcc/c-family/c.opt
@@ -1440,11 +1440,12 @@ C++ ObjC++ Alias(std=c++11) Undocumented
Deprecated in favor of -std=c++11
std=c++1y
-C++ ObjC++
-Conform to the ISO 2014(?) C++ draft standard (experimental and incomplete support)
+C++ ObjC++ Alias(std=c++14) Undocumented
+Deprecated in favor of -std=c++14
std=c++14
-C++ ObjC++ Alias(std=c++1y) Undocumented
+C++ ObjC++ Undocumented
+Conform to the ISO 2014 C++ standard (experimental and incomplete support)
std=c++1z
C++ ObjC++
@@ -1496,11 +1497,11 @@ C++ ObjC++ Alias(std=gnu++11)
Deprecated in favor of -std=gnu++11
std=gnu++1y
-C++ ObjC++
-Conform to the ISO 201y(4?) C++ draft standard with GNU extensions (experimental and incomplete support)
+C++ ObjC++ Alias(std=gnu++14) Undocumented
std=gnu++14
-C++ ObjC++ Alias(std=gnu++1y) Undocumented
+C++ ObjC++
+Conform to the ISO 2014 C++ standard with GNU extensions (experimental and incomplete support)
std=gnu++1z
C++ ObjC++
diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c
index f76fc3f..c50d8b8 100644
--- a/gcc/dwarf2out.c
+++ b/gcc/dwarf2out.c
@@ -248,10 +248,10 @@ static GTY(()) bool cold_text_section_used = false;
/* The default cold text section. */
static GTY(()) section *cold_text_section;
-/* The DIE for C++1y 'auto' in a function return type. */
+/* The DIE for C++14 'auto' in a function return type. */
static GTY(()) dw_die_ref auto_die;
-/* The DIE for C++1y 'decltype(auto)' in a function return type. */
+/* The DIE for C++14 'decltype(auto)' in a function return type. */
static GTY(()) dw_die_ref decltype_auto_die;
/* Forward declarations for functions defined in this file. */
