[Bug tree-optimization/77286] [7 Regression] ICE in fold_convert_loc, at fold-const.c:2248 building 435.gromacs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77286 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Richard Biener --- Fixed.
[Bug tree-optimization/77286] [7 Regression] ICE in fold_convert_loc, at fold-const.c:2248 building 435.gromacs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77286 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Richard Biener --- Fixed. --- Comment #7 from Richard Biener --- Author: rguenth Date: Fri Aug 19 07:02:05 2016 New Revision: 239605 URL: https://gcc.gnu.org/viewcvs?rev=239605&root=gcc&view=rev Log: 2016-08-19 Richard Biener PR tree-optimization/77286 * tree-vect-loop-manip.c (slpeel_duplicate_current_defs_from_edges): Deal with virtual PHIs being out-of-order. * gcc.dg/torture/pr77286.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr77286.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-loop-manip.c
[Bug middle-end/77295] missed optimisation when copying/moving union members
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77295
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2016-08-19
Ever confirmed|0 |1
--- Comment #1 from Richard Biener ---
Why does the implementation not simply copy the whole union with an assignment?
It's easier for GCC to optimize that.
Because with the current one you'll have
:
MEM[(struct &)this_7(D)] ={v} {CLOBBER};
_1 = x_9(D)->which;
this_7(D)->which = _1;
_2 = x_9(D)->which;
switch (_2) , case 1: , case 2: >
:
_3 = x_9(D)->D.2254.v1;
this_7(D)->D.2254.v1 = _3;
goto ();
:
_4 = x_9(D)->D.2254.v2;
this_7(D)->D.2254.v2 = _4;
:
return;
where it's hard to argue the desired transform is profitable in general
(x->which might get known via inlining and if you'd optimize the above
earlier then you'd at least lose TBAA info on the stores / loads).
Also note sth else above - we read from x->which twice (this may point
to x). There's a related PR somewhere about this missed optimization,
with a patch (that has cost even if that special situation doesn't apply,
thus I didn't pursue it).
[Bug middle-end/77295] missed optimisation when copying/moving union members
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77295
--- Comment #2 from Avi Kivity ---
Typically, the code is a template:
template
struct discriminated_union {
unsigned which;
union {
T v1;
U v2;
};
};
If either T or U have non-trivial copy/move constructors, then you can't
copy/move the union; you have to copy/move a member.
I guess a template specialization for the case where both are PODs can be used
as a work-around.
[Bug middle-end/77293] __builtin_object_size inconsistent for multidimensional arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77293 Richard Biener changed: What|Removed |Added Depends on||64715 --- Comment #1 from Richard Biener --- Well, for N == 1 the early object-size pass computes 1 as size which means, as it is supposed to be conservative, the closest surrounding subobject is the higher-ranked subarray. For N == a you get another conservative answer. Early object-size can't put a constraint to it and then folding makes a "mess" out of the address computation: : __builtin_memcpy (&MEM[(void *)&x2x3 + 2B], "abc", 4); return 0; in ccp1. To "fix" the simple case one could teach the objsz pass to lookup the definition for a (and thus see the constant 1). Or for example integrate early objsz with CCP1 and apply things before applying the final lattice. I've repeatedly said the design of __builtin_object_size conflicts with the desire to optimize -- one would need to preserve the original shape of the access. But only in some cases it seems. There is an old bug about this, PR64715. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64715 [Bug 64715] [5/6/7 Regression] __builtin_object_size (..., 1) fails to locate subobject
[Bug middle-end/77295] missed optimisation when copying/moving union members
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77295 --- Comment #3 from Avi Kivity --- If x->which is known then of course just that branch should be followed, and the others eliminated. I'm talking about the case where it isn't known (very common in my code).
[Bug c/77292] Spurious "warning: logical not is only applied to the left hand side of comparison"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77292 Richard Biener changed: What|Removed |Added Keywords||diagnostic --- Comment #1 from Richard Biener --- Well, // Make it obvious that these are booleans. a = !!a; b = !!b; this isn't visible to the compiler when it analyzes return !a == b; to warn. Your example is very specific and unlike from real code so are you complaining about return !a == b; warning even when it is not immediately preceeded by a a = !!a; stmt? Then we've discussed this to death already.
[Bug tree-optimization/77291] False positive for -Warray-bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77291
Richard Biener changed:
What|Removed |Added
Keywords||diagnostic, wrong-code
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2016-08-19
Component|c++ |tree-optimization
Ever confirmed|0 |1
--- Comment #1 from Richard Biener ---
Confirmed. VRP does
static void
check_array_ref (location_t location, tree ref, bool ignore_off_by_one)
{
...
up_bound = array_ref_up_bound (ref);
...
/* Accesses to trailing arrays via pointers may access storage
beyond the types array bounds. */
if (warn_array_bounds < 2
&& array_at_struct_end_p (ref))
return;
but here array_at_struct_end_p returns false because the size is still
constrained
by the DECL size. _But_ VRP fails to adjust up_bound accordingly, that is,
it is relying on array_at_struct_end_p to return true if the array bounds do
not
cover all possible elements towards its extent.
It looks like idx_infer_loop_bounds may have the same issue (wrong-code).
bounds_are_valid in graphite is even worse.
I'll think about a good solution.
[Bug tree-optimization/77290] [7 regression] test case gcc.dg/tree-ssa/pr71347.c fails starting with r239565
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77290 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #1 from Richard Biener --- Fixed.
[Bug tree-optimization/77290] [7 regression] test case gcc.dg/tree-ssa/pr71347.c fails starting with r239565
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77290 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #1 from Richard Biener --- Fixed. --- Comment #2 from Richard Biener --- Author: rguenth Date: Fri Aug 19 07:43:11 2016 New Revision: 239607 URL: https://gcc.gnu.org/viewcvs?rev=239607&root=gcc&view=rev Log: 2016-08-19 Richard Biener PR tree-optimization/77290 * tree-ssa-pre.c (eliminate_dom_walker::before_dom_children): Fix flag_tree_parallelize_loops check. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-pre.c
[Bug rtl-optimization/77289] [7 Regression] ICE in extract_constrain_insn, at recog.c:2212 on powerpc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77289 Richard Biener changed: What|Removed |Added Target Milestone|--- |7.0 Summary|ICE in |[7 Regression] ICE in |extract_constrain_insn, at |extract_constrain_insn, at |recog.c:2212 on powerpc64 |recog.c:2212 on powerpc64
[Bug tree-optimization/62171] restrict pointer to struct with restrict pointers parm doesn't prevent aliases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62171
--- Comment #15 from Richard Biener ---
(In reply to ncahill_alt from comment #14)
> This test is failing for me in GCC 6.1.0 (i386). It complains about having
> no vectype.
>
> Why that is, I don't know. But it doesn't seem to be a problem otherwise,
> it seems pretty safe to ignore except that it could vectorize the loop but
> doesn't.
>
> I wonder if it would be easier just to have this be UNSUPPORTED on i386.
It should be by means of the { dg-require-effective-target vect_double }
directive. Does it work if you remove the { dg-options ... } one?
[Bug target/69789] g++ -O2 is removing tests against a variable that can be changed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69789 Tomek Mrugalski changed: What|Removed |Added CC||spam.gcc at klub dot com.pl --- Comment #6 from Tomek Mrugalski --- This issue manifests itself also on g++ 5.4.0, the default compiler in Ubuntu 16.04. Exact version: (Ubuntu 5.4.0-6ubuntu1~16.04.2) 5.4.0 20160609.
[Bug target/69789] g++ -O2 is removing tests against a variable that can be changed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69789
--- Comment #7 from Jonathan Wakely ---
(In reply to Thomas Markwalder from comment #5)
> A bit more digging reveals that in the logic expression which fails:
>
> {{{
> // Check if we need to run the operation again.
> if (ec == boost::asio::error::would_block
> || ec == boost::asio::error::try_again)
> return false;
> }}}
>
> The value for error_category:m_cat differs between the implicitly created
> instances for would_block and try_again.
Do you mean that error_code(boost::asio::error::would_block) !=
error_code(boost::asio::error::try_again) ?
I don't see how that's possible, since in the optimized GIMPLE dump they both
use the same constructor, which isn't inlined. The two enums have the same
value, and the constructor will call the same asio::make_error_code() overload
that sets the category to boost::system_category().
boost::system::error_code::error_code
(&D.94931, 11, 0B);
cleanup.88 = 1;
D.165192 = boost::system::operator== (ec, &D.94931);
if (D.165192 != 0) goto ; else goto ;
:
boost::system::error_code::error_code
(&D.94932, 11, 0B);
cleanup.89 = 1;
D.165197 = boost::system::operator== (ec, &D.94932);
if (D.165197 != 0) goto ; else goto ;
:
iftmp.87 = 1;
goto ;
:
iftmp.87 = 0;
:
retval.86 = iftmp.87;
So what exactly are you seeing? What digging have you done? Stepped through
with the debugger?
The most likely explanation seems to be that ec.category() !=
boost::system::system_category() and so the comparisons are always false.
> If one splits the if into two separate if statements, the values for m_cat
> are the same. This looks a like the behavior described under "Static
> Variables in Inline Functions" described here:
>
> http://processors.wiki.ti.com/index.php/C++_Inlining_Issues
This function has nothing to do with static variables.
[Bug c/77292] Spurious "warning: logical not is only applied to the left hand side of comparison"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77292 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #2 from Marek Polacek --- Not a bug, IMHO.
[Bug c/77292] Spurious "warning: logical not is only applied to the left hand side of comparison"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77292
--- Comment #3 from M Welinder ---
The actual code I got this warning from was...
if (!lower_tail == (p > phalf)) {
where lower_tail is an int and p and phalf are doubles.
That's simply a comparison of two booleans. Note, that the hinted-at code
!(lower_tail == (p > phalf))
is dubious: comparing an int to a booleans.
> this isn't visible to the compiler when it analyzes
> return !a == b;
I am not aware of a rule that requires the compiler to ignore context
when considering warnings. It certainly does consider context when
it issues "might be used uninitialized" warnings, so why not here?
[Bug c/77292] value range propagation (VRP) would improve -Wlogical-not-parentheses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77292 Manuel López-Ibáñez changed: What|Removed |Added Status|UNCONFIRMED |SUSPENDED Last reconfirmed||2016-08-19 CC||manu at gcc dot gnu.org Summary|Spurious "warning: logical |value range propagation |not is only applied to the |(VRP) would improve |left hand side of |-Wlogical-not-parentheses |comparison" | Ever confirmed|0 |1 --- Comment #4 from Manuel López-Ibáñez --- Note that Clang suggests two ways to silence the warning: prog.cc:9:10: note: add parentheses after the '!' to evaluate the comparison first return !a == b; ^ ( ) prog.cc:9:10: note: add parentheses around left hand side expression to silence this warning return !a == b; ^ ( ) Also, we do not warn for actual booleans (bool). To be able to not warn based on the runtime range of variables, we would need something like VRP in the FE, and that is unlikely to be implemented in the medium future.
[Bug c/77292] value range propagation (VRP) would improve -Wlogical-not-parentheses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77292
--- Comment #5 from Richard Biener ---
(In reply to M Welinder from comment #3)
> The actual code I got this warning from was...
>
> if (!lower_tail == (p > phalf)) {
>
> where lower_tail is an int and p and phalf are doubles.
Well, that changes things because I agree that in the above case the
warning is bogus.
> That's simply a comparison of two booleans. Note, that the hinted-at code
>
>!(lower_tail == (p > phalf))
>
> is dubious: comparing an int to a booleans.
>
> > this isn't visible to the compiler when it analyzes
> > return !a == b;
>
> I am not aware of a rule that requires the compiler to ignore context
> when considering warnings. It certainly does consider context when
> it issues "might be used uninitialized" warnings, so why not here?
Because it's not done as in the frontend there is no data-flow available.
So, testcase:
int
foo (int a, int b)
{
return !a == (a < b);
}
t.c: In function ‘foo’:
t.c:4:13: warning: logical not is only applied to the left hand side of
comparison [-Wlogical-not-parentheses]
return !a == (a < b);
^~
[Bug target/70713] msp430 interrupt attribute prevents overriding weak symbols
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70713 Joe Seymour changed: What|Removed |Added CC||joe.s+bugzilla@somniumtech. ||com --- Comment #1 from Joe Seymour --- The test case provided in the initial report requires the msp430-gcc-support-files (headers and linker scripts) provided by TI. I believe the issue being described is that when you provide an interrupt attribute that specifies the name/number of the interrupt, the compiler generates a section named "__interrupt_vector_" containing the address of the function. It expects the linker script to use these sections to construct the vector table. The linker doesn't know that these sections are related to specific functions, so it doesn't know to discard the section corresponding to the weak version of the function when it discards the weak function. IIUC while making the sections comdat will ensure that all but one of them is discarded, the section it keeps won't necessarily correspond to the version of the function that was kept, so the resulting vector table may be incorrect in some cases. A workaround might be to to use /DISCARD/ in a linker script, to explicitly discard the versions of the section that you don't want. Alternatively, it might be easier and cleaner to omit the name/number of the interrupt, so that the compiler doesn't generate a section, then populate the vector table explicitly. Both workarounds however require you to explicitly tell the linker which version of the function is being used, at which point there might not be any benefit to using the weak attribute. Perhaps the msp430 backend should produce an error if a function is marked and weak and specifies a particular interrupt number (instead of just "interrupt")? I'll submit a patch to gcc-patches.
[Bug c/77292] value range propagation (VRP) would improve -Wlogical-not-parentheses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77292 --- Comment #6 from Marek Polacek --- (In reply to Manuel López-Ibáñez from comment #4) > Note that Clang suggests two ways to silence the warning: > > prog.cc:9:10: note: add parentheses after the '!' to evaluate the comparison > first > return !a == b; > ^ > ( ) > prog.cc:9:10: note: add parentheses around left hand side expression to > silence this warning > return !a == b; > ^ > ( ) I guess I should employ here the fix-it feature we now have... > Also, we do not warn for actual booleans (bool). This is intentional. > To be able to not warn based on the runtime range of variables, we would > need something like VRP in the FE, and that is unlikely to be implemented in > the medium future. ...if ever.
[Bug c/77292] Spurious warning: logical not is only applied to the left hand side of comparison
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77292 Richard Biener changed: What|Removed |Added Status|SUSPENDED |NEW Summary|value range propagation |Spurious warning: logical |(VRP) would improve |not is only applied to the |-Wlogical-not-parentheses |left hand side of ||comparison Known to fail||6.1.1 --- Comment #7 from Richard Biener --- Clang doesn't warn about this.
[Bug c/77292] Spurious warning: logical not is only applied to the left hand side of comparison
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77292 --- Comment #8 from Marek Polacek --- Neither does cc1plus because comparison result has a boolean type... I'll see what I can do here.
[Bug c/77292] Spurious warning: logical not is only applied to the left hand side of comparison
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77292 --- Comment #9 from Manuel López-Ibáñez --- (In reply to M Welinder from comment #3) > I am not aware of a rule that requires the compiler to ignore context > when considering warnings. It certainly does consider context when > it issues "might be used uninitialized" warnings, so why not here? Wuninitialized warnings are implemented in the middle-end. They benefit from the analysis done by optimization, but also suffer from the optimizations transforming and removing code (PR18501 and http://gcc.gnu.org/wiki/Better_Uninitialized_Warnings). Warnings in the FE, like this one, are more consistent but there is very limited analysis done in the FE (because it is harder to implement in the FE, it may slow down the compiler and would duplicate the analysis done in the middle-end for optimization).
[Bug c/77292] Spurious warning: logical not is only applied to the left hand side of comparison
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77292
--- Comment #10 from Manuel López-Ibáñez ---
(In reply to Richard Biener from comment #5)
> int
> foo (int a, int b)
> {
> return !a == (a < b);
> }
>
> t.c: In function ‘foo’:
> t.c:4:13: warning: logical not is only applied to the left hand side of
> comparison [-Wlogical-not-parentheses]
>return !a == (a < b);
> ^~
Why is this not a valid warning?
#include
void
foo (int a, bool b)
{
printf("(!a) == b -> %d\n", (int) (!a) == b);
printf("!(a == b) -> %d\n", (int) !(a == b));
}
int main()
{
foo(2,1);
}
(!a) == b -> 0
!(a == b) -> 1
[Bug middle-end/35170] Earlier VRP would help -Wreturn-type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35170 Manuel López-Ibáñez changed: What|Removed |Added Target|x86_64-unknown-linux-gnu| Status|UNCONFIRMED |NEW Keywords||diagnostic Last reconfirmed||2016-08-19 CC||manu at gcc dot gnu.org Host|x86_64-unknown-linux-gnu| Ever confirmed|0 |1 Summary|Suspected value range |Earlier VRP would help |propagation [VRP] failure |-Wreturn-type |with ? :| Severity|trivial |enhancement Build|x86_64-unknown-linux-gnu| --- Comment #2 from Manuel López-Ibáñez --- Confirm it so it does not appear in the list of UNCONFIRMED.
[Bug c/77292] Spurious warning: logical not is only applied to the left hand side of comparison
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77292 Segher Boessenkool changed: What|Removed |Added CC||segher at gcc dot gnu.org --- Comment #11 from Segher Boessenkool --- (In reply to Manuel López-Ibáñez from comment #4) > Note that Clang suggests two ways to silence the warning: > > prog.cc:9:10: note: add parentheses after the '!' to evaluate the comparison > first > return !a == b; > ^ > ( ) > prog.cc:9:10: note: add parentheses around left hand side expression to > silence this warning > return !a == b; > ^ > ( ) Both of these suggestions are not so good. "!(a == b)" is better written as "a != b", and "!(a) == b" is just horrible.
[Bug c/77292] Spurious warning: logical not is only applied to the left hand side of comparison
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77292 --- Comment #12 from Manuel López-Ibáñez --- (In reply to Segher Boessenkool from comment #11) > Both of these suggestions are not so good. "!(a == b)" is better written > as "a != b", and "!(a) == b" is just horrible. Agreed for the former, but the latter is suggesting (!a) == b, which is IMHO clearer than ! a == b.
[Bug fortran/77296] New: Compiler Error with allocatable string and associate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77296 Bug ID: 77296 Summary: Compiler Error with allocatable string and associate Product: gcc Version: 6.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: matthew.thompson at nasa dot gov Target Milestone: --- This program: program test implicit none character(len=:), allocatable :: s s = 'a' associate(ss => s) print*,ss end associate end program test causes a bogus compiler error with gfortran 6.1.0: (350) $ gfortran -v -save-temps test.F90 Driving: gfortran -v -save-temps test.F90 -l gfortran -l m -shared-libgcc Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/ford1/local/gcc/gcc-6.1.0-rhel6/libexec/gcc/x86_64-pc-linux-gnu/6.1.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: ../gcc-6.1.0/configure --prefix=/ford1/local/gcc/gcc-6.1.0-rhel6 --disable-multilib Thread model: posix gcc version 6.1.0 (GCC) COLLECT_GCC_OPTIONS='-v' '-save-temps' '-shared-libgcc' '-mtune=generic' '-march=x86-64' /ford1/local/gcc/gcc-6.1.0-rhel6/libexec/gcc/x86_64-pc-linux-gnu/6.1.0/f951 test.F90 -cpp=test.f90 -quiet -v test.F90 -quiet -dumpbase test.F90 -mtune=generic -march=x86-64 -auxbase test -version -fintrinsic-modules-path /ford1/local/gcc/gcc-6.1.0-rhel6/lib/gcc/x86_64-pc-linux-gnu/6.1.0/finclude -o test.s GNU Fortran (GCC) version 6.1.0 (x86_64-pc-linux-gnu) compiled by GNU C version 6.1.0, GMP version 4.3.2, MPFR version 2.4.2, MPC version 0.8.1, isl version 0.15 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 ignoring nonexistent directory "/ford1/local/gcc/gcc-6.1.0-rhel6/lib/gcc/x86_64-pc-linux-gnu/6.1.0/../../../../x86_64-pc-linux-gnu/include" #include "..." search starts here: #include <...> search starts here: /ford1/local/gcc/gcc-6.1.0-rhel6/lib/gcc/x86_64-pc-linux-gnu/6.1.0/finclude /ford1/local/gcc/gcc-6.1.0-rhel6/lib/gcc/x86_64-pc-linux-gnu/6.1.0/include /usr/local/include /ford1/local/gcc/gcc-6.1.0-rhel6/include /ford1/local/gcc/gcc-6.1.0-rhel6/lib/gcc/x86_64-pc-linux-gnu/6.1.0/include-fixed /usr/include End of search list. GNU Fortran2008 (GCC) version 6.1.0 (x86_64-pc-linux-gnu) compiled by GNU C version 6.1.0, GMP version 4.3.2, MPFR version 2.4.2, MPC version 0.8.1, isl version 0.15 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 test.F90:7:20: associate(ss => s) 1 Error: Entity ‘ss’ at (1) has a deferred type parameter and requires either the pointer or allocatable attribute
[Bug middle-end/71065] Missing diagnostic for statements between OpenMP 'target' and 'teams'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71065 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- This can't be diagnosed in the middle-end, that is too late and at that point there could be in between the two e.g. declarations and expressions from the teams construct clause expressions, or from gimplification thereof etc.
[Bug middle-end/71065] Missing diagnostic for statements between OpenMP 'target' and 'teams'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71065
--- Comment #2 from Jakub Jelinek ---
Note that according to the omp-lang discussions
#pragma omp target
{
#pragma omp teams
{
...
}
}
is fine, while even
#pragma omp target
{
{}
#pragma omp teams
{
...
}
}
(or ; etc., before or after teams, is invalid).
Whether
#pragma omp target
{
label:
#pragma omp teams
{
...
}
}
is valid or not is unclear.
[Bug target/77281] [ARM] Wrong code generated for move of constant vector with mix of signed and unsigned zeros
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77281 --- Comment #2 from mwahab at gcc dot gnu.org --- Author: mwahab Date: Fri Aug 19 13:59:18 2016 New Revision: 239610 URL: https://gcc.gnu.org/viewcvs?rev=239610&root=gcc&view=rev Log: [ARM] Fix an invalid check for vectors of the same floating-point constants. 2016-08-19 Matthew Wahab PR target/77281 * config/arm/arm.c (neon_valid_immediate): Delete declaration. Use const_vec_duplicate to check for duplicated elements. Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/arm.c
[Bug fortran/77296] Compiler Error with allocatable string and associate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77296 --- Comment #1 from Thomas Koenig --- Also fails with 5.4.0.
[Bug c++/77299] New: No warning for unused "INT64_MAX" and similar constants
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77299
Bug ID: 77299
Summary: No warning for unused "INT64_MAX" and similar
constants
Product: gcc
Version: 6.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: wipedout at yandex dot ru
Target Milestone: ---
On http://gcc.godbolt.org/ I select gcc 6.1 and specify -O3 -Wall
The code is:
#include
int main()
{
INT64_MIN; // no warning
INT64_MIN; // no warning
INT64_MAX; // -Wunused-value
INT64_MAX; // -Wunused-value
1; // -Wunused-value
0; // -Wunused-value
INT64_MIN + 0; // -Wunused-value
}
For some reason there's no warning where unused INT64_MIN occurs.
[Bug c++/77298] New: -Wnonnull-compare only emitted for code which is invoked
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77298
Bug ID: 77298
Summary: -Wnonnull-compare only emitted for code which is
invoked
Product: gcc
Version: 6.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: wipedout at yandex dot ru
Target Milestone: ---
On http://gcc.godbolt.org/ I select gcc 6.1 and specify -O3 -Wall
The code is:
struct CHandle {
int handle;
int GetHandle() const
{
if (this != 0) //[-Wnonnull-compare] emitted
return handle;
return 0;
}
};
int main()
{
CHandle* h = new CHandle();
return h->GetHandle();
}
Initially [-Wnonnull-compare] is emitted where "this" is checked for null. Now
I change main() to this:
int main()
{
CHandle* h = new CHandle();
return 0;//h->GetHandle();
}
and the warning is no longer emitted. The code is compiled and it's known at
compile time that there's a check of "this" against null yet not warning.
[Bug c++/77297] New: -Wnonnull-compare not emitted inside ternary operator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77297
Bug ID: 77297
Summary: -Wnonnull-compare not emitted inside ternary operator
Product: gcc
Version: 6.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: wipedout at yandex dot ru
Target Milestone: ---
On http://gcc.godbolt.org/ I select gcc 6.1 and specify -O3 -Wall
Here's the code:
struct CHandle {
int handle;
int GetHandle() const
{
if (this == 0) //[-Wnonnull-compare] emitted as expected
return handle;
return (this == 0) ? 1 : handle; //[-Wnonnull-compare] not emitted
}
};
int main()
{
CHandle* h = new CHandle();//
return h->GetHandle();
}
[-Wnonnull-compare] is emitted for "if (this == 0)" line but not for
"(this==0)?" ternary operator line. The two are completely equivalent checks.
The warning should be emitted for both. If I remove "if (this == 0) return
handle" then still no warning is emitted.
[Bug fortran/69281] gfortran ICE on temporary array in function call with -fstack-arrays -fopenmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69281 --- Comment #3 from Jakub Jelinek --- Author: jakub Date: Fri Aug 19 15:27:40 2016 New Revision: 239618 URL: https://gcc.gnu.org/viewcvs?rev=239618&root=gcc&view=rev Log: PR fortran/69281 * trans-openmp.c (gfc_trans_omp_parallel, gfc_trans_omp_task, gfc_trans_omp_target): Wrap gfc_trans_omp_code result in an extra BIND_EXPR with its own forced BLOCK. * gfortran.dg/gomp/pr69281.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/gomp/pr69281.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-openmp.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/72744] ICE in verify_ssa, at tree-ssa.c:1039
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72744 --- Comment #3 from Jakub Jelinek --- Author: jakub Date: Fri Aug 19 15:28:59 2016 New Revision: 239619 URL: https://gcc.gnu.org/viewcvs?rev=239619&root=gcc&view=rev Log: PR fortran/72744 * gfortran.dg/gomp/pr72744.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/gomp/pr72744.f90 Modified: trunk/gcc/testsuite/ChangeLog
[Bug fortran/71014] associate statement inside omp parallel do appears to disable default private attribute for inner loop indices
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71014 --- Comment #10 from Jakub Jelinek --- Author: jakub Date: Fri Aug 19 15:30:33 2016 New Revision: 239620 URL: https://gcc.gnu.org/viewcvs?rev=239620&root=gcc&view=rev Log: PR fortran/71014 * resolve.c (gfc_resolve): For ns->construct_entities don't save, clear and restore omp state around the resolving. * testsuite/libgomp.fortran/pr71014.f90: New test. Added: trunk/libgomp/testsuite/libgomp.fortran/pr71014.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/libgomp/ChangeLog
[Bug c++/77297] parenthesis suppress/silences all warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77297 Manuel López-Ibáñez changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |NEW Last reconfirmed||2016-08-19 CC||manu at gcc dot gnu.org Summary|-Wnonnull-compare not |parenthesis |emitted inside ternary |suppress/silences all |operator|warnings Ever confirmed|0 |1 --- Comment #1 from Manuel López-Ibáñez --- This is a more general issue with not warning for parenthesized expressions. Same as PR25733 in C. Same as PR74765.
[Bug c++/77299] No warning for unused "INT64_MAX" and similar constants
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77299 Manuel López-Ibáñez changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||manu at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #1 from Manuel López-Ibáñez --- It seems the same issue with extra parenthesis: INT64_MIN + 0; // -Wunused-value (INT64_MIN + 0); // missing warning *** This bug has been marked as a duplicate of bug 77297 ***
[Bug c++/77298] -Wnonnull-compare only emitted for code which is invoked
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77298
Martin Sebor changed:
What|Removed |Added
CC||msebor at gcc dot gnu.org
--- Comment #2 from Martin Sebor ---
I was about to comment on this but Manuel beat me to it.
The problem seems to be that the function is defined inline. When it's
out-of-line, the warning is emitted.
I'm inclined to agree with the submitter. The warning should be issued
consistently for inline functions as well as out-of-line ones, regardless of
whether they are called. Otherwise it will miss the problem in inline
functions in class libraries (that aren't being sufficiently tested).
$ cat z.C && /build/gcc-trunk-svn/gcc/xgcc -B /build/gcc-trunk-svn/gcc -O0
-Wall -Wextra z.C
struct A {
int f () { return this ? 1 : 0; }
};
struct B {
int f () { return this ? 1 : 0; } // missing -Wnonnull-compare
};
struct C {
int f ();
};
int C::f () { return this ? 1 : 0; }
int main()
{
return A ().f ();
}
z.C: In member function ‘int A::f()’:
z.C:2:26: warning: nonnull argument ‘this’ compared to NULL [-Wnonnull-compare]
int f () { return this ? 1 : 0; }
~^~~
z.C: In member function ‘int C::f()’:
z.C:13:27: warning: nonnull argument ‘this’ compared to NULL
[-Wnonnull-compare]
int C::f () { return this ? 1 : 0; }
~^~~
[Bug c++/77298] -Wnonnull-compare only emitted for code which is invoked
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77298
Manuel López-Ibáñez changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC||manu at gcc dot gnu.org
Resolution|--- |INVALID
--- Comment #1 from Manuel López-Ibáñez ---
This is by design. Most users do not want to get warnings for code that is not
reachable or if the thing compared against NULL has changed and become NULL
(https://gcc.gnu.org/PR69835). In your case, the whole function gets optimized
out.
This is similar to:
if (false) {
if (this != 0)
return handle;
}
[Bug c++/77297] parenthesis suppress/silences all warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77297 --- Comment #2 from Manuel López-Ibáñez --- *** Bug 77299 has been marked as a duplicate of this bug. ***
[Bug c++/77298] -Wnonnull-compare only emitted for code which is invoked
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77298
--- Comment #3 from Martin Sebor ---
I should add that Clang issues the warning for all three functions:
$ /build/llvm-trunk/bin/clang -S -Wall -Wextra -Wpedantic z.C
z.C:2:21: warning: 'this' pointer cannot be null in well-defined C++ code;
pointer may be assumed to always convert to true
[-Wundefined-bool-conversion]
int f () { return this ? 1 : 0; }
^~~~ ~
z.C:6:21: warning: 'this' pointer cannot be null in well-defined C++ code;
pointer may be assumed to always convert to true
[-Wundefined-bool-conversion]
int f () { return this ? 1 : 0; }
^~~~ ~
z.C:13:22: warning: 'this' pointer cannot be null in well-defined C++ code;
pointer may be assumed to always convert to true
[-Wundefined-bool-conversion]
int C::f () { return this ? 1 : 0; }
^~~~ ~
3 warnings generated.
[Bug rtl-optimization/64082] virtual register elimination doing bad for local array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64082 Joey Ye changed: What|Removed |Added CC||joey.ye at arm dot com --- Comment #1 from Joey Ye --- Code sequence from trunk 20160705 is as following: bar: stp x29, x30, [sp, -48]! add x29, sp, 0 stp x19, x20, [sp, 16] add x19, x29, 32 mov w20, w0 mov x0, x19 bl g ldrbw0, [x19, w20, sxtw] bl f ldp x19, x20, [sp, 16] ldp x29, x30, [sp], 48 Apparantly issue described in this ticket has been resolved, probably by https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62173. Resolved.
[Bug target/77270] Flag -mprftchw is shared with 3dnow for -march=k8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77270 Uroš Bizjak changed: What|Removed |Added Keywords|wrong-code | Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2016-08-19 Assignee|unassigned at gcc dot gnu.org |ubizjak at gmail dot com Target Milestone|--- |6.3 Ever confirmed|0 |1 --- Comment #3 from Uroš Bizjak --- I have a patch.
[Bug target/77300] New: [MIPS] incorrectly moves instruction containing local GOT16 relocation into a delay slot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77300 Bug ID: 77300 Summary: [MIPS] incorrectly moves instruction containing local GOT16 relocation into a delay slot Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: james410 at cowgill dot org.uk Target Milestone: --- Created attachment 39474 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39474&action=edit reduced testcase Debian bug: https://bugs.debian.org/834147 While I'm not sure about the exact conditions this bug occurs, I have managed to get GCC to produce an object with a dangling GOT16 relocation (ie one without a LO16) using the attached source. The bug was originally found in blender, but I've managed to reduce it to something reasonably small. Compile with: mipsel-linux-gnu-g++-6 -O2 -fPIC -c src.cpp You can tell the bug occurs because attempting to link it gives this error: mipsel-linux-gnu-g++-6 src.o /usr/lib/gcc-cross/mipsel-linux-gnu/6/../../../../mipsel-linux-gnu/bin/ld: src.o: Can't find matching LO16 reloc against `_ZN1HIiE5m_fn4ERK1G.isra.1' for R_MIPS_GOT16 at 0xcc in section `.text._ZN1HIiE5m_fn5ERK1G[_ZN1HIiE5m_fn5ERK1G]' The offending assembly contains this: === $L5: lw $16,%got(_ZN1HIiE5m_fn4ERK1G.isra.1)($28) $L17: addiu $16,$16,%lo(_ZN1HIiE5m_fn4ERK1G.isra.1) move$25,$16 .reloc 1f,R_MIPS_JALR,_ZN1HIiE5m_fn4ERK1G.isra.1 1: jalr$25 move$4,$17 move$25,$16 .reloc 1f,R_MIPS_JALR,_ZN1HIiE5m_fn4ERK1G.isra.1 1: jalr$25 move$4,$17 [...] $L15: lw $2,28($sp) beq $2,$0,$L17 lw $16,%got(_ZN1HIiE5m_fn4ERK1G.isra.1)($28) b $L16 lw $25,%call16(_ZN1HIiE5m_fn1Ev)($28) === The error is that the bottommost %got relocation does not have a corresponding %lo relocation. It seems that GCC has "optimized" the function by moving the lw into the delay slot of the 'beq $2,$0,$L17' instruction, but this unfortunately doesn't work because the corresponding %lo at $L17 also would need to be copied. My compiler is: mipsel-linux-gnu-g++-6 (Debian 6.1.1-9) 6.1.1 20160705
[Bug c/77292] Spurious warning: logical not is only applied to the left hand side of comparison
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77292 --- Comment #13 from Segher Boessenkool --- (In reply to Manuel López-Ibáñez from comment #12) > (In reply to Segher Boessenkool from comment #11) > > Both of these suggestions are not so good. "!(a == b)" is better written > > as "a != b", and "!(a) == b" is just horrible. > > Agreed for the former, but the latter is suggesting (!a) == b, which is IMHO > clearer than ! a == b. Ah. The parens are placed suggestively around the "a" in the suggestion, so it is misleading even :-/ (Or maybe I'm just not very good at reading).
[Bug tree-optimization/73714] [Regression 7] Incorrect unsigned long long arithmetic optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=73714 Marc Glisse changed: What|Removed |Added CC||marc.glisse at normalesup dot org --- Comment #2 from Marc Glisse --- Ah, my verifier considers that some_32bit_int << 57 is 0, while it actually is undefined or unspecified, and in particular may yield some_32bit_int << 25 on some platforms. I hope I didn't introduce too many similar bugs... I'll look at it more closely when I get time, but anyone should feel free to revert the first hunk of my patch if they need a quicker resolution.
[Bug c++/77298] -Wnonnull-compare only emitted for code which is invoked
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77298 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- The warning for proper behavior needs the function being gimplified and in SSA form, unless the FE start doing that themselves, otherwise it can't generally determine if an argument is known to be non-NULL or has been reassigned afterwards and no guarantees are known about it. Of course, this is quite a special case, because this isn't a parameter one can change in the function in any way, so theoretically we could warn for this in the FE.
[Bug c++/77298] -Wnonnull-compare only emitted for code which is invoked
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77298 --- Comment #5 from Jakub Jelinek --- You can always use -fkeep-inline-functions to get the warning even for unused inlines (by forcing them to be emitted). -Wnonnull-compare isn't the only warning that isn't performed in the FEs early, think about -Wuninitialized and -Wmaybe-uninitialized and many others. Those have the same behavior here.
[Bug middle-end/77301] New: __builtin_object_size incorrect for an array in a struct referenced by a pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77301
Bug ID: 77301
Summary: __builtin_object_size incorrect for an array in a
struct referenced by a pointer
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
The Object Size Checking page of the manual describes the type argument to the
__builtin_object_size intrinsic like so:
type is an integer constant from 0 to 3. If the least significant bit is clear,
objects are whole variables, if it is set, a closest surrounding subobject is
considered the object a pointer points to.
Based on this I would expect the output of the program below to be
4 8 4 8
4 8 4 8
The first line of the expected output above is for a known single object of
struct A, so in __builtin_object_size (a.a, 0), the object referenced by a.a is
a "whole variable" whose size is 4. In __builtin_object_size (a.a, 1), the
"closest surrounding subobject" of a.a is , whose size is 8. The actual
results on this line are exactly the opposite.
The second line of the expected output above is for an "unknown" object of
struct A (or an element of an array of such objects). As above, in
__builtin_object_size (p->a, 0), p->a also refers to the "whole" member a of
the struct, and a's size is 4. Similarly, in __builtin_object_size (p->a, 1)
the result should be the size of the "closest surrounding subobject" of p->a,
or the object that p points to. That's clearly an object of struct A whose
size is 8. Instead, the results are even more confounding than in the first
case. Even if the object pointed to by p were considered to be an array of
some unknown number of structs A, the expected result would then be 4 -1 4 0,
but certainly not -1 4 0 4.
$ cat z.c && /build/gcc-trunk-svn/gcc/xgcc -B /build/gcc-trunk-svn/gcc -O2
-Wall -Wextra z.c && ./a.out
struct A {
char a [4];
int i;
} a;
void __attribute__ ((noclone, noinline))
f (struct A *p)
{
__builtin_printf ("%zi %zi %zi %zi\n",
__builtin_object_size (a.a, 0),
__builtin_object_size (a.a, 1),
__builtin_object_size (a.a, 2),
__builtin_object_size (a.a, 3));
__builtin_printf ("%zi %zi %zi %zi\n",
__builtin_object_size (p->a, 0),
__builtin_object_size (p->a, 1),
__builtin_object_size (p->a, 2),
__builtin_object_size (p->a, 3));
}
int main (void)
{
f (&a);
}
8 4 8 4
-1 4 0 4
[Bug c++/77298] -Wnonnull-compare only emitted for code which is invoked
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77298 --- Comment #6 from Martin Sebor --- Yes, that makes sense to me as an explanation of the limitation of the GCC implementation and a solution/workaround for it. I don't think it's something users unfamiliar with GCC internals think of, though. I don't have a sense of how much work it would be to change GCC to issue these warnings consistently, whether or not functions are used, but I suspect it's not a trivial "bug fix." Until this change is made (if it ever is made), it seems that documenting the limitation and the -fkeep-inline-functions workaround might help users who are relying on these warnings to be consistent. If you all agree I volunteer to reopen thus bug and add something to the manual. Yes?
[Bug rtl-optimization/77289] [7 Regression] ICE in extract_constrain_insn, at recog.c:2212 on powerpc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77289
Peter Bergner changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2016-08-19
Ever confirmed|0 |1
--- Comment #1 from Peter Bergner ---
Confirmed. I'll have a look.
Here's a smaller test case:
bergner@genoa:~/gcc/BUGS/PR77289$ cat pr77289.i
void dummy (float *);
float bar (float);
void
foo (long a, long b)
{
float c[0];
b = 0;
for (; b < a; b++)
c[b] = bar (c[b]);
dummy (c);
}
bergner@genoa:~/gcc/BUGS/PR77289$
/home/bergner/gcc/build/gcc-fsf-mainline-pr77289-debug/gcc/xgcc
-B/home/bergner/gcc/build/gcc-fsf-mainline-pr77289-debug/gcc -m32 -O3
-mcpu=power7 -funroll-loops -ffast-math -S pr77289.i
pr77289.i: In function ‘foo’:
pr77289.i:11:1: error: insn does not satisfy its constraints:
}
^
(insn 77 79 71 3 (parallel [
(set (reg:SF 33 1)
(mem:SF (plus:SI (reg/f:SI 1 1)
(const_int 8 [0x8])) [1 MEM[base: _17, offset: 0B]+0 S4
A32]))
(set (reg:SI 31 31 [orig:208 ivtmp.6 ] [208])
(plus:SI (reg/f:SI 1 1)
(const_int 8 [0x8])))
]) pr77289.i:9 617 {*movsf_update1}
(nil))
pr77289.i:11:1: internal compiler error: in extract_constrain_insn, at
recog.c:2212
0x10c634f3 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/home/bergner/gcc/gcc-fsf-mainline-pr77289/gcc/rtl-error.c:108
0x10c6358f _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/home/bergner/gcc/gcc-fsf-mainline-pr77289/gcc/rtl-error.c:119
0x10be640f extract_constrain_insn(rtx_insn*)
/home/bergner/gcc/gcc-fsf-mainline-pr77289/gcc/recog.c:2212
0x10a58b0b check_rtl
/home/bergner/gcc/gcc-fsf-mainline-pr77289/gcc/lra.c:2108
0x10a59db7 lra(_IO_FILE*)
/home/bergner/gcc/gcc-fsf-mainline-pr77289/gcc/lra.c:2516
0x109d5813 do_reload
/home/bergner/gcc/gcc-fsf-mainline-pr77289/gcc/ira.c:5385
0x109d6047 execute
/home/bergner/gcc/gcc-fsf-mainline-pr77289/gcc/ira.c:5569
Please submit a full bug report,
[Bug middle-end/77301] __builtin_object_size incorrect for an array in a struct referenced by a pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77301 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jakub at gcc dot gnu.org Resolution|--- |INVALID --- Comment #1 from Jakub Jelinek --- The result looks good, the expectations are wrong. If the least significant bit is clear (i.e. bos0 and bos2), then objects are whole variables, otherwise (bos1/bos3) we take possible subobjects into account. bos0 is the size of the whole object, ignoring any subobject boundaries, so it must be 8. The subobject size is 4, so that you get for bos1. bos2 and bos3 are the minimas, but on the first line you know the sizes exactly, so bos0 == bos2 and bos1 == bos3. For the second line, you don't know how big the object is, so -1 is the maximum and 0 is minimum for the whole object. For the subobject, it isn't a flexible array member or something like that, so in a valid program the subobject length must be exactly 4.
[Bug target/32187] Complex __float128 is rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32187 --- Comment #11 from Joseph S. Myers --- Author: jsm28 Date: Fri Aug 19 17:43:26 2016 New Revision: 239625 URL: https://gcc.gnu.org/viewcvs?rev=239625&root=gcc&view=rev Log: Implement C _FloatN, _FloatNx types. ISO/IEC TS 18661-3:2015 defines C bindings to IEEE interchange and extended types, in the form of _FloatN and _FloatNx type names with corresponding fN/FN and fNx/FNx constant suffixes and FLTN_* / FLTNX_* macros. This patch implements support for this feature in GCC. The _FloatN types, for N = 16, 32, 64 or >= 128 and a multiple of 32, are types encoded according to the corresponding IEEE interchange format (endianness unspecified; may use either the NaN conventions recommended in IEEE 754-2008, or the MIPS NaN conventions, since the choice of convention is only an IEEE recommendation, not a requirement). The _FloatNx types, for N = 32, 64 and 128, are IEEE "extended" types: types extending a narrower format with range and precision at least as big as those specified in IEEE 754 for each extended type (and with unspecified representation, but still following IEEE semantics for their values and operations - and with the set of values being determined by the precision and the maximum exponent, which means that while Intel "extended" is suitable for _Float64x, m68k "extended" is not). These types are always distinct from and not compatible with each other and the standard floating types float, double, long double; thus, double, _Float64 and _Float32x may all have the same ABI, but they are three still distinct types. The type names may be used with _Complex to construct corresponding complex types (unlike __float128, which acts more like a typedef name than a keyword - thus, this patch may be considered to fix PR c/32187). The new suffixes can be combined with GNU "i" and "j" suffixes for constants of complex types (e.g. 1.0if128, 2.0f64i). The set of types supported is implementation-defined. In this GCC patch, _Float32 is SFmode if that is suitable; _Float32x and _Float64 are DFmode if that is suitable; _Float128 is TFmode if that is suitable; _Float64x is XFmode if that is suitable, and otherwise TFmode if that is suitable. There is a target hook to override the choices if necessary. "Suitable" means both conforming to the requirements of that type, and supported as a scalar type including in libgcc. The ABI is whatever the back end does for scalars of that mode (but note that _Float32 is passed without promotion in variable arguments, unlike float). All the existing issues with exceptions and rounding modes for existing types apply equally to the new type names. No GCC port supports a floating-point format suitable for _Float128x. Although there is HFmode support for ARM and AArch64, use of that for _Float16 is not enabled. Supporting _Float16 would require additional work on the excess precision aspects of TS 18661-3: there are new values of FLT_EVAL_METHOD, which are not currently supported in GCC, and FLT_EVAL_METHOD == 0 now means that operations and constants on types narrower than float are evaluated to the range and precision of float. Implementing that, so that _Float16 gets evaluated with excess range and precision, would involve changes to the excess precision infrastructure so that the _Float16 case is enabled by default, unlike the x87 case which is only enabled for -fexcess-precision=standard. Other differences between _Float16 and __fp16 would also need to be disentangled. GCC has some prior support for nonstandard floating-point types in the form of __float80 and __float128. Where these were previously types distinct from long double, they are made by this patch into aliases for _Float64x / _Float128 if those types have the required properties. In principle the set of possible _FloatN types is infinite. This patch hardcodes the four such types for N <= 128, but with as much code as possible using loops over types to minimize the number of places with such hardcoding. I don't think it's likely any further such types will be of use in future (or indeed that formats suitable for _Float128x will actually be implemented). There is a corner case that all _FloatN, for N >= 128 and a multiple of 32, should be treated as keywords even when the corresponding type is not supported; I intend to deal with that in a followup patch. Tests are added for various functionality of the new types, mostly using type-generic headers. The tests use dg-add-options to pass any extra options needed to enable the types; this is wired up to use the same options as for __float128 on powerpc to enable _Float128 and _Float64x, and effective-target keywords for runtime support do the same hardware test as for __float128 to make sure the VSX instructions generated by those options are supported. (Corresponding additions would be needed for _Float16 on ARM as well if that were enabled with -mfp16-format=ieee required to use it rather than
[Bug c++/77298] -Wnonnull-compare only emitted for code which is invoked
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77298 --- Comment #7 from Jakub Jelinek --- Different warnings are simply done at different compilation phases. This is similar to how you get only a subset of FE warnings on uninstantiated templates, only something can be warned reliably at that phase, and something is just too hard to warn at that phase. So, lots of warnings you get only when actually instantiating the templates.
[Bug target/32187] Complex __float128 is rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32187 --- Comment #12 from joseph at codesourcery dot com --- You can now use _Complex _Float128. Given that, it's not obvious that _Complex __float128, with the legacy __float128 type name, should be supported (although not supporting that means also not supporting _Complex __ibm128 for powerpc64le; both are built-in typedefs, and no _Float* keyword can be used for __ibm128). _Float128 isn't supported for C++, although there's the argument that there std::complex<__float128> is the thing support should be added / enabled for, rather than adding to the support for C-style complex types in C++.
[Bug tree-optimization/62171] restrict pointer to struct with restrict pointers parm doesn't prevent aliases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62171
--- Comment #16 from ncahill_alt at yahoo dot com ---
(In reply to Richard Biener from comment #15)
> (In reply to ncahill_alt from comment #14)
> > This test is failing for me in GCC 6.1.0 (i386). It complains about having
> > no vectype.
> >
> > Why that is, I don't know. But it doesn't seem to be a problem otherwise,
> > it seems pretty safe to ignore except that it could vectorize the loop but
> > doesn't.
> >
> > I wonder if it would be easier just to have this be UNSUPPORTED on i386.
>
> It should be by means of the { dg-require-effective-target vect_double }
> directive. Does it work if you remove the { dg-options ... } one?
It does, the test still runs but the result is a pass. If I place the
dg-options line below the require-target line, it fails.
[Bug middle-end/77301] __builtin_object_size incorrect for an array in a struct referenced by a pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77301
--- Comment #2 from Martin Sebor ---
Thanks. As surprising as that seems, it would explain the output of the test
case in comment #0, even though it's not at all obvious from the manual.
But if change the test case like below I get three different results. The
latter two don't jibe with my understanding of your explanation, or seem
correct (or desirable/safe) to me.
$ cat z.c && /build/gcc-trunk-svn/gcc/xgcc -B /build/gcc-trunk-svn/gcc -O2
-Wall -Wextra z.c && ./a.out
struct A {
char a [4];
void (*pf)(void);
} a [2];
int main (void)
{
struct A* p = __builtin_malloc (sizeof (struct A) * 2);
__builtin_printf ("%zi %zi %zi %zi\n",
__builtin_object_size (a->a, 0),
__builtin_object_size (a->a, 1),
__builtin_object_size (a->a, 2),
__builtin_object_size (a->a, 3));
__builtin_printf ("%zi %zi %zi %zi\n",
__builtin_object_size (p->a, 0),
__builtin_object_size (p->a, 1),
__builtin_object_size (p->a, 2),
__builtin_object_size (p->a, 3));
__builtin_printf ("%zi %zi %zi %zi\n",
__builtin_object_size (p->a + 1, 0),
__builtin_object_size (p->a + 1, 1),
__builtin_object_size (p->a + 1, 2),
__builtin_object_size (p->a + 1, 3));
}
32 32 32 32
32 4 32 4
31 3 31 31
[Bug target/77270] Flag -mprftchw is shared with 3dnow for -march=k8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77270 --- Comment #4 from uros at gcc dot gnu.org --- Author: uros Date: Fri Aug 19 18:14:03 2016 New Revision: 239626 URL: https://gcc.gnu.org/viewcvs?rev=239626&root=gcc&view=rev Log: PR target/77270 * config/i386/i386.c (ix86_option_override_internal): Remove PTA_PRFCHW from entries that also have PTA_3DNOW flag. Enable SSE prefetch also for TARGET_PREFETCHWT1. Do not try to enable TARGET_PRFCHW ISA flag here. * config/i386/i386.md (prefetch): Enable also for TARGET_3DNOW. Rewrite expander function body. (*prefetch_3dnow): Enable for TARGET_3DNOW and TARGET_PREFETCHWT1. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/config/i386/i386.md
[Bug debug/59319] gcc does not emit DW_AT_friend or DW_TAG_friend
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59319 Alexandre Oliva changed: What|Removed |Added Status|NEW |ASSIGNED CC||aoliva at gcc dot gnu.org --- Comment #1 from Alexandre Oliva --- Mine. Initial, incomplete patch just posted to gcc-patches.
[Bug c++/77302] New: partial specialization marked as ambiguous
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77302
Bug ID: 77302
Summary: partial specialization marked as ambiguous
Product: gcc
Version: 6.1.1
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: rlangendam at gmail dot com
Target Milestone: ---
Created attachment 39475
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39475&action=edit
C++ source file that wrongfully fails to compile
Compiling the attached C++ source file with g++ 6.1.1 20160802, as described
below, yields an ambiguity error wrongfully. After all, out of the two
mentioned partial specializations, the former is more specialized than the
latter. FYI, the file compiles fine using clang++ 3.8, using the same options.
$ g++ -std=c++11 -c test.cpp
test.cpp:15:64: error: ambiguous template instantiation for ‘struct
Test >’
static_assert(std::is_same>::type,
void>::value, "");
^~
test.cpp:6:8: note: candidates are: template struct
Test > [with T = int]
struct Test> {
^~
test.cpp:11:8: note: template struct
Test > [with T = int; T V = 0]
struct Test> :
^~
test.cpp:15:28: error: incomplete type ‘Test >’
used in nested name specifier
static_assert(std::is_same>::type,
void>::value, "");
^~~~
test.cpp:15:28: error: incomplete type ‘Test >’
used in nested name specifier
test.cpp:15:76: error: template argument 1 is invalid
static_assert(std::is_same>::type,
void>::value, "");
[Bug tree-optimization/71550] [7 Regression] wrong code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71550 --- Comment #4 from Jeffrey A. Law --- This has gone latent on the trunk, but I'm pretty sure the core issues remain. Looking deeper into the problem, this may be another case of jump threading invalidating the cached loop iteration information.
[Bug c++/77298] -Wnonnull-compare only emitted for code which is invoked
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77298 --- Comment #8 from Manuel López-Ibáñez --- (In reply to Martin Sebor from comment #6) > Yes, that makes sense to me as an explanation of the limitation of the GCC > implementation and a solution/workaround for it. I don't think it's > something users unfamiliar with GCC internals think of, though. I don't > have a sense of how much work it would be to change GCC to issue these > warnings consistently, whether or not functions are used, but I suspect it's > not a trivial "bug fix." As Jakub said, making the warning consistent for "this" is not hard. You could warn in the FE for 'this', then skip 'this' when warning in the ME. Warning the FE is trivial: https://gcc.gnu.org/viewcvs/gcc/trunk/gcc/cp/typeck.c?r1=233472&r2=233471&pathrev=233472 and it will allow you to give a nicer, more specific message like Clang does. (I think there is even a PR about the message) Feel free to reopen this PR and refashion it with that purpose.
[Bug c++/27336] "this" pointer is not assumed to be not null
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=27336 Manuel López-Ibáñez changed: What|Removed |Added CC||manu at gcc dot gnu.org --- Comment #7 from Manuel López-Ibáñez --- Isn't this fixed already? Should we close it?
[Bug tree-optimization/62171] restrict pointer to struct with restrict pointers parm doesn't prevent aliases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62171 --- Comment #17 from ncahill_alt at yahoo dot com --- This was the only test that failed for me, the others were debug info in LTO mode. I'm very glad that GCC 6.1.0 works so well and built cleanly like it did. This test was a minor thing because I don't use -O3 at all. I just thought, since it was the only test to fail, it seemed worthwhile mentioning it so that the testsuite would be very clean indeed. Thanks, hopefully I've given enough info for the fix to be obvious. Neil Cahill
[Bug tree-optimization/62171] restrict pointer to struct with restrict pointers parm doesn't prevent aliases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62171 --- Comment #18 from vries at gcc dot gnu.org --- dg-options line was removed on trunk at https://gcc.gnu.org/viewcvs?rev=237745&root=gcc&view=rev
[Bug c/52952] Wformat location info is bad (wrong column number)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52952
Bernd Edlinger changed:
What|Removed |Added
CC||bernd.edlinger at hotmail dot
de
--- Comment #46 from Bernd Edlinger ---
(In reply to David Malcolm from comment #45)
> trunk/gcc/testsuite/gcc.dg/cpp/pr66415-1.c
David, this test case does fail because the caret is not always shown in
column 71.
I've got it once, but and when I tried to repeat this test alone it works.
It seems to depend if stderr is a tty (isatty(2) != 0)
I think the problem is in diagnostics.c
diagnostic_set_caret_max_width (diagnostic_context *context, int value)
{
/* One minus to account for the leading empty space. */
value = value ? value - 1
: (isatty (fileno (pp_buffer (context->printer)->stream))
? get_terminal_width () - 1: INT_MAX);
and:
get_terminal_width (void)
{
const char * s = getenv ("COLUMNS");
if (s != NULL) {
int n = atoi (s);
if (n > 0)
return n;
}
#ifdef TIOCGWINSZ
struct winsize w;
w.ws_col = 0;
if (ioctl (0, TIOCGWINSZ, &w) == 0 && w.ws_col > 0)
return w.ws_col;
#endif
return INT_MAX;
}
I think it depends on the terminal window, where I start the
make check, it is often a COLUMNS=80 then maybe the test will
fail, because the output is squeezed into 80 column, but
if COLUMNS=120 the test will pass.
What do you think?
[Bug libstdc++/77303] New: std::max_element not constexpr with -D_GLIBCXX_DEBUG
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77303
Bug ID: 77303
Summary: std::max_element not constexpr with -D_GLIBCXX_DEBUG
Product: gcc
Version: 6.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: lukibartl at gmail dot com
Target Milestone: ---
Created attachment 39476
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39476&action=edit
The preprocessed file
When compiling with -D_GLIBCXX_DEBUG, std::max_element is not constexpr:
Code:
#include
int main() {
constexpr size_t max = std::max({1, 2, 3});
return max;
}
Compiled with:
g++ -v -save-temps -std=c++14 -D_GLIBCXX_DEBUG gcc_error.cpp
Output:
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/6.1.1/lto-wrapper
Target: x86_64-redhat-linux
Configured with: ../configure --enable-bootstrap
--enable-languages=c,c++,objc,obj-c++,fortran,ada,go,lto --prefix=/usr
--mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared
--enable-threads=posix --enable-checking=release --enable-multilib
--with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions
--enable-gnu-unique-object --enable-linker-build-id
--with-linker-hash-style=gnu --enable-plugin --enable-initfini-array
--disable-libgcj --with-isl --enable-libmpx --enable-gnu-indirect-function
--with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux
Thread model: posix
gcc version 6.1.1 20160621 (Red Hat 6.1.1-3) (GCC)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++14' '-D' '_GLIBCXX_DEBUG'
'-shared-libgcc' '-mtune=generic' '-march=x86-64'
/usr/libexec/gcc/x86_64-redhat-linux/6.1.1/cc1plus -E -quiet -v -D_GNU_SOURCE
-D _GLIBCXX_DEBUG gcc_error.cpp -mtune=generic -march=x86-64 -std=c++14
-fpch-preprocess -o gcc_error.ii
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-redhat-linux/6.1.1/include-fixed"
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-redhat-linux/6.1.1/../../../../x86_64-redhat-linux/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/lib/gcc/x86_64-redhat-linux/6.1.1/../../../../include/c++/6.1.1
/usr/lib/gcc/x86_64-redhat-linux/6.1.1/../../../../include/c++/6.1.1/x86_64-redhat-linux
/usr/lib/gcc/x86_64-redhat-linux/6.1.1/../../../../include/c++/6.1.1/backward
/usr/lib/gcc/x86_64-redhat-linux/6.1.1/include
/usr/local/include
/usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++14' '-D' '_GLIBCXX_DEBUG'
'-shared-libgcc' '-mtune=generic' '-march=x86-64'
/usr/libexec/gcc/x86_64-redhat-linux/6.1.1/cc1plus -fpreprocessed gcc_error.ii
-quiet -dumpbase gcc_error.cpp -mtune=generic -march=x86-64 -auxbase gcc_error
-std=c++14 -version -o gcc_error.s
GNU C++14 (GCC) version 6.1.1 20160621 (Red Hat 6.1.1-3) (x86_64-redhat-linux)
compiled by GNU C version 6.1.1 20160621 (Red Hat 6.1.1-3), GMP version
6.1.0, MPFR version 3.1.4, MPC version 1.0.2, isl version 0.14 or 0.13
warning: GMP header version 6.1.0 differs from library version 6.1.1.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++14 (GCC) version 6.1.1 20160621 (Red Hat 6.1.1-3) (x86_64-redhat-linux)
compiled by GNU C version 6.1.1 20160621 (Red Hat 6.1.1-3), GMP version
6.1.0, MPFR version 3.1.4, MPC version 1.0.2, isl version 0.14 or 0.13
warning: GMP header version 6.1.0 differs from library version 6.1.1.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 8e1af9556445b8cc2090cc3ce62d071f
In file included from /usr/include/c++/6.1.1/algorithm:62:0,
from gcc_error.cpp:1:
/usr/include/c++/6.1.1/bits/stl_algo.h: In function 'int main()':
gcc_error.cpp:4:36: in constexpr expansion of
'std::max(std::initializer_list{((const int*)(& ._65)), 3u})'
/usr/include/c++/6.1.1/bits/stl_algo.h:3460:31: error: 'constexpr _FIter
std::max_element(_FIter, _FIter) [with _FIter = const int*]' called in a
constant expression
{ return *std::max_element(__l.begin(), __l.end()); }
^~~~
In file included from /usr/include/c++/6.1.1/algorithm:62:0,
from gcc_error.cpp:1:
/usr/include/c++/6.1.1/bits/stl_algo.h:5539:5: note: 'constexpr _FIter
std::max_element(_FIter, _FIter) [with _FIter = const int*]' is not usable as a
constexpr function because:
max_element(_ForwardIterator __first, _ForwardIterator __last)
^~~
/usr/include/c++/6.1.1/bits/stl_algo.h:5545:45: error: call to non-constexpr
function 'bool __gnu_debug::__valid_range(const _InputIterator&, const
_InputIterator&) [with _InputIterator = const int*]'
__glibcxx_requires_valid_range(__first, __last);
~~~^~
[Bug tree-optimization/71831] __builtin_object_size poor results with no optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71831 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2016-08-19 Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #8 from Martin Sebor --- Patch posted for review: https://gcc.gnu.org/ml/gcc-patches/2016-08/msg01445.html
[Bug c++/77304] New: ICE on C++ code with invalid template parameter: in gimplify_expr, at gimplify.c:11260
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77304
Bug ID: 77304
Summary: ICE on C++ code with invalid template parameter: in
gimplify_expr, at gimplify.c:11260
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
Target Milestone: ---
It seems to affect all earlier versions of GCC since 4.7.x (hangs on 4.7.x). It
is properly rejected by 4.6.x.
$ g++-trunk -v
Using built-in specs.
COLLECT_GCC=g++-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 7.0.0 20160819 (experimental) [trunk revision 239608] (GCC)
$
$ g++-trunk -c small.cpp
small.cpp:5:14: error: ‘struct S’ is not a valid type for a template non-type
parameter
template < S > void f () {}
^
small.cpp: In static member function ‘static void* A::g() [with T = int]’:
small.cpp:9:21: internal compiler error: in gimplify_expr, at gimplify.c:11260
return (void *) f < a >;
^~~
0xb5a8cb gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc-source-trunk/gcc/gimplify.c:11260
0xb646cc gimplify_addr_expr
../../gcc-source-trunk/gcc/gimplify.c:5211
0xb5a030 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc-source-trunk/gcc/gimplify.c:10558
0xb6c08b gimplify_modify_expr
../../gcc-source-trunk/gcc/gimplify.c:4808
0xb58bf8 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc-source-trunk/gcc/gimplify.c:10512
0xb5cb86 gimplify_stmt(tree_node**, gimple**)
../../gcc-source-trunk/gcc/gimplify.c:5804
0xb6a3c5 gimplify_and_add
../../gcc-source-trunk/gcc/gimplify.c:427
0xb6a3c5 gimplify_return_expr
../../gcc-source-trunk/gcc/gimplify.c:1371
0xb5946b gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc-source-trunk/gcc/gimplify.c:10761
0xb5cb86 gimplify_stmt(tree_node**, gimple**)
../../gcc-source-trunk/gcc/gimplify.c:5804
0xb5e8ab gimplify_body(tree_node*, bool)
../../gcc-source-trunk/gcc/gimplify.c:11695
0xb5ef06 gimplify_function_tree(tree_node*)
../../gcc-source-trunk/gcc/gimplify.c:11851
0x9d6fa7 cgraph_node::analyze()
../../gcc-source-trunk/gcc/cgraphunit.c:625
0x9d9b50 analyze_functions
../../gcc-source-trunk/gcc/cgraphunit.c:1086
0x9dadb8 symbol_table::finalize_compilation_unit()
../../gcc-source-trunk/gcc/cgraphunit.c:2546
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
$
---
struct S {};
template < typename T > struct A
{
template < S > void f () {}
static void * g ()
{
return (void *) f < a >;
}
static S a;
};
void * f ()
{
return A < int >::g ();
}
[Bug lto/77305] New: [7 Regression] -fdump-tree-all and -flto causes ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77305
Bug ID: 77305
Summary: [7 Regression] -fdump-tree-all and -flto causes ICE
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
Target Milestone: ---
apinski@apinski-ss1:~/rrt$ cat t.c
short calc_func() {}
apinski@apinski-ss1:~/rrt$ ./tools/bin/gcc -fdump-tree-all -flto t.c
In function ‘calc_func’:
lto1: internal compiler error: Segmentation fault
0xa2d1b7 crash_signal
../../gcc/gcc/toplev.c:335
0xa146dc statistics_counter_event(function*, char const*, int)
../../gcc/gcc/statistics.c:315
0xac0ab7 update_ssa(unsigned int)
../../gcc/gcc/tree-into-ssa.c:3267
0x8ea4cb input_function
../../gcc/gcc/lto-streamer-in.c:1137
0x8ea4cb lto_read_body_or_constructor
../../gcc/gcc/lto-streamer-in.c:1208
0x64672b cgraph_node::get_untransformed_body()
../../gcc/gcc/cgraph.c:3568
0x65281b cgraph_node::expand()
../../gcc/gcc/cgraphunit.c:1955
0x653863 output_in_order
../../gcc/gcc/cgraphunit.c:2228
0x653c9f symbol_table::compile()
../../gcc/gcc/cgraphunit.c:2472
0x5bc047 lto_main()
../../gcc/gcc/lto/lto.c:3320
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See for instructions.
lto-wrapper: fatal error: ./tools/bin/gcc returned 1 exit status
compilation terminated.
/home/apinski/rrt/tools/bin/../lib/gcc/aarch64-unknown-linux-gnu/7.0.0/../../../../aarch64-unknown-linux-gnu/bin/ld:
error: lto-wrapper failed
collect2: error: ld returned 1 exit status
[Bug lto/77305] [7 Regression] -fdump-tree-all and -flto causes ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77305 Andrew Pinski changed: What|Removed |Added Keywords||ice-on-valid-code Target Milestone|--- |7.0
[Bug lto/77305] [7 Regression] -fdump-tree-all and -flto causes ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77305 --- Comment #1 from Andrew Pinski --- https://gcc.gnu.org/ml/gcc-patches/2016-08/msg01456.html
[Bug c++/77306] New: Unable to specify visibility for explicit template instantiations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77306
Bug ID: 77306
Summary: Unable to specify visibility for explicit template
instantiations
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: abbeyj+gcc at gmail dot com
Target Milestone: ---
Created attachment 39477
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39477&action=edit
Reproducer
This bug is being filed as a request for a more limited form of attributes than
that which was rejected in bug #71154. That bug requested any attribute be
allowed on an explicit template instantiation. This bug limits the scope to
just __attribute__((visibility)) which should hopefully be more acceptable.
The visibility attribute is somewhat different from other attributes in that it
doesn't affect the layout or semantics of the type.
Trying to apply a visibility("default") attribute to an explicit template
instantiation does not work if the type has been previously mentioned in the
translation unit.
STR:
==
$ cat main.cpp
template
class C
{
void foo();
};
C g_c_int;
C g_c_double;
template
void C::foo() {}
template class __attribute__((visibility("default"))) C;
template class C;
$ g++ -fvisibility=hidden -fPIC -shared main.cpp -o main.so
main.cpp:13:55: warning: type attributes ignored after type is already defined
[-Wattributes]
template class __attribute__((visibility("default"))) C;
^~
$ nm -C main.so | grep foo
061c t C::foo()
0610 t C::foo()
==
Note that C::foo() is marked as local (lowercase t) when the intent was to
make it global (uppercase). When compiled with clang++ instead there are no
warnings and nm reports:
0510 t C::foo()
0500 W C::foo()
where C::foo() is global as desired.
Similar code, with the __attribute__ replaced with __declspec(dllexport), works
as expected with MSVC 2012. That is, C::foo() is exported from the DLL
and C::foo() is not.
I have a patch for this which I will attach. It relaxes the existing check to
allow attributes on a type that has already been defined as long as the
attribute is a visibility attribute.
[Bug c++/77306] Unable to specify visibility for explicit template instantiations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77306 --- Comment #1 from James Abbatiello --- Created attachment 39478 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39478&action=edit Patch
[Bug tree-optimization/61839] More optimize opportunity for VRP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61839 --- Comment #3 from kugan at gcc dot gnu.org --- Author: kugan Date: Sat Aug 20 01:18:09 2016 New Revision: 239637 URL: https://gcc.gnu.org/viewcvs?rev=239637&root=gcc&view=rev Log: gcc/testsuite/ChangeLog: 2016-08-20 Kugan Vivekanandarajah PR tree-optimization/61839 * gcc.dg/tree-ssa/pr61839_1.c: New test. * gcc.dg/tree-ssa/pr61839_2.c: New test. * gcc.dg/tree-ssa/pr61839_3.c: New test. * gcc.dg/tree-ssa/pr61839_4.c: New test. gcc/ChangeLog: 2016-08-20 Kugan Vivekanandarajah PR tree-optimization/61839 * tree-vrp.c (two_valued_val_range_p): New. (simplify_stmt_using_ranges): Convert CST BINOP VAR where VAR is two-valued to VAR == VAL1 ? (CST BINOP VAL1) : (CST BINOP VAL2). Also Convert VAR BINOP CST where VAR is two-valued to VAR == VAL1 ? (VAL1 BINOP CST) : (VAL2 BINOP CST). Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/pr61839_1.c trunk/gcc/testsuite/gcc.dg/tree-ssa/pr61839_2.c trunk/gcc/testsuite/gcc.dg/tree-ssa/pr61839_3.c trunk/gcc/testsuite/gcc.dg/tree-ssa/pr61839_4.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vrp.c
[Bug debug/49348] DW_TAG_template_* DIEs missing from template specializations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49348 Alexandre Oliva changed: What|Removed |Added CC||aoliva at gcc dot gnu.org --- Comment #4 from Alexandre Oliva --- >From Jason's feedback in response to the proposed patch, it looks like this is not a bug, after all, and GCC is working as intended. Is there any reason for this bug to remain open?
[Bug c/52952] Wformat location info is bad (wrong column number)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52952
--- Comment #47 from Bernd Edlinger ---
COLUMNS=82 make check-gcc-c RUNTESTFLAGS="cpp.exp=pr66415-1.c"
...
Running /home/ed/gnu/gcc-trunk/gcc/testsuite/gcc.dg/cpp/cpp.exp ...
=== gcc Summary ===
# of expected passes3
/home/ed/gnu/gcc-build/gcc/xgcc version 7.0.0 20160819 (experimental) (GCC)
COLUMNS=80 make check-gcc-c RUNTESTFLAGS="cpp.exp=pr66415-1.c"
...
Running /home/ed/gnu/gcc-trunk/gcc/testsuite/gcc.dg/cpp/cpp.exp ...
FAIL: gcc.dg/cpp/pr66415-1.c expected multiline pattern lines 11-12 not found:
"\s*__builtin_printf
\("x%dxxx"\);.*\n
~\^\n"
FAIL: gcc.dg/cpp/pr66415-1.c (test for excess errors)
=== gcc Summary ===
# of expected passes1
# of unexpected failures2
/home/ed/gnu/gcc-build/gcc/xgcc version 7.0.0 20160819 (experimental) (GCC)
[Bug c/52952] Wformat location info is bad (wrong column number)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52952
--- Comment #48 from Bernd Edlinger ---
somethin like that fixes it for me:
Index: pr66415-1.c
===
--- pr66415-1.c (revision 239624)
+++ pr66415-1.c (working copy)
@@ -1,6 +1,7 @@
/* PR c/66415 */
/* { dg-do compile } */
/* { dg-options "-Wformat -fdiagnostics-show-caret" } */
+/* { dg-set-compiler-env-var COLUMNS "82" } */
void
fn1 (void)
[Bug c++/27336] "this" pointer is not assumed to be not null
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=27336
--- Comment #8 from Guillaume Melquiond
---
It is partly fixed. In callee position, GCC now knows that "this" is non-null.
But in caller position, GCC still cannot make use of that information to remove
non-null checks from dynamic casts. The following testcase is still relevant.
struct A { void g(); };
bool f(A *a) {
a->g();
return a;
}
[Bug target/61352] gcc 4.9.0 fails to execute dsymutil when linking executables on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61352 Andrew Pinski changed: What|Removed |Added Component|debug |target --- Comment #17 from Andrew Pinski --- Is this still true?
