[Bug tree-optimization/69823] [6/7 Regression] internal compiler error: in create_pw_aff_from_tree, at graphite-sese-to-poly.c:445
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69823
Tom de Vries changed:
What|Removed |Added
CC||vries at gcc dot gnu.org
--- Comment #5 from Tom de Vries ---
Test-case minimized from PR68279:
...
void
foo (int c, int *p, int *a1, int *a2, int *a3)
{
int i;
if (c)
{
for (i = 0; i < 8; i++)
a1[i] = 1;
if (*p)
*a2 = 0;
}
for (i = 0; i < 8; i++)
a3[i] = 0;
}
...
Fails on x86_64:
...
$ gcc pr-graphite.c -O2 -fgraphite-identity
pr-graphite.c: In function ‘foo’:
pr-graphite.c:2:1: internal compiler error: in create_pw_aff_from_tree, at
graphite-sese-to-poly.c:445
...
[Bug tree-optimization/69823] [6/7 Regression] internal compiler error: in create_pw_aff_from_tree, at graphite-sese-to-poly.c:445
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69823 --- Comment #6 from Tom de Vries --- (In reply to Tom de Vries from comment #5) > Test-case minimized from PR68279: That should have been: Test-case minimized from PR68279 comment 3
[Bug c++/57728] Explicit template instantiation with defaulted method causes missing symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57728 --- Comment #11 from Jason Merrill --- Author: jason Date: Thu Sep 1 01:55:47 2016 New Revision: 239913 URL: https://gcc.gnu.org/viewcvs?rev=239913&root=gcc&view=rev Log: PR c++/57728 - adjust testcase * g++.dg/cpp0x/explicit12.C: Add -save-temps. Modified: trunk/gcc/testsuite/g++.dg/cpp0x/explicit12.C
[Bug other/77437] New: recipe for target 'cp/cp-array-notation.o' failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77437 Bug ID: 77437 Summary: recipe for target 'cp/cp-array-notation.o' failed Product: gcc Version: 4.9.4 Status: UNCONFIRMED Severity: critical Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: manishthatte at hotmail dot com Target Milestone: ---
[Bug other/77437] recipe for target 'cp/cp-array-notation.o' failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77437 Manish changed: What|Removed |Added CC||manishthatte at hotmail dot com --- Comment #1 from Manish --- Created attachment 39530 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39530&action=edit Error while compiling gcc from source code...
[Bug c++/77437] recipe for target 'cp/cp-array-notation.o' failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77437 Andrew Pinski changed: What|Removed |Added Keywords||build Component|other |c++ Severity|critical|normal
[Bug c++/77437] recipe for target 'cp/cp-array-notation.o' failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77437 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2016-09-01 Ever confirmed|0 |1 --- Comment #2 from Andrew Pinski --- Couple of questions: 1) What version of gcc are you starting with? 2) the log file does not have all of error messages (there are some more I know of it).
[Bug rtl-optimization/77416] [7 Regression] LRA rematerializing use of CA reg across function call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77416
--- Comment #3 from Peter Bergner ---
Here's a creduce'd minimal version of the test case that shows the addz after
the function call. Same compiler options as above.
extern int fn2 ();
extern void fn3 ();
extern void fn4 (int);
int a, c, d, f, g, h, i, j, k, l, m, n;
struct
{
int escape;
} *b;
int e[8];
void
fn1 (int p1, int p2)
{
int o = a;
for (; f; f++)
{
int p;
if (e[h])
continue;
if (fn2 (o, d, l, n, p1, i, j, k, 0==0))
continue;
p = p2;
if (b[g].escape)
p++;
fn3 ("", c, m);
if (k)
fn4 (p);
}
}
[Bug c++/77437] recipe for target 'cp/cp-array-notation.o' failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77437 --- Comment #3 from Andrew Pinski --- Also how did you configure gcc?
[Bug c++/77437] recipe for target 'cp/cp-array-notation.o' failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77437 --- Comment #4 from Manish --- (In reply to Andrew Pinski from comment #2) > Couple of questions: > 1) What version of gcc are you starting with? > 2) the log file does not have all of error messages (there are some more I > know of it). Currently I have compiled and installed version 7 gcc from source. And configure log is also attached in the original bug report.
[Bug c++/77437] recipe for target 'cp/cp-array-notation.o' failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77437 --- Comment #5 from Manish --- ../configure --enable-multilib --with-gmp=../gmp --with-mpc=../mpc --with-mpfr=../mpfr
[Bug tree-optimization/77438] New: MMX intrinsic on x86_64 generates bloated code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77438
Bug ID: 77438
Summary: MMX intrinsic on x86_64 generates bloated code
Product: gcc
Version: 4.8.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: acahalan at gmail dot com
Target Milestone: ---
__m64 __attribute__((noinline)) mmx(__m64 x, __m64 y){return _mm_add_pi8(x,y);}
That gives 6 lines of assembly. (movq,movdq2q,paddb,movq,movq,ret) Stuff even
gets moved to the stack. Good code would just do the operation in an xmm
register instead of moving it to a mm register. Failing that, gcc could at
least avoid using the stack.
[Bug c++/60994] gcc does not recognize hidden/shadowed enumeration as valid nested-name-specifier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60994 drepper.fsp+rhbz at gmail dot com changed: What|Removed |Added CC||drepper.fsp+rhbz at gmail dot com --- Comment #11 from drepper.fsp+rhbz at gmail dot com --- There is one problem remaining, it seems, and that's Jonathan's in comment #7. I got here because I re-tested some of the compiler bugs which hit me. Those are fixed.
[Bug target/71151] [avr] -fmerge-constants and -fdata-sections/-ffunction-sections results in string constants in .progmem.gcc_sw section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71151 --- Comment #23 from Senthil Kumar Selvaraj --- Tracking binutils bug https://sourceware.org/bugzilla/show_bug.cgi?id=20545
[Bug bootstrap/68873] excessive duplicate checking during build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68873 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Andrew Pinski --- > 26 checking how to hardcode library paths into programs... immediate This is just a shell switch statement so it does not do much. > 23 checking whether the C compiler works... yes This is done by default by normal autoconf and caching it does not help because the newly build gcc might not work. Anyways caching won't help cross builds here.
[Bug target/77438] MMX intrinsic on x86_64 generates bloated code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77438 --- Comment #1 from Marc Glisse --- Gcc does avoid using the stack when it is more efficient to do so (depends on the -march setting). Yes, using SSE would be better. The general advice is to stop using MMX. Using gcc's vector extension generates even worse code in this case: _8 = VIEW_CONVERT_EXPR(x_4(D)); _9 = VIEW_CONVERT_EXPR(y_5(D)); _10 = _8 ^ _9; _11 = _9 & 9187201950435737471; _12 = _8 & 9187201950435737471; _13 = _10 & 9259542123273814144; _14 = _11 + _12; _15 = _13 ^ _14; _6 = VIEW_CONVERT_EXPR<__m64>(_15); (I think there is another PR asking that vector lowering allow the use of larger vector types)
[Bug libfortran/77261] gfortran.dg/random_3.f90 FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77261 Janne Blomqvist changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Janne Blomqvist --- Fixed, closing.
[Bug other/77417] New: libiberty strverscmp incompatible with glibc strverscmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77417 Bug ID: 77417 Summary: libiberty strverscmp incompatible with glibc strverscmp Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: peda at lysator dot liu.se Target Milestone: --- gnulib strverscmp was recently synced to match glibc strverscmp libiberty is still using the old sort order from glibc before March 2009, and also needs a sync, as glibc and libiberty currently compare differently. See these glibc bugs: https://sourceware.org/bugzilla/show_bug.cgi?id=20524 https://sourceware.org/bugzilla/show_bug.cgi?id=9913 libiberty strverscmp suffers from both, but I have the feeling that 20524 will not be fixed in glibc/gnulib.
[Bug other/77417] libiberty strverscmp incompatible with glibc strverscmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77417 --- Comment #1 from Andrew Pinski --- The only place where strverscmp is used is in darwin specific code. One way of fixing this is to use gnulib which I thought one of the GSOC students were doing (though I don't know the status on that project).
[Bug fortran/77418] New: SELECT TYPE associating entity can be (de)allocated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77418 Bug ID: 77418 Summary: SELECT TYPE associating entity can be (de)allocated Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: pault at gcc dot gnu.org Target Milestone: --- Spotted by Steve Lionel, Intel. As committed this morning, dtio_5.f90 contains a standard defying deallocation at line 153. deallocate(top) To quote Steve: "SELECT TYPE, an associating entity does not have the POINTER or ALLOCATABLE attribute even if its selector does. See 8.1.3.3 - this is more clearly stated in 16-007r1 (same section)." Currently, gfortran permits both allocation and deallocation of the associating entity 'top'. I will correct the testcase to make it conform to the standard. Paul
[Bug fortran/77418] SELECT TYPE associating entity can be (de)allocated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77418 --- Comment #1 from Paul Thomas --- Author: pault Date: Wed Aug 31 07:50:44 2016 New Revision: 239881 URL: https://gcc.gnu.org/viewcvs?rev=239881&root=gcc&view=rev Log: 2016-08-31 Paul Thomas PR fortran/77418 * gfortran.dg/dtio_5.f90: Remove the non-standard deallocation of the associate entity and replace with a pointer to the intended item on the stack. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/dtio_5.f90
[Bug fortran/77418] SELECT TYPE associating entity can be (de)allocated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77418 Paul Thomas changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2016-08-31 Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Paul Thomas --- I will take this one. Paul
[Bug tree-optimization/77352] ICE: verify_ssa failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77352 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Created attachment 39522 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39522&action=edit gcc7-pr77352.patch Untested fix.
[Bug target/71776] relocation truncated to fit: R_ARM_THM_JUMP11 against symbol `__gnu_h2f_internal'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71776 --- Comment #7 from malithyapa at gmail dot com --- >From what i understand this is because of a Thumb16 branch instruction in libgcc. Would it help if i compiled gcc with thumb disabled?
[Bug bootstrap/77359] [7 Regression] AIX bootstrap failure due to alignment of stack pointer + STACK_DYNAMIC_OFFSET
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77359
Dominik Vogt changed:
What|Removed |Added
CC||uweigand at gcc dot gnu.org
--- Comment #3 from Dominik Vogt ---
This test program shows what's happening:
--
#include
#define ALIGN __attribute__ ((aligned(2)))
__attribute__ ((noinline))
void foo(int sz, int x)
{
ALIGN char s[sz];
printf("!!! %p %d\n", (void *)s, x);
}
int main(int sz, char **argv)
{
int x;
foo(sz, x);
return 0;
}
--
(Not sure if "x" is really necessary).
With a 2 byte alignment, the printed address is aligned to 8 bytes but not to
16 bytes, i.e. no more than an 8 byte alignment is guaranteed for the dynamic
stack area.
When compiling the test with 16 byte alignment in the ALIGN macro, the code
generated looks as if the dynamic stack area were 16 byte aligned. When
get_dynamic_stack_size is called the value of REGNO_POINTER_ALIGN
(VIRTUAL_STACK_DYNAMIC_REGNUM) is indeed 128.
._Z3fooii:
LFB..1:
mflr 0
stw 31,-4(1)
addi 3,3,15 <--- was 30 before the patch
So, on AIX "REGNO_POINTER_ALIGN (VIRTUAL_STACK_DYNAMIC_REGNUM)" lies about the
actual alignment of the dynamic area. This may also cause problems with other
users of the expression.
--
As far as I can see, the value is hard coded to STACK_BOUNDARY
(emit-rtl.c:init-emit()) which is hard coded to 128 in aix.h. If
STACK_BOUNDARY cannot be used as this alignment on all targets, we could add
something like
#ifdef STACK_VIRTUAL_STACK_DYNAMIC_ALIGN
REGNO_POINTER_ALIGN (VIRTUAL_STACK_DYNAMIC_REGNUM)
= STACK_VIRTUAL_STACK_DYNAMIC_ALIGN;
#endif
and put the correct value in aix.h:
#define STACK_VIRTUAL_STACK_DYNAMIC_ALIGN 8
--
(Actually, this may be necessary on s390 too which has STACK_BOUNDARY 8 but the
alignment of the dynamic area is only 4.)
--
Comments?
[Bug c++/71913] [5/6/7 Regression] Missing copy elision with operator new
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71913 --- Comment #12 from Jonathan Wakely --- The 4.9 branch is closed.
[Bug fortran/72743] ICE in get_constraint_for_ssa_var, at tree-ssa-structalias.c:2958
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72743 Tobias Burnus changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #6 from Tobias Burnus --- Posted patch: https://gcc.gnu.org/ml/gcc-patches/2016-08/msg02114.html
[Bug bootstrap/77359] [7 Regression] AIX bootstrap failure due to alignment of stack pointer + STACK_DYNAMIC_OFFSET
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77359 --- Comment #4 from David Edelsohn --- Altivec works on AIX, which requires 128 bit alignment. So GCC and AIX are able to cooperate to generate the necessary alignment. The stack pointer is supposed to maintain quadword alignment on AIX. Presumably something in the rs6000 backend is not maintaining or not instructing the common part of GCC to maintain the alignment on AIX, but presumably is maintained on Linux.
[Bug libstdc++/77395] [6/7 Regression] std::is_constructible is false for type constructible via implicit conversion operator affecting std::tuple
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77395 --- Comment #7 from ville at gcc dot gnu.org --- Author: ville Date: Wed Aug 31 12:38:05 2016 New Revision: 239890 URL: https://gcc.gnu.org/viewcvs?rev=239890&root=gcc&view=rev Log: PR libstdc++/77395 * include/std/type_traits (is_constructible): Forward-declare... (__is_base_to_derived_ref): ...and use here. * testsuite/20_util/declval/requirements/1_neg.cc: Adjust. * testsuite/20_util/is_constructible/77395.cc: New. * testsuite/20_util/make_signed/requirements/typedefs_neg.cc: Adjust. * testsuite/20_util/make_unsigned/requirements/typedefs_neg.cc: Likewise. * testsuite/20_util/tuple/77395.cc: New. Added: branches/gcc-6-branch/libstdc++-v3/testsuite/20_util/is_constructible/77395.cc - copied, changed from r239884, branches/gcc-6-branch/libstdc++-v3/testsuite/20_util/declval/requirements/1_neg.cc branches/gcc-6-branch/libstdc++-v3/testsuite/20_util/tuple/77395.cc - copied, changed from r239884, branches/gcc-6-branch/libstdc++-v3/testsuite/20_util/declval/requirements/1_neg.cc Modified: branches/gcc-6-branch/libstdc++-v3/ChangeLog branches/gcc-6-branch/libstdc++-v3/include/std/type_traits branches/gcc-6-branch/libstdc++-v3/testsuite/20_util/declval/requirements/1_neg.cc branches/gcc-6-branch/libstdc++-v3/testsuite/20_util/make_signed/requirements/typedefs_neg.cc branches/gcc-6-branch/libstdc++-v3/testsuite/20_util/make_unsigned/requirements/typedefs_neg.cc
[Bug libstdc++/77395] [6/7 Regression] std::is_constructible is false for type constructible via implicit conversion operator affecting std::tuple
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77395 Ville Voutilainen changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Ville Voutilainen --- Fixed.
[Bug c++/77419] New: Unconsistent behavior with references& and __attribute__((unused))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77419
Bug ID: 77419
Summary: Unconsistent behavior with references& and
__attribute__((unused))
Product: gcc
Version: 6.1.1
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tobias.leibner at googlemail dot com
Target Milestone: ---
The following code
int main() {
int __attribute__((unused)) int_var_unused = 42;
int int_var = 42;
int& __attribute__((unused)) int_ref = int_var;
auto __attribute__((unused)) auto_var_unused = 42;
auto auto_var = 42;
auto& __attribute__((unused)) auto_ref = auto_var;
return 0;
}
produces an unused variable warning for auto_ref when compiled with g++
-std=c++11 -Wall, but not for the other variables.
I just learned that __attribute__((unused)) is intended to be placed after the
variable name, in that case the warning is suppressed as expected. So I am not
sure whether this is expected behavior, but it seems to work for everything
that is not an auto& variable and also works in clang.
[Bug bootstrap/77359] [7 Regression] AIX bootstrap failure due to alignment of stack pointer + STACK_DYNAMIC_OFFSET
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77359 --- Comment #5 from Dominik Vogt --- Sounds fair. So, either the bug is that the stack pointer has 8 byte alignment, or the formula for STACK_DYNAMIC_OFFSET results in the the wrong amount: -- rs6000.h -- /* Offset from the stack pointer register to an item dynamically allocated on the stack, e.g., by `alloca'. The default value for this macro is `STACK_POINTER_OFFSET' plus the length of the outgoing arguments. The default is correct for most machines. See `function.c' for details. */ #define STACK_DYNAMIC_OFFSET(FUNDECL) \ (RS6000_ALIGN (crtl->outgoing_args_size, \ (TARGET_ALTIVEC || TARGET_VSX) ? 16 : 8) \ + (STACK_POINTER_OFFSET)) -- snip -- Or there is some place that doesn't properly use STACK_DYNAMIC_OFFSET(). -- Hm, if neither TARGET_ALTIVEC nor TARGET_VSX is set, we would get an 8 byte aligned STACK_DYNAMIC_OFFSET while the STACK_BOUNDARY from aix.h is 128. The common code uses STACK_BOUNDARY as the assumed alignment, which is wrong => bang. I don't know about the AIX Abi, but there are (at least) three ways to fix that: 1) Provide a version in STACK_DYNAMIC_OFFSET in aix.h that always rounds up to STACK_BOUNDARY. 2) In aix.h, use 128 bit STACK_BOUNDARY only if TARGET_ALITVEC or TARGET_VSX is set (probably breaks the Abi?). 3) Introduce another macro into common code to override the hard wired REGNO_POINTER_ALIGN (VIRTUAL_STACK_DYNAMIC_REGNUM) = STACK_BOUNDARY. Use a new macro that with the value "((TARGET_ALTIVEC || TARGET_VSX) ? 128 : 64)". The latter is probably the most flexible solution, but I'm not sure if that's really necessary.
[Bug bootstrap/77359] [7 Regression] AIX bootstrap failure due to alignment of stack pointer + STACK_DYNAMIC_OFFSET
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77359 --- Comment #6 from Dominik Vogt --- > Presumably something in the rs6000 backend is not maintaining or not > instructing the common part of GCC to maintain the alignment on AIX, > but presumably is maintained on Linux. Might be a problem with Linux too: -- rs6000.h -- #define STACK_BOUNDARY \ ((TARGET_32BIT && !TARGET_ALTIVEC && !TARGET_ALTIVEC_ABI && !TARGET_VSX) \ ? 64 : 128) -- snip -- This may also result in a STACK_BOUNDARY of 128 and STACK_DYNAMIC_OFFSET being rounded to a multiple of 8 bytes. I don't quite understand the point in requiring STACK_DYNAMIC_OFFSET to be 16 byte aligned with altivec. If some memory (a vector?) needs to be aligned more than 8 bytes in the dynamic area, you can just make the area larger but keep the 8 byte alignment. Either way you'll have 8 unused bytes in front of the vector to enforce alignment. The real problem seems to be that common code just assumes that stack pointer alignment is the same as alignment of the dynamic stack area.
[Bug bootstrap/77359] [7 Regression] AIX bootstrap failure due to alignment of stack pointer + STACK_DYNAMIC_OFFSET
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77359 --- Comment #7 from David Edelsohn --- It looks like STACK_DYNAMIC_OFFSET will behave correctly on AIX if Altivec or VSX is enabled. AIX increased the alignment when Altivec support was added. It appears that STACK_DYNAMIC_OFFSET should add a test for AIX. It does look like there could be a problem for PPC64 Linux, but it did not occur. It simply may be that recent GCC on PPC64 Linux defaults to processors with Altivec enabled, so the macros choose consistent values.
[Bug fortran/77420] New: gfortran and equivalence produces internal compiler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77420 Bug ID: 77420 Summary: gfortran and equivalence produces internal compiler error Product: gcc Version: 5.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: m...@rolf-sander.net Target Milestone: --- Created attachment 39523 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39523&action=edit example code that shows the bug Hello, I encountered an internal compiler error with gfortran (Ubuntu 5.4.0-6ubuntu1~16.04.2). I was able to boil down the problem to the following simple code: --- MODULE test_equivalence REAL, PRIVATE, DIMENSION(100) :: array1 REAL, PRIVATE, DIMENSION(100) :: array2 EQUIVALENCE(array1(1),array2(1)) END MODULE test_equivalence MODULE mymodule USE test_equivalence ! declare a local variable with the same name as the (private!) ! variable in module test_equivalence: REAL, DIMENSION(:), ALLOCATABLE :: array1 END MODULE mymodule PROGRAM test USE mymodule END PROGRAM test --- AFAICS, this code is correct Fortran90. The private arrays in MODULE test_equivalence should be separate from those in MODULE mymodule. However, it seems that gfortran turns array1 into a public variable because of the EQUIVALENCE statement. Asking a colleague, I was told that the bug also occurs in version 6.2.0 but not in 4.3.4, 4.8.1, and 4.9.4. The error message was: --- gfortran gfortran_test_equivalence.f90 gfortran_test_equivalence.f90:14:0: PROGRAM test 1 internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. --- Asking in fort...@gcc.gnu.org, the bug was confirmed and I was told that reverting the revision 224159 does fix the problem. Best regards Rolf
[Bug bootstrap/77359] [7 Regression] AIX bootstrap failure due to alignment of stack pointer + STACK_DYNAMIC_OFFSET
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77359 --- Comment #8 from Dominik Vogt --- Something like this: -- snip -- diff --git a/gcc/config/rs6000/rs6000.h b/gcc/config/rs6000/rs6000.h index 353f388..3158c24 100644 --- a/gcc/config/rs6000/rs6000.h +++ b/gcc/config/rs6000/rs6000.h @@ -1719,6 +1719,11 @@ extern enum reg_class rs6000_constraints[RS6000_CONSTRAINT_MAX]; (TARGET_ALTIVEC || TARGET_VSX) ? 16 : 8)\ + RS6000_SAVE_AREA)) +/* Rounds up BYTE_SIZE (in bytes) to the guaranteed alignment of the dynamic + stack offset. */ +#define STACK_DYNAMIC_OFFSET_ALIGN(byte_size) \ + (RS6000_ALIGN (byte_size, (TARGET_ALTIVEC || TARGET_VSX) ? 16 : 8)) + /* Offset from the stack pointer register to an item dynamically allocated on the stack, e.g., by `alloca'. @@ -1726,9 +1731,8 @@ extern enum reg_class rs6000_constraints[RS6000_CONSTRAINT_MAX]; length of the outgoing arguments. The default is correct for most machines. See `function.c' for details. */ #define STACK_DYNAMIC_OFFSET(FUNDECL) \ - (RS6000_ALIGN (crtl->outgoing_args_size, \ -(TARGET_ALTIVEC || TARGET_VSX) ? 16 : 8) \ - + (STACK_POINTER_OFFSET)) + (STACK_DYNAMIC_OFFSET_ALIGN(crtl->outgoing_args_size) \ + (STACK_POINTER_OFFSET)) /* If we generate an insn to push BYTES bytes, this says how many the stack pointer really advances by. diff --git a/gcc/emit-rtl.c b/gcc/emit-rtl.c index 99f052d..5ec68ae 100644 --- a/gcc/emit-rtl.c +++ b/gcc/emit-rtl.c @@ -5717,6 +5717,13 @@ init_emit (void) REGNO_POINTER_ALIGN (VIRTUAL_CFA_REGNUM) = BITS_PER_WORD; #endif +#ifdef STACK_DYNAMIC_OFFSET_ALIGN + REGNO_POINTER_ALIGN (VIRTUAL_STACK_DYNAMIC_REGNUM) = +STACK_DYNAMIC_OFFSET_ALIGN (1); + gcc_assert (REGNO_POINTER_ALIGN (VIRTUAL_STACK_DYNAMIC_REGNUM) + <= REGNO_POINTER_ALIGN (STACK_POINTER_REGNUM)); +#endif + #ifdef INIT_EXPANDERS INIT_EXPANDERS; #endif -- snip --
[Bug bootstrap/77359] [7 Regression] AIX bootstrap failure due to alignment of stack pointer + STACK_DYNAMIC_OFFSET
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77359 --- Comment #9 from Dominik Vogt --- > AIX increased the alignment when Altivec support was added. It > appears that STACK_DYNAMIC_OFFSET should add a test for AIX. Is the alignment of the dynamic area part of the AIX Abi?
[Bug fortran/77420] [5/6/7 Regression] gfortran and equivalence produces internal compiler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77420 Dominique d'Humieres changed: What|Removed |Added Priority|P3 |P4 Status|UNCONFIRMED |NEW Known to work||4.9.3 Keywords||ice-on-valid-code Last reconfirmed||2016-08-31 Ever confirmed|0 |1 Summary|gfortran and equivalence|[5/6/7 Regression] gfortran |produces internal compiler |and equivalence produces |error |internal compiler error Known to fail||5.4.0, 6.2.0, 7.0 --- Comment #1 from Dominique d'Humieres --- Caused by revision r224159 on gcc-6 and trunk and r224171 on gcc-5.
[Bug bootstrap/77359] [7 Regression] AIX bootstrap failure due to alignment of stack pointer + STACK_DYNAMIC_OFFSET
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77359 --- Comment #10 from David Edelsohn --- I was thinking more of #define STACK_DYNAMIC_OFFSET(FUNDECL) \ (RS6000_ALIGN (crtl->outgoing_args_size, \ (TARGET_ALTIVEC || TARGET_VSX || TARGET_AIX) ? 16 : 8) \ + (STACK_POINTER_OFFSET)) But this still leaves the Linux problem. Maybe STACK_DYNAMIC_OFFSET should use 16, except for PPC32 Linux without Altivec.
[Bug bootstrap/77359] [7 Regression] AIX bootstrap failure due to alignment of stack pointer + STACK_DYNAMIC_OFFSET
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77359 --- Comment #11 from Dominik Vogt --- But does that really match the Abi? On s390 (31 bit) we have an 8 byte aligned stack pointer, but the size of a stack slot is just 4 bytes, so the offset from the stack pointer may just be a multiple of 4. The same may be the case on other targets.
[Bug target/71151] [avr] -fmerge-constants and -fdata-sections/-ffunction-sections results in string constants in .progmem.gcc_sw section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71151 --- Comment #22 from Senthil Kumar Selvaraj --- Confirmed that it's a linker issue related to adjusting reloc addends in the presence of align directives. Found two separate bugs, will post patches later this week.
[Bug bootstrap/77359] [7 Regression] AIX bootstrap failure due to alignment of stack pointer + STACK_DYNAMIC_OFFSET
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77359 David Edelsohn changed: What|Removed |Added Target|powerpc-ibm-aix*|powerpc*-*-* --- Comment #12 from David Edelsohn --- What do you mean by size of a stack slot? AIX stack pointer alignment was increased to quadword, to allow for Altivec. It doesn't really refer to the alignment of objects on the stack. I assume that those followed the type alignment rules in the ABI.
[Bug bootstrap/77359] [7 Regression] AIX bootstrap failure due to alignment of stack pointer + STACK_DYNAMIC_OFFSET
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77359 --- Comment #13 from Dominik Vogt --- > What do you mean by size of a stack slot? On s390, if we have one "int" variables on the stack, this uses a "slot" 4 bytes. The stack pointer maintains an 8 byte alignmet though, i.e. SP is changec by 8. If we have two "int" on the stack, they use a 4 byte slot each, and the SP is still changed by just 8. The 4 bytes is what the s390 Abi calls a stack "slot" which is the minimum allocation unit for variables on the stack, i.e. whatever a variable needs is rouded up to a multiple of 4. When this is done, the final sum of needed stack space (including the dynamic stack area) is rounded up to STACK_BOUNDARY. Actually I don't know if any other target has something similar.
[Bug other/77421] New: Bugs found in GCC with the help of PVS-Studio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77421 Bug ID: 77421 Summary: Bugs found in GCC with the help of PVS-Studio Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: karpov at viva64 dot com Target Milestone: --- Hello. I've got to the GCC code and checked it with PVS-Studio analyzer. There are some suspicious code fragments described in the article: http://www.viva64.com/en/b/0425/ I hope, it will help to fix several of them.
[Bug other/59055] gcc.texinfo warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59055 Gerald Pfeifer changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||gerald at pfeifer dot com Resolution|--- |FIXED --- Comment #3 from Gerald Pfeifer --- This has been resolved from all I can tell (looking at concrete cases as well a bootstrap log of current trunk any makeinfo 6.1), thus closing this report. Thank you!
[Bug other/77421] Bugs found in GCC with the help of PVS-Studio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77421 Andreas Schwab changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2016-08-31 Ever confirmed|0 |1 --- Comment #1 from Andreas Schwab --- If you have anything to report, please do it here.
[Bug middle-end/77422] New: -fdata-sections should put each string literal in its own section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77422
Bug ID: 77422
Summary: -fdata-sections should put each string literal in its
own section
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: hjl.tools at gmail dot com
Target Milestone: ---
[hjl@gnu-6 string-1]$ cat x.i
void
foo (void)
{
__builtin_printf ("bar\n");
__builtin_printf ("test\n");
}
int
main ()
{
__builtin_printf ("hello\n");
__builtin_printf ("test\n");
return 0;
}
[hjl@gnu-6 string-1]$ make
/export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc/build-x86_64-linux/gcc/ -O2 -fdata-sections
-ffunction-sections -S -o x.s x.i
[hjl@gnu-6 string-1]$ cat x.s
.file "x.i"
.section.rodata.foo.str1.1,"aMS",@progbits,1
.LC0:
.string "bar"
.LC1:
.string "test"
.section.text.foo,"ax",@progbits
.p2align 4,,15
.globl foo
.type foo, @function
foo:
.LFB0:
.cfi_startproc
subq$8, %rsp
.cfi_def_cfa_offset 16
movl$.LC0, %edi
callputs
movl$.LC1, %edi
addq$8, %rsp
.cfi_def_cfa_offset 8
jmp puts
.cfi_endproc
.LFE0:
.size foo, .-foo
.section.rodata.main.str1.1,"aMS",@progbits,1
.LC2:
.string "hello"
.section.text.startup.main,"ax",@progbits
.p2align 4,,15
.globl main
.type main, @function
main:
.LFB1:
.cfi_startproc
subq$8, %rsp
.cfi_def_cfa_offset 16
movl$.LC2, %edi
callputs
movl$.LC1, %edi
callputs
xorl%eax, %eax
addq$8, %rsp
.cfi_def_cfa_offset 8
ret
.cfi_endproc
.LFE1:
.size main, .-main
.ident "GCC: (GNU) 7.0.0 20160829 (experimental)"
.section.note.GNU-stack,"",@progbits
[hjl@gnu-6 string-1]$
.LC0 and .LC1 are in the same section, .rodata.foo.str1.1.
.rodata.foo.str1.1 can't be discarded even when function foo
is unused since LC1 is also referenced by main.
[Bug libstdc++/70081] Document how to add new symbols to libstdc++ exports
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70081 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |7.0 --- Comment #1 from Jonathan Wakely --- Fixed at r239572
[Bug middle-end/77422] -fdata-sections should put each constant in its own section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77422
H.J. Lu changed:
What|Removed |Added
Summary|-fdata-sections should put |-fdata-sections should put
|each string literal in its |each constant in its own
|own section |section
--- Comment #1 from H.J. Lu ---
Constant has the same issue:
[hjl@gnu-6 string-1]$ cat y.i
void
foo (void)
{
__builtin_printf ("%f\n", 2.1);
__builtin_printf ("%f\n", 2.2);
}
int
main ()
{
__builtin_printf ("%f\n", 2.2);
__builtin_printf ("%f\n", 2.3);
return 0;
}
[hjl@gnu-6 string-1]$ make y.s
/export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc/build-x86_64-linux/gcc/ -O2 -fdata-sections
-ffunction-sections -S -o y.s y.i
[hjl@gnu-6 string-1]$ cat y.s
.file "y.i"
.section.rodata.foo.str1.1,"aMS",@progbits,1
.LC1:
.string "%f\n"
.section.text.foo,"ax",@progbits
.p2align 4,,15
.globl foo
.type foo, @function
foo:
.LFB0:
.cfi_startproc
subq$8, %rsp
.cfi_def_cfa_offset 16
movl$.LC1, %edi
movl$1, %eax
movsd .LC0(%rip), %xmm0
callprintf
movsd .LC2(%rip), %xmm0
movl$.LC1, %edi
movl$1, %eax
addq$8, %rsp
.cfi_def_cfa_offset 8
jmp printf
.cfi_endproc
.LFE0:
.size foo, .-foo
.section.text.startup.main,"ax",@progbits
.p2align 4,,15
.globl main
.type main, @function
main:
.LFB1:
.cfi_startproc
subq$8, %rsp
.cfi_def_cfa_offset 16
movl$.LC1, %edi
movl$1, %eax
movsd .LC2(%rip), %xmm0
callprintf
movsd .LC3(%rip), %xmm0
movl$.LC1, %edi
movl$1, %eax
callprintf
xorl%eax, %eax
addq$8, %rsp
.cfi_def_cfa_offset 8
ret
.cfi_endproc
.LFE1:
.size main, .-main
.section.rodata.cst8,"aM",@progbits,8
.align 8
.LC0:
.long 1717986918
.long 1087604742
.align 8
.LC2:
.long 3435973837
.long 1087604748
.align 8
.LC3:
.long 858993459
.long 1087604755
.ident "GCC: (GNU) 7.0.0 20160829 (experimental)"
.section.note.GNU-stack,"",@progbits
[hjl@gnu-6 string-1]$
[Bug other/16519] -pthreads and -threads undocumented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16519 Jonathan Wakely changed: What|Removed |Added Last reconfirmed|2005-07-19 05:27:40 |2016-8-31 --- Comment #2 from Jonathan Wakely --- Presumably it should be -pthread (the more portable option) not -pthreads (the redundant, Solaris-only option). It's currently only documented as valid for Solaris: https://gcc.gnu.org/onlinedocs/gcc/Solaris-2-Options.html and RS/6000 & PowerPC: https://gcc.gnu.org/onlinedocs/gcc/RS_002f6000-and-PowerPC-Options.html It should also be listed at: https://gcc.gnu.org/onlinedocs/gcc/GNU_002fLinux-Options.html
[Bug c/77423] New: -Wlogical-not-parentheses false positive for bitwise expression with _Bool operands
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77423
Bug ID: 77423
Summary: -Wlogical-not-parentheses false positive for bitwise
expression with _Bool operands
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
-Wlogical-not-parentheses option is documented as follows:
Warn about logical not used on the left hand side operand of a comparison.
This option does not warn if the RHS operand is of a boolean type.
Thanks to integer promotions there's a bit of a mismatch between the
specification and the implementation in GCC when operands of type _Bool are
involved. In C, _Bool operands are promoted to int so the RHS operand's type
is never _Bool, but it may be Boolean in nature. The mismatch is due to the
documentation failing to spell out what GCC considers a "boolean type" in this
context.
This came up during the review of the fix for bug 77292 where it was observed
that the warning is issued for bitwise expressions and not for logical
expressions involving _Bool operands. The following test case shows the
inconsistency. The type of both of the RHS operands of the equality
expressions is int and not _Bool, yet only the one involving the bitwise OR is
diagnosed even though with _Bool operands they are equivalent and often used
interchangeably. I think the warning should not be issued for this case or any
case where the operand can be considered to be Boolean (i.e., it's the result
of either logical or bitwise expression on all Boolean operands).
As a separate issue, the documentation should avoid referring to the type of
the RHS operand (since its type need not be _Bool). Instead, it could say
something like "this option does not warn if the right operand is considered to
be a Boolean expression."
$ cat t.c && /build/gcc-trunk/gcc/xgcc -B /build/gcc-trunk/gcc -S
-Wlogical-not-parentheses t.c
_Bool f (int a, _Bool b, _Bool c)
{
_Bool r;
r = !a == (b || c); // no warning (okay)
r = !a == (b | c);// warning (unexpected)
return r;
}
t.c: In function ‘f’:
t.c:6:10: warning: logical not is only applied to the left hand side of
comparison [-Wlogical-not-parentheses]
r = !a == (b | c);// warning (unexpected)
^~
t.c:6:7: note: add parentheses around left hand side expression to silence this
warning
r = !a == (b | c);// warning (unexpected)
^~
( )
[Bug c/77423] -Wlogical-not-parentheses false positive for bitwise expression with _Bool operands
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77423 Martin Sebor changed: What|Removed |Added Keywords||diagnostic Severity|normal |minor
[Bug testsuite/61513] [fortran-dev] libgomp.fortran/alloc(-comp-[23].f90|atable12.f90) fail when compiled with fortran-dev
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61513 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-08-31 Ever confirmed|0 |1 --- Comment #2 from Dominique d'Humieres --- Still failing for both -m32 and -m64 at r239895: FAIL: libgomp.fortran/aligned1.f03 -O0 execution test FAIL: libgomp.fortran/aligned1.f03 -O1 execution test FAIL: libgomp.fortran/aligned1.f03 -O2 execution test FAIL: libgomp.fortran/aligned1.f03 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions execution test FAIL: libgomp.fortran/aligned1.f03 -O3 -g execution test FAIL: libgomp.fortran/aligned1.f03 -Os execution test FAIL: libgomp.fortran/alloc-comp-2.f90 -O0 execution test FAIL: libgomp.fortran/alloc-comp-2.f90 -O2 execution test FAIL: libgomp.fortran/alloc-comp-3.f90 -O0 execution test FAIL: libgomp.fortran/alloc-comp-3.f90 -O2 execution test FAIL: libgomp.fortran/allocatable11.f90 -O0 execution test FAIL: libgomp.fortran/allocatable11.f90 -O1 execution test FAIL: libgomp.fortran/allocatable11.f90 -O2 execution test FAIL: libgomp.fortran/allocatable11.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions execution test FAIL: libgomp.fortran/allocatable11.f90 -O3 -g execution test FAIL: libgomp.fortran/allocatable11.f90 -Os execution test FAIL: libgomp.fortran/allocatable12.f90 -O0 execution test FAIL: libgomp.fortran/allocatable12.f90 -O1 execution test FAIL: libgomp.fortran/allocatable12.f90 -O2 execution test FAIL: libgomp.fortran/allocatable12.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions execution test FAIL: libgomp.fortran/allocatable12.f90 -O3 -g execution test FAIL: libgomp.fortran/allocatable12.f90 -Os execution test
[Bug c/77423] -Wlogical-not-parentheses false positive for bitwise expression with _Bool operands
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77423 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2016-08-31 CC||mpolacek at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- Mine.
[Bug c/65467] [libgomp] sorry, unimplemented: '_Atomic' with OpenMP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65467 --- Comment #11 from Jakub Jelinek --- Created attachment 39524 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39524&action=edit gcc7-pr65467-wip.patch Untested WIP patch. This attempts to handle _Atomic qualified vars/expressions etc. where it is easy and non-controversial, and error out otherwise. Testsuite coverage for the rejections is still missing. The cases I plan to (in the current patch or later) reject are: 1) omp loop iterators (for, simd, distribute, taskloop) - I think it makes little sense to support that, and would be a nightmare to support 2) _Atomic vars in linear clause (again, little sense, not that hard to support, but right now looks like wasted time to do until omp-lang decides) 3) _Atomic vars in reduction clause and _Atomic types in omp declare reduction (again, little sense to do that, and quite a lot of work to support) 4) _Atomic vars in aligned clause (it is fine if it is in alignment expression) 5) _Atomic x expression in #pragma omp atomic (v or expr can be _Atomic) 6) _Atomic return type on omp declare simd functions, or _Atomic arguments unless they are uniform (again, not impossible to handle, but lots of work and little sense) - this isn't rejected, but just warned and declare simd ignored 7) _Atomic vars in explicit map/to/from clauses (this a nightmare to support, right now the runtime library doesn't have support to run special functions to copy the data to/from, it is similar to not actually running ctors/dtors, but just doing memcpy-ish transfers; and it isn't just the host <-> device transfers, but also possible copying into a temporary for target nowait Not in the patch yet: 8) reject implicit map clauses for _Atomic vars 9) reject firstprivate on _Atomic vars on the target construct (not as hard as map, but also very complicated)
[Bug middle-end/77422] -fdata-sections should put each constant in its own section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77422 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- That doesn't make sense. The mergeable sections really need to be the same, otherwise nothing gets merged. And, unused constants/strings in those can be removed if nothing uses them, the linker has all the relocations into them and can figure out what is used and what is unused. At least I thought it was working properly from the introduction of mergeable sections in the linker, though haven't tried to verify that.
[Bug tree-optimization/77424] New: Identical statements in if-else branches
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77424
Bug ID: 77424
Summary: Identical statements in if-else branches
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Blocks: 77421
Target Milestone: ---
thread_through_all_blocks in tree-ssa-threadupdate.c has identical statements
for if-else branches:
/* Case 1, threading from outside to inside the loop
after we'd already threaded through the header. */
if ((*path)[0]->e->dest->loop_father
!= path->last ()->e->src->loop_father)
{
delete_jump_thread_path (path);
e->aux = NULL;
ei_next (&ei);
}
else
{
delete_jump_thread_path (path);
e->aux = NULL;
ei_next (&ei);
}
One of these is presumably wrong.
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77421
[Bug 77421] Bugs found in GCC with the help of PVS-Studio
[Bug rtl-optimization/77425] New: Pointer test follows dereference in sched-int.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77425 Bug ID: 77425 Summary: Pointer test follows dereference in sched-int.h Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: redi at gcc dot gnu.org Blocks: 77421 Target Milestone: --- sd_iterator_cond in gcc/sched-int.h has: it_ptr->linkp = &DEPS_LIST_FIRST (list); if (list) continue; where DEPS_LIST_FIRST dereferences list, so either the test is always true or the dereference is undefined behavious. Maybe it should be: it_ptr->linkp = list ? &DEPS_LIST_FIRST (list) : NULL; if (list) continue; Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77421 [Bug 77421] Bugs found in GCC with the help of PVS-Studio
[Bug middle-end/77426] New: Duplicate condition in expmed.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77426 Bug ID: 77426 Summary: Duplicate condition in expmed.c Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: redi at gcc dot gnu.org Blocks: 77421 Target Milestone: --- synth_mult in expmed.c has a condition that checks the mode member twice: /* See if we already know what to do for T. */ entry_ptr = alg_hash_entry_ptr (hash_index); if (entry_ptr->t == t && entry_ptr->mode == mode && entry_ptr->mode == mode && entry_ptr->speed == speed && entry_ptr->alg != alg_unknown) Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77421 [Bug 77421] Bugs found in GCC with the help of PVS-Studio
[Bug other/77421] Bugs found in GCC with the help of PVS-Studio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77421 --- Comment #2 from joseph at codesourcery dot com --- I'd also encourage people to look at these issues for ideas for new warnings in GCC, if they can define a warning case that's plausible to check for in GCC with a low false-positive rate (so might go in -Wall or -Wextra).
[Bug other/77421] Bugs found in GCC with the help of PVS-Studio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77421 --- Comment #3 from Jonathan Wakely --- Created attachment 39525 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39525&action=edit Patch to fix most of the reported issues. I've created three new bugs for cases where the fix isn't clear. This patch addresses the more obvious fixes.
[Bug other/77421] Bugs found in GCC with the help of PVS-Studio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77421 Jonathan Wakely changed: What|Removed |Added Status|WAITING |NEW --- Comment #4 from Jonathan Wakely --- Since the details are now in this bug (see attachment) I'm confirming this.
[Bug other/77421] Bugs found in GCC with the help of PVS-Studio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77421 --- Comment #5 from Jonathan Wakely --- Remaining issues: find_structure in gengtype.c does: structures = s; s->kind = kind; s->u.s.tag = name; structures = s; The first assignment is redundant. ix86_expand_args_builtin in gcc/config/i386/i386.c does: case V8DI_FTYPE_V8DI_V8DI_V8DI_INT_UQI: case V16SI_FTYPE_V16SI_V16SI_V16SI_INT_UHI: case V2DF_FTYPE_V2DF_V2DF_V2DI_INT_UQI: case V4SF_FTYPE_V4SF_V4SF_V4SI_INT_UQI: case V8SF_FTYPE_V8SF_V8SF_V8SI_INT_UQI: case V8SI_FTYPE_V8SI_V8SI_V8SI_INT_UQI: case V4DF_FTYPE_V4DF_V4DF_V4DI_INT_UQI: case V4DI_FTYPE_V4DI_V4DI_V4DI_INT_UQI: case V4SI_FTYPE_V4SI_V4SI_V4SI_INT_UQI: case V2DI_FTYPE_V2DI_V2DI_V2DI_INT_UQI: nargs = 5; nargs = 5; The first one is redundant, and wrongly indented. cand_value_at in tree-ssa-loop-ivopts.c does: tree type = TREE_TYPE (iv->base); tree steptype = type; if (POINTER_TYPE_P (type)) steptype = sizetype; steptype = unsigned_type_for (type); It's unclear why the last four lines aren't just: tree steptype = unsigned_type_for (type);
[Bug middle-end/77426] Duplicate condition in expmed.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77426 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-08-31 CC||ktkachov at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from ktkachov at gcc dot gnu.org --- Looks like a typo as part of a much larger change (r139821) that introduced the size/speed differentiation in RTL costing. I think one of the redundant checks should just be deleted.
[Bug other/77421] Bugs found in GCC with the help of PVS-Studio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77421 --- Comment #6 from Jonathan Wakely --- Oh one more I missed. alter_output_for_subst_insn in gensupport.c has: if (alt < 2 || *insn_out == '*' || *insn_out != '@') return insn_out; The second condition is redundant, since if it's == '*' then it's also != '@' The fix isn't obvious.
[Bug middle-end/77422] -fdata-sections should put each constant in its own section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77422 --- Comment #3 from H.J. Lu --- (In reply to Jakub Jelinek from comment #2) > That doesn't make sense. The mergeable sections really need to be the same, > otherwise nothing gets merged. And, unused constants/strings in those can > be removed if nothing uses them, the linker has all the relocations into > them and can figure out what is used and what is unused. At least I thought > it was working properly from the introduction of mergeable sections in the > linker, though haven't tried to verify that. Linker section merge doesn't check how entries in mergeable sections are used. It simply collects all entries in mergeable sections which are kept in output. When a mergeable section has .section .rodata.foo.str1.1,"aMS",@progbits,1 .LC0: .string "bar\n" .LC1: .string "test\n" all entries in it will be included in output if any entry is kept. As far as mergeable constant concerned, there is no difference between .section .rodata.foo.str1.1,"aMS",@progbits,1 .LC0: .string "bar\n" .LC1: .string "test\n" vs .section .rodata.foo.str1.1.0,"aMS",@progbits,1 .LC0: .string "bar\n" .section .rodata.foo.str1.1.1,"aMS",@progbits,1 .LC1: .string "test\n" Both put the same 2 entries into the table.
[Bug fortran/48298] [F03] User-Defined Derived-Type IO (DTIO)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48298 --- Comment #18 from Walter Spector --- Awesome! I have noticed one bug so far. The compiler is missing a check to see if the arguments in the I/O procedures have the 'optional' attribute. It is allowing the attribute - even though it is illegal. E.g. the following should be flagged as erroneous: SUBROUTINE pwf (dtv,unit,iotype,vlist,iostat,iomsg) ! argument definitions CLASS(person), INTENT(IN) :: dtv INTEGER, INTENT(IN), OPTIONAL :: unit CHARACTER (LEN=*), INTENT(IN), OPTIONAL :: iotype INTEGER, INTENT(IN), OPTIONAL :: vlist(:) INTEGER, INTENT(OUT), OPTIONAL :: iostat CHARACTER (LEN=*), INTENT(INOUT), OPTIONAL :: iomsg ... Walter
[Bug libfortran/77393] [7 Regression] Revision r237735 changed the behavior of F0.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77393 --- Comment #1 from Jerry DeLisle --- Author: jvdelisle Date: Wed Aug 31 17:45:26 2016 New Revision: 239900 URL: https://gcc.gnu.org/viewcvs?rev=239900&root=gcc&view=rev Log: 2016-08-31 Jerry DeLisle PR libgfortran/77393 * io/write.c (kind_from_size): New function to calculate required buffer size based on kind type. (select_buffer, select_string): Use new function. (write_float_0, write_real, write_real_g0, write_complex): Adjust calls to pass parameters needed by new function. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/io/write.c
[Bug libfortran/77393] [7 Regression] Revision r237735 changed the behavior of F0.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77393 --- Comment #2 from Jerry DeLisle --- Author: jvdelisle Date: Wed Aug 31 17:54:32 2016 New Revision: 239901 URL: https://gcc.gnu.org/viewcvs?rev=239901&root=gcc&view=rev Log: 2016-08-31 Jerry DeLisle PR libgfortran/77393 * gfortran.dg/fmt_f0_2.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/fmt_f0_2.f90 Modified: trunk/gcc/testsuite/ChangeLog
[Bug middle-end/77422] -fdata-sections should put each constant in its own section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77422 --- Comment #4 from H.J. Lu --- Created attachment 39526 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39526&action=edit A patch
[Bug middle-end/77422] -fdata-sections should put each constant in its own section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77422 --- Comment #5 from Jakub Jelinek --- I don't really like that. The linker has all the info to remove unused mergeable constants or strings, so if it doesn't do that now, it should be changed to do that.
[Bug c++/77427] New: ice when canonical types differ for identical types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77427 Bug ID: 77427 Summary: ice when canonical types differ for identical types Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: --- Created attachment 39527 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39527&action=edit C++ source code The attached code, when compiled by g++ trunk dated 20160830, does this: src/messages.cpp: In function ‘std::__cxx11::string mysprintf(const char*, ...)’ : src/messages.cpp:64:26: internal compiler error: canonical types differ for iden tical types __va_list_tag [1] and __va_list_tag [1] 0x7c521c comptypes(tree_node*, tree_node*, int) ../../src/trunk/gcc/cp/typeck.c:1430 0x644c04 reference_related_p(tree_node*, tree_node*) ../../src/trunk/gcc/cp/call.c:1415 0x64c3a3 reference_binding ../../src/trunk/gcc/cp/call.c:1559 0x64b26c implicit_conversion ../../src/trunk/gcc/cp/call.c:1805
[Bug tree-optimization/73714] [Regression 7] Incorrect unsigned long long arithmetic optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=73714 --- Comment #3 from Marc Glisse --- Author: glisse Date: Wed Aug 31 18:22:58 2016 New Revision: 239902 URL: https://gcc.gnu.org/viewcvs?rev=239902&root=gcc&view=rev Log: match.pd: Revert a * (1 << b) relaxation. 2016-08-31 Marc Glisse PR tree-optimization/73714 gcc/ * match.pd (a * (1 << b)): Revert change from 2016-05-23. gcc/testsuite/ * gcc.dg/tree-ssa/pr73714.c: New test. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/pr73714.c Modified: trunk/gcc/ChangeLog trunk/gcc/match.pd trunk/gcc/testsuite/ChangeLog
[Bug other/77417] libiberty strverscmp incompatible with glibc strverscmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77417 Manuel López-Ibáñez changed: What|Removed |Added CC||manu at gcc dot gnu.org --- Comment #2 from Manuel López-Ibáñez --- (In reply to Andrew Pinski from comment #1) > The only place where strverscmp is used is in darwin specific code. > > One way of fixing this is to use gnulib which I thought one of the GSOC > students were doing (though I don't know the status on that project). Current status is here https://gcc.gnu.org/wiki/replacelibibertywithgnulib Ayush told me he wished to continue with the project until it is committed, but if someone could add additional testing to his patches and suggest improvements, that would be helpful.
[Bug tree-optimization/59124] [5/6/7 Regression] Wrong warnings "array subscript is above array bounds"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59124 --- Comment #44 from Patrick Palka --- (In reply to Szőts Ákos from comment #43) > Yes, I can agree with this reasoning. However, when you remove either the > "while" or the "if" statements, the warning disappears. I don't think they > should have any influence on the array_size. Hmm yeah it's rather flaky. The warning depends on whether or not the compiler unrolls the for loop.
[Bug objc/77428] New: incorrect 'set but not used' warning with @throw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77428
Bug ID: 77428
Summary: incorrect 'set but not used' warning with @throw
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: objc
Assignee: unassigned at gcc dot gnu.org
Reporter: vries at gcc dot gnu.org
Target Milestone: ---
test.m:
...
#import
#import
void
foo2 (void)
{
printf ("foo2\n");
}
int
main (void)
{
id o = nil;
@try {
printf ("before throw\n");
@throw o;
printf ("after throw\n");
} @catch (id ue) {
if (ue != nil)
foo2 ();
else
printf ("not foo2\n");
}
return 0;
}
...
$ gcc test.m -fobjc-exceptions -lobjc -Wall:
...
test.m: In function ‘main’:
test.m:13:6: warning: variable ‘o’ set but not used [-Wunused-but-set-variable]
id o = nil;
^
...
The warning is incorrect, variable 'o' is in fact used by @throw.
[Bug objc/77428] incorrect 'set but not used' warning with @throw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77428 --- Comment #1 from Tom de Vries --- Created attachment 39528 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39528&action=edit tentative patch
[Bug c++/77427] [7 Regression] ice when canonical types differ for identical types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77427
Markus Trippelsdorf changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2016-08-31
CC||trippels at gcc dot gnu.org
Summary|ice when canonical types|[7 Regression] ice when
|differ for identical types |canonical types differ for
||identical types
Ever confirmed|0 |1
--- Comment #1 from Markus Trippelsdorf ---
typedef __builtin_va_list a;
void b(int, a &);
struct c {
operator a &();
operator const a &();
};
void d() {
c a;
b(0, a);
}
[Bug preprocessor/42669] libcpp: five redundant tests
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42669 Manuel López-Ibáñez changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||manu at gcc dot gnu.org Resolution|--- |FIXED --- Comment #3 from Manuel López-Ibáñez --- (In reply to Shakthi Kannan from comment #2) > With cppcheck-1.59 on Fedora 18 (x86_64) and gcc-4.8.0, the "Redundant > condition" is not present. This probably got fixed on its own. Thanks anyway for reporting it.
[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 Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Marc Glisse --- Fixed, thanks for the report. I checked and it doesn't look like I introduced other shifty undefined behavior at the same time.
[Bug middle-end/77426] Duplicate condition in expmed.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77426
Manuel López-Ibáñez changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
--- Comment #2 from Manuel López-Ibáñez ---
For the simplest case (A && A), we warn with -Wlogical-op:
int foo(int a, int b, int c)
{
if(b == c && b == c) return 1; /* warn */
if(a && b == c && b == c) return 2; /* missing warning */
return 0;
}
Also PR71345.
[Bug c/71345] Warn about redundant conditions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71345
Manuel López-Ibáñez changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
--- Comment #2 from Manuel López-Ibáñez ---
A simpler case would be:
int foo(int a, int b, int c)
{
if(b == c && b == c) return 1; /* warns with -Wlogical-op */
if(a && b == c && b == c) return 2; /* missing warning */
return 0;
}
[Bug fortran/77374] [6/7 Regression] ICE in resolve_omp_atomic, at fortran/openmp.c:3949
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77374 --- Comment #4 from Jakub Jelinek --- Author: jakub Date: Wed Aug 31 18:42:08 2016 New Revision: 239903 URL: https://gcc.gnu.org/viewcvs?rev=239903&root=gcc&view=rev Log: PR fortran/77374 * parse.c (parse_omp_oacc_atomic): Copy over cp->ext.omp_atomic to cp->block->ext.omp_atomic. * resolve.c (gfc_resolve_blocks): Assert block with one or two EXEC_ASSIGNs for EXEC_*_ATOMIC. * openmp.c (resolve_omp_atomic): Don't assert one or two EXEC_ASSIGNs, instead return quietly for EXEC_NOPs and otherwise error unexpected statements. * gfortran.dg/gomp/pr77374.f08: New test. Added: trunk/gcc/testsuite/gfortran.dg/gomp/pr77374.f08 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/openmp.c trunk/gcc/fortran/parse.c trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/77352] ICE: verify_ssa failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77352 --- Comment #3 from Jakub Jelinek --- Author: jakub Date: Wed Aug 31 18:42:55 2016 New Revision: 239904 URL: https://gcc.gnu.org/viewcvs?rev=239904&root=gcc&view=rev Log: PR fortran/77352 * trans-openmp.c (gfc_trans_omp_parallel_workshare): Always add a BIND_EXPR with BLOCK around what gfc_trans_omp_workshare returns. * gfortran.dg/gomp/pr77352.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/gomp/pr77352.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-openmp.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/77429] New: ICE in gfc_check_dependency, at fortran/dependency.c:1261
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77429 Bug ID: 77429 Summary: ICE in gfc_check_dependency, at fortran/dependency.c:1261 Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gerhard.steinmetz.fort...@t-online.de Target Milestone: --- Affects version 6, 7 at optimization level -Og, -Os, -O1 or higher. ICE/backtrace when configured with --enable-checking=yes. Bailed out with official release (--enable-checking=release). Invalid code : $ cat z1.f90 program p shape(1) = 0 end $ cat z2.f90 program p shape(1,2) = 0 end $ gfortran-7-20160828 -O0 z1.f90 z1.f90:2:3: shape(1) = 0 1 Error: Non-variable expression in variable definition context (assignment) at (1) $ gfortran-7-20160828 -O2 z1.f90 z1.f90:2:3: shape(1) = 0 1 Error: Non-variable expression in variable definition context (assignment) at (1) f951: internal compiler error: in gfc_check_dependency, at fortran/dependency.c:1261 0x7157b3 gfc_check_dependency(gfc_expr*, gfc_expr*, bool) ../../gcc/fortran/dependency.c:1261 0x7b181b optimize_assignment ../../gcc/fortran/frontend-passes.c:1183 0x7b181b optimize_code ../../gcc/fortran/frontend-passes.c:221 0x7b4229 gfc_code_walker(gfc_code**, int (*)(gfc_code**, int*, void*), int (*)(gfc_expr**, int*, void*), void*) ../../gcc/fortran/frontend-passes.c:3397 0x7b5284 optimize_namespace ../../gcc/fortran/frontend-passes.c:1005 0x7b5440 gfc_run_passes(gfc_namespace*) ../../gcc/fortran/frontend-passes.c:132 0x6efbc7 gfc_resolve(gfc_namespace*) ../../gcc/fortran/resolve.c:15608 0x6daeba resolve_all_program_units ../../gcc/fortran/parse.c:5849 0x6daeba gfc_parse_file() ../../gcc/fortran/parse.c:6101 0x71d3a2 gfc_be_parse_file ../../gcc/fortran/f95-lang.c:198
[Bug fortran/77429] ICE in gfc_check_dependency, at fortran/dependency.c:1261
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77429 --- Comment #1 from Gerhard Steinmetz --- Whereas : $ cat z3.f90 program p shape(1,2,3) = 0 end $ gfortran-7-20160828 z3.f90 z3.f90:2:3: shape(1,2,3) = 0 1 Error: Too many arguments in call to 'shape' at (1) --- Some other cases with ICE : $ cat z5.f90 program p lbound([1]) = 0 end $ cat z6.f90 program p shape([1]) = 0 end $ cat z7.f90 program p transfer(1,2,3) = 0 end $ cat z8.f90 program p ubound([1]) = 0 end
[Bug other/77421] Bugs found in GCC with the help of PVS-Studio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77421 Manuel López-Ibáñez changed: What|Removed |Added CC||manu at gcc dot gnu.org --- Comment #7 from Manuel López-Ibáñez --- (In reply to Jonathan Wakely from comment #6) > Oh one more I missed. alter_output_for_subst_insn in gensupport.c has: > > if (alt < 2 || *insn_out == '*' || *insn_out != '@') > return insn_out; > > The second condition is redundant, since if it's == '*' then it's also != '@' > The missing warning is PR71345
[Bug c++/77430] New: warn about redundant assignments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77430
Bug ID: 77430
Summary: warn about redundant assignments
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: manu at gcc dot gnu.org
Target Milestone: ---
Simple testcase:
int foo(int a)
{
a = 0;
a = 0; /* missing warning */
return a;
}
More complex cases present in GCC:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77421#c5
[Bug other/77421] Bugs found in GCC with the help of PVS-Studio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77421 --- Comment #8 from Manuel López-Ibáñez --- (In reply to Jonathan Wakely from comment #5) > Remaining issues: The missing warning is tracked in PR77430.
[Bug middle-end/68542] [6 Regression] 10% 481.wrf performance regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68542 --- Comment #11 from Patrick Palka --- Author: ppalka Date: Wed Aug 31 19:06:22 2016 New Revision: 239907 URL: https://gcc.gnu.org/viewcvs?rev=239907&root=gcc&view=rev Log: Fix folding of VECTOR_CST comparisons gcc/ChangeLog: Backport from mainline 2016-08-27 Patrick Palka PR tree-optimization/71077 PR tree-optimization/68542 * fold-const.c (fold_relational_const): Fix folding of VECTOR_CST comparisons that have a scalar boolean result type. gcc/testsuite/ChangeLog: Backport from mainline 2016-08-27 Patrick Palka PR tree-optimization/71077 * gcc.target/i386/pr71077.c: New test. Added: branches/gcc-6-branch/gcc/testsuite/gcc.target/i386/pr71077.c Modified: branches/gcc-6-branch/gcc/ChangeLog branches/gcc-6-branch/gcc/fold-const.c branches/gcc-6-branch/gcc/testsuite/ChangeLog
[Bug tree-optimization/71077] [7 Regression] gcc -lto raises ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71077 --- Comment #9 from Patrick Palka --- Author: ppalka Date: Wed Aug 31 19:06:22 2016 New Revision: 239907 URL: https://gcc.gnu.org/viewcvs?rev=239907&root=gcc&view=rev Log: Fix folding of VECTOR_CST comparisons gcc/ChangeLog: Backport from mainline 2016-08-27 Patrick Palka PR tree-optimization/71077 PR tree-optimization/68542 * fold-const.c (fold_relational_const): Fix folding of VECTOR_CST comparisons that have a scalar boolean result type. gcc/testsuite/ChangeLog: Backport from mainline 2016-08-27 Patrick Palka PR tree-optimization/71077 * gcc.target/i386/pr71077.c: New test. Added: branches/gcc-6-branch/gcc/testsuite/gcc.target/i386/pr71077.c Modified: branches/gcc-6-branch/gcc/ChangeLog branches/gcc-6-branch/gcc/fold-const.c branches/gcc-6-branch/gcc/testsuite/ChangeLog
[Bug c++/64767] Could GCC warn when a pointer is compared against '\0'?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64767 Manuel López-Ibáñez changed: What|Removed |Added CC||manu at gcc dot gnu.org --- Comment #5 from Manuel López-Ibáñez --- This could have detected a bug in GCC: http://www.viva64.com/en/b/0425/
[Bug other/77421] Bugs found in GCC with the help of PVS-Studio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77421 --- Comment #9 from Manuel López-Ibáñez --- || xloc.file == '\0' || xloc.file[0] == '\xff' || xloc.file[1] == '\xff') This missing warning is PR64767
[Bug c++/77431] New: warn for having the same code in if-else branches
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77431
Bug ID: 77431
Summary: warn for having the same code in if-else branches
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: manu at gcc dot gnu.org
Target Milestone: ---
Simple testcase:
int foo(int *a)
{
if (a)
return 0;
else
return 0;
}
Complex testcase in GCC sources: PR77424
[Bug tree-optimization/77424] Identical statements in if-else branches
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77424 Manuel López-Ibáñez changed: What|Removed |Added CC||manu at gcc dot gnu.org --- Comment #1 from Manuel López-Ibáñez --- The missing warning is tracked in PR77431
[Bug rtl-optimization/77425] Pointer test follows dereference in sched-int.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77425
Manuel López-Ibáñez changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
--- Comment #1 from Manuel López-Ibáñez ---
There is also this example:
odr_type
get_odr_type (tree type, bool insert)
{
odr_types[val->id] = 0;
gcc_assert (val->derived_types.length() == 0);
if (odr_types_ptr)
val->id = odr_types.length ();
}
which is even more insidious since it is hidden behind macros.
[Bug c++/77432] New: warn about null check after pointer dereference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77432
Bug ID: 77432
Summary: warn about null check after pointer dereference
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: manu at gcc dot gnu.org
Target Milestone: ---
Simple testcase:
int foo(int *a)
{
int b = *a;
if (a)
return b;
return 0;
}
The check is too late to catch anything.
Bug in GCC: PR77425
and from PR77421 : http://www.viva64.com/en/b/0425/
odr_type
get_odr_type (tree type, bool insert)
{
odr_types[val->id] = 0;
gcc_assert (val->derived_types.length() == 0);
if (odr_types_ptr)
val->id = odr_types.length ();
}
[Bug c++/77433] New: warn about pointer that escapes its scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77433
Bug ID: 77433
Summary: warn about pointer that escapes its scope
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: manu at gcc dot gnu.org
Target Milestone: ---
void bar(int *x);
int foo(int a)
{
int *b = 0;
if (a) {
int x[] = {0};
b = x;
}
bar(b);
return 0;
}
Real bug in GCC: PR77421
static void
dump_hsa_symbol (FILE *f, hsa_symbol *symbol)
{
const char *name;
if (symbol->m_name)
name = symbol->m_name;
else
{
char buf[64];
sprintf (buf, "__%s_%i", hsa_seg_name (symbol->m_segment),
symbol->m_name_number);
name = buf;
}
fprintf (f, "align(%u) %s_%s %s",
hsa_byte_alignment (symbol->m_align),
hsa_seg_name(symbol->m_segment),
hsa_type_name(symbol->m_type & ~BRIG_TYPE_ARRAY_MASK),
name);
}
[Bug c++/77434] New: warn about suspicious precedence of ternary operator (?:)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77434
Bug ID: 77434
Summary: warn about suspicious precedence of ternary operator
(?:)
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: manu at gcc dot gnu.org
Target Milestone: ---
Code such as the following are suspicious:
int foo(int a, int b)
{
return (a > 0 && a <= (b == 1) ? 1 : 2);
}
some users may expect it to be equivalent to a <= ((b==1) ? 1 :2)
but it is in fact equivalent to (a <= (b == 1)) ? 1 : 2
We should warn with -Wparenthesis
Real bug in GCC: PR77421
static void
output_loc_operands (dw_loc_descr_ref loc, int for_eh_or_skip)
{
unsigned long die_offset
= get_ref_die_offset (val1->v.val_die_ref.die);
gcc_assert (die_offset > 0
&& die_offset <= (loc->dw_loc_opc == DW_OP_call2)
? 0x
: 0x);
}
[Bug c++/77433] warn about object that escapes its scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77433 Andrew Pinski changed: What|Removed |Added Keywords||diagnostic Summary|warn about pointer that |warn about object that |escapes its scope |escapes its scope Severity|normal |enhancement --- Comment #1 from Andrew Pinski --- There might be already a bug report about this same thing. Basically we emit a "clobber" for the objects when the scope ends.
