Re: Is this a compiler bug?
On Sun, Sep 21, 2014 at 7:49 PM, Ed Smith-Rowland 3dw...@verizon.net wrote: On 09/21/2014 09:56 PM, Steve Kargl wrote: + is a binary operator. 0x3ffe is a hexidecimal-constant according to 6.6.4.1 in n1256.pdf. 63 is, of course, a decimal-constant. Also, a hex floating point uses p as an exponent for this reason... These should just be adding integers. i = 0x3ffe+63; /* integral */ i = 0x3ffp+63; /* floating point */ Post the PR. I did a lot of stuff in this area for C++11 user-defined literals. I either caused it of I might be able to help. 6.4.8 is what matters here. pp-number is defined as: pp-number e sign pp-number E sign pp-number identifier-nondigit And /3 says: Preprocessing number tokens lexically include all floating and integer constant tokens. And /4 says: A preprocessing number does not have type or a value; it acquires both after a successful conversion (as part of translation phase 7) to a floating constant token or an integer constant token. So we have 0x3ffe+63 as one token (a pp-number) but it is not a successive token to either a floating point token or an integer constant token so it is rejected. Thanks, Andrew Pinski Ed
Re: [gomp4] openacc kernels directive support
On Tue, 16 Sep 2014, Tom de Vries wrote: On 09-09-14 12:56, Richard Biener wrote: On Tue, 9 Sep 2014, Tom de Vries wrote: On 18-08-14 14:16, Tom de Vries wrote: On 06-08-14 17:10, Tom de Vries wrote: We could insert a pass-group here that only deals with functions that have the kernels directive, and do the auto-par thing in a pass_oacc_kernels (which should share the majority of the infrastructure with the parloops pass): ... NEXT_PASS (pass_build_ealias); INSERT_PASSES_AFTER/WITHIN (passes_oacc_kernels) NEXT_PASS (pass_ch); NEXT_PASS (pass_ccp); NEXT_PASS (pass_lim_aux); NEXT_PASS (pass_oacc_par); POP_INSERT_PASSES () ... Any comments, ideas or suggestions ? I've experimented with implementing this on top of gomp-4_0-branch, and I ran into PR46032. PR46032 is about vectorization failure on a function split off by omp parallelization. The vectorization fails due to aliasing constraints in the split off function, which are not present in the original code. Heh. At least the omp-low.c parts from comment #1 should be pushed to trunk... Hi Richard, Right, but the intra_create_variable_infos part does not apply cleanly, and I don't know yet how to resolve that. In the gomp-4_0-branch, the code marked by the openacc kernels directive is split off during omp_expand. The generated code has the same additional aliasing constraints, and in pass_oacc_par the parallelization fails. The PR46032 contains a tentative patch by Richard Biener, which applies cleanly on top of 4.6 (I haven't yet reached a level of understanding of tree-ssa-structalias.c to be able to resolve the conflict in intra_create_variable_infos when applying on 4.7). The tentative patch involves running ipa-pta, which is also a pass run after the point where we write out the lto stream. I'm not sure whether it makes sense to run the pta-ipa pass as part of the pass_oacc_kernels pass list. No, that's not even possible I think. OK, thanks for confirming that. I see three ways of continuing from here: - take the tentative patch and make it work, including running pta-ipa during passes_oacc_kernels - same, but try somehow to manage without running pta-ipa. - try to postpone splitting of the function until the end of pass_oacc_par. I don't understand the last option? What is the actual issue you run into? You split oacc kernels off and _then_ run autopar on the split-off function (and get additional kernels)? Let me try to reiterate the problem in more detail. We're trying to implement the auto-parallelization part of the oacc kernels directive using the existing parloops pass. The source starting point is the gomp-4_0-branch. The gomp-4_0-branch has a dummy implementation of the oacc kernels directive, analogous to the oacc parallel directive. So the current gomp-4_0-branch does the following steps for oacc parallel/kernels directives: 1. pass_lower_omp/scan_omp: - create record type with rewrite vars (.omp_data_t). - declare function with arg with type pointer to .omp_data_t. 2. pass_lower_omp/lower_omp: - rewrite region in terms of rewrite vars - add omp_return at end 3. pass_expand_omp: - split off the region into a separate function - replace region with call to GOACC_parallel/GOACC_kernels, with function pointer as argument I wrote an example with a single oacc kernels region containing a simple vector addition loop, and tried to make auto-parallelization work. Ah, so the target OACC directive tells it to vectorize only, not to parallelize? And we split off the kernel only because we have to ship it to the accelerator. The first problem I ran into was that the parloops pass failed to analyze the dependencies in an vector addition example, due to the fact that the region was already split off into a separate function, similar to PR46032. I looked briefly into the patches set in PR46032, but I realized that even if I fix it, the next problem I run into will be that the parloops pass is run after the lto stream read/write point. So any changes the parloops pass makes at that point are in the accelerator compile flow, in other words we're talking about launching an accelerator kernel from the accelerator. While that is possible with recent cuda accelerators, I guess in general we should not expect that to be possible. HSA also supports that btw. [ I also thought of a fancy scheme where we don't split off a new function, but manipulate the body of the already split off function, and emit a c file from the accelerator compiler containing the parameters that the host compiler should use to
Re: LTO testsuite - single test execution
On Thu, Sep 18, 2014 at 11:17 PM, Martin Liška mli...@suse.cz wrote: Hello. I would to introduce a new test case for an issue (PR63270). I was looking for *.exp files and I expected that another test located in: ./gcc/testsuite/g++.dg/lto/pr63166_0.ii can be executed with: make check -k RUNTESTFLAGS=lto.exp=pr63166* inside gcc/ make check-g++ RUNTESTFLAGS=lto.exp=pr63166_0.C would work for me. Note that .exp files usually glob by extension and .ii is surely not handled. But without succeed. Another interesting issue is running: 'make check-lto', where I was given: make: *** No rule to make target `check-lto'. Stop. Can you please help my with a LTO test integration? Thanks, Martin
Listing a maintainer for libcilkrts, and GCC's Cilk Plus implementation generally?
Hi! As has been noted before, http://news.gmane.org/find-root.php?message_id=%3Cyddhabgief1.fsf%40lokon.CeBiTec.Uni-Bielefeld.DE%3E, GCC's MAINTAINERS file does not list a maintainer for libcilkrts, or GCC's Cilk Plus implementation generally. Shouldn't it? I regularely consult this file when reporting issues in specific parts of the GCC code base. Grüße, Thomas pgpP58O2AB4qz.pgp Description: PGP signature
Re: Is this a compiler bug?
On Sun, 2014-09-21 at 22:15 -0700, Andrew Pinski wrote: On Sun, Sep 21, 2014 at 8:08 PM, Steve Kargl s...@troutmask.apl.washington.edu wrote: On Sun, Sep 21, 2014 at 07:57:45PM -0700, Andrew Pinski wrote: On Sun, Sep 21, 2014 at 6:56 PM, Steve Kargl s...@troutmask.apl.washington.edu wrote: + is a binary operator. 0x3ffe is a hexidecimal-constant according to 6.6.4.1 in n1256.pdf. 63 is, of course, a decimal-constant. This is before tokens happen and during lexing of the program. e+64 is exponent-part see 6.4.4.2. 6.4.4.2 applies to floating point constant. 6.4.4.1 is for integer constants. Nope again, this time from bug 3885: Strange as it may seem, the behavior is correct, and mandated by the C Standard. 0x00E-0x00A is a single preprocessor token, of type pp-number, and it must become a single compiler token, but it can't. The gotcha is the `E-' sequence, that makes it seem like the exponent notation of floating-point constants. Looks like this is a common misunderstood part of C. If people tend to get this wrong, should we issue a warning for it?
Re: Is this a compiler bug?
On Sun, Sep 21, 2014 at 10:15:01PM -0700, Andrew Pinski wrote: On Sun, Sep 21, 2014 at 8:08 PM, Steve Kargl s...@troutmask.apl.washington.edu wrote: On Sun, Sep 21, 2014 at 07:57:45PM -0700, Andrew Pinski wrote: On Sun, Sep 21, 2014 at 6:56 PM, Steve Kargl s...@troutmask.apl.washington.edu wrote: + is a binary operator. 0x3ffe is a hexidecimal-constant according to 6.6.4.1 in n1256.pdf. 63 is, of course, a decimal-constant. This is before tokens happen and during lexing of the program. e+64 is exponent-part see 6.4.4.2. 6.4.4.2 applies to floating point constant. 6.4.4.1 is for integer constants. Nope again, this time from bug 3885: Strange as it may seem, the behavior is correct, and mandated by the C Standard. 0x00E-0x00A is a single preprocessor token, of type pp-number, and it must become a single compiler token, but it can't. The gotcha is the `E-' sequence, that makes it seem like the exponent notation of floating-point constants. Looks like this is a common misunderstood part of C. Looks like a defect in the C standard. -- Steve
Re: Is this a compiler bug?
On Mon, Sep 22, 2014 at 10:22:59AM -0400, David Malcolm wrote: On Sun, 2014-09-21 at 22:15 -0700, Andrew Pinski wrote: On Sun, Sep 21, 2014 at 8:08 PM, Steve Kargl s...@troutmask.apl.washington.edu wrote: On Sun, Sep 21, 2014 at 07:57:45PM -0700, Andrew Pinski wrote: On Sun, Sep 21, 2014 at 6:56 PM, Steve Kargl s...@troutmask.apl.washington.edu wrote: + is a binary operator. 0x3ffe is a hexidecimal-constant according to 6.6.4.1 in n1256.pdf. 63 is, of course, a decimal-constant. This is before tokens happen and during lexing of the program. e+64 is exponent-part see 6.4.4.2. 6.4.4.2 applies to floating point constant. 6.4.4.1 is for integer constants. Nope again, this time from bug 3885: Strange as it may seem, the behavior is correct, and mandated by the C Standard. 0x00E-0x00A is a single preprocessor token, of type pp-number, and it must become a single compiler token, but it can't. The gotcha is the `E-' sequence, that makes it seem like the exponent notation of floating-point constants. Looks like this is a common misunderstood part of C. If people tend to get this wrong, should we issue a warning for it? We already diagnose it, with an error actually, not warning: error: invalid suffix +63 on integer constant etc. Just apparently people are surprised when the compiler diagnoses it. So perhaps some extra note explaining it (== hint how to fix that). Jakub
Re: Is this a compiler bug?
This aspect of pp-numbers is mentioned in the manual (trouble.texi) because of the confusion it causes. -- Joseph S. Myers jos...@codesourcery.com
Make name+email address cut'n'paste-able (was: Listing a maintainer for libcilkrts, and GCC's Cilk Plus implementation generally?)
On Mon, 2014-09-22 16:06:21 +0200, Thomas Schwinge tho...@codesourcery.com wrote: As has been noted before, http://news.gmane.org/find-root.php?message_id=%3Cyddhabgief1.fsf%40lokon.CeBiTec.Uni-Bielefeld.DE%3E, GCC's MAINTAINERS file does not list a maintainer for libcilkrts, or GCC's Cilk Plus implementation generally. Shouldn't it? I regularely consult this file when reporting issues in specific parts of the GCC code base. While we're at it... I consult that file as well, even quite often for preparing Build Robot emails. There's another usability enhancement: I'd like to propose to put all email addresses between '' and '', which would quite ease cut'n'past-ability. What's your oppinion on that? Should I prepare a patch? MfG, JBG -- Jan-Benedict Glaw jbg...@lug-owl.de +49-172-7608481 Signature of: The course of history shows that as a government grows, liberty the second : decreases. (Thomas Jefferson) signature.asc Description: Digital signature
Re: Implementing OpenACC's Fortran module
Hi Tobias!
On Sat, 20 Sep 2014 13:51:58 +0200, Tobias Burnus bur...@net-b.de wrote:
On 19.09.2014 11:03, Thomas Schwinge wrote:
Regarding linking the object file produced by Fortran openacc.f90 into
libgomp: (with the version that Jim already has internally checked in)
I find that libgomp then has undefined references to
_gfortran_internal_unpack and _gfortran_internal_pack.
Internal pack and unpack appears when you a (potentially) noncontiguous
array is passed as argument to an argument which requires a contiguous
argument. Internal pack checks at run time whether the argument is
contiguous - and if not it creates a temporary and copies the data to
the temporary ('copy in') - internal unpack ensures for all arrays but
intent(in) that the data is propagated back to the original one.
Thanks for the explanation.
I am pretty sure that copy-in will break the OpenACC functions.
One possibility would be to mark the dummy arguments in openacc.f90 as
CONTIGUOUS. That way, no internal pack/unpack is called by openacc.f90.
(If one has a noncontiguous array, the caller of openacc.f90 will do the
copy in/out.)
Thus, you could try to add , contiguous to all procedures which take
an assumed-rank array (..) as argument.
That works. For avoidance of doubt: just tag to the actual
implementation (which is enough to avoid the references to
_gfortran_internal_unpack and _gfortran_internal_pack), or also the
interfaces, as detailed in the following pseudo patch:
[openacc.f90]
module openacc_internal
use openacc_kinds
implicit none
interface
subroutine acc_delete_32_h (a, len)
use iso_c_binding, only: c_int32_t, c_size_t
!GCC$ ATTRIBUTES NO_ARG_CHECK :: a
type(*), dimension(*) :: a
integer(c_int32_t) len
end subroutine
subroutine acc_delete_64_h (a, len)
use iso_c_binding, only: c_int64_t, c_size_t
!GCC$ ATTRIBUTES NO_ARG_CHECK :: a
type(*), dimension(*) :: a
integer(c_int64_t) len
end subroutine
subroutine acc_delete_array_h (a)
use iso_c_binding, only: c_size_t
- type(*), dimension(..) :: a
+ type(*), dimension(..), contiguous :: a
end subroutine
end interface
interface
subroutine acc_delete_l (a, len)
bind(C, name=acc_delete)
use iso_c_binding, only: c_size_t
!GCC$ ATTRIBUTES NO_ARG_CHECK :: a
type(*), dimension(*) :: a
integer(c_size_t), value :: len
end subroutine
end interface
end module
module openacc
use openacc_kinds
use openacc_internal
interface acc_delete
procedure :: acc_delete_32_h
procedure :: acc_delete_64_h
procedure :: acc_delete_array_h
end interface
end module
subroutine acc_delete_32_h (a, len)
use iso_c_binding, only: c_int32_t, c_size_t
use openacc_internal, only: acc_delete_l
!GCC$ ATTRIBUTES NO_ARG_CHECK :: a
type(*), dimension(*) :: a
integer(c_int32_t) len
call acc_delete_l (a, int (len, kind=c_size_t))
end subroutine
subroutine acc_delete_64_h (a, len)
use iso_c_binding, only: c_int64_t, c_size_t
use openacc_internal, only: acc_delete_l
!GCC$ ATTRIBUTES NO_ARG_CHECK :: a
type(*), dimension(*) :: a
integer(c_int64_t) len
call acc_delete_l (a, int (len, kind=c_size_t))
end subroutine
subroutine acc_delete_array_h (a)
use iso_c_binding, only: c_size_t
use openacc_internal, only: acc_delete_l
- type(*), dimension(..) :: a
+ type(*), dimension(..), contiguous :: a
call acc_delete_l (a, sizeof (a))
end subroutine
[openacc_lib.h]
interface acc_delete
subroutine acc_delete_32_h (a, len)
use iso_c_binding, only: c_int32_t
!GCC$ ATTRIBUTES NO_ARG_CHECK :: a
type(*), dimension(*) :: a
integer(c_int32_t) len
end subroutine
subroutine acc_delete_64_h (a, len)
use iso_c_binding, only: c_int64_t
!GCC$ ATTRIBUTES NO_ARG_CHECK :: a
type(*), dimension(*) :: a
integer(c_int64_t) len
end subroutine
subroutine acc_delete_array_h (a)
- class(*), dimension(..) :: a
+ class(*), dimension(..), contiguous :: a
end subroutine
end interface
Grüße,
Thomas
pgpYDfNt3QQpL.pgp
Description: PGP signature
Re: [PATCH] gcc parallel make check
On 09/12/2014 08:04 PM, Jakub Jelinek wrote:
I've been worried about the quick cases where
parallelization is not beneficial, like make check-gcc \
RUNTESTFLAGS=dg.exp=pr60123.c or similar, but one doesn't usually pass -jN
in that case.
I have -jN in my $MAKEFLAGS, so I've been running into this with my rgt
shell function:
rgt ()
{
( cd ~/m/$CANON/gcc/gcc;
make check-c++ ${1:+RUNTESTFLAGS=$*} )
}
If I say 'rgt dg.exp=var-templ1.C' the actual test results are lost in
the explosion of shell verbosity. Could we add some '@'s to more of the
rules, perhaps?
Jason
Re: [PATCH] gcc parallel make check
On Mon, Sep 22, 2014 at 11:21:14AM -0400, Jason Merrill wrote:
On 09/12/2014 08:04 PM, Jakub Jelinek wrote:
I've been worried about the quick cases where
parallelization is not beneficial, like make check-gcc \
RUNTESTFLAGS=dg.exp=pr60123.c or similar, but one doesn't usually pass -jN
in that case.
I have -jN in my $MAKEFLAGS, so I've been running into this with my rgt
shell function:
rgt ()
{
( cd ~/m/$CANON/gcc/gcc;
make check-c++ ${1:+RUNTESTFLAGS=$*} )
}
If I say 'rgt dg.exp=var-templ1.C' the actual test results are lost in the
explosion of shell verbosity. Could we add some '@'s to more of the rules,
perhaps?
I've been considering that too, but not sure what info people find valuable
and what they don't.
Jakub
Re: Implementing OpenACC's Fortran module
On 22.09.2014 17:17, Thomas Schwinge wrote: That works. For avoidance of doubt: just tag to the actual implementation (which is enough to avoid the references to _gfortran_internal_unpack and _gfortran_internal_pack), or also the interfaces, as detailed in the following pseudo patch: Well, the standard mandates that those match, thus, I think one should do it. If one passes a noncontiguous array to a CONTIGUOUS dummy argument, the caller ensures that the argument is truly packed by creating a temporary and packing it, iff it is not contiguous. (If it is known at compile time that the array is contiguous, no run-time test is inserted.) The idea is to avoid wrong code, if one passes something noncontiguous. Hence, the caller has to see the attribute - and if it only sees the interface block and not the function itself, it must be in the interface block. In case of OpenACC, the OpenACC semantics require that the argument is contiguous. If users gets it wrong, it will be wrong either way: If the variable is not packed and when it is packed (and the temporary removed after the function call). Tobias
Re: Implementing OpenACC's Fortran module
On 22.09.2014 17:31, Tobias Burnus wrote: In case of OpenACC, the OpenACC semantics require that the argument is contiguous. If users gets it wrong, it will be wrong either way: If the variable is not packed and when it is packed (and the temporary removed after the function call). Post script: Actually, in some cases, the copy-in/copy-out using a temporary will actually work: Namely, if one only needs to transfer the memory once, such that the pointer address does not matter (e.g. only acc_copyin w/o later copyout or update). Thus, while copy-in/out with a temporary is bad, passing the unpacked array is worse as it will also use the wrong values in this special case. – That's another argument for using CONTIGUOUS also in the INTERFACE block. Tobias
Re: [PATCH] gcc parallel make check
On 09/22/2014 11:26 AM, Jakub Jelinek wrote:
On Mon, Sep 22, 2014 at 11:21:14AM -0400, Jason Merrill wrote:
If I say 'rgt dg.exp=var-templ1.C' the actual test results are lost in the
explosion of shell verbosity. Could we add some '@'s to more of the rules,
perhaps?
I've been considering that too, but not sure what info people find valuable
and what they don't.
I don't see much information in the ~128 repetitions of the
check-parallel rules with different numbers; the actual runtest command
is the same in all of them. Adding @ to all of the commands of the
check-parallel-% rule makes things much better for me:
diff --git a/gcc/Makefile.in b/gcc/Makefile.in
index 6f251a5..be4c840 100644
--- a/gcc/Makefile.in
+++ b/gcc/Makefile.in
@@ -3674,10 +3674,10 @@ $(lang_checks_parallelized): check-% : site.exp
fi
check-parallel-% : site.exp
- -test -d plugin || mkdir plugin
- -test -d $(TESTSUITEDIR) || mkdir $(TESTSUITEDIR)
- test -d $(TESTSUITEDIR)/$(check_p_subdir) || mkdir $(TESTSUITEDIR)/$(check_p_subdir)
- -(rootme=`${PWD_COMMAND}`; export rootme; \
+ -@test -d plugin || mkdir plugin
+ -@test -d $(TESTSUITEDIR) || mkdir $(TESTSUITEDIR)
+ @test -d $(TESTSUITEDIR)/$(check_p_subdir) || mkdir $(TESTSUITEDIR)/$(check_p_subdir)
+ -@(rootme=`${PWD_COMMAND}`; export rootme; \
srcdir=`cd ${srcdir}; ${PWD_COMMAND}` ; export srcdir ; \
if [ -n $(check_p_subno) ] \
[ -n $$GCC_RUNTEST_PARALLELIZE_DIR ] \
Re: [PATCH] gcc parallel make check
On Mon, Sep 22, 2014 at 05:26:04PM +0200, Jakub Jelinek wrote: I've been considering that too, but not sure what info people find valuable and what they don't. The ten million Running blablablalba.exp ... messages on a very parallel run aren't helpful in my opinion. There might be more but that drowns out everything else :-) Segher
Inserting global variable daclaration
Hi, I was trying to insert a global variable declaration using gcc plugins.
I tried to make simple plugin example that inserts a global int variable called
_fake_var_.
The plugin code is this:
plugin.cpp --
int plugin_is_GPL_compatible;
static tree fake_var = NULL;
static void start_unit_callback (void *gcc_data, void *user_data)
{
printf(\n--Start Unit--\n);
fake_var = build_decl (UNKNOWN_LOCATION, VAR_DECL,
get_identifier (_fake_var_),
integer_type_node);
TREE_PUBLIC (fake_var) = 1;
DECL_ARTIFICIAL (fake_var) = 1;
TREE_USED(fake_var) = 1;
}
int plugin_init (struct plugin_name_args *plugin_info,
struct plugin_gcc_version *version)
{
register_callback (start_unit, PLUGIN_START_UNIT,
start_unit_callback, NULL);
return 0;
}
--
Then i compiled the next code(test.c) using that plugin:
test.c --
int main(void) {
_fake_var_=2;
return 0;
}
---
But i get this message:
error: ‘_fake_var_’ was not declared in this scope _fake_var_=2;
The question is that if I'm missing something here and if there is
something wrong, because i didn't find further documentation about how
to do this.
Andrés.
Re: [PATCH] gcc parallel make check
On Mon, Sep 22, 2014 at 10:44:06AM -0500, Segher Boessenkool wrote: On Mon, Sep 22, 2014 at 05:26:04PM +0200, Jakub Jelinek wrote: I've been considering that too, but not sure what info people find valuable and what they don't. The ten million Running blablablalba.exp ... messages on a very parallel run aren't helpful in my opinion. There might be more but that drowns out everything else :-) It has some value, it shows the actual progress. Sure, you can just watch the *.log files as they are populated and get better picture. I think the Running *.exp messages go from dejagnu, not from gcc testsuite changes. Jakub
-Wstack-usage and alloca in loops
For the following translation unit:
#include stdlib.h
int
foo (unsigned n)
{
int *p;
if (n 1024)
p = alloca (n * sizeof (int));
else
p = malloc (n * sizeof (int));
return g (p, n);
}
int
bar (unsigned n)
{
int x, i, *p;
for (x = 0, i = 0; i n; i++)
{
if (n 1024)
p = alloca (n * sizeof (int));
else
p = malloc (n * sizeof (int));
x += h (p, n);
if (n = 1024)
free (p);
}
return x;
}
compiling with -Wstack-usage=32 produces (as of 4.9.1):
test.c: In function 'foo':
test.c:14:1: warning: stack usage might be unbounded [-Wstack-usage=]
}
^
test.c: In function 'bar':
test.c:35:1: warning: stack usage might be unbounded [-Wstack-usage=]
}
^
1) I'm just curious why it's unbounded for foo(). It shouldn't be too
hard to find that alloca() is never requested to allocate more than
1024 * sizeof (int), and never called more than once, isn't it?
2) In bar(), stack usage is unbounded unless bar() is always inline with
a compile-time constant argument N.
IIUC good detection of 2) is much harder to implement, but is it
reasonable/possible to make -Wstack-usage more accurate in 1)?
Dmitry
Re: [PATCH] gcc parallel make check
On Mon, Sep 22, 2014 at 11:43:35AM -0400, Jason Merrill wrote:
On 09/22/2014 11:26 AM, Jakub Jelinek wrote:
On Mon, Sep 22, 2014 at 11:21:14AM -0400, Jason Merrill wrote:
If I say 'rgt dg.exp=var-templ1.C' the actual test results are lost in the
explosion of shell verbosity. Could we add some '@'s to more of the rules,
perhaps?
I've been considering that too, but not sure what info people find valuable
and what they don't.
I don't see much information in the ~128 repetitions of the check-parallel
rules with different numbers; the actual runtest command is the same in all
of them. Adding @ to all of the commands of the check-parallel-% rule makes
things much better for me:
LGTM (though, supposedly we want similar change in
libstdc++-v3/testsuite/Makefile.am).
Or, if people would really like to see the commands, we could print them
just once, using e.g.
-$(if $(check_p_subno),@)(rootme= ...
(then e.g. check-parallel-gcc goal would print the command, but
check-parallel-gcc-1 or check-parallel-gcc-112 would not).
--- a/gcc/Makefile.in
+++ b/gcc/Makefile.in
@@ -3674,10 +3674,10 @@ $(lang_checks_parallelized): check-% : site.exp
fi
check-parallel-% : site.exp
- -test -d plugin || mkdir plugin
- -test -d $(TESTSUITEDIR) || mkdir $(TESTSUITEDIR)
- test -d $(TESTSUITEDIR)/$(check_p_subdir) || mkdir
$(TESTSUITEDIR)/$(check_p_subdir)
- -(rootme=`${PWD_COMMAND}`; export rootme; \
+ -@test -d plugin || mkdir plugin
+ -@test -d $(TESTSUITEDIR) || mkdir $(TESTSUITEDIR)
+ @test -d $(TESTSUITEDIR)/$(check_p_subdir) || mkdir
$(TESTSUITEDIR)/$(check_p_subdir)
+ -@(rootme=`${PWD_COMMAND}`; export rootme; \
srcdir=`cd ${srcdir}; ${PWD_COMMAND}` ; export srcdir ; \
if [ -n $(check_p_subno) ] \
[ -n $$GCC_RUNTEST_PARALLELIZE_DIR ] \
Jakub
Re: [PATCH] gcc parallel make check
On Mon, Sep 22, 2014 at 05:49:12PM +0200, Jakub Jelinek wrote: On Mon, Sep 22, 2014 at 10:44:06AM -0500, Segher Boessenkool wrote: On Mon, Sep 22, 2014 at 05:26:04PM +0200, Jakub Jelinek wrote: I've been considering that too, but not sure what info people find valuable and what they don't. The ten million Running blablablalba.exp ... messages on a very parallel run aren't helpful in my opinion. There might be more but that drowns out everything else :-) It has some value, it shows the actual progress. Sure, you can just watch the *.log files as they are populated and get better picture. I think the Running *.exp messages go from dejagnu, not from gcc testsuite changes. Hrm. Looking at the log files it seems there are not more of those messages at all since the changes. Maybe it just all got too fast! :-) Segher
Re: [PATCH] gcc parallel make check
On 09/22/2014 11:58 AM, Jakub Jelinek wrote:
LGTM (though, supposedly we want similar change in
libstdc++-v3/testsuite/Makefile.am).
Or, if people would really like to see the commands, we could print them
just once, using e.g.
-$(if $(check_p_subno),@)(rootme= ...
(then e.g. check-parallel-gcc goal would print the command, but
check-parallel-gcc-1 or check-parallel-gcc-112 would not).
So, like this?
commit c750897381a3f936e27cabd825cfa85ce936a6a9
Author: Jason Merrill ja...@redhat.com
Date: Mon Sep 22 11:44:00 2014 -0400
gcc/
* Makefile.in (check-parallel-%): Add @.
libstdc++-v3/
* testsuite/Makefile.am (%/site.exp): Add @.
(check-DEJAGNU): Likewise.
* testsuite/Makefile.in: Regenerate.
diff --git a/gcc/Makefile.in b/gcc/Makefile.in
index 6f251a5..97b439a 100644
--- a/gcc/Makefile.in
+++ b/gcc/Makefile.in
@@ -3674,10 +3674,10 @@ $(lang_checks_parallelized): check-% : site.exp
fi
check-parallel-% : site.exp
- -test -d plugin || mkdir plugin
- -test -d $(TESTSUITEDIR) || mkdir $(TESTSUITEDIR)
- test -d $(TESTSUITEDIR)/$(check_p_subdir) || mkdir $(TESTSUITEDIR)/$(check_p_subdir)
- -(rootme=`${PWD_COMMAND}`; export rootme; \
+ -@test -d plugin || mkdir plugin
+ -@test -d $(TESTSUITEDIR) || mkdir $(TESTSUITEDIR)
+ @test -d $(TESTSUITEDIR)/$(check_p_subdir) || mkdir $(TESTSUITEDIR)/$(check_p_subdir)
+ -$(if $(check_p_subno),@)(rootme=`${PWD_COMMAND}`; export rootme; \
srcdir=`cd ${srcdir}; ${PWD_COMMAND}` ; export srcdir ; \
if [ -n $(check_p_subno) ] \
[ -n $$GCC_RUNTEST_PARALLELIZE_DIR ] \
diff --git a/libstdc++-v3/testsuite/Makefile.am b/libstdc++-v3/testsuite/Makefile.am
index e206aba..b4c9e85 100644
--- a/libstdc++-v3/testsuite/Makefile.am
+++ b/libstdc++-v3/testsuite/Makefile.am
@@ -91,9 +91,9 @@ new-abi-baseline:
${extract_symvers} ../src/.libs/libstdc++.so $${output})
%/site.exp: site.exp
- -test -d $* || mkdir $*
+ -@test -d $* || mkdir $*
@srcdir=`cd $(srcdir); ${PWD_COMMAND}`;
- objdir=`${PWD_COMMAND}`/$*; \
+ @objdir=`${PWD_COMMAND}`/$*; \
sed -e s|^set srcdir .*$$|set srcdir $$srcdir| \
-e s|^set objdir .*$$|set objdir $$objdir| \
site.exp $*/site.exp.tmp
@@ -115,7 +115,7 @@ $(check_DEJAGNU_normal_targets): check-DEJAGNUnormal%: normal%/site.exp
# Run the testsuite in normal mode.
check-DEJAGNU $(check_DEJAGNU_normal_targets): check-DEJAGNU%: site.exp
- AR=$(AR); export AR; \
+ $(if $*,@)AR=$(AR); export AR; \
RANLIB=$(RANLIB); export RANLIB; \
if [ -z $* ] [ $(filter -j, $(MFLAGS)) = -j ]; then \
rm -rf normal-parallel || true; \
diff --git a/libstdc++-v3/testsuite/Makefile.in b/libstdc++-v3/testsuite/Makefile.in
index 59060b8..0fc26f4 100644
--- a/libstdc++-v3/testsuite/Makefile.in
+++ b/libstdc++-v3/testsuite/Makefile.in
@@ -553,9 +553,9 @@ new-abi-baseline:
${extract_symvers} ../src/.libs/libstdc++.so $${output})
%/site.exp: site.exp
- -test -d $* || mkdir $*
+ -@test -d $* || mkdir $*
@srcdir=`cd $(srcdir); ${PWD_COMMAND}`;
- objdir=`${PWD_COMMAND}`/$*; \
+ @objdir=`${PWD_COMMAND}`/$*; \
sed -e s|^set srcdir .*$$|set srcdir $$srcdir| \
-e s|^set objdir .*$$|set objdir $$objdir| \
site.exp $*/site.exp.tmp
@@ -566,7 +566,7 @@ $(check_DEJAGNU_normal_targets): check-DEJAGNUnormal%: normal%/site.exp
# Run the testsuite in normal mode.
check-DEJAGNU $(check_DEJAGNU_normal_targets): check-DEJAGNU%: site.exp
- AR=$(AR); export AR; \
+ $(if $*,@)AR=$(AR); export AR; \
RANLIB=$(RANLIB); export RANLIB; \
if [ -z $* ] [ $(filter -j, $(MFLAGS)) = -j ]; then \
rm -rf normal-parallel || true; \
Re: [PATCH] gcc parallel make check
On Mon, Sep 22, 2014 at 12:21:08PM -0400, Jason Merrill wrote:
On 09/22/2014 11:58 AM, Jakub Jelinek wrote:
LGTM (though, supposedly we want similar change in
libstdc++-v3/testsuite/Makefile.am).
Or, if people would really like to see the commands, we could print them
just once, using e.g.
-$(if $(check_p_subno),@)(rootme= ...
(then e.g. check-parallel-gcc goal would print the command, but
check-parallel-gcc-1 or check-parallel-gcc-112 would not).
So, like this?
Ok, thanks.
commit c750897381a3f936e27cabd825cfa85ce936a6a9
Author: Jason Merrill ja...@redhat.com
Date: Mon Sep 22 11:44:00 2014 -0400
gcc/
* Makefile.in (check-parallel-%): Add @.
libstdc++-v3/
* testsuite/Makefile.am (%/site.exp): Add @.
(check-DEJAGNU): Likewise.
* testsuite/Makefile.in: Regenerate.
diff --git a/gcc/Makefile.in b/gcc/Makefile.in
index 6f251a5..97b439a 100644
--- a/gcc/Makefile.in
+++ b/gcc/Makefile.in
@@ -3674,10 +3674,10 @@ $(lang_checks_parallelized): check-% : site.exp
fi
check-parallel-% : site.exp
- -test -d plugin || mkdir plugin
- -test -d $(TESTSUITEDIR) || mkdir $(TESTSUITEDIR)
- test -d $(TESTSUITEDIR)/$(check_p_subdir) || mkdir
$(TESTSUITEDIR)/$(check_p_subdir)
- -(rootme=`${PWD_COMMAND}`; export rootme; \
+ -@test -d plugin || mkdir plugin
+ -@test -d $(TESTSUITEDIR) || mkdir $(TESTSUITEDIR)
+ @test -d $(TESTSUITEDIR)/$(check_p_subdir) || mkdir
$(TESTSUITEDIR)/$(check_p_subdir)
+ -$(if $(check_p_subno),@)(rootme=`${PWD_COMMAND}`; export rootme; \
srcdir=`cd ${srcdir}; ${PWD_COMMAND}` ; export srcdir ; \
if [ -n $(check_p_subno) ] \
[ -n $$GCC_RUNTEST_PARALLELIZE_DIR ] \
diff --git a/libstdc++-v3/testsuite/Makefile.am
b/libstdc++-v3/testsuite/Makefile.am
index e206aba..b4c9e85 100644
--- a/libstdc++-v3/testsuite/Makefile.am
+++ b/libstdc++-v3/testsuite/Makefile.am
@@ -91,9 +91,9 @@ new-abi-baseline:
${extract_symvers} ../src/.libs/libstdc++.so $${output})
%/site.exp: site.exp
- -test -d $* || mkdir $*
+ -@test -d $* || mkdir $*
@srcdir=`cd $(srcdir); ${PWD_COMMAND}`;
- objdir=`${PWD_COMMAND}`/$*; \
+ @objdir=`${PWD_COMMAND}`/$*; \
sed -e s|^set srcdir .*$$|set srcdir $$srcdir| \
-e s|^set objdir .*$$|set objdir $$objdir| \
site.exp $*/site.exp.tmp
@@ -115,7 +115,7 @@ $(check_DEJAGNU_normal_targets): check-DEJAGNUnormal%:
normal%/site.exp
# Run the testsuite in normal mode.
check-DEJAGNU $(check_DEJAGNU_normal_targets): check-DEJAGNU%: site.exp
- AR=$(AR); export AR; \
+ $(if $*,@)AR=$(AR); export AR; \
RANLIB=$(RANLIB); export RANLIB; \
if [ -z $* ] [ $(filter -j, $(MFLAGS)) = -j ]; then \
rm -rf normal-parallel || true; \
diff --git a/libstdc++-v3/testsuite/Makefile.in
b/libstdc++-v3/testsuite/Makefile.in
index 59060b8..0fc26f4 100644
--- a/libstdc++-v3/testsuite/Makefile.in
+++ b/libstdc++-v3/testsuite/Makefile.in
@@ -553,9 +553,9 @@ new-abi-baseline:
${extract_symvers} ../src/.libs/libstdc++.so $${output})
%/site.exp: site.exp
- -test -d $* || mkdir $*
+ -@test -d $* || mkdir $*
@srcdir=`cd $(srcdir); ${PWD_COMMAND}`;
- objdir=`${PWD_COMMAND}`/$*; \
+ @objdir=`${PWD_COMMAND}`/$*; \
sed -e s|^set srcdir .*$$|set srcdir $$srcdir| \
-e s|^set objdir .*$$|set objdir $$objdir| \
site.exp $*/site.exp.tmp
@@ -566,7 +566,7 @@ $(check_DEJAGNU_normal_targets): check-DEJAGNUnormal%:
normal%/site.exp
# Run the testsuite in normal mode.
check-DEJAGNU $(check_DEJAGNU_normal_targets): check-DEJAGNU%: site.exp
- AR=$(AR); export AR; \
+ $(if $*,@)AR=$(AR); export AR; \
RANLIB=$(RANLIB); export RANLIB; \
if [ -z $* ] [ $(filter -j, $(MFLAGS)) = -j ]; then \
rm -rf normal-parallel || true; \
Jakub
Re: Make name+email address cut'n'paste-able
On 09/22/14 08:35, Jan-Benedict Glaw wrote: On Mon, 2014-09-22 16:06:21 +0200, Thomas Schwinge tho...@codesourcery.com wrote: As has been noted before, http://news.gmane.org/find-root.php?message_id=%3Cyddhabgief1.fsf%40lokon.CeBiTec.Uni-Bielefeld.DE%3E, GCC's MAINTAINERS file does not list a maintainer for libcilkrts, or GCC's Cilk Plus implementation generally. Shouldn't it? I regularely consult this file when reporting issues in specific parts of the GCC code base. While we're at it... I consult that file as well, even quite often for preparing Build Robot emails. There's another usability enhancement: I'd like to propose to put all email addresses between '' and '', which would quite ease cut'n'past-ability. What's your oppinion on that? Should I prepare a patch? Sure. Jeff
Re: Is this a compiler bug?
On Mon, 2014-09-22 at 16:32 +0200, Jakub Jelinek wrote: On Mon, Sep 22, 2014 at 10:22:59AM -0400, David Malcolm wrote: On Sun, 2014-09-21 at 22:15 -0700, Andrew Pinski wrote: On Sun, Sep 21, 2014 at 8:08 PM, Steve Kargl s...@troutmask.apl.washington.edu wrote: On Sun, Sep 21, 2014 at 07:57:45PM -0700, Andrew Pinski wrote: On Sun, Sep 21, 2014 at 6:56 PM, Steve Kargl s...@troutmask.apl.washington.edu wrote: + is a binary operator. 0x3ffe is a hexidecimal-constant according to 6.6.4.1 in n1256.pdf. 63 is, of course, a decimal-constant. This is before tokens happen and during lexing of the program. e+64 is exponent-part see 6.4.4.2. 6.4.4.2 applies to floating point constant. 6.4.4.1 is for integer constants. Nope again, this time from bug 3885: Strange as it may seem, the behavior is correct, and mandated by the C Standard. 0x00E-0x00A is a single preprocessor token, of type pp-number, and it must become a single compiler token, but it can't. The gotcha is the `E-' sequence, that makes it seem like the exponent notation of floating-point constants. Looks like this is a common misunderstood part of C. If people tend to get this wrong, should we issue a warning for it? We already diagnose it, with an error actually, not warning: error: invalid suffix +63 on integer constant etc. Just apparently people are surprised when the compiler diagnoses it. So perhaps some extra note explaining it (== hint how to fix that). I've filed PR63337 with some ideas on how the error message could be improved for this case.
Re: Listing a maintainer for libcilkrts, and GCC's Cilk Plus implementation generally?
On 09/22/14 08:06, Thomas Schwinge wrote: Hi! As has been noted before, http://news.gmane.org/find-root.php?message_id=%3Cyddhabgief1.fsf%40lokon.CeBiTec.Uni-Bielefeld.DE%3E, GCC's MAINTAINERS file does not list a maintainer for libcilkrts, or GCC's Cilk Plus implementation generally. Shouldn't it? I regularely consult this file when reporting issues in specific parts of the GCC code base. The original plan was for Balaji to take on this role; however, his assignment within Intel has changed and thus he's not going to have time to work on Cilk+ anymore. Igor Zamyatin has been doing a fair amount of Cilk+ maintenance/bugfixing and it might make sense for him to own it in the long term if he's interested. jeff
Re: -Wstack-usage and alloca in loops
On 09/22/14 09:56, Dmitry Antipov wrote:
For the following translation unit:
#include stdlib.h
int
foo (unsigned n)
{
int *p;
if (n 1024)
p = alloca (n * sizeof (int));
else
p = malloc (n * sizeof (int));
return g (p, n);
}
int
bar (unsigned n)
{
int x, i, *p;
for (x = 0, i = 0; i n; i++)
{
if (n 1024)
p = alloca (n * sizeof (int));
else
p = malloc (n * sizeof (int));
x += h (p, n);
if (n = 1024)
free (p);
}
return x;
}
compiling with -Wstack-usage=32 produces (as of 4.9.1):
test.c: In function 'foo':
test.c:14:1: warning: stack usage might be unbounded [-Wstack-usage=]
}
^
test.c: In function 'bar':
test.c:35:1: warning: stack usage might be unbounded [-Wstack-usage=]
}
^
1) I'm just curious why it's unbounded for foo(). It shouldn't be too
hard to find that alloca() is never requested to allocate more than
1024 * sizeof (int), and never called more than once, isn't it?
2) In bar(), stack usage is unbounded unless bar() is always inline with
a compile-time constant argument N.
IIUC good detection of 2) is much harder to implement, but is it
reasonable/possible to make -Wstack-usage more accurate in 1)?
The implementation of -Wstack-usage is a bit lame in that it does not do
any flow analysis or tie into the range information computed by VRP.
In the first example it sees an dynamic alloca and considers the
allocation potentially unbounded -- even though range information would
indicate that n 1024 and thus the total allocation is 1024 * sizeof
(int).
Moving the stack usage computation into its own analysis phase which has
access to VRP bounds and such would be a a significant improvement and
one which I think would be quite useful.
Jeff
Re: -Wstack-usage and alloca in loops
The implementation of -Wstack-usage is a bit lame in that it does not do any flow analysis or tie into the range information computed by VRP. Right, that was by design in order to be conservatively correct. May I remind you of where we came from with -Wframe-larger-than? :-) Moving the stack usage computation into its own analysis phase which has access to VRP bounds and such would be a a significant improvement and one which I think would be quite useful. Yes, provided the outcome is still guaranteed to be conservatively correct. -- Eric Botcazou
[Bug rtl-optimization/63325] [5.0 regression] ICE fold check: original tree changed by fold
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63325 Dmitry G. Dyachenko dimhen at gmail dot com changed: What|Removed |Added CC||hubicka at gcc dot gnu.org --- Comment #1 from Dmitry G. Dyachenko dimhen at gmail dot com --- start FAIL r215409
[Bug c/63326] New: pragma GCC causes wrong code generation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63326 Bug ID: 63326 Summary: pragma GCC causes wrong code generation Product: gcc Version: 4.9.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: dietmar.schind...@manroland-web.com Created attachment 33530 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33530action=edit preprocessed file The following command generates wrong code, returning 1 instead of 0 (as if the pragma line ended the statement in which it is placed). raeksrv1:~/bin/so/c /tmp/usr/local/bin/gcc -v -save-temps bug.c -o bug Using built-in specs. COLLECT_GCC=/tmp/usr/local/bin/gcc COLLECT_LTO_WRAPPER=/tmp/usr/local/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.9.1/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gcc-4.9.1/configure --enable-plugin --disable-libsanitizer : (reconfigured) ../gcc-4.9.1/configure --enable-plugin --enable-languages=c --disable-libsanitizer : (reconfigured) ../gcc-4.9.1/configure --enable-plugin --enable-languages=c --disable-libsanitizer --disable-libcilkrts Thread model: posix gcc version 4.9.1 (GCC) COLLECT_GCC_OPTIONS='-v' '-save-temps' '-o' 'bug' '-mtune=generic' '-march=x86-64' /tmp/usr/local/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.9.1/cc1 -E -quiet -v -iprefix /tmp/usr/local/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.9.1/ bug.c -mtune=generic -march=x86-64 -fpch-preprocess -o bug.i ignoring nonexistent directory /tmp/usr/local/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.9.1/../../../../x86_64-unknown-linux-gnu/include ignoring duplicate directory /tmp/usr/local/bin/../lib/gcc/../../lib/gcc/x86_64-unknown-linux-gnu/4.9.1/include ignoring duplicate directory /tmp/usr/local/bin/../lib/gcc/../../lib/gcc/x86_64-unknown-linux-gnu/4.9.1/include-fixed ignoring nonexistent directory /tmp/usr/local/bin/../lib/gcc/../../lib/gcc/x86_64-unknown-linux-gnu/4.9.1/../../../../x86_64-unknown-linux-gnu/include #include ... search starts here: #include ... search starts here: /tmp/usr/local/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.9.1/include /tmp/usr/local/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.9.1/include-fixed /usr/local/include /usr/include End of search list. COLLECT_GCC_OPTIONS='-v' '-save-temps' '-o' 'bug' '-mtune=generic' '-march=x86-64' /tmp/usr/local/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.9.1/cc1 -fpreprocessed bug.i -quiet -dumpbase bug.c -mtune=generic -march=x86-64 -auxbase bug -version -o bug.s GNU C (GCC) version 4.9.1 (x86_64-unknown-linux-gnu) compiled by GNU C version 4.9.1, GMP version 4.3.2, MPFR version 2.4.2, MPC version 0.8.1 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 GNU C (GCC) version 4.9.1 (x86_64-unknown-linux-gnu) compiled by GNU C version 4.9.1, GMP version 4.3.2, MPFR version 2.4.2, MPC version 0.8.1 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: aa505e323dbffe0cb500ba62f983d917 COLLECT_GCC_OPTIONS='-v' '-save-temps' '-o' 'bug' '-mtune=generic' '-march=x86-64' as -v --64 -o bug.o bug.s GNU assembler version 2.20.1 (i486-linux-gnu) using BFD version (GNU Binutils for Debian) 2.20.1-system.20100303 COMPILER_PATH=/tmp/usr/local/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.9.1/:/tmp/usr/local/bin/../libexec/gcc/ LIBRARY_PATH=/tmp/usr/local/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.9.1/:/tmp/usr/local/bin/../lib/gcc/:/tmp/usr/local/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.9.1/../../../../lib64/:/lib/../lib64/:/usr/lib/../lib64/:/tmp/usr/local/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.9.1/../../../:/lib/:/usr/lib/ COLLECT_GCC_OPTIONS='-v' '-save-temps' '-o' 'bug' '-mtune=generic' '-march=x86-64' /tmp/usr/local/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.9.1/collect2 --eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 -o bug /usr/lib/../lib64/crt1.o /usr/lib/../lib64/crti.o /tmp/usr/local/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.9.1/crtbegin.o -L/tmp/usr/local/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.9.1 -L/tmp/usr/local/bin/../lib/gcc -L/tmp/usr/local/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.9.1/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/tmp/usr/local/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.9.1/../../.. bug.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /tmp/usr/local/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.9.1/crtend.o /usr/lib/../lib64/crtn.o
[Bug c/63326] pragma GCC causes wrong code generation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63326 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- #pragma are considered statements.
[Bug debug/63300] 'const volatile' sometimes stripped in debug info
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63300 Mark Wielaard mark at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |mark at gcc dot gnu.org --- Comment #3 from Mark Wielaard mark at gcc dot gnu.org --- Proposed fix: https://gcc.gnu.org/ml/gcc-patches/2014-09/msg01723.html
[Bug fortran/44882] Bogus types in references with mismatched commons
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44882 --- Comment #15 from rguenther at suse dot de rguenther at suse dot de --- On Fri, 19 Sep 2014, dominiq at lps dot ens.fr wrote: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44882 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|NEW |WAITING --- Comment #14 from Dominique d'Humieres dominiq at lps dot ens.fr --- I dont see any ICE for the test in comment 12 on powerpc-apple-darwin9 (from 4.4.7 to r214282). Any reason why this PR is still open? See comment #5/6, the Fortran frontend still produces wrong-code or silently accepts invalid input.
[Bug c/63303] Pointer subtraction is broken when using -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63303 --- Comment #10 from Richard Biener rguenth at gcc dot gnu.org --- To support the standards definition of p1 - p2 we'd need a POINTER_DIFF_EXPR that also embeds the exact division by the array element size. Btw, while C and C++ share pointer_int_sum they have differing implementations for computing pointer differences. The safe variant would be indeed to compute the pointer difference using an unsigned type and I can't see what optimizations we lose when doing that. Note that you'd still need to convert the result to a signed type before doing the exact division by the element size.
[Bug fortran/63327] New: Poor caret location in error mesage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63327 Bug ID: 63327 Summary: Poor caret location in error mesage Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: Joost.VandeVondele at mat dot ethz.ch Example code showing somewhat confusing lines and caret info cat test.f90 SUBROUTINE S1(d) INTEGER :: i,d(*) !$OMP PARALLEL DO !$OMP DEFAULT(NONE) SHARED(d) PRIVATE(i) DO i=1,100 c= c + d(i) d(i)=c*c ENDDO END SUBROUTINE S1 gfortran -fopenmp test.f90 test.f90: In function ‘s1’: test.f90:7:0: error: ‘c’ not specified in enclosing parallel d(i) ^ test.f90:4:0: error: enclosing parallel !$OMP DEFAULT(NONE) SHARED(d) PRIVATE(i) ^
[Bug sanitizer/63316] [5.0 Regression] False asan positive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63316 --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org --- MALLOC_ABI_ALIGNMENT is BITS_PER_WORD (too small for Linux actually, glibc guarantees 2 * BITS_PER_WORD). So, this IMNSHO is a libsanitizer bug, in that it doesn't provide the Linux ABI guaranteed alignments. On 32-bit Linux targets, malloc even for 1-7 bytes (and 0 if it doesn't return NULL for that) allocations should return 8 byte aligned memory, and for 64-bit Linux targets, malloc even for 1-15 bytes long allocations should return 16 byte aligned memory. Kostya, can you please fix sanitizer_common?
[Bug c++/63323] confused by earlier errors, bailing out with no other errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63323 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-09-22 Known to work||5.0 Ever confirmed|0 |1 Known to fail||4.9.0, 4.9.1 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org --- Confirmed. Trunk prints the full error though.
[Bug c++/63323] confused by earlier errors, bailing out with no other errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63323 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||mpolacek at gcc dot gnu.org --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org --- This is a dup of PR61272 , Marek, can you please apply your PR61272 patch to 4.9 branch too? Thanks.
[Bug c++/63323] confused by earlier errors, bailing out with no other errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63323 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Target Milestone|--- |4.9.2 --- Comment #3 from Marek Polacek mpolacek at gcc dot gnu.org --- On it.
[Bug debug/55641] debug info for the type of a reference declared with a typedef has spurious 'const'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55641 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #10 from Marek Polacek mpolacek at gcc dot gnu.org --- Mark recently tweaked this code, but I still see the DW_TAG_const_type in there.
[Bug debug/60782] DWARF does not represent _Atomic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60782 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-09-22 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Marek Polacek mpolacek at gcc dot gnu.org --- Confirmed.
[Bug ipa/63270] [5 Regression] internal compiler error: in odr_types_equivalent_p, at ipa-devirt.c:1075
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63270 --- Comment #5 from marxin at gcc dot gnu.org --- Author: marxin Date: Mon Sep 22 09:39:20 2014 New Revision: 215451 URL: https://gcc.gnu.org/viewcvs?rev=215451root=gccview=rev Log: PR lto/63270 - new test * g++.dg/lto/pr63270_0.C: New test. * g++.dg/lto/pr63270_1.C: New test. Added: trunk/gcc/testsuite/g++.dg/lto/pr63270_0.C trunk/gcc/testsuite/g++.dg/lto/pr63270_1.C Modified: trunk/gcc/testsuite/ChangeLog
[Bug fortran/63327] Poor caret location in error mesage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63327 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-09-22 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr --- Confirmed from 4.8.3 up to trunk (5.0). The errors are displayed without caret with gfortran 4.7.4.
[Bug ipa/63298] [5 Regression] internal compiler error: in types_same_for_odr, at ipa-devirt.c:449 with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63298 Martin Liška mliska at suse dot cz changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Martin Liška mliska at suse dot cz --- Fixed.
[Bug debug/63328] New: c-c++-common/gomp/pr60823-3.c test fails with -fcompare-debug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63328 Bug ID: 63328 Summary: c-c++-common/gomp/pr60823-3.c test fails with -fcompare-debug Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug Assignee: jakub at gcc dot gnu.org Reporter: jakub at gcc dot gnu.org xgcc: error: /usr/src/gcc/gcc/testsuite/c-c++-common/gomp/pr60823-3.c: -fcompare-debug failure
[Bug ipa/63298] [5 Regression] internal compiler error: in types_same_for_odr, at ipa-devirt.c:449 with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63298 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |5.0
[Bug c++/63295] Insane memory use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63295 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||compile-time-hog --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- Confirmed on trunk. It also takes much time to compile.
[Bug lto/63286] [5 Regression] FAIL: g++.dg/lto/20101014-2 cp_lto_20101014-2_0.o assemble, * after r215196
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63286 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |5.0
[Bug tree-optimization/63288] [5 Regression] gcc.c-torture/execute/20140326-1.c FAILs with -Og -fgcse -fif-conversion2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63288 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |5.0
[Bug debug/63285] [4.9 Regression] -fcompare-debug scheduler related failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63285 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-09-22 Known to work||5.0 Summary|[4.9/5 Regression] |[4.9 Regression] |-fcompare-debug scheduler |-fcompare-debug scheduler |related failure |related failure Ever confirmed|0 |1 Known to fail||4.9.1 --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org --- Fixed on trunk sofar.
[Bug pch/63319] [5 Regression] ICE: Segmentation fault building qt5 with pch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63319 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |5.0
[Bug sanitizer/63316] [5.0 Regression] False asan positive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63316 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |5.0
[Bug ipa/63313] [5 Regression] ICE in ipa-comdats.c:371
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63313 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Version|unknown |5.0 Target Milestone|--- |5.0 Summary|ICE in ipa-comdats.c:371|[5 Regression] ICE in ||ipa-comdats.c:371
[Bug middle-end/63311] [4.9/5 Regression] -O1 optimization introduces valgrind warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63311 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.9.2
[Bug middle-end/63311] [4.9/5 Regression] -O1 optimization introduces valgrind warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63311 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- This is probably ifcombine at work and the target splitting the combined condition back, but the other way around.
[Bug c/63307] [4.9/5 Regression] Cilk+ breaks -fcompare-debug bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63307 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.9.2
[Bug debug/63284] [4.9/5 Regression] -fcompare-debug issue due to redirection to __builtin_unreachable ()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63284 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #5 from Richard Biener rguenth at gcc dot gnu.org --- Fixed.
[Bug bootstrap/63280] [5 Regression] Double free in GCC compiled with LTO and -O3.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63280 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added CC||rsandifo at gcc dot gnu.org Target Milestone|--- |5.0 Summary|Double free in GCC compiled |[5 Regression] Double free |with LTO and -O3. |in GCC compiled with LTO ||and -O3.
[Bug debug/63328] c-c++-common/gomp/pr60823-3.c test fails with -fcompare-debug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63328 --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Mon Sep 22 10:32:09 2014 New Revision: 215454 URL: https://gcc.gnu.org/viewcvs?rev=215454root=gccview=rev Log: PR debug/63328 * omp-low.c (ipa_simd_modify_stmt_ops): For debug stmts insert a debug source bind stmt setting DEBUG_EXPR_DECL instead of a normal gimple assignment stmt. * c-c++-common/gomp/pr63328.c: New test. Added: trunk/gcc/testsuite/c-c++-common/gomp/pr63328.c Modified: trunk/gcc/ChangeLog trunk/gcc/omp-low.c trunk/gcc/testsuite/ChangeLog
[Bug middle-end/63311] [4.9/5 Regression] -O1 optimization introduces valgrind warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63311 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-09-22 Ever confirmed|0 |1 --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr --- Confirmed.
[Bug debug/63328] c-c++-common/gomp/pr60823-3.c test fails with -fcompare-debug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63328 --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Mon Sep 22 10:34:16 2014 New Revision: 215455 URL: https://gcc.gnu.org/viewcvs?rev=215455root=gccview=rev Log: PR debug/63328 * omp-low.c (ipa_simd_modify_stmt_ops): For debug stmts insert a debug source bind stmt setting DEBUG_EXPR_DECL instead of a normal gimple assignment stmt. * c-c++-common/gomp/pr63328.c: New test. Added: branches/gcc-4_9-branch/gcc/testsuite/c-c++-common/gomp/pr63328.c Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/omp-low.c branches/gcc-4_9-branch/gcc/testsuite/ChangeLog
[Bug debug/63328] c-c++-common/gomp/pr60823-3.c test fails with -fcompare-debug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63328 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org --- Fixed.
[Bug target/63312] FAIL: gcc.dg/torture/float128-exact-underflow.c -O0 execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63312 --- Comment #3 from Joseph S. Myers jsm28 at gcc dot gnu.org --- Author: jsm28 Date: Mon Sep 22 11:08:03 2014 New Revision: 215458 URL: https://gcc.gnu.org/viewcvs?rev=215458root=gccview=rev Log: PR target/63312 * config/ia64/sfp-machine.h (FE_EX_ALL, FP_TRAPPING_EXCEPTIONS): New macros. Modified: trunk/libgcc/ChangeLog trunk/libgcc/config/ia64/sfp-machine.h
[Bug target/63312] FAIL: gcc.dg/torture/float128-exact-underflow.c -O0 execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63312 Joseph S. Myers jsm28 at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #4 from Joseph S. Myers jsm28 at gcc dot gnu.org --- Fixed for GCC 5.
[Bug target/63312] FAIL: gcc.dg/torture/float128-exact-underflow.c -O0 execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63312 Joseph S. Myers jsm28 at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |5.0
[Bug c++/63323] confused by earlier errors, bailing out with no other errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63323 --- Comment #4 from Marek Polacek mpolacek at gcc dot gnu.org --- Author: mpolacek Date: Mon Sep 22 11:27:54 2014 New Revision: 215459 URL: https://gcc.gnu.org/viewcvs?rev=215459root=gccview=rev Log: PR c++/63323 * ubsan.c (is_ubsan_builtin_p): Turn assert into a condition. * g++.dg/ubsan/pr61272.C: New test. Added: branches/gcc-4_9-branch/gcc/testsuite/g++.dg/ubsan/pr61272.C Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/testsuite/ChangeLog branches/gcc-4_9-branch/gcc/ubsan.c
[Bug c++/63323] confused by earlier errors, bailing out with no other errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63323 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Marek Polacek mpolacek at gcc dot gnu.org --- Should be fixed.
[Bug libstdc++/63329] New: std::bind does not define argument_type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63329
Bug ID: 63329
Summary: std::bind does not define argument_type
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: thomas.sanchz at gmail dot com
Hi,
It looks like the data structure returned by bind does not contain some type
(argument_type) required by std::not1 for instance.
It works with clang + the libc++ on Mac Os X.
#include functional
#include algorithm
struct Test { bool pred() const { return true; } };
int main(int argc, char *argv[])
{
// works
auto f1 = std::not1(std::mem_fn(Test::pred));
// works
auto f2 = std::not1(std::mem_fun(Test::pred));
// does not work: error: no type named ‘argument_type’
auto f3 = std::not1(std::bind(Test::pred, std::placeholders::_1));
}
Thanks a lot.
[Bug target/63330] New: vector shuffle resembling vector shift not expanded optimally
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63330
Bug ID: 63330
Summary: vector shuffle resembling vector shift not expanded
optimally
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: rguenth at gcc dot gnu.org
Target: x86_64-*-*, i?86-*-*
typedef int v4si __attribute__((vector_size(16)));
v4si foo (v4si x)
{
return __builtin_shuffle (x, (v4si){ 0, 0, 0, 0 },
(v4si){4, 3, 2, 1 });
}
and similar shuffles shifting a vector by whole-element amounts
left/right and inserting zeros are not expanded optimally (while
the target has at least a vec_shr optab which suggests sth would
be available).
With -mavx2 I get for the above
vpxor %xmm1, %xmm1, %xmm1
vpalignr$4, %xmm0, %xmm1, %xmm0
vpshufd $27, %xmm0, %xmm0
while I expected sth like
psrldq %xmm0, $4
__builtin_shuffle (x, (v4si) { -1, -1, -1, -1 }, ... )
Arbitrary constants shifted in could be handled the same by IORing
the shifted in value after the psrldq in the appropriate elements
for the cost of an extra vector constant.
[Bug target/63330] vector shuffle resembling vector shift not expanded optimally
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63330 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- (this is aimed at removing VEC_RSHIFT_EXPR and thus no longer using vec_shr)
[Bug lto/63226] [5 Regression] ICE with -flto-odr-type-merging
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63226 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED CC||trippels at gcc dot gnu.org Resolution|--- |FIXED --- Comment #10 from Markus Trippelsdorf trippels at gcc dot gnu.org --- marxin added a testcase in r215451.
[Bug libstdc++/63329] std::bind does not define argument_type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63329 --- Comment #1 from Thomas Sanchez thomas.sanchz at gmail dot com --- BTW, I forgot to add that the compiler is invoked with this command: g++ -std=c++11 test.cpp Also, funny thing, with clang, it is the first one that do not compile :) Thanks,
[Bug c++/61857] An init-capturing lambda is parsed incorrectly when used in a braced-init-list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61857 --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com --- In our case the issue is slightly different, the problem is in cp_parser_initializer_list, here: cp_parser_parse_tentatively (parser); cp_lexer_consume_token (parser-lexer); designator = cp_parser_constant_expression (parser, true, non_const); cp_parser_require (parser, CPP_CLOSE_SQUARE, RT_CLOSE_SQUARE); cp_parser_require (parser, CPP_EQ, RT_EQ); if (!cp_parser_parse_definitely (parser)) designator = NULL_TREE; else if (non_const) require_potential_rvalue_constant_expression (designator); where cp_parser_constant_expression is tentatively called. I think it can be solved by looking forward for the '=', similarly to other GNU extensions, for example compound literals.
[Bug fortran/63331] New: Fortran -fcompare-debug issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63331 Bug ID: 63331 Summary: Fortran -fcompare-debug issues Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jakub at gcc dot gnu.org CC: burnus at gcc dot gnu.org In -fcompare-debug bootstrap/regtest (GCC_COMPARE_DEBUG=1 in the environment), I'm seeing various gfortran.dg regressions compared to normal regtest: +FAIL: gfortran.dg/coarray/alloc_comp_1.f90 -fcoarray=single -O2 (test for excess errors) +UNRESOLVED: gfortran.dg/coarray/alloc_comp_1.f90 -fcoarray=single -O2 compilation failed to produce executable +FAIL: gfortran.dg/coarray/alloc_comp_1.f90 -fcoarray=lib -O2 -lcaf_single (test for excess errors) +UNRESOLVED: gfortran.dg/coarray/alloc_comp_1.f90 -fcoarray=lib -O2 -lcaf_single compilation failed to produce executable +FAIL: gfortran.dg/coarray/alloc_comp_3.f90 -fcoarray=single -O2 (test for excess errors) +FAIL: gfortran.dg/coarray/alloc_comp_3.f90 -fcoarray=lib -O2 -lcaf_single (test for excess errors) +FAIL: gfortran.dg/coarray/lib_realloc_1.f90 -fcoarray=single -O2 (test for excess errors) +UNRESOLVED: gfortran.dg/coarray/lib_realloc_1.f90 -fcoarray=single -O2 compilation failed to produce executable +FAIL: gfortran.dg/coarray/lib_realloc_1.f90 -fcoarray=lib -O2 -lcaf_single (test for excess errors) +UNRESOLVED: gfortran.dg/coarray/lib_realloc_1.f90 -fcoarray=lib -O2 -lcaf_single compilation failed to produce executable +FAIL: gfortran.dg/coarray/subobject_1.f90 -fcoarray=single -O2 (test for excess errors) +UNRESOLVED: gfortran.dg/coarray/subobject_1.f90 -fcoarray=single -O2 compilation failed to produce executable +FAIL: gfortran.dg/coarray/subobject_1.f90 -fcoarray=lib -O2 -lcaf_single (test for excess errors) +UNRESOLVED: gfortran.dg/coarray/subobject_1.f90 -fcoarray=lib -O2 -lcaf_single compilation failed to produce executable +FAIL: gfortran.dg/class_optional_1.f90 -O0 (test for excess errors) +UNRESOLVED: gfortran.dg/class_optional_1.f90 -O0 compilation failed to produce executable +FAIL: gfortran.dg/class_optional_1.f90 -O1 (test for excess errors) +UNRESOLVED: gfortran.dg/class_optional_1.f90 -O1 compilation failed to produce executable +FAIL: gfortran.dg/class_optional_1.f90 -O2 (test for excess errors) +UNRESOLVED: gfortran.dg/class_optional_1.f90 -O2 compilation failed to produce executable +FAIL: gfortran.dg/class_optional_1.f90 -O3 -fomit-frame-pointer (test for excess errors) +UNRESOLVED: gfortran.dg/class_optional_1.f90 -O3 -fomit-frame-pointer compilation failed to produce executable +FAIL: gfortran.dg/class_optional_1.f90 -O3 -fomit-frame-pointer -funroll-loops (test for excess errors) +UNRESOLVED: gfortran.dg/class_optional_1.f90 -O3 -fomit-frame-pointer -funroll-loops compilation failed to produce executable +FAIL: gfortran.dg/class_optional_1.f90 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions (test for excess errors) +UNRESOLVED: gfortran.dg/class_optional_1.f90 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions compilation failed to produce executable +FAIL: gfortran.dg/class_optional_1.f90 -O3 -g (test for excess errors) +UNRESOLVED: gfortran.dg/class_optional_1.f90 -O3 -g compilation failed to produce executable +FAIL: gfortran.dg/class_optional_1.f90 -Os (test for excess errors) +UNRESOLVED: gfortran.dg/class_optional_1.f90 -Os compilation failed to produce executable +FAIL: gfortran.dg/class_optional_2.f90 -O0 (test for excess errors) +UNRESOLVED: gfortran.dg/class_optional_2.f90 -O0 compilation failed to produce executable +FAIL: gfortran.dg/class_optional_2.f90 -O1 (test for excess errors) +UNRESOLVED: gfortran.dg/class_optional_2.f90 -O1 compilation failed to produce executable +FAIL: gfortran.dg/class_optional_2.f90 -O2 (test for excess errors) +UNRESOLVED: gfortran.dg/class_optional_2.f90 -O2 compilation failed to produce executable +FAIL: gfortran.dg/class_optional_2.f90 -O3 -fomit-frame-pointer (test for excess errors) +UNRESOLVED: gfortran.dg/class_optional_2.f90 -O3 -fomit-frame-pointer compilation failed to produce executable +FAIL: gfortran.dg/class_optional_2.f90 -O3 -fomit-frame-pointer -funroll-loops (test for excess errors) +UNRESOLVED: gfortran.dg/class_optional_2.f90 -O3 -fomit-frame-pointer -funroll-loops compilation failed to produce executable +FAIL: gfortran.dg/class_optional_2.f90 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions (test for excess errors) +UNRESOLVED: gfortran.dg/class_optional_2.f90 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions compilation failed to produce executable +FAIL: gfortran.dg/class_optional_2.f90 -O3 -g (test for excess errors) +UNRESOLVED: gfortran.dg/class_optional_2.f90 -O3 -g
[Bug fortran/63331] Fortran -fcompare-debug issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63331 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-09-22 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr --- Confirmed.
[Bug libstdc++/53626] [C++11] move assignment for ifstream
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53626 --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org --- Author: redi Date: Mon Sep 22 13:34:09 2014 New Revision: 215463 URL: https://gcc.gnu.org/viewcvs?rev=215463root=gccview=rev Log: Make streams movable and swappable. PR libstdc++/54316 PR libstdc++/53626 * config/abi/pre/gnu.ver: Add new exports. * config/io/basic_file_stdio.h (__basic_file): Support moving and swapping. * include/bits/basic_ios.h (basic_ios::move, basic_ios::swap): Likewise. * include/bits/ios_base.h (ios_base::_M_move, ios_base::_M_swap): Likewise. * include/bits/fstream.tcc (basic_filebuf): Likewise. * include/bits/move.h (__exchange): Define for C++11 mode. * include/ext/stdio_filebuf.h (stdio_filebuf): Support moving and swapping. * include/ext/stdio_sync_filebuf.h (stdio_sync_filebuf): Likewise. * include/std/fstream (basic_filebuf, basic_ifstream, basic_ofstream, basic_fstream): Likewise. * include/std/ios: Remove whitespace. * include/std/istream (basic_istream, basic_iostream): Support moving and swapping. * include/std/ostream (basic_ostream): Likewise. * include/std/sstream (basic_stringbuf, basic_istringstream, basic_ostringstream, basic_stringstream): Likewise. * include/std/streambuf (basic_streambuf): Do not default copy constructor and assignment on first declaration. * include/std/utility (exchange): Forward to __exchange. * testsuite/27_io/basic_filebuf/cons/char/copy_neg.cc: New. * src/c++11/Makefile.am: Add stream-related files. * src/c++11/Makefile.in: Regenerate. * src/c++11/ext11-inst.cc (stdio_filebuf, stdio_sync_filebuf): New file for explicit instantiation definitions. * src/c++11/ios.cc: Move from src/c++98 to here. (ios_base::_M_move, ios_base::_M_swap): Define. * src/c++11/ios-inst.cc: Move from src/c++98 to here. * src/c++11/iostream-inst.cc: Likewise. * src/c++11/istream-inst.cc: Likewise. * src/c++11/ostream-inst.cc: Likewise. * src/c++11/sstream-inst.cc: Likewise. * src/c++11/streambuf-inst.cc: Likewise. * src/c++98/Makefile.am: Remove stream-related files. * src/c++98/Makefile.in: Regenerate. * src/c++98/ext-inst.cc (stdio_filebuf): Remove explicit instantiations. * src/c++98/misc-inst.cc (stdio_sync_filebuf): Likewise. * src/c++98/ios-inst.cc: Move to src/c++11/. * src/c++98/ios.cc: Move to src/c++11/. * src/c++98/iostream-inst.cc: Likewise. * src/c++98/istream-inst.cc: Likewise. * src/c++98/ostream-inst.cc: Likewise. * src/c++98/sstream-inst.cc: Likewise. * src/c++98/streambuf-inst.cc: Likewise. * testsuite/27_io/basic_filebuf/cons/char/copy_neg.cc: New. * testsuite/27_io/basic_fstream/cons/move.cc: New. * testsuite/27_io/basic_fstream/assign/1.cc: New. * testsuite/27_io/basic_ifstream/cons/move.cc: New. * testsuite/27_io/basic_ifstream/assign/1.cc: New. * testsuite/27_io/basic_istringstream/assign/1.cc: New. * testsuite/27_io/basic_istringstream/cons/move.cc: New. * testsuite/27_io/basic_ofstream/cons/move.cc: New. * testsuite/27_io/basic_ofstream/assign/1.cc: New. * testsuite/27_io/basic_ostringstream/assign/1.cc: New. * testsuite/27_io/basic_ostringstream/cons/move.cc: New. * testsuite/27_io/basic_stringstream/assign/1.cc: New. * testsuite/27_io/basic_stringstream/cons/move.cc: New. Added: trunk/libstdc++-v3/src/c++11/ext11-inst.cc - copied, changed from r215458, trunk/libstdc++-v3/src/c++98/ios-inst.cc trunk/libstdc++-v3/src/c++11/ios-inst.cc - copied, changed from r215458, trunk/libstdc++-v3/src/c++98/ios-inst.cc trunk/libstdc++-v3/src/c++11/ios.cc - copied, changed from r215458, trunk/libstdc++-v3/src/c++98/ios.cc trunk/libstdc++-v3/src/c++11/iostream-inst.cc - copied, changed from r215458, trunk/libstdc++-v3/src/c++98/iostream-inst.cc trunk/libstdc++-v3/src/c++11/istream-inst.cc - copied, changed from r215458, trunk/libstdc++-v3/src/c++98/istream-inst.cc trunk/libstdc++-v3/src/c++11/ostream-inst.cc - copied, changed from r215458, trunk/libstdc++-v3/src/c++98/ostream-inst.cc trunk/libstdc++-v3/src/c++11/sstream-inst.cc - copied, changed from r215458, trunk/libstdc++-v3/src/c++98/sstream-inst.cc trunk/libstdc++-v3/src/c++11/streambuf-inst.cc - copied, changed from r215458, trunk/libstdc++-v3/src/c++98/streambuf-inst.cc trunk/libstdc++-v3/testsuite/27_io/basic_filebuf/cons/char/copy_neg.cc trunk/libstdc++-v3/testsuite/27_io/basic_fstream/assign/ trunk/libstdc++-v3/testsuite/27_io/basic_fstream/assign/1.cc trunk/libstdc++-v3/testsuite/27_io/basic_fstream/cons/move.cc trunk/libstdc++-v3/testsuite/27_io/basic_ifstream/assign/ trunk/libstdc++-v3/testsuite/27_io/basic_ifstream/assign/1.cc trunk/libstdc++-v3/testsuite/27_io/basic_ifstream/cons/move.cc
[Bug libstdc++/54316] [C++11] move constructor for stringstream
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54316 --- Comment #9 from Jonathan Wakely redi at gcc dot gnu.org --- Author: redi Date: Mon Sep 22 13:34:09 2014 New Revision: 215463 URL: https://gcc.gnu.org/viewcvs?rev=215463root=gccview=rev Log: Make streams movable and swappable. PR libstdc++/54316 PR libstdc++/53626 * config/abi/pre/gnu.ver: Add new exports. * config/io/basic_file_stdio.h (__basic_file): Support moving and swapping. * include/bits/basic_ios.h (basic_ios::move, basic_ios::swap): Likewise. * include/bits/ios_base.h (ios_base::_M_move, ios_base::_M_swap): Likewise. * include/bits/fstream.tcc (basic_filebuf): Likewise. * include/bits/move.h (__exchange): Define for C++11 mode. * include/ext/stdio_filebuf.h (stdio_filebuf): Support moving and swapping. * include/ext/stdio_sync_filebuf.h (stdio_sync_filebuf): Likewise. * include/std/fstream (basic_filebuf, basic_ifstream, basic_ofstream, basic_fstream): Likewise. * include/std/ios: Remove whitespace. * include/std/istream (basic_istream, basic_iostream): Support moving and swapping. * include/std/ostream (basic_ostream): Likewise. * include/std/sstream (basic_stringbuf, basic_istringstream, basic_ostringstream, basic_stringstream): Likewise. * include/std/streambuf (basic_streambuf): Do not default copy constructor and assignment on first declaration. * include/std/utility (exchange): Forward to __exchange. * testsuite/27_io/basic_filebuf/cons/char/copy_neg.cc: New. * src/c++11/Makefile.am: Add stream-related files. * src/c++11/Makefile.in: Regenerate. * src/c++11/ext11-inst.cc (stdio_filebuf, stdio_sync_filebuf): New file for explicit instantiation definitions. * src/c++11/ios.cc: Move from src/c++98 to here. (ios_base::_M_move, ios_base::_M_swap): Define. * src/c++11/ios-inst.cc: Move from src/c++98 to here. * src/c++11/iostream-inst.cc: Likewise. * src/c++11/istream-inst.cc: Likewise. * src/c++11/ostream-inst.cc: Likewise. * src/c++11/sstream-inst.cc: Likewise. * src/c++11/streambuf-inst.cc: Likewise. * src/c++98/Makefile.am: Remove stream-related files. * src/c++98/Makefile.in: Regenerate. * src/c++98/ext-inst.cc (stdio_filebuf): Remove explicit instantiations. * src/c++98/misc-inst.cc (stdio_sync_filebuf): Likewise. * src/c++98/ios-inst.cc: Move to src/c++11/. * src/c++98/ios.cc: Move to src/c++11/. * src/c++98/iostream-inst.cc: Likewise. * src/c++98/istream-inst.cc: Likewise. * src/c++98/ostream-inst.cc: Likewise. * src/c++98/sstream-inst.cc: Likewise. * src/c++98/streambuf-inst.cc: Likewise. * testsuite/27_io/basic_filebuf/cons/char/copy_neg.cc: New. * testsuite/27_io/basic_fstream/cons/move.cc: New. * testsuite/27_io/basic_fstream/assign/1.cc: New. * testsuite/27_io/basic_ifstream/cons/move.cc: New. * testsuite/27_io/basic_ifstream/assign/1.cc: New. * testsuite/27_io/basic_istringstream/assign/1.cc: New. * testsuite/27_io/basic_istringstream/cons/move.cc: New. * testsuite/27_io/basic_ofstream/cons/move.cc: New. * testsuite/27_io/basic_ofstream/assign/1.cc: New. * testsuite/27_io/basic_ostringstream/assign/1.cc: New. * testsuite/27_io/basic_ostringstream/cons/move.cc: New. * testsuite/27_io/basic_stringstream/assign/1.cc: New. * testsuite/27_io/basic_stringstream/cons/move.cc: New. Added: trunk/libstdc++-v3/src/c++11/ext11-inst.cc - copied, changed from r215458, trunk/libstdc++-v3/src/c++98/ios-inst.cc trunk/libstdc++-v3/src/c++11/ios-inst.cc - copied, changed from r215458, trunk/libstdc++-v3/src/c++98/ios-inst.cc trunk/libstdc++-v3/src/c++11/ios.cc - copied, changed from r215458, trunk/libstdc++-v3/src/c++98/ios.cc trunk/libstdc++-v3/src/c++11/iostream-inst.cc - copied, changed from r215458, trunk/libstdc++-v3/src/c++98/iostream-inst.cc trunk/libstdc++-v3/src/c++11/istream-inst.cc - copied, changed from r215458, trunk/libstdc++-v3/src/c++98/istream-inst.cc trunk/libstdc++-v3/src/c++11/ostream-inst.cc - copied, changed from r215458, trunk/libstdc++-v3/src/c++98/ostream-inst.cc trunk/libstdc++-v3/src/c++11/sstream-inst.cc - copied, changed from r215458, trunk/libstdc++-v3/src/c++98/sstream-inst.cc trunk/libstdc++-v3/src/c++11/streambuf-inst.cc - copied, changed from r215458, trunk/libstdc++-v3/src/c++98/streambuf-inst.cc trunk/libstdc++-v3/testsuite/27_io/basic_filebuf/cons/char/copy_neg.cc trunk/libstdc++-v3/testsuite/27_io/basic_fstream/assign/ trunk/libstdc++-v3/testsuite/27_io/basic_fstream/assign/1.cc trunk/libstdc++-v3/testsuite/27_io/basic_fstream/cons/move.cc trunk/libstdc++-v3/testsuite/27_io/basic_ifstream/assign/ trunk/libstdc++-v3/testsuite/27_io/basic_ifstream/assign/1.cc trunk/libstdc++-v3/testsuite/27_io/basic_ifstream/cons/move.cc
[Bug testsuite/63332] New: problem with VERIFY in ext/random/k_distribution/operators/serialize.cc execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63332 Bug ID: 63332 Summary: problem with VERIFY in ext/random/k_distribution/operators/serialize.cc execution test Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: richard at netbsd dot org Created attachment 33531 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33531action=edit testsuite module updated with couts showing issue is with VERIFY Working with gcc49 on SunOS 5.11 i386 (Omnios) and pkgsrc (32-bit trunk) I came across the following failure: FAIL: ext/random/k_distribution/operators/serialize.cc execution test scratching my head a bit, I added some outputs and found that the problem is with VERIFY and not with the functions being tested. here is my output with the attached (modified) serialize.cc: $ ./a.out u: 2.0e+00 1.5e+00 3.0e+00 2.0e+00 5.0e-01 0.0e+00 1.0e+00 1 -1.08681804426135680e+00 3.0e+00 5.0e-01 0.0e+00 1.0e+00 1 1.89131873404367808e-01 v: 2.0e+00 1.5e+00 3.0e+00 2.0e+00 5.0e-01 0.0e+00 1.0e+00 1 -1.08681804426135680e+00 3.0e+00 5.0e-01 0.0e+00 1.0e+00 1 1.89131873404367808e-01 Assertion failed: u == v, file serialize.cc, line 48, function test01 Abort (core dumped)
[Bug testsuite/63332] problem with VERIFY in ext/random/k_distribution/operators/serialize.cc execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63332 --- Comment #1 from Richard PALO richard at netbsd dot org --- BTW, I'm curious if the problem is related to float rounding in I/O, as in FAIL: ext/random/hypergeometric_distribution/operators/values.cc execution test
[Bug libstdc++/54316] [C++11] move constructor for stringstream
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54316 Bug 54316 depends on bug 53626, which changed state. Bug 53626 Summary: [C++11] move assignment for ifstream https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53626 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug libstdc++/53626] [C++11] move assignment for ifstream
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53626 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org --- Fixed for GCC 5
[Bug libstdc++/54316] [C++11] move constructor for stringstream
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54316 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #10 from Jonathan Wakely redi at gcc dot gnu.org --- Fixed for GCC 5
[Bug libstdc++/63329] std::bind does not define argument_type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63329 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org --- The standard does not require the typedef to be defined (libc++ apparently does it as an extension) See http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4076.html for a generic replacement for std::not1 that is proposed for a future standard.
[Bug libstdc++/63329] std::bind does not define argument_type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63329 --- Comment #3 from Thomas Sanchez thomas.sanchz at gmail dot com --- While it is not really intuitive I understand. Thanks for your time!
[Bug c/63303] Pointer subtraction is broken when using -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63303 --- Comment #11 from mikulas at artax dot karlin.mff.cuni.cz --- Richard Biener: if the middle end tells us that one pointer is greater or equal than the other pointer, we could do unsigned subtraction and shift. But if we don't know which pointer is greater, it gets more complicated: To do correct short* pointer subtraction, we need to subtract pointers using sub %edx, %eax; rcr $1, %eax --- i.e. shift the carry bit back to the topmost bit of the result. According to Agner's tables, rcr with 1-bit count takes 1 tick on AMD and 2 ticks on Intel, so the performance penalty isn't that big. On other architectures that lack rcr, it would be more complicated. Another possibility is to file a defect report on the C standard and request that program in comment 4 be considered invalid. - for example, change the wording to this: If the result multiplied by the size of the array element is not representable in an object of that type, the behavior is undefined. - that would specify that that subtraction is invalid.
[Bug target/63330] vector shuffle resembling vector shift not expanded optimally
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63330 David Edelsohn dje at gcc dot gnu.org changed: What|Removed |Added Target|x86_64-*-*, i?86-*-*|x86_64-*-*, i?86-*-*, ||powerpc*-*-* Status|UNCONFIRMED |NEW Last reconfirmed||2014-09-22 CC||dje at gcc dot gnu.org, ||wschmidt at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from David Edelsohn dje at gcc dot gnu.org --- Confirmed on PPC also.
[Bug middle-end/63197] tc-m68k.c: Wrong warning array subscript is below array bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63197 --- Comment #2 from Jan-Benedict Glaw jbg...@lug-owl.de --- With today's binutils snapshot, there's a gas_assert in front of it, which silences this bogus warning. That needs to be reverted to test GCC wrt. this issue.
[Bug fortran/63331] Fortran -fcompare-debug issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63331 --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org --- Created attachment 33532 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33532action=edit gcc5-pr63331.patch Untested patch to fix (or work around) all but the last 2 FAILs. It seems there is no real need to have DECL_UID differences in this case, we can just use DEBUG_EXPR_DECLs instead of VAR_DECLs for the debughook. That said, the use of DECL_UID in lhd_set_decl_assembler_name is IMHO still problematic, but if DECL_UID appear only after the FE is done with the stuff, it should be less important issue.
[Bug middle-end/63197] tc-m68k.c: Wrong warning array subscript is below array bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63197 Alan Modra amodra at gmail dot com changed: What|Removed |Added CC||amodra at gmail dot com --- Comment #3 from Alan Modra amodra at gmail dot com --- Created attachment 33533 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33533action=edit reduced testcase
[Bug middle-end/63197] tc-m68k.c: Wrong warning array subscript is below array bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63197 Alan Modra amodra at gmail dot com changed: What|Removed |Added Target||x86_64-linux Status|UNCONFIRMED |NEW Last reconfirmed||2014-09-22 Host||x86_64-linux Ever confirmed|0 |1 Build||x86_64-linux
[Bug lto/63333] New: lto, 1to1 segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=6 Bug ID: 6 Summary: lto, 1to1 segmentation fault Product: gcc Version: 4.9.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: a...@cloudius-systems.com A random change (adding a new virtual function) in a program produced this. I realize this is not sufficient to reproduce, but maybe this can jog someone's memory. If not, I can try to minimize. (gdb) bt #0 0x7f2f900bd887 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 #1 0x7f2f900bef78 in __GI_abort () at abort.c:89 #2 0x009eed13 in real_abort () at ../../gcc/diagnostic.c:1200 #3 diagnostic_action_after_output (context=context@entry=0x167a700 global_diagnostic_context, diagnostic=0x7fffb8503f60) at ../../gcc/diagnostic.c:447 #4 0x00eede6e in diagnostic_report_diagnostic(diagnostic_context*, diagnostic_info*) () at ../../gcc/diagnostic.c:804 #5 0x009eef5f in internal_error (gmsgid=gmsgid@entry=0xf8aafe %s) at ../../gcc/diagnostic.c:1136 #6 0x00697bdc in crash_signal (signo=11) at ../../gcc/toplev.c:339 #7 signal handler called #8 htab_hash_string (p=0x0) at ../../libiberty/hashtab.c:839 #9 0x00569f9d in hash (r=optimized out) at ../../gcc/dwarf2out.c:7501 #10 find_slot (insert=INSERT, value=0x7fffb8504650, this=0x7fffb8504648) at ../../gcc/hash-table.h:505 #11 lookup_external_ref (map=..., die=die@entry=0x7f2f897f70f0) at ../../gcc/dwarf2out.c:7529 #12 0x00569c44 in optimize_external_refs_1 (die=0x7f2f894957d0, map=map@entry=...) at ../../gcc/dwarf2out.c:7567 #13 0x00aa0eff in optimize_external_refs_1(die_struct*, hash_tableexternal_ref_hasher, xcallocator) () at ../../gcc/dwarf2out.c:7571 #14 0x00aa0eff in optimize_external_refs_1(die_struct*, hash_tableexternal_ref_hasher, xcallocator) () at ../../gcc/dwarf2out.c:7571 #15 0x00e634a2 in optimize_external_refs(die_struct*) () at ../../gcc/dwarf2out.c:7621 #16 0x00e63205 in output_comp_unit(die_struct*, int) () at ../../gcc/dwarf2out.c:8807 #17 0x00561d12 in dwarf2out_finish (filename=optimized out) at ../../gcc/dwarf2out.c:24252 #18 0x00e9664e in compile_file() () at ../../gcc/toplev.c:601 #19 0x00e960e6 in do_compile () at ../../gcc/toplev.c:1917 #20 toplev_main(int, char**) () at ../../gcc/toplev.c:1995 #21 0x7f2f900a9d65 in __libc_start_main (main=0xa1a5e0 main(int, char**), argc=25, argv=0x7fffb8504b88, init=optimized out, fini=optimized out, rtld_fini=optimized out, stack_end=0x7fffb8504b78) at libc-start.c:285 #22 0x00e1365c in _start () In frame 9, die-die_id is zeroed.
[Bug target/63334] New: -m16 should turn off MMX, SSE, AVX as well as VEX-encoded scalar instructions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63334 Bug ID: 63334 Summary: -m16 should turn off MMX, SSE, AVX as well as VEX-encoded scalar instructions Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: hjl.tools at gmail dot com CC: kirill.yukhin at intel dot com Target: x86 MMX, SSE, AVX as well as VEX-encoded scalar instructions are supported in 16-bit mode. -m16 should turn them off: [hjl@gnu-6 gcc]$ touch x.i [hjl@gnu-6 gcc]$ ./xgcc -B./ -m16 x.i -march=native -v -S Reading specs from ./specs COLLECT_GCC=./xgcc Target: x86_64-unknown-linux-gnu Configured with: /export/gnu/import/git/gcc/configure --enable-languages=c,c++,fortran --disable-bootstrap --prefix=/usr/gcc-5.0.0 --with-local-prefix=/usr/local --enable-gnu-indirect-function --with-fpmath=sse Thread model: posix gcc version 5.0.0 20140911 (experimental) (GCC) COLLECT_GCC_OPTIONS='-B' './' '-m16' '-march=native' '-v' '-S' ./cc1 -fpreprocessed x.i -march=haswell -mmmx -mno-3dnow -msse -msse2 -msse3 -mssse3 -mno-sse4a -mcx16 -msahf -mmovbe -maes -mno-sha -mpclmul -mpopcnt -mabm -mno-lwp -mfma -mno-fma4 -mno-xop -mbmi -mbmi2 -mno-tbm -mavx -mavx2 -msse4.2 -msse4.1 -mlzcnt -mno-rtm -mno-hle -mrdrnd -mf16c -mfsgsbase -mno-rdseed -mno-prfchw -mno-adx -mfxsr -mxsave -mxsaveopt -mno-avx512f -mno-avx512er -mno-avx512cd -mno-avx512pf -mno-prefetchwt1 -mno-clflushopt -mno-xsavec -mno-xsaves -mno-avx512dq -mno-avx512bw -mno-avx512vl --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=8192 -mtune=haswell -quiet -dumpbase x.i -m16 -auxbase x -version -o x.s GNU C (GCC) version 5.0.0 20140911 (experimental) (x86_64-unknown-linux-gnu) compiled by GNU C version 4.8.3 20140624 (Red Hat 4.8.3-1), GMP version 5.1.2, MPFR version 3.1.2, MPC version 1.0.1 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 GNU C (GCC) version 5.0.0 20140911 (experimental) (x86_64-unknown-linux-gnu) compiled by GNU C version 4.8.3 20140624 (Red Hat 4.8.3-1), GMP version 5.1.2, MPFR version 3.1.2, MPC version 1.0.1 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Compiler executable checksum: 86d44baffb9b5e3d04fa82fe0af72a3d COMPILER_PATH=./ LIBRARY_PATH=./:/lib/../lib64/:/usr/lib/../lib64/:/lib/:/usr/lib/ COLLECT_GCC_OPTIONS='-B' './' '-m16' '-march=native' '-v' '-S' [hjl@gnu-6 gcc]$
[Bug libgcc/63335] New: GCC:failures for vector double on calls to bif vec_[all|any]_[nge|nle]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63335
Bug ID: 63335
Summary: GCC:failures for vector double on calls to bif
vec_[all|any]_[nge|nle]
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgcc
Assignee: unassigned at gcc dot gnu.org
Reporter: lei at ca dot ibm.com
Calls to the following vector bifs fails with gcc with type vector double.
Passes for vector float.
The same failures are on both BE and LE machines.
vec_all_nge
vec_any_nge
vec_all_nle
vec_any_nle
-
RELEASE LEVEL INFO:
Fails on both gcc 4.8.2 and 4.9.2
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/powerpc64le-linux-gnu/4.8/lto-wrapper
Target: powerpc64le-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.8.2-19ubuntu1'
--with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs
--enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.8 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib --enable-nls
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-libmudflap
--disable-libsanitizer --disable-libquadmath --enable-plugin --with-system-zlib
--disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.8-ppc64el/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-ppc64el
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-ppc64el
--with-arch-directory=ppc64el --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-secureplt --with-cpu=power7 --with-tune=power8
--disable-multilib --enable-multiarch --disable-werror --with-long-double-128
--enable-checking=release --build=powerpc64le-linux-gnu
--host=powerpc64le-linux-gnu --target=powerpc64le-linux-gnu
Thread model: posix
gcc version 4.8.2 (Ubuntu 4.8.2-19ubuntu1)
$ /opt/at8.0/bin/gcc -v
Using built-in specs.
COLLECT_GCC=/opt/at8.0/bin/gcc
COLLECT_LTO_WRAPPER=/opt/at8.0/libexec/gcc/powerpc64le-linux-gnu/4.9.2/lto-wrapper
Target: powerpc64le-linux-gnu
Configured with:
/home/tuliom/at8.0-0/at8.0-0.ubuntu-14_ppc64le_ppc64le/sources/gcc/configure
--build=powerpc64le-linux-gnu --host=powerpc64le-linux-gnu
--target=powerpc64le-linux-gnu --with-cpu=default64 --prefix=/opt/at8.0
--with-long-double-128 --enable-secureplt --disable-multilib
--enable-threads=posix --enable-languages=c,c++,fortran,go
--enable-__cxa_atexit --enable-shared --enable-checking=release --enable-lto
--enable-gnu-indirect-function --enable-initfini-array
--with-gmp-include=/opt/at8.0/include --with-gmp-lib=/opt/at8.0/lib64
--with-mpfr-include=/opt/at8.0/include --with-mpfr-lib=/opt/at8.0/lib64
--with-mpc-include=/opt/at8.0/include --with-mpc-lib=/opt/at8.0/lib64
--without-ppl --without-cloog --without-libelf
--with-host-libstdcxx='-L/opt/at8.0/lib64 -lstdc++ -lsupc++ -lgmp -lgmpxx -lm'
--with-cpu=power7 --with-tune=power8
Thread model: posix
gcc version 4.9.2 20140812 (Advance-Toolchain-at8.0) [ibm/gcc-4_9-branch,
revision: 213889 merged from gcc-4_9-branch, revision 213872] (GCC)
-
STEPS TO REPRODUCE: (Reduce the code in the README.ksh file as much as
possible)
$ gcc -m64 -fabi-version=4 -mcpu=power8 a.c
$ a.out
-
ACTUAL OUTPUT:
99.00 99.00
Actual: 1 Expected: 0
return code: 1
-
EXPECTED OUTPUT:
return code: 0
-
TESTCASE SOURCE:
$ cat a.c
#include stdio.h
#include altivec.h
#ifdef _TEST_FLOAT
vector float vec = (vector float ) {99.0, 99.0, 99.0, 99.0};
#else
vector double vec = (vector double) {99.0, 99.0};
#endif
int main() {
int actual = -1;
actual = vec_all_nge(vec, vec);
if ( actual != 0) {
printf(Actual: %d Expected: 0\n, actual);
return 1;
}
return 0;
}
[Bug c/63336] New: cilkplus array notation ICE in find_rank
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63336 Bug ID: 63336 Summary: cilkplus array notation ICE in find_rank Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: tprince at computer dot org Created attachment 33534 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33534action=edit pre-processed C source with cilkplus array notation $ gcc -std=c99 -c -fcilkplus -v s422.i Using built-in specs. COLLECT_GCC=gcc Target: x86_64-unknown-cygwin Configured with: ../configure --prefix=/usr/local/gcc5.0 --enable-languages='c c ++ fortran' --enable-libgomp --enable-threads=posix --disable-__cxa_atexit --wit h-dwarf2 --without-libiconv-prefix --without-libintl-prefix --with-system-zlib - -disable-werror --without-cloog --without-isl Thread model: posix gcc version 5.0.0 20140922 (experimental) (GCC) COLLECT_GCC_OPTIONS='-std=c99' '-c' '-fcilkplus' '-v' '-mtune=generic' '-march=x 86-64' '-pthread' /usr/local/gcc5.0/libexec/gcc/x86_64-unknown-cygwin/5.0.0/cc1.exe -fpreprocesse d s422.i -quiet -dumpbase s422.i -mtune=generic -march=x86-64 -auxbase s422 -std =c99 -version -fcilkplus -o /tmp/ccCsOctk.s GNU C (GCC) version 5.0.0 20140922 (experimental) (x86_64-unknown-cygwin) compiled by GNU C version 5.0.0 20140922 (experimental), GMP version 6.0 .0, MPFR version 3.1.2, MPC version 1.0.2 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 GNU C (GCC) version 5.0.0 20140922 (experimental) (x86_64-unknown-cygwin) compiled by GNU C version 5.0.0 20140922 (experimental), GMP version 6.0 .0, MPFR version 3.1.2, MPC version 1.0.2 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Compiler executable checksum: 418ff77cc465e61e11d739c56dbe80c7 s422.c: In function ‘s422_’: s422.c:86:5: internal compiler error: in find_rank, at c-family/array-notation-c ommon.c:231 } ^ Please submit a full bug report,
[Bug c/63337] New: Hexadecimal exponent: improvements to error message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63337 Bug ID: 63337 Summary: Hexadecimal exponent: improvements to error message Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: dmalcolm at gcc dot gnu.org As discussed in the thread here: https://gcc.gnu.org/ml/gcc/2014-09/msg00282.html if the user mistakenly tries to use the e suffix for a exponent marker with a hexadecimal constant, the warning could be improved. $ cat /tmp/foo.c float f = 0x3ffe+63; $ gcc/cc1 /tmp/foo.c /tmp/foo.c:1:11: error: invalid suffix +63 on integer constant float f = 0x3ffe+63; ^ A better warning might be something like: /tmp/foo.c:1:11: error: invalid suffix +63 on integer constant float f = 0x3ffe+63; ^ /tmp/foo.c:1:11: hint: if you meant for e to be an exponent, use p as an exponent suffix for hexadecimal constants: float f = 0x3ffe+63; ^ float f = 0x3ffp+63; ^ or somesuch; maybe even just: /tmp/foo.c:1:11: error: use p rather than e for exponents for hexadecimal constants float f = 0x3ffe+63; ^ (how far can we go down the road of actually outputting a patch?)
[Bug preprocessor/63337] Hexadecimal exponent: improvements to error message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63337 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-09-22 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org --- That would be nice. Another great candidate for https://gcc.gnu.org/ml/gcc-patches/2014-08/msg02723.html
[Bug target/63334] -m16 should turn off unsupported instructions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63334 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Summary|-m16 should turn off MMX, |-m16 should turn off |SSE, AVX as well as |unsupported instructions |VEX-encoded scalar | |instructions| --- Comment #1 from H.J. Lu hjl.tools at gmail dot com --- Only VEX/EVEX instructions aren't supported in 16-bit mode.
[Bug target/63335] GCC:failures for vector double on calls to bif vec_[all|any]_[nge|nle]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63335 David Edelsohn dje at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-09-22 CC||dje at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from David Edelsohn dje at gcc dot gnu.org --- Confirmed.
[Bug c++/61465] Bogus parameter set but not used warning in constructor initialization list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61465 --- Comment #5 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Mon Sep 22 18:47:16 2014 New Revision: 215476 URL: https://gcc.gnu.org/viewcvs?rev=215476root=gccview=rev Log: PR c++/61465 * call.c (convert_like_real) [ck_identity]: Call mark_rvalue_use after pulling out an element from a CONSTRUCTOR. Added: branches/gcc-4_9-branch/gcc/testsuite/g++.dg/warn/Wunused-parm-6.C Modified: branches/gcc-4_9-branch/gcc/cp/ChangeLog branches/gcc-4_9-branch/gcc/cp/call.c
[Bug c++/62219] [c++11] Spurious error for lambda in a friend function of a class template with a default template parameters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62219 --- Comment #3 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org --- Author: paolo Date: Mon Sep 22 19:21:20 2014 New Revision: 215477 URL: https://gcc.gnu.org/viewcvs?rev=215477root=gccview=rev Log: /cp 2014-09-22 Paolo Carlini paolo.carl...@oracle.com PR c++/62219 * pt.c (check_default_tmpl_args): Check LAMBDA_FUNCTION_P. /testsuite 2014-09-22 Paolo Carlini paolo.carl...@oracle.com PR c++/62219 * g++.dg/cpp0x/lambda/lambda-template14.C: New. Added: trunk/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-template14.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog
