[Bug c++/68203] Аbout infinite compilation time on struct with nested array of pairs with -std=c++11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68203 Richard Biener changed: What|Removed |Added Keywords||compile-time-hog, ||missed-optimization Status|UNCONFIRMED |NEW Last reconfirmed||2015-11-04 Ever confirmed|0 |1 --- Comment #2 from Richard Biener --- And we have a duplicate bugreport for this somewhere.
[Bug c/68201] alloc_size attribute and memory pools
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68201 --- Comment #1 from Richard Biener --- As GCC uses the attribute for static analysis it can't go out and read the actual value from pool->block_size so I see no value in providing the size this way (it would also only work if pool_alloc is inlined).
[Bug libstdc++/52604] mt allocator crashes on multi-threaded
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52604 Richard Biener changed: What|Removed |Added CC||oremanj at mit dot edu --- Comment #22 from Richard Biener --- *** Bug 68200 has been marked as a duplicate of this bug. ***
[Bug libstdc++/68200] g++ 5.2 optimizes out pointer assignment in libstdc++ mt_allocator freelist destructor, causing crash at global-dtor time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68200 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Richard Biener --- Duplicate then (52604 is not marked fixed anyway). *** This bug has been marked as a duplicate of bug 52604 ***
[Bug libstdc++/52604] mt allocator crashes on multi-threaded
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52604 --- Comment #23 from Richard Biener --- According to the dup the fix is bogus (the added stmt is optimized away).
[Bug tree-optimization/66726] missed optimization, factor conversion out of COND_EXPR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66726 --- Comment #13 from Andreas Schwab --- ../../gcc/tree-ssa-reassoc.c: In function 'void maybe_optimize_range_tests(gimple*)': ../../gcc/tree-ssa-reassoc.c:3193:8: error: 'operand_entry_t' was not declared in this scope operand_entry_t oe = operand_entry_pool.allocate (); ^ ../../gcc/tree-ssa-reassoc.c:3193:24: error: expected ';' before 'oe' operand_entry_t oe = operand_entry_pool.allocate (); ^ ../../gcc/tree-ssa-reassoc.c:3194:8: error: 'oe' was not declared in this scope oe->op = lhs; ^
[Bug fortran/48820] TR 29113: Implement parts needed for MPI 3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48820 Dominique d'Humieres changed: What|Removed |Added Status|NEW |WAITING --- Comment #21 from Dominique d'Humieres --- No activity for over three years, broken links, ... . IMO this PR should be closed as FIXED and new PR(s) should be opened for remaining issue(s) not covered by existing PRs.
[Bug target/68199] avr-gcc rise a warning when defining a custom interruption
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68199 astralien3000 changed: What|Removed |Added Severity|normal |enhancement
[Bug fortran/68196] [4.9/5/6 Regression] ICE on function result with procedure pointer component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68196
Paul Thomas changed:
What|Removed |Added
CC||pault at gcc dot gnu.org
Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org
--- Comment #2 from Paul Thomas ---
Created attachment 36646
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36646&action=edit
Patch for the PR
Dear Damian,
Thanks for this one! Dominique was quite right as to where the infinite
recursion occurs. Once fixed, however, the same thing happens again in
trans-types.c!
The attached patch fixes both and is just now regtesting.
The testcase is:
! { dg-do run }
! Tests the fix for PR68196
!
! Contributed by Damian Rouson
!
type AA
integer :: i
procedure(foo), pointer :: funct
end type
class(AA), allocatable :: my_AA
type(AA) :: res
allocate (my_AA, source = AA (1, foo))
res = my_AA%funct ()
if (res%i .ne. 3) call abort
if (.not.associated (res%funct)) call abort
if (my_AA%i .ne. 4) call abort
if (associated (my_AA%funct)) call abort
contains
function foo(A)
class(AA), allocatable :: A
type(AA) foo
if (.not.allocated (A)) then
allocate (A, source = AA (2, foo))
endif
select type (A)
type is (AA)
foo = AA (3, foo)
A = AA (4, NULL ())
end select
end function
end
Cheers
Paul
[Bug fortran/35031] ELEMENTAL procedure with BIND(C)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35031 --- Comment #4 from Dominique d'Humieres --- This is C1252 An elemental procedure shall not have the BIND attribute. in subclause 12.6.2.1 of my Fortran 2015 draft.
[Bug c++/68208] New: g++ doesn't warn against reference self-initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68208
Bug ID: 68208
Summary: g++ doesn't warn against reference self-initialization
Product: gcc
Version: 5.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ooprala at redhat dot com
Target Milestone: ---
Created attachment 36647
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36647&action=edit
reproducer
/usr/bin/gcc -v
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-default-libstdcxx-abi=c++98 --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 5.1.1 20150618 (Red Hat 5.1.1-4) (GCC)
g++ remains silent with -Wall -Wextra.
However, even with no extra options,
clang++ -c repr.cc emits:
repr.cc:4:10: warning: reference 'm' is not yet bound to a value when used here
[-Wuninitialized]
S0():m(m){}
^
1 warning generated.
[Bug c/68201] alloc_size attribute and memory pools
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68201 --- Comment #2 from Daniel Fruzynski --- What about code compiled with -D_FORTIFY_SOURCE=1, when functions like strcpy are replaced with __builtin___strcpy_chk? This is a runtime check, so passing pool->block_size should be reasonable there. Inlining requirement for pool_alloc is OK for me. Make sure it will be documented in gcc manual.
[Bug c++/68089] c++ friend with template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68089 Evgeniy Dushistov changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Evgeniy Dushistov --- >The error seems correct to me Yes my mistake.
[Bug ipa/68175] g++ 5.2.1 produces broken executables with devirtualization enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68175 Boris Nagaev changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|DUPLICATE |--- --- Comment #2 from Boris Nagaev --- The patch from bug 67056 [1] was applied to MXE [2]. It doesn't work. The executable produced from my test code (class BufferedIfstream) is crashing. The patch was applied to Debian Stretch version of gcc (5.2.1-22) and the resulting gcc compiler makes crashing executables as well. The code provided in bug 67056 as a test code [3] is compiled to a working executable by patched MXE, original MXE and Debian Stretch's gcc 5.2.1. Bugs 67056 and 68175 seems not to be the same bug. Can you confirm that patched gcc (rev. 229148) compiles my test code correctly (class BufferedIfstream), please? [1] https://gcc.gnu.org/viewcvs/gcc/trunk/gcc/ipa-polymorphic-call.c?r1=229148&r2=229147&pathrev=229148 [2] https://github.com/LuaAndC/mxe/commit/5c47e8ef678ea785b1092272fd3adb51beebff4e [3] https://gcc.gnu.org/viewcvs/gcc/trunk/gcc/testsuite/g%2B%2B.dg/ipa/pr67056.C?view=markup&pathrev=229148
[Bug c++/68209] New: C++11 code compiled without -std=c++11 but doesn't work as expected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68209
Bug ID: 68209
Summary: C++11 code compiled without -std=c++11 but doesn't
work as expected
Product: gcc
Version: 5.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: mirzayanovmr at gmail dot com
Target Milestone: ---
Tried on g++.EXE (tdm-1) 5.1.0 and g++ (GCC) 5.1.1 20150618 (Red Hat 5.1.1-4).
This code compiled successfully with command line 'g++ a.cpp'
#include
#include
using namespace std;
int main()
{
vector a;
for (int aa: a)
cout << aa << endl;
}
It prints warrning 'warning: range-based ‘for’ loops only available with
-std=c++11 or -std=gnu++11' but it is not a error.
I expected behaviour like on 4.9.2: it gives error 'error: range-based 'for'
loops are not allowed in C++98 mode'
As a result code compiled but doesn't work correctly. It prints lines
containing "0" infinitely.
I expect that such code shouldn't be compiled or at least (if compiled) work as
expected.
[Bug c++/68209] C++11 code compiled without -std=c++11 but doesn't work as expected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68209 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #1 from Marek Polacek --- So use -pedantic-errors or -Werror if you want an error?
[Bug fortran/68101] Provide a way to allocate arrays aligned to 32 bytes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68101 Dominique d'Humieres changed: What|Removed |Added Status|WAITING |NEW --- Comment #4 from Dominique d'Humieres --- Also related to pr642447.
[Bug c++/68209] C++11 code compiled without -std=c++11 but doesn't work as expected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68209 --- Comment #2 from MikeMirzayanov --- Right now code written as C++11 can be unintentionally compiled in C++98-mode and it leads to incorrect behavior of the code. What is the reason why it compiled on C++98? I expect that it is incorrect syntax for C++98 and code doesn't match language grammatics. So expected behavior is "compilation error".
[Bug middle-end/64247] malloc alignment and -mavx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64247 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2015-11-04 Ever confirmed|0 |1 --- Comment #10 from Dominique d'Humieres --- A few comments: (1) Why do you want to use PURE in this context? (2) On x86_64-apple-darwin14 I have run the test in comment 9 with 4.8 up to trunk (6.0), various options, and various values of N without getting the message "pure routine gives different results at iter: ... ". IIRC the default alignment on darwin is bigger than the one in linux. (3) It may help to have pr68101 implemented. (4) I agree with comment 7 that this PR is invalid: although I am not an expert in vectorization, I understand that the vectorization may depend on the alignment (peeling, versioning, ... ), thus I expect that the round-off error may depend on the alignment. If I add a line print *, maxval(abs(Cv1(1:N*N)-Cv2(1+2:N*N+2)))/epsilon(Cv1) before 'IF (ANY(Cv1(1:N*N).NE.Cv2(1+2:N*N+2))) CALL ABORT()', I get 4 for N=10, 48 for N=100, and 768 for N=1000, roughly what I expect for round-off errors.
[Bug fortran/68196] [4.9/5/6 Regression] ICE on function result with procedure pointer component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68196 --- Comment #3 from Dominique d'Humieres --- The patch in comment 2 looks good (works as advertised without regression, no duplicate in store)!
[Bug tree-optimization/67742] 3rd-level restrict ignored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67742 --- Comment #7 from vries at gcc dot gnu.org --- Author: vries Date: Wed Nov 4 14:18:43 2015 New Revision: 229755 URL: https://gcc.gnu.org/viewcvs?rev=229755&root=gcc&view=rev Log: Handle recursive restrict in function parameter 2015-11-04 Tom de Vries PR tree-optimization/67742 * tree-ssa-structalias.c (struct fieldoff): Add restrict_pointed_type field. (push_fields_onto_fieldstack): Handle restrict_pointed_type field. (create_variable_info_for_1): Add and handle handle_param parameter. Add restrict handling. (create_variable_info_for): Call create_variable_info_for_1 with extra arg. (make_param_constraints): Drop restrict_name parameter. Ignore vi->only_restrict_pointers. (intra_create_variable_infos): Call create_variable_info_for_1 with extra arg. Remove restrict handling. Call make_param_constraints with one less arg. * gcc.dg/tree-ssa/restrict-7.c: New test. * gcc.dg/tree-ssa/restrict-8.c: New test. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/restrict-7.c trunk/gcc/testsuite/gcc.dg/tree-ssa/restrict-8.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-structalias.c
[Bug tree-optimization/67742] 3rd-level restrict ignored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67742 vries at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from vries at gcc dot gnu.org --- patch and test-cases committed, marking resolved-fixed.
[Bug fortran/53699] Missing "restrict" qualifier for OPTIONAL dummy arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53699 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-11-04 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Still missing at revision r229727 (trunk 6.0).
[Bug driver/67613] spell suggestions for misspelled command line options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67613 David Malcolm changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |dmalcolm at gcc dot gnu.org --- Comment #1 from David Malcolm --- Candidate patch posted here: https://gcc.gnu.org/ml/gcc-patches/2015-11/msg00355.html
[Bug fortran/64973] Duplicate use-statements could be diagnosed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64973 --- Comment #1 from Dominique d'Humieres --- Correct link: https://gcc.gnu.org/ml/fortran/2015-02/msg00036.html.
[Bug middle-end/64247] malloc alignment and -mavx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64247 --- Comment #11 from Joost VandeVondele --- (In reply to Dominique d'Humieres from comment #10) > A few comments: > > (1) Why do you want to use PURE in this context? because this is a pure procedure ? Comment 7 is not too the point (indeed reassociation can happen) as explained afterwards The bug here is that the same (serial) binary gives different results from run to run, as soon as the user enables avx, and there is no way around. I agree that it would be fixed if there was an option as askin in pr68101. (and yes, this could help with performance as well).
[Bug libstdc++/68210] New: nothrow operator fails to call default new
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68210
Bug ID: 68210
Summary: nothrow operator fails to call default new
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
A recent discussion about operator new
(https://gcc.gnu.org/ml/gcc-patches/2015-11/msg00192.html) revealed that the
libstdc++ implementation of the nothrow overload of the operator doesn't
conform to the requirement to "return a pointer obtained as if acquired from
the (possibly replaced) ordinary version." The test case below illustrates
some of the problems.
The requirement quoted above implies that a conforming implementation of the
nothrow overload must call the ordinary form like so:
void* operator new (size_t n, const nothrow_t&) {
try {
return operator new (n);
}
catch (...) {
return 0;
}
}
$ cat t.cpp && ~/bin/gcc-5.1.0/bin/g++ -Wall t.cpp && ./a.out
#include
#include
#include
struct MyBadAlloc: std::bad_alloc { };
static bool new_fail;
static bool bad_alloc_thrown;
static unsigned new_called;
static unsigned new_handler_called;
static void new_handler ()
{
if (new_handler_called++)
throw MyBadAlloc ();
}
void* operator new (size_t n)
{
static size_t cntr;
++new_called;
for ( ; ; ) {
if (void *p = new_fail ? 0 : malloc (n + sizeof n)) {
*static_cast(p) = ++cntr;
return static_cast(p) + 1;
}
if (std::new_handler h = std::set_new_handler (0)) {
std::set_new_handler (h);
h ();
}
else {
bad_alloc_thrown = true;
throw MyBadAlloc ();
}
}
}
void operator delete (void *p)
{
if (p)
free (static_cast(p) - 1);
}
int main ()
{
new_called = 0;
void *p = operator new (1, std::nothrow);
assert (p != 0);
assert (1 == new_called);
std::set_new_handler (new_handler);
new_fail = true;
try {
p = operator new (1, std::nothrow);
}
catch (...) {
assert (!"nothrow operator new threw");
}
assert (0 == p);
assert (2 == new_handler_called);
assert (bad_alloc_thrown);
}
a.out: t.cpp:53: int main(): Assertion `1 == new_called' failed.
Aborted (core dumped)
[Bug target/68211] New: Free __m128d subreg of double
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68211
Bug ID: 68211
Summary: Free __m128d subreg of double
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
Target Milestone: ---
Target: x86_64-*-*
Hello,
we still seem to be missing some way of passing a double to intrinsics that
take a __m128d argument (see below for an example) without any overhead when we
do not care about the high part.
__m128d to __m256d has an intrinsic, although its implementation is not optimal
(see PR 50829). But Intel apparently "forgot" to add a similar one for double
to __m128d.
Say I want to use the new AVX512 _mm_sqrt_round_sd to compute the square root
of a double rounded towards +infinity. Using -mavx512f, I can try:
#include
double sqrt_up(double x){
__m128d y = { x, 0 };
return _mm_cvtsd_f64(_mm_sqrt_round_sd(y, y,
_MM_FROUND_TO_POS_INF|_MM_FROUND_NO_EXC));
}
which generates
vmovsd %xmm0, -16(%rsp)
vmovsd -16(%rsp), %xmm0
vsqrtsd {ru-sae}, %xmm0, %xmm0, %xmm0
I get the exact same code with
double d = d;
__m128d y = { x, d };
or
__m128d y = y;
y[0] = x;
I can shorten it to
vmovddup%xmm0, %xmm0
vsqrtsd {ru-sae}, %xmm0, %xmm0, %xmm0
using
__m128d y = { x, x };
I am forced to use inline asm
__m128d y;
asm("":"=x"(y):"0"(x));
to get what I wanted, i.e. only vsqrtsd without any extra instruction. But that
makes the code non-portable, and I might as well write the vsqrtsd instruction
myself in the asm. It probably also has similar drawbacks to the unspec in PR
50829.
[Bug tree-optimization/67742] 3rd-level restrict ignored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67742 --- Comment #9 from vries at gcc dot gnu.org --- Author: vries Date: Wed Nov 4 16:51:06 2015 New Revision: 229766 URL: https://gcc.gnu.org/viewcvs?rev=229766&root=gcc&view=rev Log: Backport "Handle recursive restrict in function parameter" 2015-11-04 Tom de Vries backport from trunk: 2015-11-04 Tom de Vries PR tree-optimization/67742 * tree-ssa-structalias.c (struct fieldoff): Add restrict_pointed_type field. (push_fields_onto_fieldstack): Handle restrict_pointed_type field. (create_variable_info_for_1): Add and handle handle_param parameter. Add restrict handling. (create_variable_info_for): Call create_variable_info_for_1 with extra arg. (make_param_constraints): Drop restrict_name parameter. Ignore vi->only_restrict_pointers. (intra_create_variable_infos): Call create_variable_info_for_1 with extra arg. Remove restrict handling. Call make_param_constraints with one less arg. * gcc.dg/tree-ssa/restrict-7.c: New test. * gcc.dg/tree-ssa/restrict-8.c: New test. * tree-ssa-structalias.c (create_variable_info_for_1): Use decl_type variable. Added: branches/gomp-4_0-branch/gcc/testsuite/gcc.dg/tree-ssa/restrict-7.c branches/gomp-4_0-branch/gcc/testsuite/gcc.dg/tree-ssa/restrict-8.c Modified: branches/gomp-4_0-branch/gcc/ChangeLog.gomp branches/gomp-4_0-branch/gcc/testsuite/ChangeLog.gomp branches/gomp-4_0-branch/gcc/tree-ssa-structalias.c
[Bug c/68212] New: Loop unroller breaks basic block frequencies
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68212
Bug ID: 68212
Summary: Loop unroller breaks basic block frequencies
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: kelvin.nilsen at gmail dot com
Target Milestone: ---
Here’s a very simple program to demonstrate the existing problems:
void foo(double *d, unsigned long int n) {
unsigned long int i;
for (i=0;i> 4;
mod4_elements = extended_element_count & 0x03;
goto B9; /* fall through, probability 100%, frequency 819 */
B9: /* frequency 819 */
*((double *) ivtmp.6) = zero_preload;
ivtmp.6 += 16;
if (ivtmp.6 == _17) goto B10; /* probability 91%, frequency 745 */
else goto B7; /* fall through, probability 9%, frequency 74 */
B10: /* frequency 745 */
/* no code */
goto BB23; /* fall through, probability 75%, frequency 559 */
/* WRONG: probability should be 100%, frequency should be 745 */
B23: /* frequency 497: WRONG: B10 is the only predecessor, frequency
* should be 559 based on existing B10 information
*/
if (mod4_elements == 0) goto B22; /* 25% probability, frequency 124 */
else goto BB19; /* fall through, probability 100%, frequency 497.
WRONG: should be probability 75%, frequency 373 */
B19: /* frequency: 373. INCONSISTENT with B23 data, but this is a correct
value by some standard. */
if (mod4_elements == 1) goto BB18; /* 33% probability, frequency 123
*/
else goto B15; /* fall-through, probability 100%, frequency 373.
WRONG: should be probability 67%, frequency 250 */
B15: /* frequency: 745. WRONG: only predecessor is B19, should be 373 as B19
is currently described */
if (mod4_elements == 2) goto B14; /* probability 50%, frequency = 373
*/
else goto B11; /* fall through, probability 100%, frequency 745.
WRONG: should be probability 50%, frequency 373 */
B11: /* frequency 745 */
/* note: mod4_elements == 3 */
goto B12; /* fall through, probability 100%, frequency = 745 */
B12: /* frequency 745 */
*((double *) ivtmp.6) = zero_preload;
ivtmp.6 += 16;
goto B13; /* fall through, probability 100%, frequency 745 */
B13: /* frequency 745 */
/* no code */
goto B14; */ fall through, probability 100%, frequency 745 */
B14: /* frequency 745 WRONG: predecessors are B13 and B15, should be 1118 =
745 + 373 */
/* no code */
goto B16; /* fall through, probability 100%, frequency 745 */
B16: /* frequency 745 */
*((double *) ivtmp.6) = zero_preload;
ivtmp.6 += 16;
goto B17; /* fall through, probability 100%, frequency 745 */
B17: /* frequency 745 */
goto B18; /* fall through, probability 100%, frequency 745 */
B18: /* frequency 745. WRONG: predecessors are B19 and B17. should be 868 =
123 + 745 */
goto B20; /* fall through, probability 100%, frequency 745 */
B20: /* frequency 745 */
*((double *) ivtmp.6) = zero_preload;
ivtmp.6 += 16;
if (ivtmp.6 != _17) goto B21; /* probability 91%, frequency 678 */
else goto B7; /* fall through, 9%, frequency 67 */
B21: /* frequency 678 */
/* no code */
goto B22; /* fall through, probability 100%, frequency 678 */
B22: /* frequency 678. WRONG: should be 802 = 678 (predecessor B21) + 124
(predecessor B23) */
goto B5; /* fall through, probability 100%, frequency 678 */
B24: /* frequency 1884 */
*((double *) ivtmp.6) = zero_preload;
ivtmp.6 = unrolled_ivtmp_base + 16;
goto B25; /* fall through, probability 100%, frequency 1884 */
B25: /* frequency 1884 */
/* no code */
goto B26; /* fall through, probability 100%, frequency 1884 */
B26: /* frequency 1884 */
*((double *) ivtmp.6) = zero_preload;
ivtmp.6 = unrolled_ivtmp_base + 32;
goto B27;
B27: /* frequency 1884 */
/* no code */
goto B28; /* fall through, probability 100%, frequency 1884 */
B28: /* frequency 1884 */
*((double *) ivtmp.6) = zero_preload;
ivtmp.6 = unrolled_ivtmp_base + 48;
if (ivtmp.6 != _17) goto B29; /* probability 91%, frequency 1715 */
else goto B7; /* fall through, probability 9%, frequency 170 */
B29: /* frequency 1715 */
/* no code */
goto B5; /* fall through, probability 100%, frequency 1715 */
B5: /* frequency 1884. WRONG: should be 2393 = 678 (predecessor B22) + 1715
(predecessor B29) */
/* Note: as represented currently, the frequency of the original loop
* body has been divided by 4 as a consequence of unrolling the loop
* 4 times. As part of our planned improvements, we intend to not
* divide the orig
[Bug c/68162] [5/6 Regression] Incompatible pointer type using a typedef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68162 Joseph S. Myers changed: What|Removed |Added CC||rguenth at gcc dot gnu.org --- Comment #2 from Joseph S. Myers --- Fixing this runs into failures of gcc.dg/debug/dwarf2/pr47939-4.c with what looks like a problem with the DWARF debug output. The problem (arising from the fix for PR 47939) is that the array of the typedef was incorrectly constructed without a TYPE_MAIN_VARIANT being an array of unqualified elements as it should be (though it seems some more recent change resulted in this producing incorrect diagnostics, likely the support for C++-style handling of arrays of qualified type). Fixing the incorrect logic for determining first_non_attr_kind results in failures of that DWARF test because the type ends up no longer being based on the typedef. A more complicated fix, however, as suggested in that PR, results in a type properly based on the typedef, but the test still fails. The type I get (which results in debug info not referencing Harry_t, but looks correct to me) is: unit size align 32 symtab -145814880 alias set -1 canonical type 0x774e39d8 fields SI file t.c line 1 col 35 size unit size align 32 offset_align 128 offset bit offset context >> BLK size constant 320> unit size constant 40> align 32 symtab 0 alias set -1 canonical type 0x774e3f18 domain unit size align 64 symtab -145814480 alias set -1 canonical type 0x773d21f8 precision 64 min max > DI size unit size align 64 symtab 0 alias set -1 canonical type 0x774e3c78 precision 64 min max >>
[Bug c++/68195] gcc//ld produces invalid ABI results (cxx11 problem?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68195 Evgeniy Dushistov changed: What|Removed |Added CC||dushistov at mail dot ru --- Comment #1 from Evgeniy Dushistov --- The behavior of compiler generate code with segfault and generate valid code was changed by this commit: commit 7fbf53b8667745c0122e964e1b11dcb99959e377 Author: hubicka Date: Mon Nov 24 16:15:46 2014 + PR ipa/63671 * ipa-inline-transform.c (can_remove_node_now_p_1): Handle alises and -fno-devirtualize more carefully. (can_remove_node_now_p): Update. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@218024 138bc75d-0d04-0410-961f-82ee72b054a4
[Bug c/68162] [5/6 Regression] Incompatible pointer type using a typedef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68162 --- Comment #3 from Joseph S. Myers --- Created attachment 36648 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36648&action=edit Minimal patch for grokdeclarator
[Bug c/68162] [5/6 Regression] Incompatible pointer type using a typedef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68162 --- Comment #4 from Joseph S. Myers --- Created attachment 36649 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36649&action=edit Patch that preserves the typedef but does not fix the debug test failure
[Bug debug/67192] [6 Regression] Backward-goto in loop can get wrong line number
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67192 --- Comment #22 from Andreas Arnez --- Here's another version of the fix: https://gcc.gnu.org/ml/gcc-patches/2015-11/msg00368.html It addresses an issue with the previous version that was brought up by Bernd Schmidt: A breakpoint on the "while (1)" didn't behave as expected, but on the first hit one loop iteration may have executed already.
[Bug fortran/66459] bogus warning 'w.offset' may be used uninitialized in this function [-Wmaybe-uninitialized]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66459 --- Comment #2 from Dominique d'Humieres --- > Possibly related bug: PR60500 Likely, but I get the warning for this PR for 4.5.4, but not 4.4.7, while the warnings for PR60500 appear only for 4.7.3.
[Bug fortran/66244] [4.9/5/6 Regression] ICE on assigning a value to a pointer variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66244 Dominique d'Humieres changed: What|Removed |Added Summary|ICE on assigning a value to |[4.9/5/6 Regression] ICE on |a pointer variable |assigning a value to a ||pointer variable --- Comment #3 from Dominique d'Humieres --- Compiling the test in comment 0 with 4.7.3 does not ICE, but the error pr66244.f90:3.35: integer, pointer :: z => a(3) 1 Error: Pointer initialization target at (1) must have the SAVE attribute Note that the ICE for 4.8.5 is pr66244.f90:6:0: internal compiler error: in varpool_node_for_decl, at varpool.c:45 end ^ The change occurred between revisions r194897 (2013-01-04, error) and r195140 (2013-01-14, ICE at varpool.c:45). Note that the code compiles with integer, save, target :: a(3)
[Bug c++/68195] gcc//ld produces invalid ABI results (cxx11 problem?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68195 Jan Hubicka changed: What|Removed |Added CC||hubicka at gcc dot gnu.org --- Comment #2 from Jan Hubicka --- This works for me on mainline: $ ls Lib.cpp Lib.hpp main.cpp Makefile README.md $ g++ --version g++ (GCC) 6.0.0 20151010 (experimental) Copyright (C) 2015 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ make test1 g++ -shared -fPIC -o libmyLib.so Lib.cpp -O2 g++ -o main -std=c++11 main.cpp -L. -l myLib LD_LIBRARY_PATH=$LD_LIBRARY_PATH:. ./main I am building GCC-5 branch to see if it fails.
[Bug fortran/67933] [5 Regression] ICE for array of a derived type with allocatable class in derived type object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67933 --- Comment #10 from Paul Thomas --- Author: pault Date: Wed Nov 4 20:00:19 2015 New Revision: 229777 URL: https://gcc.gnu.org/viewcvs?rev=229777&root=gcc&view=rev Log: 2015-01-25 Paul Thomas Backported from trunk. PR fortran/67171 * trans-array.c (structure_alloc_comps): On deallocation of class components, reset the vptr to the declared type vtable and reset the _len field of unlimited polymorphic components. *trans-expr.c (gfc_find_and_cut_at_last_class_ref): Bail out on allocatable component references to the right of part reference with non-zero rank and return NULL. (gfc_reset_vptr): Simplify this function by using the function gfc_get_vptr_from_expr. Return if the vptr is NULL_TREE. (gfc_reset_len): If gfc_find_and_cut_at_last_class_ref returns NULL return. 2015-01-25 Paul Thomas Backported from trunk. PR fortran/67171 * gfortran.dg/allocate_with_source_12.f03: New test Backported from trunk. PR fortran/61819 * gfortran.dg/allocate_with_source_13.f03: New test Backported from trunk. PR fortran/61830 * gfortran.dg/allocate_with_source_14.f03: New test Backported from trunk. PR fortran/67933 * gfortran.dg/allocate_with_source_15.f03: New test Added: branches/gcc-5-branch/gcc/testsuite/gfortran.dg/allocate_with_source_12.f03 branches/gcc-5-branch/gcc/testsuite/gfortran.dg/allocate_with_source_13.f03 branches/gcc-5-branch/gcc/testsuite/gfortran.dg/allocate_with_source_14.f03 branches/gcc-5-branch/gcc/testsuite/gfortran.dg/allocate_with_source_15.f03 Modified: branches/gcc-5-branch/gcc/fortran/ChangeLog branches/gcc-5-branch/gcc/fortran/trans-array.c branches/gcc-5-branch/gcc/fortran/trans-expr.c branches/gcc-5-branch/gcc/testsuite/ChangeLog
[Bug fortran/61830] [4.9/5/6 regression] Memory leak with assignment to array of derived types with allocatable components
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61830 --- Comment #9 from Paul Thomas --- Author: pault Date: Wed Nov 4 20:00:19 2015 New Revision: 229777 URL: https://gcc.gnu.org/viewcvs?rev=229777&root=gcc&view=rev Log: 2015-01-25 Paul Thomas Backported from trunk. PR fortran/67171 * trans-array.c (structure_alloc_comps): On deallocation of class components, reset the vptr to the declared type vtable and reset the _len field of unlimited polymorphic components. *trans-expr.c (gfc_find_and_cut_at_last_class_ref): Bail out on allocatable component references to the right of part reference with non-zero rank and return NULL. (gfc_reset_vptr): Simplify this function by using the function gfc_get_vptr_from_expr. Return if the vptr is NULL_TREE. (gfc_reset_len): If gfc_find_and_cut_at_last_class_ref returns NULL return. 2015-01-25 Paul Thomas Backported from trunk. PR fortran/67171 * gfortran.dg/allocate_with_source_12.f03: New test Backported from trunk. PR fortran/61819 * gfortran.dg/allocate_with_source_13.f03: New test Backported from trunk. PR fortran/61830 * gfortran.dg/allocate_with_source_14.f03: New test Backported from trunk. PR fortran/67933 * gfortran.dg/allocate_with_source_15.f03: New test Added: branches/gcc-5-branch/gcc/testsuite/gfortran.dg/allocate_with_source_12.f03 branches/gcc-5-branch/gcc/testsuite/gfortran.dg/allocate_with_source_13.f03 branches/gcc-5-branch/gcc/testsuite/gfortran.dg/allocate_with_source_14.f03 branches/gcc-5-branch/gcc/testsuite/gfortran.dg/allocate_with_source_15.f03 Modified: branches/gcc-5-branch/gcc/fortran/ChangeLog branches/gcc-5-branch/gcc/fortran/trans-array.c branches/gcc-5-branch/gcc/fortran/trans-expr.c branches/gcc-5-branch/gcc/testsuite/ChangeLog
[Bug fortran/61819] [4.9/4.10 Regression] ICE in gfc_conv_descriptor_data_get
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61819 --- Comment #15 from Paul Thomas --- Author: pault Date: Wed Nov 4 20:00:19 2015 New Revision: 229777 URL: https://gcc.gnu.org/viewcvs?rev=229777&root=gcc&view=rev Log: 2015-01-25 Paul Thomas Backported from trunk. PR fortran/67171 * trans-array.c (structure_alloc_comps): On deallocation of class components, reset the vptr to the declared type vtable and reset the _len field of unlimited polymorphic components. *trans-expr.c (gfc_find_and_cut_at_last_class_ref): Bail out on allocatable component references to the right of part reference with non-zero rank and return NULL. (gfc_reset_vptr): Simplify this function by using the function gfc_get_vptr_from_expr. Return if the vptr is NULL_TREE. (gfc_reset_len): If gfc_find_and_cut_at_last_class_ref returns NULL return. 2015-01-25 Paul Thomas Backported from trunk. PR fortran/67171 * gfortran.dg/allocate_with_source_12.f03: New test Backported from trunk. PR fortran/61819 * gfortran.dg/allocate_with_source_13.f03: New test Backported from trunk. PR fortran/61830 * gfortran.dg/allocate_with_source_14.f03: New test Backported from trunk. PR fortran/67933 * gfortran.dg/allocate_with_source_15.f03: New test Added: branches/gcc-5-branch/gcc/testsuite/gfortran.dg/allocate_with_source_12.f03 branches/gcc-5-branch/gcc/testsuite/gfortran.dg/allocate_with_source_13.f03 branches/gcc-5-branch/gcc/testsuite/gfortran.dg/allocate_with_source_14.f03 branches/gcc-5-branch/gcc/testsuite/gfortran.dg/allocate_with_source_15.f03 Modified: branches/gcc-5-branch/gcc/fortran/ChangeLog branches/gcc-5-branch/gcc/fortran/trans-array.c branches/gcc-5-branch/gcc/fortran/trans-expr.c branches/gcc-5-branch/gcc/testsuite/ChangeLog
[Bug fortran/67171] [6 regression] sourced allocation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67171 --- Comment #11 from Paul Thomas --- Author: pault Date: Wed Nov 4 20:00:19 2015 New Revision: 229777 URL: https://gcc.gnu.org/viewcvs?rev=229777&root=gcc&view=rev Log: 2015-01-25 Paul Thomas Backported from trunk. PR fortran/67171 * trans-array.c (structure_alloc_comps): On deallocation of class components, reset the vptr to the declared type vtable and reset the _len field of unlimited polymorphic components. *trans-expr.c (gfc_find_and_cut_at_last_class_ref): Bail out on allocatable component references to the right of part reference with non-zero rank and return NULL. (gfc_reset_vptr): Simplify this function by using the function gfc_get_vptr_from_expr. Return if the vptr is NULL_TREE. (gfc_reset_len): If gfc_find_and_cut_at_last_class_ref returns NULL return. 2015-01-25 Paul Thomas Backported from trunk. PR fortran/67171 * gfortran.dg/allocate_with_source_12.f03: New test Backported from trunk. PR fortran/61819 * gfortran.dg/allocate_with_source_13.f03: New test Backported from trunk. PR fortran/61830 * gfortran.dg/allocate_with_source_14.f03: New test Backported from trunk. PR fortran/67933 * gfortran.dg/allocate_with_source_15.f03: New test Added: branches/gcc-5-branch/gcc/testsuite/gfortran.dg/allocate_with_source_12.f03 branches/gcc-5-branch/gcc/testsuite/gfortran.dg/allocate_with_source_13.f03 branches/gcc-5-branch/gcc/testsuite/gfortran.dg/allocate_with_source_14.f03 branches/gcc-5-branch/gcc/testsuite/gfortran.dg/allocate_with_source_15.f03 Modified: branches/gcc-5-branch/gcc/fortran/ChangeLog branches/gcc-5-branch/gcc/fortran/trans-array.c branches/gcc-5-branch/gcc/fortran/trans-expr.c branches/gcc-5-branch/gcc/testsuite/ChangeLog
[Bug fortran/61819] [4.9/4.10 Regression] ICE in gfc_conv_descriptor_data_get
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61819 Paul Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #16 from Paul Thomas --- Fixed on trunk and 5 branch. Thanks for the report. Paul
[Bug fortran/61830] [4.9/5/6 regression] Memory leak with assignment to array of derived types with allocatable components
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61830 Paul Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #10 from Paul Thomas --- Fixed on trunk and 5 branch. I'll take a look at fixing it on 4.9 but, for now, I am closing this PR. Thanks for the report. Paul
[Bug fortran/67933] [5 Regression] ICE for array of a derived type with allocatable class in derived type object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67933 Paul Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #11 from Paul Thomas --- Fixed on trunk and 5 branch. Thanks for the report. Paul
[Bug c++/68213] New: Exception handling corrupts a VLA in MinGW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68213
Bug ID: 68213
Summary: Exception handling corrupts a VLA in MinGW
Product: gcc
Version: 5.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: hedayat.fwd at gmail dot com
Target Milestone: ---
Code:
-
#include
#include
#include
#include
using namespace std;
int main(int argc, char **argv)
{
int n;
stringstream ss(argv[1]);
ss >> n;
cout << "N: " << n << endl;
char tbuff[n];
try
{
memset(tbuff, 0, n);
throw runtime_error("ERR");
}
catch (exception &e)
{
cout << "Writing to VLA" << endl;
memset(tbuff, 0, n);
cout << "Wrote" << endl;
}
}
-
Compiled with:
/usr/bin/i686-w64-mingw32-g++ -O2 test.cpp -o t
Run with wine (similar results under Windows) results in crash:
[]% ./t 100
fixme:winediag:start_process Wine Staging is a testing version containing
experimental patches.
fixme:winediag:start_process Please report bugs at http://bugs.wine-staging.com
(instead of winehq.org).
N: 100
Writing to VLA
wine: Unhandled page fault on read access to 0x at address (nil)
(thread 0009), starting debugger...
Unhandled exception: page fault on read access to 0x in 32-bit code
(0x).
[Bug c++/68209] C++11 code compiled without -std=c++11 but doesn't work as expected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68209 Daniel Krügler changed: What|Removed |Added CC||daniel.kruegler@googlemail. ||com --- Comment #3 from Daniel Krügler --- > What is the reason why it compiled on C++98? > I expect that it is incorrect > syntax for C++98 and code doesn't match language grammatics. So expected > behavior is "compilation error". There is no requirement for your expected behaviour. The standard only requires a diagnostics in such a case, see [intro.compliance] p2: If a program contains a violation of any diagnosable rule or an occurrence of a construct described in this Standard as “conditionally-supported” when the implementation does not support that construct, a conforming implementation shall issue at least one diagnostic message. This diagnostics is produced. I'd like to point out that clang behaves similarly (albeit this is not really relevant when we talk about the correctness).
[Bug c++/68195] gcc//ld produces invalid ABI results (cxx11 problem?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68195 --- Comment #3 from Evgeniy Dushistov --- I build gcc with last commit: commit 06d6724083a2cb1f35e36f4a0db3025bfde20667 Author: nathan Date: Wed Nov 4 17:01:23 2015 + * libgomp.oacc-c-c++-common/loop-red-g-1.c: New. * libgomp.oacc-c-c++-common/loop-red-gwv-1.c: New. * libgomp.oacc-c-c++-common/loop-red-v-1.c: New. * libgomp.oacc-c-c++-common/loop-red-v-2.c: New. * libgomp.oacc-c-c++-common/loop-red-w-1.c: New. * libgomp.oacc-c-c++-common/loop-red-w-2.c: New. * libgomp.oacc-c-c++-common/loop-red-wv-1.c: New. * libgomp.oacc-fortran/reduction-5.f90: Avoid reference var. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@229770 138bc75d-0d04-0410-961f-82ee72b054a4 $/home/evgeniy/local/bin/g++ --version | head -n 1 g++ (GCC) 6.0.0 20151104 (experimental) $ LANG=C make /home/evgeniy/local/bin/g++ -std=c++03 -g3 -shared -fPIC -o libmyLib.so Lib.cpp -O2 /home/evgeniy/local/bin/g++ -std=c++11 -g3 main.cpp -o main -L. -l myLib LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/home/evgeniy/local/lib64:./ ./main Makefile:7: recipe for target 'test1' failed make: *** [test1] Segmentation fault So the bug should be in trunk also, linux/amd64
[Bug c++/68195] gcc//ld produces invalid ABI results (cxx11 problem?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68195 --- Comment #4 from Evgeniy Dushistov --- Created attachment 36650 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36650&action=edit preprocessed sources I attached files created with gcc -E from main.cpp and Lib.cpp, hope this helps reproduce bug (used xz compressor to work around 1000KB restriction from bugzilla).
[Bug c++/68209] C++11 code compiled without -std=c++11 but doesn't work as expected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68209 Marc Glisse changed: What|Removed |Added Keywords||diagnostic, wrong-code Status|UNCONFIRMED |NEW Last reconfirmed||2015-11-04 Ever confirmed|0 |1
[Bug c++/68209] C++11 code compiled without -std=c++11 but doesn't work as expected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68209 Marc Glisse changed: What|Removed |Added Keywords||accepts-invalid --- Comment #4 from Marc Glisse --- (Oups, pressed return by mistake) Yes it is QoI, but we could still do better. (the -Wall warning is a better sign that something is going wrong: x.cc:8:22: warning: 'aa' may be used uninitialized in this function [-Wmaybe-uninitialized] cout << aa << endl; ^ )
[Bug target/68214] New: gcc.dg/cwsc1.c fails on arm-none-eabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68214
Bug ID: 68214
Summary: gcc.dg/cwsc1.c fails on arm-none-eabi
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: sandra at gcc dot gnu.org
Target Milestone: ---
Created attachment 36651
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36651&action=edit
cwsc1.s
The testcase gcc.dg/cwsc1.c seems to assume that register "ip" is always
reserved for the static chain pointer on ARM, but it's being re-used as a
temporary to hold the value of the variable "ptr" prior to calling it:
arm-none-eabi-gcc src/gcc-mainline/gcc/testsuite/gcc.dg/cwsc1.c -S -O
produces:
main:
@ Function supports interworking.
@ args = 0, pretend = 0, frame = 8
@ frame_needed = 0, uses_anonymous_args = 0
stmfd sp!, {r4, lr}
sub sp, sp, #8
add r4, sp, #7
mov ip, r4
ldr r3, .L6
ldr ip, [r3]
mov lr, pc
bx ip
cmp r4, r0
bne .L5
Invalid testcase or bug in the ARM backend?
[Bug fortran/63331] Fortran -fcompare-debug issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63331 Dominique d'Humieres changed: What|Removed |Added Status|NEW |WAITING --- Comment #4 from Dominique d'Humieres --- > Untested patch to fix (or work around) all but the last 2 FAILs. Is this patch committed as revision r215516? Setting GCC_COMPARE_DEBUG=1, I see FAIL: gfortran.dg/iso_c_binding_compiler_1.f90 -O (test for excess errors) FAIL: gfortran.dg/iso_c_binding_compiler_3.f90 -O (test for excess errors) at r229727. Is this OK. Any reason to keep this PR opened?
[Bug fortran/63327] Poor caret location in error mesage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63327 --- Comment #2 from Dominique d'Humieres --- See also pr54224 comment 22 for other examples: Manuel López-Ibáñez wrote > You will get a more precise column info (and better location for '^') > if Fortran gives a more precise DECL_SOURCE_LOCATION() when generating > this tree. May be related to 29819.
[Bug rtl-optimization/68212] Loop unroller breaks basic block frequencies
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68212 David Edelsohn changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-11-04 CC||dje at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from David Edelsohn --- Confirmed.
[Bug fortran/53694] [OOP] GENERIC type-bound procs should be available without part-ref syntax
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53694 Dominique d'Humieres changed: What|Removed |Added Status|NEW |WAITING --- Comment #9 from Dominique d'Humieres --- More than three years ago Tobias Burnus wrote > Actually, I am no longer sure that this PR is valid - nor is Richard Maine > in c.l.f. Janus seems to have the same doubts, if I read comment 5 correctly. > > The standard seems to make a distinction between 'generic type-bound > procedure' > and 'generic procedure name'. Any reason to keep this PR opened? Note that the tests now fail with Error: INTENT(OUT) argument 'a' of pure procedure 'scalar_equals_field' at (1) may not be polymorphic
[Bug fortran/54224] Warn for unused internal procedures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54224 --- Comment #30 from Dominique d'Humieres --- > so I give up. I am planning to submit the following patch, open a new PR > for the bad locus, then close this PR as fixed. The new PR won't be necessary: it is already pr63327.
[Bug middle-end/68215] New: [6 regression] FAIL: c-c++-common/opaque-vector.c -std=c++11 (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68215 Bug ID: 68215 Summary: [6 regression] FAIL: c-c++-common/opaque-vector.c -std=c++11 (internal compiler error) Product: gcc Version: 6.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: sch...@linux-m68k.org CC: ienkovich at gcc dot gnu.org Target Milestone: --- Target: powerpc-*-* $ gcc/xg++ -Bgcc/ ../gcc/testsuite/c-c++-common/opaque-vector.c -nostdinc++ -Ipowerpc64-suse-linux/32/libstdc++-v3/include/powerpc64-suse-linux -Ipowerpc64-suse-linux/32/libstdc++-v3/include -I../libstdc++-v3/libsupc++ -I../libstdc++-v3/include/backward -I../libstdc++-v3/testsuite/util -std=c++11 -S -m32 ../gcc/testsuite/c-c++-common/opaque-vector.c: In function ‘void f()’: ../gcc/testsuite/c-c++-common/opaque-vector.c:3:153: internal compiler error: in expand_shift_1, at expmed.c:2334 peof((v
[Bug rtl-optimization/67753] [6 Regression] FAIL: cxg1005, cxg2002, cxg2006, cxg2007, cxg2008, cxg2018, cxg2019 and cxg2020
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67753 --- Comment #5 from dave.anglin at bell dot net --- On 2015-11-04, at 1:57 AM, aoliva at gcc dot gnu.org wrote: > --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36645&action=edit > Here's a patch I'm testing to fix this problem Testing... -- John David Anglin dave.ang...@bell.net
[Bug c++/67625] some constexpr expressions rejected as enumerator value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67625 Oleg Endo changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-11-05 CC||olegendo at gcc dot gnu.org Ever confirmed|0 |1 Known to fail||5.2.1 --- Comment #1 from Oleg Endo --- I just ran into the very same issue.
[Bug c++/67625] some constexpr expressions rejected as enumerator value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67625
--- Comment #2 from Oleg Endo ---
There is a funny work around for this though ...
#include
struct bswapped16
{
const uint16_t val;
constexpr bswapped16 (uint16_t v) : val (__builtin_bswap16 (v)) { }
};
constexpr uint16_t bswap16 (uint16_t x)
{
return bswapped16 (x).val;
}
enum { foo_4 = bswap16 (1) }; // OK
[Bug c/61588] Optimization defaults are not what documentation say they should be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61588 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-11-05 CC||msebor at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #4 from Martin Sebor --- Confirmed with the latest trunk. The -Os documentation states: -Os disables the following optimization flags: -falign-functions -falign-jumps -falign-loops -falign-labels -freorder-blocks -freorder-blocks-algorithm=stc -freorder-blocks-and-partition -fprefetch-loop-arrays Invoking "gcc -Os -Q --help=optimizers" to "to find out the exact set of optimizations that are enabled at [the given optimization] level" indicates that all the options are enabled: $ /build/gcc-trunk-svn/gcc/xgcc -B /build/gcc-trunk-svn/gcc -Os -o/dev/null -Q --help=optimizers | grep -E "[-]f(align-functions|align-jumps|align-loops|align-labels|reorder-blocks|reorder-blocks-algorithm|reorder-blocks-and-partition|prefetch-loop-arrays)" -falign-functions [enabled] -falign-jumps [enabled] -falign-labels[enabled] -falign-loops [enabled] -fprefetch-loop-arrays[enabled] -freorder-blocks [enabled] -freorder-blocks-algorithm= simple -freorder-blocks-and-partition[enabled]
[Bug fortran/68216] New: [F2003] IO problem with allocatable, deferred character length arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68216 Bug ID: 68216 Summary: [F2003] IO problem with allocatable, deferred character length arrays Product: gcc Version: 6.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: --- The following segfaults in the READ statement: PROGRAM hello IMPLICIT NONE CHARACTER(LEN=:),DIMENSION(:),ALLOCATABLE :: array_lineas INTEGER :: largo , cant_lineas , i WRITE(*,*) ' Escriba un numero para el largo de cada linea' READ(*,*) largo WRITE(*,*) ' Escriba la cantidad de lineas' READ(*,*) cant_lineas ALLOCATE(CHARACTER(LEN=largo) :: array_lineas(cant_lineas)) WRITE(*,*) 'Escriba el array', len(array_lineas), size(array_lineas) READ(*,*) (array_lineas(i),i=1,cant_lineas) WRITE(*,*) 'Array guardado: ' DO i=1,cant_lineas WRITE(*,*) array_lineas(i) ENDDO READ(*,*) END PROGRAM Reported on clf https://groups.google.com/forum/#!topic/comp.lang.fortran/eWQTKfqKLZc Paul
[Bug fortran/68216] [F2003] IO problem with allocatable, deferred character length arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68216 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2015-11-05 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- I am not sure it has anything to do with IO, but I think it is rather a duplicate of pr50221.
[Bug c/68217] New: Wrong constant folding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68217
Bug ID: 68217
Summary: Wrong constant folding
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: ishiura-compiler at ml dot kwansei.ac.jp
Target Milestone: ---
GCC-6.0.0 miscompiles the following code.
$ cat error.c
int main(void){
volatile int a = -1;
long long b = -9223372036854775807LL-1; // LLONG_MIN
long long x = (a & b); // x == 0x8000
if ( x < 1LL ) { ; } else { __builtin_abort(); }
return 0;
}
$ gcc-6.0 error.c -O3 && ./a.out
[1]26572 abort (core dumped) ./a.out
$ gcc-6.0 -v
Using built-in specs.
COLLECT_GCC=gcc-6.0
COLLECT_LTO_WRAPPER=$HOME/opt/gcc-6.0.0/libexec/gcc/x86_64-pc-linux-gnu/6.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --prefix=$HOME/opt/gcc-6.0.0
--enable-languages=c --program-suffix=-6.0
Thread model: posix
gcc version 6.0.0 20151105 (experimental) (GCC)
[Bug rtl-optimization/68217] Wrong constant folding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68217 Marc Glisse changed: What|Removed |Added Keywords||wrong-code Status|UNCONFIRMED |NEW Last reconfirmed||2015-11-05 Component|c |rtl-optimization Ever confirmed|0 |1 Known to fail||4.8.5, 4.9.3, 5.2.1 --- Comment #1 from Marc Glisse --- Might happen during the combine pass (or not).
[Bug fortran/68218] New: ALLOCATE with size given by a module function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68218 Bug ID: 68218 Summary: ALLOCATE with size given by a module function Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: ysheofue at imgof dot com Target Milestone: --- Calling ALLOCATE with an array size that is given by a function argument results in multiple calls of this function. This issue is present (at least) on gfortran versions 4.7 ... 5 The following program unintentionally calls "nquery()" four times: MODULE mo_test CONTAINS FUNCTION nquery() INTEGER :: nquery WRITE (0,*) "hello!" nquery = 1 END FUNCTION nquery END MODULE mo_test ! -- ! MAIN PROGRAM ! -- PROGRAM example USE mo_test INTEGER, ALLOCATABLE :: query_buf(:) ALLOCATE(query_buf(nquery())) END PROGRAM example
[Bug fortran/68218] ALLOCATE with size given by a module function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68218 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-11-05 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Confirmed from 4.3.1 up to trunk (6.0).
[Bug fortran/63859] OpenACC DEVICE_RESIDENT clause
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63859 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-11-05 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Confirmed at revision r229787 (trunk 6.0) !$acc declare device_resident (a) ^ sorry, unimplemented: directive not yet implemented
[Bug fortran/58769] RFC: Creating SIMD variant for Fortran's ELEMENTAL functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58769 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2015-11-05 Ever confirmed|0 |1 --- Comment #2 from Dominique d'Humieres --- WTF? No activity for over two years.
