Re: Question about simple_return pattern for the GCC ARM backend.
On 2013/12/28 09:31 AM, Yangfei (Felix) wrote: Hi, I think that simple_return standard pattern is useful for the ARM. I mean it should be good for target code performance. But seems this pattern is not there for the GCC ARM backend. Can anyone explain the reason why we don’t need this? Cheers, Fei It does use it. Search for the return_strreturn expand pattern, and the returns code iterator in config/arm/iterators.md. Chung-Lin
Re: Remove spam in GCC mailing list
You want to send a mail to python-dev at python dot org. The spam still exists in gcc-bugs mailing list: http://gcc.gnu.org/ml/gcc-bugs/2013-08/msg00689.html http://gcc.gnu.org/ml/gcc-bugs/2013-08/msg00759.html http://gcc.gnu.org/ml/gcc-bugs/2013-08/msg00776.html http://gcc.gnu.org/ml/gcc-bugs/2013-08/msg01181.html http://gcc.gnu.org/ml/gcc-bugs/2013-08/msg01586.html http://gcc.gnu.org/ml/gcc-bugs/2013-09/msg01513.html http://gcc.gnu.org/ml/gcc-bugs/2013-09/msg01946.html http://gcc.gnu.org/ml/gcc-bugs/2013-09/msg01947.html http://gcc.gnu.org/ml/gcc-bugs/2013-09/msg02011.html There's no reason that the gcc-bugs mailing list can post bug reports directly. Please delete spam messages from gcc-bugs. -- Tae-Wong Seo Korea, Republic of
gcc-4.7-20131228 is now available
Snapshot gcc-4.7-20131228 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.7-20131228/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.7 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_7-branch revision 206233 You'll find: gcc-4.7-20131228.tar.bz2 Complete GCC MD5=5e96611f52dd4a9f1358bf4a5eac3349 SHA1=3f36bfeba2695e12c1bfa5cbcb8303bd62379def Diffs from 4.7-20131221 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.7 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
RE: Remove spam in GCC mailing list
Some background on the below: Google has recently changed its algorithms, and the presence of obvious spam mails pointing to a site now *lower* that site's Google rank. So the same search engine optimization people who created the spams for pay in the first place are now frantically trying to get the spams removed, to keep their clients from suing them. I think gcc is best served by just leaving the spams in the archive, as permanent punishment for the people who paid to wreck the Internet for their own gain. -Original Message- From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of Tae Wong Sent: Saturday, December 28, 2013 3:40 AM To: gcc@gcc.gnu.org Subject: Re: Remove spam in GCC mailing list You want to send a mail to python-dev at python dot org. The spam still exists in gcc-bugs mailing list: http://gcc.gnu.org/ml/gcc-bugs/2013-08/msg00689.html http://gcc.gnu.org/ml/gcc-bugs/2013-08/msg00759.html http://gcc.gnu.org/ml/gcc-bugs/2013-08/msg00776.html http://gcc.gnu.org/ml/gcc-bugs/2013-08/msg01181.html http://gcc.gnu.org/ml/gcc-bugs/2013-08/msg01586.html http://gcc.gnu.org/ml/gcc-bugs/2013-09/msg01513.html http://gcc.gnu.org/ml/gcc-bugs/2013-09/msg01946.html http://gcc.gnu.org/ml/gcc-bugs/2013-09/msg01947.html http://gcc.gnu.org/ml/gcc-bugs/2013-09/msg02011.html There's no reason that the gcc-bugs mailing list can post bug reports directly. Please delete spam messages from gcc-bugs. -- Tae-Wong Seo Korea, Republic of
[Bug c/59615] asm goto output or at least clobbered operands
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59615 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org --- 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 asmwarrior at gmail dot com ---
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 boost/asio.hpp
#include boost/iostreams/filtering_stream.hpp
#include boost/program_options.hpp
#include boost/thread.hpp
#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 boost/asio.hpp, 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 jan.kratochvil at redhat dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID |--- --- Comment #2 from Jan Kratochvil jan.kratochvil at redhat dot com --- 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::vectorint, std::allocatorint ::iterator s/::iterator$// (gdb) p end._M_current._M_current == ((std::__debug::vectorint, std::allocatorint *)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 trippels at gcc dot gnu.org --- 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 ubizjak at gmail dot com ---
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 ubizjak at gmail dot com --- (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 tkoenig at gcc dot gnu.org 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 tkoenig at gcc dot gnu.org --- 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 tkoenig at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|UNCONFIRMED Ever confirmed|1 |0 --- Comment #7 from Thomas Koenig tkoenig at gcc dot gnu.org --- (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 tkoenig at gcc dot gnu.org changed: What|Removed |Added Blocks||58003 --- Comment #4 from Thomas Koenig tkoenig at gcc dot gnu.org --- (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 trippels at gcc dot gnu.org --- Created attachment 31527 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31527action=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 denis.v.koles...@safe-mail.net changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|INVALID |---
--- Comment #14 from Denis Kolesnik denis.v.koles...@safe-mail.net ---
In the following code:
// a small text file filter.c //
#include stdio.h
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 denis.v.koles...@safe-mail.net --- 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 jakub at gcc dot gnu.org --- 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 sch...@linux-m68k.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #16 from Andreas Schwab sch...@linux-m68k.org --- 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 denis.v.koles...@safe-mail.net changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID |--- --- Comment #17 from Denis Kolesnik denis.v.koles...@safe-mail.net --- 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 pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #18 from Andrew Pinski pinskia at gcc dot gnu.org --- 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=31528action=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 denis.v.koles...@safe-mail.net changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID |--- --- Comment #19 from Denis Kolesnik denis.v.koles...@safe-mail.net --- 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 denis.v.koles...@safe-mail.net --- '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 denis.v.koles...@safe-mail.net --- 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 denis.v.koles...@safe-mail.net --- 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=31529action=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 ktietz at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||ktietz at gcc dot gnu.org Resolution|--- |INVALID --- Comment #23 from Kai Tietz ktietz at gcc dot gnu.org --- 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 ktietz at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX --- Comment #27 from Kai Tietz ktietz at gcc dot gnu.org --- .
[Bug c++/59598] very simple code using file open for read
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59598 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #25 from Kai Tietz ktietz at gcc dot gnu.org --- 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 denis.v.koles...@safe-mail.net changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID |--- --- Comment #26 from Denis Kolesnik denis.v.koles...@safe-mail.net --- 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 denis.v.koles...@safe-mail.net changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID |--- --- Comment #24 from Denis Kolesnik denis.v.koles...@safe-mail.net --- 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 denis.v.koles...@safe-mail.net changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|WONTFIX |---
--- Comment #28 from Denis Kolesnik denis.v.koles...@safe-mail.net ---
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 denis.v.koles...@safe-mail.net --- 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 denis.v.koles...@safe-mail.net --- 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 denis.v.koles...@safe-mail.net --- 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 ktietz at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #32 from Kai Tietz ktietz at gcc dot gnu.org --- (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 andrewh at inmarket dot com.au --- Created attachment 31530 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31530action=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 andrewh at inmarket dot com.au --- Created attachment 31531 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31531action=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 andrewh at inmarket dot com.au --- Created attachment 31532 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31532action=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 andrewh at inmarket dot com.au --- Created attachment 31533 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31533action=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 biergaizi2009 at gmail dot com --- Created attachment 31534 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31534action=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 biergaizi2009 at gmail dot com --- 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)
Adjust -fdump-ada-spec after C++ decloning patch
The C++ decloning patch revealed that the -fdump-ada-spec code handling
constructors and destructors was too fragile. This patch revamps it.
Tested on x86_64-suse-linux, applied on the mainline.
2013-12-28 Eric Botcazou ebotca...@adacore.com
c-family/
* c-ada-spec.c (print_constructor): New function.
(print_destructor): Retrieve the origin of the destructor.
(print_ada_declaration): Revamp handling of constructors/destructors.
--
Eric Botcazou
Index: c-family/c-ada-spec.c
===
--- c-family/c-ada-spec.c (revision 206166)
+++ c-family/c-ada-spec.c (working copy)
@@ -2521,20 +2521,34 @@ dump_nested_types (pretty_printer *buffe
TREE_VISITED (t) = 1;
}
+/* Dump in BUFFER constructor spec corresponding to T. */
+
+static void
+print_constructor (pretty_printer *buffer, tree t)
+{
+ tree decl_name = DECL_NAME (DECL_ORIGIN (t));
+
+ pp_string (buffer, New_);
+ pp_ada_tree_identifier (buffer, decl_name, t, false);
+}
+
/* Dump in BUFFER destructor spec corresponding to T. */
static void
print_destructor (pretty_printer *buffer, tree t)
{
- const char *s = IDENTIFIER_POINTER (DECL_NAME (t));
+ tree decl_name = DECL_NAME (DECL_ORIGIN (t));
+ const char *s = IDENTIFIER_POINTER (decl_name);
if (*s == '_')
-for (s += 2; *s != ' '; s++)
- pp_character (buffer, *s);
+{
+ for (s += 2; *s != ' '; s++)
+ pp_character (buffer, *s);
+}
else
{
pp_string (buffer, Delete_);
- pp_ada_tree_identifier (buffer, DECL_NAME (t), t, false);
+ pp_ada_tree_identifier (buffer, decl_name, t, false);
}
}
@@ -2785,7 +2799,7 @@ print_ada_declaration (pretty_printer *b
}
else if (TREE_CODE (t) == FUNCTION_DECL)
{
- bool is_function = true, is_abstract_class = false;
+ bool is_function, is_abstract_class = false;
bool is_method = TREE_CODE (TREE_TYPE (t)) == METHOD_TYPE;
tree decl_name = DECL_NAME (t);
int prev_in_function = in_function;
@@ -2805,24 +2819,21 @@ print_ada_declaration (pretty_printer *b
is_copy_constructor = cpp_check (t, IS_COPY_CONSTRUCTOR);
}
- /* Skip __comp_dtor destructor which is redundant with the '~class()'
- destructor. */
- if (is_destructor
- !strncmp (IDENTIFIER_POINTER (decl_name), __comp, 6))
- return 0;
-
/* Skip copy constructors: some are internal only, and those that are
not cannot be called easily from Ada anyway. */
if (is_copy_constructor)
return 0;
- /* If this function has an entry in the dispatch table, we cannot
- omit it. */
- if (!DECL_VINDEX (t) *IDENTIFIER_POINTER (decl_name) == '_')
+ if (is_constructor || is_destructor)
{
- if (IDENTIFIER_POINTER (decl_name)[1] == '_')
+ /* Only consider constructors/destructors for complete objects. */
+ if (strncmp (IDENTIFIER_POINTER (decl_name), __comp, 6) != 0)
return 0;
+ }
+ /* If this function has an entry in the vtable, we cannot omit it. */
+ else if (!DECL_VINDEX (t) *IDENTIFIER_POINTER (decl_name) == '_')
+ {
INDENT (spc);
pp_string (buffer, -- skipped func );
pp_string (buffer, IDENTIFIER_POINTER (decl_name));
@@ -2832,19 +2843,22 @@ print_ada_declaration (pretty_printer *b
if (need_indent)
INDENT (spc);
- if (is_constructor)
- pp_string (buffer, function New_);
- else if (VOID_TYPE_P (TREE_TYPE (TREE_TYPE (t
+ if (VOID_TYPE_P (TREE_TYPE (TREE_TYPE (t))) !is_constructor)
{
- is_function = false;
pp_string (buffer, procedure );
+ is_function = false;
}
else
- pp_string (buffer, function );
+ {
+ pp_string (buffer, function );
+ is_function = true;
+ }
in_function = is_function;
- if (is_destructor)
+ if (is_constructor)
+ print_constructor (buffer, t);
+ else if (is_destructor)
print_destructor (buffer, t);
else
dump_ada_decl_name (buffer, t, false);
@@ -2856,16 +2870,9 @@ print_ada_declaration (pretty_printer *b
if (is_function)
{
pp_string (buffer, return );
-
- if (is_constructor)
- {
- dump_ada_decl_name (buffer, t, false);
- }
- else
- {
- dump_generic_ada_node
- (buffer, TREE_TYPE (TREE_TYPE (t)), type, spc, false, true);
- }
+ tree ret_type
+ = is_constructor ? DECL_CONTEXT (t) : TREE_TYPE (TREE_TYPE (t));
+ dump_generic_ada_node (buffer, ret_type, type, spc, false, true);
}
if (is_constructor
@@ -2877,7 +2884,7 @@ print_ada_declaration (pretty_printer *b
for (tmp = TYPE_METHODS (type); tmp; tmp = TREE_CHAIN (tmp))
if (cpp_check (tmp, IS_ABSTRACT))
{
- is_abstract_class = 1;
+ is_abstract_class = true;
break;
}
}
@@ -2896,8 +2903,8 @@ print_ada_declaration (pretty_printer *b
if (is_constructor)
{
- pp_string (buffer, pragma CPP_Constructor (New_);
- dump_ada_decl_name (buffer, t, false);
+ pp_string (buffer, pragma
Document -fada-spec-parent
Tested on x86_64-suse-linux, applied on the mainline and 4.8 branch.
2013-12-28 Eric Botcazou ebotca...@adacore.com
* doc/invoke.texi (output file options): Document -fada-spec-parent.
--
Eric Botcazou
Index: doc/invoke.texi
===
--- doc/invoke.texi (revision 206166)
+++ doc/invoke.texi (working copy)
@@ -161,7 +161,7 @@ in the following sections.
-pipe -pass-exit-codes @gol
-x @var{language} -v -### --help@r{[}=@var{class}@r{[},@dots{}@r{]]} --target-help @gol
--version -wrapper @@@var{file} -fplugin=@var{file} -fplugin-arg-@var{name}=@var{arg} @gol
--fdump-ada-spec@r{[}-slim@r{]} -fada-spec-parent=@var{arg} -fdump-go-spec=@var{file}}
+-fdump-ada-spec@r{[}-slim@r{]} -fada-spec-parent=@var{unit} -fdump-go-spec=@var{file}}
@item C Language Options
@xref{C Dialect Options,,Options Controlling C Dialect}.
@@ -1518,10 +1518,15 @@ for the plugin called @var{name}.
@item -fdump-ada-spec@r{[}-slim@r{]}
@opindex fdump-ada-spec
-For C and C++ source and include files, generate corresponding Ada
-specs. @xref{Generating Ada Bindings for C and C++ headers,,, gnat_ugn,
+For C and C++ source and include files, generate corresponding Ada specs.
+@xref{Generating Ada Bindings for C and C++ headers,,, gnat_ugn,
GNAT User's Guide}, which provides detailed documentation on this feature.
+@item -fada-spec-parent=@var{unit}
+@opindex fada-spec-parent
+In conjunction with @option{-fdump-ada-spec@r{[}-slim@r{]}} above, generate
+Ada specs as child units of parent @var{unit}.
+
@item -fdump-go-spec=@var{file}
@opindex fdump-go-spec
For input files in any language, generate corresponding Go
Re: PATCH: PR target/59605: Create jump_around_label only if it doesn't exist
On Thu, Dec 26, 2013 at 06:31:10PM -0800, H.J. Lu wrote: 2013-12-26 H.J. Lu hongjiu...@intel.com PR target/59605 * config/i386/i386.c (ix86_expand_set_or_movmem): Create jump_around_label only if it doesn't exist. gcc/testsuite/ 2013-12-26 H.J. Lu hongjiu...@intel.com PR target/59605 * gcc.dg/pr59605.c: New test. This is ok, thanks. Jakub
libgo patch committed: Work around Solaris oddity
If one thread does a connect to localhost on a non-blocking socket such
that the connect fails with EINPROGRESS, and then another thread accepts
the connection and closes the accepted socket, and then the first thread
does the connect again, that connect should succeed and return a socket
whose other end is closed. For some reason, on Solaris, the second
connect fails with an error of EINVAL, a possibility that is not
documented on the connect man page. This case arises in some of the
libgo testsuite. This patch works around the problem by testing for
this possibility on Solaris. The same patch has been applied to the
master Go repository. Bootstrapped and ran Go testsuite on
x86_64-unknown-linux-gnu, which I admit proves little for a
Solaris-specific patch. I also tested the specific patch on
i386-pc-solaris2.11, where it fixes a testsuite failure. Committed to
mainline and 4.8 branch.
Ian
diff -r 0d4f83bb938b src/pkg/net/fd_unix.go
--- a/src/pkg/net/fd_unix.go Sat Dec 28 20:33:05 2013 +1100
+++ b/src/pkg/net/fd_unix.go Sat Dec 28 09:37:28 2013 -0800
@@ -80,6 +80,16 @@
if err == nil || err == syscall.EISCONN {
break
}
+
+ // On Solaris we can see EINVAL if the socket has
+ // already been accepted and closed by the server.
+ // Treat this as a successful connection--writes to
+ // the socket will see EOF. For details and a test
+ // case in C see http://golang.org/issue/6828.
+ if runtime.GOOS == solaris err == syscall.EINVAL {
+ break
+ }
+
if err != syscall.EINPROGRESS err != syscall.EALREADY err != syscall.EINTR {
return err
}
Re: [PATCH i386 7/8] [AVX-512] Add tests.
Hello, On 18 Dec 17:08, Uros Bizjak wrote: Whoa. --- a/gcc/config/i386/sse.md +++ b/gcc/config/i386/sse.md No, not in this patch. Okay, moved it to 5/8 patch. -- Thanks, K
[Patch, i386] Separate Intel processor with expanded ISA
The function dispatcher might currently choose functions declared with target(arch=ivybridge) on a Sandy Bridge CPU. This happens because the function is only detected as sandybridge when generated. The attached patch detects Westmere, Ivybridge and Broadwell processors based on new ISAs they support. Regards `Allan Index: gcc/ChangeLog === --- gcc/ChangeLog (revision 206233) +++ gcc/ChangeLog (working copy) @@ -1,3 +1,9 @@ +2013-12-29 Allan Sandfeld Jensen sandf...@kde.org + + * config/i386/i386.c (get_builtin_code_for_version): Separate + Westmere from Nehalem, Ivy Bridge from Sandy Bridge and + Broadwell from Haswell. + 2013-12-28 Eric Botcazou ebotca...@adacore.com * doc/invoke.texi (output file options): Document -fada-spec-parent. Index: gcc/config/i386/i386.c === --- gcc/config/i386/i386.c (revision 206233) +++ gcc/config/i386/i386.c (working copy) @@ -30030,18 +30005,27 @@ priority = P_PROC_SSSE3; break; case PROCESSOR_NEHALEM: - /* We translate arch=corei7 and arch=nehelam to - corei7 so that it will be mapped to M_INTEL_COREI7 - as cpu type to cover all M_INTEL_COREI7_XXXs. */ - arg_str = corei7; + if (new_target-x_ix86_isa_flags OPTION_MASK_ISA_AES) + arg_str = westmere; + else + /* We translate arch=corei7 and arch=nehelam to + corei7 so that it will be mapped to M_INTEL_COREI7 + as cpu type to cover all M_INTEL_COREI7_XXXs. */ + arg_str = corei7; priority = P_PROC_SSE4_2; break; case PROCESSOR_SANDYBRIDGE: - arg_str = sandybridge; + if (new_target-x_ix86_isa_flags OPTION_MASK_ISA_F16C) + arg_str = ivybridge; + else + arg_str = sandybridge; priority = P_PROC_AVX; break; case PROCESSOR_HASWELL: - arg_str = haswell; + if (new_target-x_ix86_isa_flags OPTION_MASK_ISA_ADX) + arg_str = broadwell; + else + arg_str = haswell; priority = P_PROC_AVX2; break; case PROCESSOR_BONNELL:
