[Bug c/59615] "asm goto" output or at least clobbered operands
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59615 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- The reason for the limitation is that any needed reload out can't be then inserted after the asm goto, but all the other edges would need to be split and the reload outs inserted on all the edges. Looking at your example though, can you explain why you want to use asm goto then? I'd say that for addition, two conditional jumps and one comparison you definitely don't want to use asm goto, the compiler can't see through it thus can't optimize it. Why isn't what GCC generates sufficient? Do you have a testcase?
[Bug c++/56926] Crash (without ICE) while compiling Boost.Math
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56926
--- Comment #6 from asmwarrior ---
It is very simple to reproduce this bug. Here is the steps I do
1, download the GCC 4.8.2 from MinGW-w64 site, I'm using
i686-4.8.2-release-posix-dwarf-rt_v3-rev1
2, download the boost source package, I'm using boost_1_55_0.7z download from
boost official site, extract its source to some folder like:
D:\mingw-builds\boost_1_55_0. (Note, no need to build boost library, only the
boost header files are needed for testing)
3, create a simple file named "pch.h", which contains following:
#ifndef pch_h
#define pch_h
#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wdelete-non-virtual-dtor"
#include
#include
#include
#include
#pragma GCC diagnostic pop
#endif
4, create a simple "test.cpp" file, which contains following:
#include "pch.h"
int main()
{
int a;
int b;
int c;
a++;
b++;
}
5, build the pch file by running the command.
g++.exe -Wall -fexceptions -g -march=core2 -Wall
-ID:\mingw-builds\boost_1_55_0 -c pch.h -o pch.h.gch
6, now, you will see a file named "pch.h.gch" was generated, its size is bigger
than 200M.
7, compile the test.cpp file by running the command:
g++.exe -v -Wall -fexceptions -g -march=core2 -Wall
-ID:\mingw-builds\boost_1_55_0 -Winvalid-pch -include pch.h -c test.cpp -o
test.o
8, I see some verbose messages, but no "test.o" file was generated in the
working directory, also I see no crash dialog shown.
So, this is indeed a bug.
Now, if you comment out some lines in the pch.h file, e.g. only leave the first
#include directive: #include , and comment out the later three
include directive, and run the steps again, you get a 47M pch.h.gch and a 206K
test.o file.
I try to use GDB to catch the errors, but failed.
Try use GDB, I did such thing:
gdb g++.exe [enter]
then
set args -v -Wall -fexceptions -g -march=core2 -Wall
-ID:\mingw-builds\boost_1_55_0 -Winvalid-pch -include pch.h -c test.cpp -o
test.o [enter]
then
r [enter]
GDB can't catch anything, just the same as I run the command in the Command
line, the last message from GDB is: [Inferior 1 (process 2000) exited with code
01]
Does exit code "01" has some special meaning?
BTW: I have test the GCC 4.9 snapshot
i686-4.9.0-snapshot-20131119-rev205009-posix-dwarf-rt_v4.7z from mingw-w64
site, it has the same bug.
[Bug debug/59170] pretty printers: end iterator invalid pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59170 Jan Kratochvil changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID |--- --- Comment #2 from Jan Kratochvil --- It is fixable, only for development builds but that does not matter much IMO. Just one has to build the executable with -D_GLIBCXX_DEBUG. The test whether it is an end() iterator can be done by: (gdb) whatis end type = std::__debug::vector >::iterator s/::iterator$// (gdb) p end._M_current._M_current == ((std::__debug::vector > *)end._M_sequence)._M_impl._M_finish $29 = true That is with -D_GLIBCXX_DEBUG each iterator contains: /** The sequence this iterator references; may be NULL to indicate a singular iterator. */ _Safe_sequence_base* _M_sequence;
[Bug lto/59543] [4.9 Regression] lto1: fatal error: Cgraph edge statement index out of range
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59543 --- Comment #3 from Markus Trippelsdorf --- It turned out to be a problem with debugging information. Some files in libjs_static.a are build with "-g", even when Firefox is configured with --disable-debug --disable-debug-symbols. If I add -g to the g++ invocation above, or build the object files in libjs_static.a without -g, the issue goes away.
[Bug c/59615] "asm goto" output or at least clobbered operands
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59615
--- Comment #2 from Uroš Bizjak ---
Looking at the assembly, you probably want:
--cut here--
int test (int a, int b, int c)
{
unsigned r = a + b;
if (r < (unsigned) a)
return 1;
else if (r > c)
return 1;
return 0;
}
--cut here--
gcc-4.8.2 -O2:
test:
addl%esi, %edi
movl$1, %eax
jc .L2
xorl%eax, %eax
cmpl%edx, %edi
seta%al
.L2:
rep ret
Please note how the compiler is able to generate jc without compare insn.
[Bug c/59615] "asm goto" output or at least clobbered operands
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59615 --- Comment #3 from Uroš Bizjak --- (In reply to Uroš Bizjak from comment #2) > if (r < (unsigned) a) Explicit cast is not needed here, the compiler will do it for you.
[Bug fortran/59604] Constant comparisons with -fno-range-check and int(z'...')
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59604 Thomas Koenig changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2013-12-28 Assignee|unassigned at gcc dot gnu.org |tkoenig at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #6 from Thomas Koenig --- I have a patch.
[Bug fortran/59604] Constant comparisons with -fno-range-check and int(z'...')
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59604 Thomas Koenig changed: What|Removed |Added Status|ASSIGNED|UNCONFIRMED Ever confirmed|1 |0 --- Comment #7 from Thomas Koenig --- (In reply to Steve Kargl from comment #5) > On Fri, Dec 27, 2013 at 07:53:00PM +, tkoenig at gcc dot gnu.org wrote: > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59604 > > > > Thomas Koenig changed: > > > >What|Removed |Added > > > > Blocks||58003 > > > > --- Comment #4 from Thomas Koenig --- > > (In reply to kargl from comment #2) > > > (In reply to Thomas Koenig from comment #1) > > > > TRANSFER gets this right. > > > > > > It is unclear what you mean here. > > > > What I mean is that > > > > program test > > if (transfer(z'',1) /= -1) call abort > > end program test > > > > does not call abort. > > I suspect that the above is not portable as transfer() simply copies > bits. z'FFF' is an integer(8) (or integer(16)) entity. Transfer() > is copying 32-bits from that entity. It is clear from the > -fdump-tree-original that middle-end is "converting" the resulting > 32-bit thing into -1. So, you're relying on twos-complement wrap > around semantics. As gcc supports only twos complement arithmetic, I think this is OK.
[Bug lto/59543] [4.9 Regression] lto1: fatal error: Cgraph edge statement index out of range
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59543 --- Comment #4 from Markus Trippelsdorf --- Created attachment 31527 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31527&action=edit testcase Here's a small testcase: % cat check.sh g++ -g -fprofile-use -fPIC -flto -fno-exceptions -O2 -std=c++11 -c uniset.ii g++ -fPIC -flto -fno-exceptions -O2 -std=c++11 -c unistr.ii g++ -fPIC -flto -fno-exceptions -O2 -std=c++11 -c unorm.ii gcc -O3 -c -fPIC unorm_it.i g++ -flto -O2 uniset.o unistr.o unorm_it.o unorm.o % ./check.sh In member function ‘extractBetween’: lto1: fatal error: Cgraph edge statement index out of range 25 < 50 compilation terminated.
[Bug fortran/59612] iso_fortran_env segfaults with -fdump-fortran-original
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59612 janus at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-valid-code Status|UNCONFIRMED |NEW Last reconfirmed||2013-12-28 CC||janus at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from janus at gcc dot gnu.org --- Straightforward patch: Index: gcc/fortran/dump-parse-tree.c === --- gcc/fortran/dump-parse-tree.c(revision 206176) +++ gcc/fortran/dump-parse-tree.c(working copy) @@ -110,7 +110,8 @@ show_typespec (gfc_typespec *ts) break; case BT_CHARACTER: - show_expr (ts->u.cl->length); + if (ts->u.cl) +show_expr (ts->u.cl->length); fprintf(dumpfile, " %d", ts->kind); break;
[Bug fortran/59612] iso_fortran_env segfaults with -fdump-fortran-original
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59612
--- Comment #2 from janus at gcc dot gnu.org ---
Note that there are two small errors in the related documentation:
Index: gcc/fortran/invoke.texi
===
--- gcc/fortran/invoke.texi(revision 206176)
+++ gcc/fortran/invoke.texi(working copy)
@@ -989,11 +989,12 @@ Output the internal parse tree after translating t
into internal representation. Only really useful for debugging the
GNU Fortran compiler itself.
-@item -fdump-optimized-tree
+@item -fdump-fortran-optimized
@opindex @code{fdump-fortran-optimized}
Output the parse tree after front-end optimization. Only really
useful for debugging the GNU Fortran compiler itself.
+@item -dump-parse-tree
@opindex @code{fdump-parse-tree}
Output the internal parse tree after translating the source program
into internal representation. Only really useful for debugging the
Does -fdump-fortran-optimized actually do anything?
[Bug c++/56926] Crash (without ICE) while compiling Boost.Math
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56926 --- Comment #7 from baltic <1000hz.radiowave at gmail dot com> --- (In reply to baltic from comment #5) > worked fine with 4.6 This is not true anymore :) was probably working fine with previous versions of the Qt, because headers were smaller back than. Now 4.6 version of MinGW-64 doesn't work with the PCH's full of Qt headers either.
[Bug fortran/59589] [4.9 Regression] [OOP] Memory leak when deallocating polymorphic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59589 janus at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code CC||janus at gcc dot gnu.org Summary|[4.9 Regression] Memory |[4.9 Regression] [OOP] |leak when deallocating |Memory leak when |polymorphic |deallocating polymorphic --- Comment #12 from janus at gcc dot gnu.org --- I can confirm the problem on x86_64-unknown-linux-gnu with a current trunk build. It is certainly related to finalization, which was introduced in 4.9. The dump shows that a finalizer routine is called for 'b' upon deallocation: b._vptr->_final (&desc.7, b._vptr->_size, 0); However, the finalizer routine apparently misses to properly deallocate the components.
[Bug fortran/59612] iso_fortran_env segfaults with -fdump-fortran-original
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59612
--- Comment #3 from janus at gcc dot gnu.org ---
Maybe it would make sense to run the testsuite with -fdump-fortran-original, in
order to check for further problems:
Index: gcc/testsuite/gfortran.dg/dg.exp
===
--- gcc/testsuite/gfortran.dg/dg.exp(revision 206231)
+++ gcc/testsuite/gfortran.dg/dg.exp(working copy)
@@ -22,7 +22,7 @@
# If a testcase doesn't have special options, use these.
global DEFAULT_FFLAGS
if ![info exists DEFAULT_FFLAGS] then {
-set DEFAULT_FFLAGS " -pedantic-errors"
+set DEFAULT_FFLAGS " -pedantic-errors -fdump-fortran-original"
}
# Initialize `dg'.
[Bug fortran/59589] [4.9 Regression] [OOP] Memory leak when deallocating polymorphic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59589 janus at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |janus at gcc dot gnu.org --- Comment #13 from janus at gcc dot gnu.org --- I think the following is sufficient to fix it: Index: gcc/fortran/class.c === --- gcc/fortran/class.c(revision 206231) +++ gcc/fortran/class.c(working copy) @@ -811,6 +811,7 @@ finalize_component (gfc_expr *expr, gfc_symbol *de return; if (comp->ts.type == BT_DERIVED && !comp->attr.allocatable + && !comp->ts.u.derived->attr.alloc_comp && (comp->ts.u.derived->f2k_derived == NULL || comp->ts.u.derived->f2k_derived->finalizers == NULL) && !has_finalizer_component (comp->ts.u.derived))
[Bug c++/59598] very simple code using file open for read
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59598
Denis Kolesnik changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|INVALID |---
--- Comment #14 from Denis Kolesnik ---
In the following code:>
// a small text file filter.c //
#include
main(int argc, char* argv[])
{
char c, previous_c;
int word_begin_position[3000];
int spec_symbol[7]={0xAE,0xBB,0xAB,0xA9,0x22,0x2F,0x27};
int eof_symbol[2]={0x0D,0x0A};
int search_result;
int this_is_the_same_word;
int words_count;
int word_number;
int search_result_A_count;
int search_result_space;
FILE *stream,*stream2;
int i, j, characters_count, character_number;
int other_character_printed;
// double characters
int A_count, E_count;
characters_count=0;
stream = fopen (argv[1],"r");
while ((c = fgetc(stream)) != EOF)
{
characters_count++;
}
fclose(stream);
//printf("total characters are %i\n", characters_count);
character_number=1;
words_count=0;
previous_c=0;
stream = fopen (argv[1],"r");
while ((c = fgetc(stream)) != EOF)
{
if(((c!=0x20) && (character_number==1)) || ((previous_c==0x20) &&
(c!=0x20) && (c!=0x0A)) || ((previous_c!=0x20) && (c==0x0D)) || ((c!=0x20) &&
(c!=0x0D) && (c!=0x0A) && (previous_c==0x0A)) || ((previous_c!=0x20) &&
(previous_c!=0x0A) && (character_number==characters_count) && (c==0x20)))
//1. ((c!=0x20) && (character_number==1))
//2. ((previous_c==0x20) && (c!=0x20) && (c!=0x0A))
//3. ((previous_c!=0x20) && (c==0x0D))
//!((previous_c!=0x0D) && (c==0x0A))
//4. ((c!=0x20) && (c!=0x0D) && (c!=0x0A) && (previous_c==0x0A))
//5. ((previous_c!=0x20) && (previous_c!=0x0A) &&
(character_number==characters_count) && (c==0x20))
this_is_the_same_word=0;
else
this_is_the_same_word=1;
if(this_is_the_same_word==0)
{
words_count++;
word_begin_position[words_count]=character_number;
//printf(" the begin char is .
%i",word_begin_position[words_count]);
}
//if(character_number==characters_count)
//printf("the last character");
/*
printf(" the number of words is %i\n", words_count);
printf(" the current character is . %c\n", c);
if(c==0x0D)
printf(" the current character is . 0x0D\n");
if(c==0x0A)
printf(" the current character is . 0x0A\n");
*/
previous_c=c;
character_number++;
}
fclose(stream);
word_number=1;
character_number=1;
A_count=1;
E_count=1;
stream = fopen (argv[1],"r");
//stream2 = fopen (argv[2],"w");
while ((c = fgetc(stream)) != EOF)
{
other_character_printed=0;
if((character_number >= word_begin_position[word_number]) &&
(character_number <= word_begin_position[word_number+1]) )
{
if(((c=='a') || (c=='а') || (c=='A') || (c=='А')) )
{
if(A_count==1)
{
printf("A1");
A_count=2;
other_character_printed=1;
}
else
{
printf("A2");
A_count=1;
other_character_printed=1;
}
}
else
if((other_character_printed==0) && ((c!='е') && (c!='e') &&
(c!='Е') && (c!='E')))
{
printf("%c", c);
other_character_printed=1;
}
if((c=='e') || (c=='е') || (c=='Е') || (c=='E'))
{
if(E_count==1)
{
printf("E1");
E_count=2;
other_character_printed=1;
}
else
{
printf("E2");
E_count=1;
other_character_printed=1;
}
}
else
if((other_character_printed==0) && (((c=='a') & (c=='а') &&
(c=='A') && (c=='А'
{
printf("%c", c);
other_character_printed=1;
}
}
else
{
A_count=1;
E_count=1;
word_number++;
}
character_number++;
}
fclose(stream);
//printf(" the number of words is %i", words_count);
return 0;
}
why other characters representing number are displayed to the screen except
"0"?
when the input text file is of the cintent:
ARSeNALE 2012 ARSENALE
It is a bug and nothing else! Nowhere in my code is stated to ignore "0"
--
[Bug c++/59598] very simple code using file open for read
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59598 --- Comment #15 from Denis Kolesnik --- the output line is:> A1RSE1NA2LE2 212 A1 should be:> A1RSE1NA2LE2 2012 A1
[Bug fortran/59612] iso_fortran_env segfaults with -fdump-fortran-original
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59612 --- Comment #4 from janus at gcc dot gnu.org --- (In reply to janus from comment #3) > Maybe it would make sense to run the testsuite with -fdump-fortran-original, > in order to check for further problems: Does not seem to yield any failures here (with the patch from comment 1 applied).
[Bug c/59615] "asm goto" output or at least clobbered operands
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59615 --- Comment #4 from Jakub Jelinek --- But it would warn about it with -Wsign-compare. You want unsigned r = (unsigned) a + b; or similar to avoid undefined behavior if there is a possibility of signed integer overflow. Anyway, you definitely don't want to use inline asm in this case, if there is some code GCC doesn't optimize as good as you'd like to, just report that.
[Bug c++/59598] very simple code using file open for read
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59598 Andreas Schwab changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #16 from Andreas Schwab --- We are not going to debug your code.
[Bug c++/59598] very simple code using file open for read
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59598 Denis Kolesnik changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID |--- --- Comment #17 from Denis Kolesnik --- please specify the reason for your demand? I can not see anything I missed in my code!!
[Bug c++/59598] very simple code using file open for read
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59598 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #18 from Andrew Pinski --- Again this is not a place to learn c programming or get help to debug your code. This is a place to report bugs against GCC and I don't see a bug here. There are other places on the internet to get c programming help.
[Bug c/59616] New: OpenMP standard conflict in parallel default clause
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59616 Bug ID: 59616 Summary: OpenMP standard conflict in parallel default clause Product: gcc Version: 4.8.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: beamesleach at gmail dot com Created attachment 31528 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31528&action=edit MWE exhibiting error in gcc's OMP predetermined sharing I'm trying to get OpenMP directives to work under both GCC and Intel compilers, but I've found a conflict, when using `default(none)` on an `omp parallel for` directive. I've been reading through relevant sections of the OpenMP 4.0 standard and I haven't managed to pick out any obvious contradiction in the compilers' behaviours, but I think the below compiler error makes the least sense and might also be the easiest to fix: $ gcc-4.8 test_ompmin.c -o omp -fopenmp -std=c99 test_ompmin.c:15:68: error: 'b' is predetermined 'shared' for 'shared' # pragma omp parallel for schedule(static) default(none) shared(a,b,c) ^ test_ompmin.c is attached - a minimal working example designed to test out this behaviour. What's interesting, is g++ does not raise this error, only gcc. Neither do icc or icpc raise the error; these both exhibit the same behaviour as g++ (they compile test_ompmin.c fine, but raise an error if `b` is omitted from the `shared` clause). I'm inclined to surmise that this is a bug in gcc's implementation, as there are no relevant differences between C and C++ in the OpenMP specification. Compile commands that succeed:- > g++-4.8 test_ompmin.c -o omp-gxx -fopenmp > icc test_ompmin.c -o omp-icc -openmp -std=c99 > icpc test_ompmin.c -o omp-icpc -openmp - GCC versions tested: Mac OS X (Mavericks) gcc 4.8.2 (built with Homebrew) Linux 2.6.35 (Fedora 14) gcc 4.5.1 (x86_64-redhat-linux) - Below are sections I copied from the OpenMP specification (v4.0.0) that look relevant: 2.14.1.1 - Data-sharing Attribute Rules for Variables Referenced in a Construct === Certain variables and objects have predetermined data-sharing attributes as follows: C/C++ - - Objects with dynamic storage duration are shared. - [ nothing specifically mentioning const variables... ] Variables with predetermined data-sharing attributes may not be listed in data-sharing attribute clauses, except for the cases listed below. For these exceptions only, listing a predetermined variable in a data-sharing attribute clause is allowed and overrides the variable's predetermined data-sharing attributes. - [...] - Variables with `const`-qualified type having no mutable member may be listed in a `firstprivate` clause, even if they are static data members. 2.14.3 - Data-Sharing Atribute Clauses == 2.14.3.1 - `default` clause --- The `default` clause explicitly determines the data-sharing attributes of variables that are referenced in a `parallel`, `task` or `teams` construct and would otherwise be implicitly determined. The `default(none)` clause requires that each variable that is referenced in the construct, and that does not have a predetermined data-sharing attribute, must have its data-sharing attribute explicitly determined by being listed in a data-sharing attribute clause. 2.14.3.2 - `shared` clause -- The `shared` clause declares one or more list items to be shared by tasks generated by a `parallel`, `task` or `teams` construct.
[Bug c++/59598] very simple code using file open for read
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59598 Denis Kolesnik changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID |--- --- Comment #19 from Denis Kolesnik --- I do not have errors in my core: other characters processed except '0'. This is a bug!
[Bug c++/59598] very simple code using file open for read
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59598 --- Comment #20 from Denis Kolesnik --- '0' is not 'a' in 2 languages and not 'e' in 2 languages in both: small or capital variants
[Bug c++/59598] very simple code using file open for read
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59598 --- Comment #21 from Denis Kolesnik --- Even all characters, which are numeric are processed except '0'. This is a bug! I do not violate eny C++ rules and I do not receive even any messages while compilation. This is a bug. You can not hide the truth!
[Bug c++/59598] very simple code using file open for read
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59598 --- Comment #22 from Denis Kolesnik --- I know that this is not a place to report programming problems, but I do not see errors in my code
[Bug tree-optimization/59617] New: [vectorizer] ICE in vectorizable_mask_load_store with AVX-512F's gathers enabled.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59617 Bug ID: 59617 Summary: [vectorizer] ICE in vectorizable_mask_load_store with AVX-512F's gathers enabled. Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: kirill.yukhin at intel dot com Created attachment 31529 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31529&action=edit Reproducer Hello, I am going to check in a patch, which will enable AVX-512F new gathers instructions. New gathers are use mask registers (%kN), while vectorizable_mask_load_store asserts mask type to be compatible with operand type. This fails 416.gamess to build with -mavx512f -Ofast. Reproducer attached. Reproduce: $ gfortran -S -Ofast -mavx512f hss2a.fppized.f Back trace: 0xbcfc27 vectorizable_mask_load_store /export/users/kyukhin/gcc/git/gcc/gcc/tree-vect-stmts.c:1901 0xbddf6c vectorizable_call /export/users/kyukhin/gcc/git/gcc/gcc/tree-vect-stmts.c:2172 0xbe1021 vect_transform_stmt(gimple_statement_base*, gimple_stmt_iterator*, bool*, _slp_tree*, _slp_instance*) /export/users/kyukhin/gcc/git/gcc/gcc/tree-vect-stmts.c:7017 0xbe4731 vect_transform_loop(_loop_vec_info*) /export/users/kyukhin/gcc/git/gcc/gcc/tree-vect-loop.c:6046 0xc00838 vectorize_loops() /export/users/kyukhin/gcc/git/gcc/gcc/tree-vectorizer.c:476 I'll check my patch in with disabled gathers, so to enable it - remove `#if 0' in gcc/config/i386/i386.c
[Bug c++/59598] very simple code using file open for read
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59598 Kai Tietz changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||ktietz at gcc dot gnu.org Resolution|--- |INVALID --- Comment #23 from Kai Tietz --- First, don't be so self-righteous. Your program has more then one bug ... for sure you need to learn this language better ... within this code there are at least two major logical failures, and one serious array out-of-bounds access on uninitialized data, and your coding-style is simply poor. The C language isn't Lisp, you don't need that much frames, neither you don't need to repeat within on logical expression the prior expression ... it just makes code unreadable ... anyway I won't tell you your bugs, as I am assuming your are a rooky student trying to learn C and I don't want to destroy the sense of your teachers lesson. So I close this bug as invalid, as it is ...
[Bug c++/59598] very simple code using file open for read
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59598 Kai Tietz changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX --- Comment #27 from Kai Tietz --- .
[Bug c++/59598] very simple code using file open for read
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59598 Kai Tietz changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #25 from Kai Tietz --- It is none.
[Bug c++/59598] very simple code using file open for read
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59598 Denis Kolesnik changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID |--- --- Comment #26 from Denis Kolesnik --- My code has no errors. It is a bug.
[Bug c++/59598] very simple code using file open for read
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59598 Denis Kolesnik changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID |--- --- Comment #24 from Denis Kolesnik --- Mister, I have had tragedies in my life, that is why I do not want to make politica with all. It is a bug and I described why.
[Bug c++/59598] very simple code using file open for read
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59598
Denis Kolesnik changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|WONTFIX |---
--- Comment #28 from Denis Kolesnik ---
commenting gives no change:>
//int spec_symbol[7]={0xAE,0xBB,0xAB,0xA9,0x22,0x2F,0x27};
//int eof_symbol[2]={0x0D,0x0A};
other the only one array is declared fully correct as stated at "C How to
Program" H.M. Deitel Nove University Deitel and Associates P. J. Deitel Deitel
Associates
[Bug c++/59598] very simple code using file open for read
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59598 --- Comment #29 from Denis Kolesnik --- My code style has nothing to do with it. I even do not tell, that I do not fully like the interface of this site!!
[Bug c++/59598] very simple code using file open for read
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59598 --- Comment #30 from Denis Kolesnik --- I use the elements of the array fully correct:> int word_begin_position[3000];
[Bug c++/59598] very simple code using file open for read
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59598 --- Comment #31 from Denis Kolesnik --- Your arguments are based on what?? I argued my arguments!
[Bug c++/59598] very simple code using file open for read
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59598 Kai Tietz changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #32 from Kai Tietz --- (In reply to Denis Kolesnik from comment #29) > My code style has nothing to do with it. I even do not tell, that I do not > fully like the interface of this site!! Well, you coding-style and ability is poor. Believe me. I wasn't referring to those none-used arrays. Think about this if-line in your second sample. It contains the out of bounds access: ... if((character_number >= word_begin_position[word_number]) && (character_number <= word_begin_position[word_number+1]) ) ... What is word_begin_position[word_number+1]??? Imagine you are within the final word in your file. The value at this position isn't initialized and therefore contains random number. Btw here in this line is also one of the logical failures you made. Why your if-condition includes first character of next word? So you mights see, or I fear you won't, that your program has more then one bug and therefore this is a invalid bug-report of gcc.
[Bug c/59618] New: internal compiler error: Killed (program as)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59618 Bug ID: 59618 Summary: internal compiler error: Killed (program as) Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: andrewh at inmarket dot com.au Compiling large file: gcc: internal compiler error: Killed (program as) Tried with gcc-4.6 i386 (Linux Mint 13 32-bit) and then gcc-4.8 (Linux Mint 16 64-bit compile with -m32) Same problem. Source file compiles with gcc-4.7.1 ARM and with mingw32 4.8.1 (Win32) Zip contains: 1/ gccver.txt - the full gcc -v output 2/ i_system.i - the source file preprocessor output 3/ makeout.txt - the full command line and its output
[Bug c/59618] internal compiler error: Killed (program as)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59618 --- Comment #1 from inmarket --- Created attachment 31530 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31530&action=edit All files except i_system.i All files except i_system.i
[Bug c/59618] internal compiler error: Killed (program as)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59618 --- Comment #2 from inmarket --- Created attachment 31531 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31531&action=edit Part 3 of 3 for i_system.i Compressed with 7zip After extraction combine parts with: cat i_system.i-part1 i_system.i-part2 i_system.i-part3 > i_system.i
[Bug c/59618] internal compiler error: Killed (program as)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59618 --- Comment #3 from inmarket --- Created attachment 31532 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31532&action=edit Part 2 of 3 for i_system.i Compressed with 7zip After extraction combine parts with: cat i_system.i-part1 i_system.i-part2 i_system.i-part3 > i_system.i
[Bug c/59618] internal compiler error: Killed (program as)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59618 --- Comment #4 from inmarket --- Created attachment 31533 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31533&action=edit Part 1 of 3 for i_system.i Compressed with 7zip After extraction combine parts with: cat i_system.i-part1 i_system.i-part2 i_system.i-part3 > i_system.i
[Bug c/59619] New: gstaudiotestsrc.c:479:1: error: unrecognizable insn: DEFINE_SQUARE (int16, 32767.0);
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59619 Bug ID: 59619 Summary: gstaudiotestsrc.c:479:1: error: unrecognizable insn: DEFINE_SQUARE (int16, 32767.0); Product: gcc Version: 4.8.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: biergaizi2009 at gmail dot com mips64el-unknown-linux-gnu-gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I../.. -save-temps -march=loongson2f -mplt -Wa,-mfix-loongson2f-nop -pipe -fomit-frame-pointer -mno-branch-likely -pthread -I/usr/include/glib-2.0 -I/usr/lib32/glib-2.0/include -pthread -I/usr/include/gstreamer-0.10 -I/usr/include/glib-2.0 -I/usr/lib32/glib-2.0/include -I/usr/include/libxml2 -DG_THREADS_MANDATORY -DG_DISABLE_CAST_CHECKS -DG_DISABLE_ASSERT -Wall -Wdeclaration-after-statement -Wvla -Wpointer-arith -Wmissing-declarations -Wmissing-prototypes -Wredundant-decls -Wundef -Wwrite-strings -Wformat-nonliteral -Wformat-security -Winit-self -Wmissing-include-dirs -Waddress -Waggregate-return -Wno-multichar -Wnested-externs -pthread -I/usr/include/gstreamer-0.10 -I/usr/include/glib-2.0 -I/usr/lib32/glib-2.0/include -I/usr/include/libxml2 -O2 -march=loongson2f -mplt -Wa,-mfix-loongson2f-nop -pipe -fomit-frame-pointer -mno-branch-likely -c -o libgstaudiotestsrc_la-gstaudiotestsrc.lo `test -f 'gstaudiotestsrc.c' || echo './'`gstaudiotestsrc.c mips64el-unknown-linux-gnu-gcc: warning: -pipe ignored because -save-temps specified gstaudiotestsrc.c: In function ‘gst_audio_test_src_create_square_int16’: gstaudiotestsrc.c:479:1: error: unrecognizable insn: DEFINE_SQUARE (int16, 32767.0); ^ (insn 106 105 107 8 (set (reg:SI 284) (if_then_else:SI (ne:CC (reg:CC 67 $fcc0) (const_int 0 [0])) (reg:SI 249 [ iftmp.184 ]) (reg:SI 251 [ iftmp.184 ]))) -1 (nil)) gstaudiotestsrc.c:479:1: internal compiler error: in extract_insn, at recog.c:2154 Please submit a full bug report, with preprocessed source if appropriate.
[Bug c/59620] New: gstaudiotestsrc.c:479:1: error: unrecognizable insn: DEFINE_SQUARE (int16, 32767.0);
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59620 Bug ID: 59620 Summary: gstaudiotestsrc.c:479:1: error: unrecognizable insn: DEFINE_SQUARE (int16, 32767.0); Product: gcc Version: 4.8.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: biergaizi2009 at gmail dot com mips64el-unknown-linux-gnu-gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I../.. -save-temps -march=loongson2f -mplt -Wa,-mfix-loongson2f-nop -pipe -fomit-frame-pointer -mno-branch-likely -pthread -I/usr/include/glib-2.0 -I/usr/lib32/glib-2.0/include -pthread -I/usr/include/gstreamer-0.10 -I/usr/include/glib-2.0 -I/usr/lib32/glib-2.0/include -I/usr/include/libxml2 -DG_THREADS_MANDATORY -DG_DISABLE_CAST_CHECKS -DG_DISABLE_ASSERT -Wall -Wdeclaration-after-statement -Wvla -Wpointer-arith -Wmissing-declarations -Wmissing-prototypes -Wredundant-decls -Wundef -Wwrite-strings -Wformat-nonliteral -Wformat-security -Winit-self -Wmissing-include-dirs -Waddress -Waggregate-return -Wno-multichar -Wnested-externs -pthread -I/usr/include/gstreamer-0.10 -I/usr/include/glib-2.0 -I/usr/lib32/glib-2.0/include -I/usr/include/libxml2 -O2 -march=loongson2f -mplt -Wa,-mfix-loongson2f-nop -pipe -fomit-frame-pointer -mno-branch-likely -c -o libgstaudiotestsrc_la-gstaudiotestsrc.lo `test -f 'gstaudiotestsrc.c' || echo './'`gstaudiotestsrc.c mips64el-unknown-linux-gnu-gcc: warning: -pipe ignored because -save-temps specified gstaudiotestsrc.c: In function ‘gst_audio_test_src_create_square_int16’: gstaudiotestsrc.c:479:1: error: unrecognizable insn: DEFINE_SQUARE (int16, 32767.0); ^ (insn 106 105 107 8 (set (reg:SI 284) (if_then_else:SI (ne:CC (reg:CC 67 $fcc0) (const_int 0 [0])) (reg:SI 249 [ iftmp.184 ]) (reg:SI 251 [ iftmp.184 ]))) -1 (nil)) gstaudiotestsrc.c:479:1: internal compiler error: in extract_insn, at recog.c:2154 Please submit a full bug report, with preprocessed source if appropriate.
[Bug c/59620] gstaudiotestsrc.c:479:1: error: unrecognizable insn: DEFINE_SQUARE (int16, 32767.0);
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59620 --- Comment #1 from Tom Li --- Created attachment 31534 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31534&action=edit preprocessed source
[Bug c/59620] gstaudiotestsrc.c:479:1: error: unrecognizable insn: DEFINE_SQUARE (int16, 32767.0);
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59620 --- Comment #2 from Tom Li --- Using built-in specs. COLLECT_GCC=/usr/mips64el-unknown-linux-gnu/gcc-bin/4.8.2/gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/mips64el-unknown-linux-gnu/4.8.2/lto-wrapper Target: mips64el-unknown-linux-gnu Configured with: /var/tmp/portage/sys-devel/gcc-4.8.2/work/gcc-4.8.2/configure --prefix=/usr --bindir=/usr/mips64el-unknown-linux-gnu/gcc-bin/4.8.2 --includedir=/usr/lib/gcc/mips64el-unknown-linux-gnu/4.8.2/include --datadir=/usr/share/gcc-data/mips64el-unknown-linux-gnu/4.8.2 --mandir=/usr/share/gcc-data/mips64el-unknown-linux-gnu/4.8.2/man --infodir=/usr/share/gcc-data/mips64el-unknown-linux-gnu/4.8.2/info --with-gxx-include-dir=/usr/lib/gcc/mips64el-unknown-linux-gnu/4.8.2/include/g++-v4 --host=mips64el-unknown-linux-gnu --build=mips64el-unknown-linux-gnu --disable-altivec --disable-fixed-point --without-cloog --disable-lto --enable-nls --without-included-gettext --with-system-zlib --enable-obsolete --disable-werror --enable-secureplt --enable-multilib --enable-libmudflap --disable-libssp --disable-libgomp --with-python-dir=/share/gcc-data/mips64el-unknown-linux-gnu/4.8.2/python --enable-checking=release --disable-libgcj --enable-libstdcxx-time --disable-libquadmath --with-abi=n32 --enable-languages=c,c++ --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.8.2 p1.0, pie-0.5.8' Thread model: posix gcc version 4.8.2 (Gentoo 4.8.2 p1.0, pie-0.5.8)
