[Bug c++/58193] New: init_priority attribute doesn't work on non-class types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58193
Bug ID: 58193
Summary: init_priority attribute doesn't work on non-class
types
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: wielkiegie at gmail dot com
__attribute__ ((init_priority (x))) makes it possible to order the
initialization of global objects. However, gcc rejects this attribute on
globals of non-class (or struct) types. It is still possible for gcc to emit a
constructor in .init_array section when non-class global is initialized by a
function, but it's not possible to set priority of such initializer.
$ cat i1.cpp
extern int bar();
const int foo __attribute__ ((init_priority (1000))) = bar();
$ g++ i1.cpp -c
i1.cpp:3:52: error: can only use ‘init_priority’ attribute on file-scope
definitions of objects of class type
const int foo __attribute__ ((init_priority (1000))) = bar();
^
$
The workaround for such a case is to wrap the type in struct.
$ cat i2.cpp
template
class WrapInStruct {
public:
WrapInStruct() : _value() {}
WrapInStruct(const Type& value) : _value(value) {}
operator Type() const { return _value; }
private:
Type _value;
};
extern int bar();
const WrapInStruct foo __attribute__ ((init_priority (1000))) = bar();
$ g++ i2.cpp -c
$
[Bug fortran/58171] [F03] Incorrect error message on invalid code when using type constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58171 janus at gcc dot gnu.org changed: What|Removed |Added CC||janus at gcc dot gnu.org Summary|Incorrect error message on |[F03] Incorrect error |invalid code when using |message on invalid code |class constructor |when using type constructor --- Comment #1 from janus at gcc dot gnu.org --- Well, I think in situations like this it is not trivial for the compiler to guess what you want to do: In principle 'structure constructors' and 'constructor functions' (i.e. generic procedures with the same name as the derived type) can be used alongside each other. In your case: Since the call of 'cps' does not have the right number of arguments to match the 'newCps' function, it is interpreted as a 'structure constructor', but this also fails since your type has private components. The compiler can not really tell whether you forgot one argument in the call, or if you actually intended to call a structure constructor but 'wrongly' gave the type private components. Btw, if you rename the type, you will get the following: Error: There is no specific function for the generic 'cps' at (1) Does that sound more like what you were expecting? If yes, one could think about adding a special error for cases like this (where the type has private components and a 'constructor' function is present).
[Bug fortran/46271] [F03] OpenMP default(none) and procedure pointers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46271 janus at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from janus at gcc dot gnu.org --- (In reply to janus from comment #2) > Here is a simple patch to accept version A: ... which has been committed to 4.9 trunk: Author: janus Date: Mon Aug 19 09:03:20 2013 New Revision: 201835 URL: http://gcc.gnu.org/viewcvs?rev=201835&root=gcc&view=rev Log: 2013-08-19 Janus Weil PR fortran/46271 * openmp.c (resolve_omp_clauses): Bugfix for procedure pointers. 2013-08-19 Janus Weil PR fortran/46271 * gfortran.dg/gomp/proc_ptr_1.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/gomp/proc_ptr_1.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/openmp.c trunk/gcc/testsuite/ChangeLog I think the rejection of version B is ok (see above discussion), therefore I'm closing this PR. Thanks for the report!
[Bug c++/58191] Can't use boost transform_iterator with _GLIBCXX_DEBUG
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58191 Paolo Carlini changed: What|Removed |Added Severity|major |normal
[Bug c++/58191] Can't use boost transform_iterator with _GLIBCXX_DEBUG
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58191 Paolo Carlini changed: What|Removed |Added CC||fdumont at gcc dot gnu.org --- Comment #2 from Paolo Carlini --- With 100 KB of code to look at, this could be anything, could be front-end, could be library, could well be boost. Francois, did we change anything in the library for 4.8.x?
[Bug c++/58191] Can't use boost transform_iterator with _GLIBCXX_DEBUG
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58191 --- Comment #3 from Daniel Krügler --- First, this issue should be categorized as belonging to the component "libstdc++", not to "c++". Second, the defect report is invalid, because std::upper_bound requires a minimum iterator category of "forward iterator", but boost::transform_iterator with a function object that returns a value (not a real reference) has an iterator category "input iterator", which is correct, since forward iterators are required to return a real reference for operator*.
[Bug c++/58191] Can't use boost transform_iterator with _GLIBCXX_DEBUG
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58191 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #4 from Paolo Carlini --- Oh well, thanks Daniel for helping on this.
[Bug c++/58193] init_priority attribute doesn't work on non-class types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58193 Paolo Carlini changed: What|Removed |Added Severity|normal |enhancement
[Bug c++/58191] Can't use boost transform_iterator with _GLIBCXX_DEBUG
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58191
--- Comment #5 from Daniel Krügler ---
(In reply to Paolo Carlini from comment #2)
> Francois, did we change anything in the library for 4.8.x?
I think that Francois added more iterator concept checking and this one looks
correct. Unfortunately I would say, this is correct, because the standard says
so, but from a practical point of view, std::upper_bound "just works" for any
forward traversal iterator and it does not require that the return type of
operator* *really* is a reference type. We also cannot blame boost here,
because it is not their fault that the standard requires for forward iterators
to have a real reference return type for iterator dereference. My
recommendation to the issue reporter would be to provide a function object that
returns a real reference. This can be easily done by a unary functor adaptor
such as the following one:
template
struct LValueUnaryFunctionAdaptor
{
typedef typename std::result_of::type
value_type;
LValueUnaryFunctionAdaptor(UnaryFunction func) : func(func) {}
typedef const value_type& result_type;
result_type operator()(ArgumentType arg) const
{
return res = func(arg);
}
private:
UnaryFunction func;
mutable value_type res;
};
template
inline
LValueUnaryFunctionAdaptor
make_LValueUnaryFunction(UnaryFunction func)
{
return LValueUnaryFunctionAdaptor(func);
}
So instead of
calc_value
he could use
make_LValueUnaryFunction(calc_value)
This trick doesn't make the transform_iterator fully conforming, but it should
convince the compile-time test machinery.
[Bug c++/58191] Can't use boost transform_iterator with _GLIBCXX_DEBUG
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58191 --- Comment #6 from Danil Ilinykh --- Thank you!
[Bug rtl-optimization/58034] [4.8/4.9 Regression] glibc nptl/tst-cleanup2 fail due to scheduling
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58034 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED CC||jakub at gcc dot gnu.org Resolution|--- |INVALID --- Comment #7 from Jakub Jelinek --- I agree this looks like a glibc test issue rather than gcc bug.
[Bug other/58133] GCC should emit arm assembly following the unified syntax
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58133 Richard Earnshaw changed: What|Removed |Added Target||arm Status|UNCONFIRMED |NEW Last reconfirmed||2013-08-19 Ever confirmed|0 |1 --- Comment #2 from Richard Earnshaw --- Unified syntax is currently only supported for ARM and Thumb2 stated (for the latter it's mandatory). Thumb1, for historical reasons, still uses the old syntax. This is a known issue.
[Bug libstdc++/58191] Can't use boost transform_iterator with _GLIBCXX_DEBUG
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58191 Jonathan Wakely changed: What|Removed |Added Component|c++ |libstdc++ --- Comment #7 from Jonathan Wakely --- (In reply to Daniel Krügler from comment #5) > (In reply to Paolo Carlini from comment #2) > > Francois, did we change anything in the library for 4.8.x? > > I think that Francois added more iterator concept checking and this one > looks correct. I think the change in behaviour is a consequence of http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53263#c11 Potentially we could disable the partitioning checks when input iterators are used (unless _GLIBCXX_DEBUG_PEDANTIC is defined) or explicitly check for input iterators and give a better diagnostic.
[Bug fortran/58100] Spurious "DO loop at (1) will be executed zero times" warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58100 --- Comment #4 from Thomas Koenig --- In principle, we could also introduce a !GCC$ NOWARN directive, which could suppress all warnings on the following statement. I'm not volunteering, though :-)
[Bug other/58133] GCC should emit arm assembly following the unified syntax
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58133 --- Comment #3 from Sven --- (In reply to Richard Earnshaw from comment #2) > This is a known issue. So what needs to be done? Where do I find the source/configuration/whatever of the code generator for thumb mode?
[Bug libstdc++/58191] Can't use boost transform_iterator with _GLIBCXX_DEBUG
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58191 --- Comment #8 from Paolo Carlini --- Thanks everybody. Lower priority wrt regressions, I agree we could do even better here, just bailing out for input iterators would be Ok with me too (wouldn't be the first time we do that), but anything that suits you and our debug-mode expert Francois is basically Ok with me. Thanks again.
[Bug fortran/58182] [4.9 Regression] ICE with global binding name used as a FUNCTION
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58182
janus at gcc dot gnu.org changed:
What|Removed |Added
Keywords||ice-on-invalid-code
CC||janus at gcc dot gnu.org
--- Comment #2 from janus at gcc dot gnu.org ---
There may be other ways to fix this, but a particularly simple one is just
flipping the checks in the if statement which produces the ICE:
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c(revision 201834)
+++ gcc/fortran/resolve.c(working copy)
@@ -10114,11 +10114,11 @@ gfc_verify_binding_labels (gfc_symbol *sym)
&& ((gsym->type != GSYM_SUBROUTINE && gsym->type != GSYM_FUNCTION)
|| (gsym->defined && sym->attr.if_source != IFSRC_IFBODY))
&& sym != gsym->ns->proc_name
- && (strcmp (gsym->sym_name, sym->name) != 0
- || module != gsym->mod_name
+ && (module != gsym->mod_name
+ || strcmp (gsym->sym_name, sym->name) != 0
|| (module && strcmp (module, gsym->mod_name) != 0)))
{
- /* Print an error if the procdure is defined multiple times; we have to
+ /* Print an error if the procedure is defined multiple times; we have to
exclude references to the same procedure via module association or
multiple checks for the same procedure. */
gfc_error ("Procedure %s with binding label %s at %L uses the same "
With this I get the following:
mod2.f90:2.6:
use fg
1
mod2.f90:1.8:
module f
2
Error: Procedure f with binding label f at (1) uses the same global identifier
as entity at (2)
This is slightly different from the error message in comment 0, but it still
sounds reasonable to me.
Btw, does it make sense to have a dummy procedure with 'BIND(C)' at all? I have
the feeling that this might be something which should be forbidden in general
... (?)
[Bug fortran/58182] [4.9 Regression] ICE with global binding name used as a FUNCTION
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58182 --- Comment #3 from janus at gcc dot gnu.org --- (In reply to janus from comment #2) > There may be other ways to fix this, but a particularly simple one is just > flipping the checks in the if statement which produces the ICE: Note: The patch in comment 2 regtests cleanly.
[Bug fortran/52832] [F03] ASSOCIATE construct with proc-pointer selector is rejected
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52832 --- Comment #4 from janus at gcc dot gnu.org --- (In reply to janus from comment #3) > (I wonder whether we properly handle proc-ptr-valued functions as target in > a proc-ptr assignment. Should check that ...) Apparently this works, cf. PR 36704 etc. Not sure why it fails here. One problem is of course that in an actual proc-ptr assignment, we can tell for sure that we're dealing with a proc-ptr assignment (because the lhs is declared as a procedure pointer), while in an ASSOCIATE statement we have no prior information on the identify of the lhs (but have to deduce it from the rhs).
[Bug fortran/53655] [OOP] CLASS-related warnings: "__copy" defined but not used; "default initializer" warnings
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53655 janus at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-08-19 CC||janus at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #3 from janus at gcc dot gnu.org --- (In reply to Tobias Burnus from comment #1) > c) One gets the bogus error: > warning: ‘__copy_MAIN___T2’ defined but not used [-Wunused-function] > It probably should be marked as DECL_ARTIFICIAL(). This problem has apparently been fixed at some point. I see it neither with 4.7.4, 4.8.2 nor with trunk.
[Bug fortran/53655] [OOP] CLASS-related warnings: "__copy" defined but not used; "default initializer" warnings
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53655
--- Comment #4 from janus at gcc dot gnu.org ---
(In reply to Tobias Burnus from comment #1)
> a) For foo's "x" there is the warning:
> "Derived-type dummy argument 'x' at (1) was declared INTENT(OUT) but was not
> set and does not have a default initializer"
> As "t" has no components, the warning doesn't make sense.
This is easily fixed by the following:
Index: gcc/fortran/trans-decl.c
===
--- gcc/fortran/trans-decl.c(revision 201834)
+++ gcc/fortran/trans-decl.c(working copy)
@@ -4745,7 +4745,8 @@
gfc_warning ("Dummy argument '%s' at %L was declared "
"INTENT(OUT) but was not set", sym->name,
&sym->declared_at);
- else if (!gfc_has_default_initializer (sym->ts.u.derived))
+ else if (!gfc_has_default_initializer (sym->ts.u.derived)
+ && !sym->ts.u.derived->attr.zero_comp)
gfc_warning ("Derived-type dummy argument '%s' at %L was "
"declared INTENT(OUT) but was not set and "
"does not have a default initializer",
[Bug fortran/58171] [F03] Incorrect error message on invalid code when using type constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58171 --- Comment #2 from Andrew Benson --- I see your point about it not being obvious what was intended in situations like this. Something such as: Error: There is no specific function for the generic 'cps' at (1) would definitely be more helpful if it were possible to generate.
[Bug fortran/58182] [4.9 Regression] ICE with global binding name used as a FUNCTION
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58182 --- Comment #4 from Andrew Benson --- "Btw, does it make sense to have a dummy procedure with 'BIND(C)' at all? I have the feeling that this might be something which should be forbidden in general ... (?)" Possibly not... This was reduced from the FGSL library source, so not my own code. I could check in the original if the BIND(C) is actually needed.
[Bug fortran/53655] [OOP] CLASS-related warnings: "__copy" defined but not used; "default initializer" warnings
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53655
--- Comment #5 from janus at gcc dot gnu.org ---
(In reply to Tobias Burnus from comment #1)
> b) For bar's "x" there is no warning as it is sym->attr.referenced, but I
> think one should warn that the "declared type" does not have an initializer.
With 4.9 trunk, the following code is generated for 'bar':
bar (struct __class_MAIN___T2 & restrict x)
{
if (x->_vptr->_final != 0B)
{
{
struct array0_unknown desc.0;
desc.0.dtype = 600;
desc.0.data = (void * restrict) x->_data;
x->_vptr->_final (&desc.0, x->_vptr->_size, 0);
}
}
(void) __builtin_memcpy ((void *) x->_data, (void *) x->_vptr->_def_init,
(unsigned long) x->_vptr->_size);
}
The _final call is new in 4.9, but the memcpy from _def_init appeared already
with 4.7 and 4.8. (Possibly this is what sets sym->referenced?)
However, I'm not convinced that one should throw a warning here: Even if the
declared type does not have a default initializer, an extended type might have
one and of course we don't know the actual (dynamic) type of the class variable
at compile time (that's why we have the _def_init after all).
[Bug c++/58192] G++ emits incorrect code when passing enum classes as function parameters
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58192 Kenton Varda changed: What|Removed |Added Attachment #30672|0 |1 is obsolete|| --- Comment #3 from Kenton Varda --- Created attachment 30673 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30673&action=edit Demonstration of enum class passing bug (v2) The first version of my demo was doing slightly weird things with unions in main(). This was vestigial code from my attempts to narrow down the bug, but wasn't actually necessary to trigger it. So, I simplified it.
[Bug c++/58192] G++ emits incorrect code when passing enum classes as function parameters
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58192 Paolo Carlini changed: What|Removed |Added Keywords||wrong-code Priority|P3 |P2 Status|UNCONFIRMED |NEW Last reconfirmed||2013-08-19 Ever confirmed|0 |1 --- Comment #4 from Paolo Carlini --- I have yet to analyze this in detail, but let's play safe and confirm it as wrong-code.
[Bug c++/58192] G++ emits incorrect code when passing enum classes as function parameters
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58192
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
||rth at gcc dot gnu.org
--- Comment #5 from Jakub Jelinek ---
The difference is that in the S1set(Foo) case
setup_incoming_promotions in combine.c says that the argument has non-zero mask
of 0xff, because the function is local to the TU, while for S2 all caller's
aren't guaranteed local and thus it isn't optimized. The argument type is Foo
(QImode) passed in SImode register, guess combine.c expects that caller
zero-extends in this case, but it doesn't (in neither case).
enum class Foo : unsigned char { FOO };
struct S1
{
struct
{
unsigned int i;
void __attribute__((noinline))
set (Foo foo)
{
i = static_cast (foo);
}
} x;
};
struct S2
{
struct X
{
unsigned int i;
void __attribute__((noinline))
set (Foo foo)
{
i = static_cast (foo);
}
};
X x;
};
struct T { unsigned short i; Foo f; unsigned char c; };
__attribute__((noinline)) void
baz (unsigned int x)
{
if (x != 0) __builtin_abort ();
}
void
bar (T t)
{
S1 s1;
s1.x.set(t.f);
baz (s1.x.i);
S2 s2;
s2.x.set(t.f);
baz (s2.x.i);
}
int
main()
{
T t = { 0xabcd, Foo::FOO, 0xef};
bar (t);
}
For:
unsigned int v1, v2;
__attribute__((noinline, noclone)) static void
foo (unsigned char a)
{
v1 = a;
}
__attribute__((noinline, noclone)) void
bar (unsigned char a)
{
v2 = a;
}
void
baz (unsigned int a)
{
foo (a);
bar (a);
}
the situation is similar for foo/bar (foo optimizes and doesn't zero extend
from 8 to 32 bits, bar doesn't), but the caller in this case always zero
extends.
[Bug c++/58194] New: default argument for constructor outside of class DR 1344
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58194
Bug ID: 58194
Summary: default argument for constructor outside of class DR
1344
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: dushistov at mail dot ru
Such simple code accepted by gcc 4.8.1:
struct Foo {
Foo(const char *);
};
Foo::Foo(const char *str = 0)
{
}
There is DR 1344 about it:
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#1344
and according to disscussion in clang mailing list:
http://clang-developers.42468.n3.nabble.com/Reason-for-Diagnostic-on-default-ctors-redeclaration-td4032117.html
Quote:
This was last discussed by WG21 at the Bloomington meeting. Notes from there:
"Consensus: Make this ill-formed as suggested in the write-up. Core issue
1344. Priority 0, Doug drafting."
So it would be nice, if gcc emit error on such bad code.
[Bug fortran/58182] [4.9 Regression] ICE with global binding name used as a FUNCTION
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58182 --- Comment #5 from janus at gcc dot gnu.org --- (In reply to Andrew Benson from comment #4) > "Btw, does it make sense to have a dummy procedure with 'BIND(C)' at all? I > have the feeling that this might be something which should be forbidden in > general ... (?)" Trying to answer that myself: It seems like at least BIND(C,NAME=...) is forbidden for a dummy procedure (and is indeed rejected by gfortran). Quote from F08: C1254 (R1229) A proc-language-binding-spec with a NAME= specifier shall not be specified in the function-stmt or subroutine-stmt of an internal procedure, or of an interface body for an abstract interface or a dummy procedure. However, BIND(C) without NAME=... seems to be allowed.
[Bug c++/58178] variant function name was used for user defined constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58178 --- Comment #3 from chihin ko --- a.out execution does not have problem, it is the debugging support would have problem.
[Bug rtl-optimization/58195] New: Missed optimization opportunity when returning a conditional
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58195
Bug ID: 58195
Summary: Missed optimization opportunity when returning a
conditional
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: warp at iki dot fi
When compiling the following function:
int a(int input)
{
return input == 0 ? 0 : -input;
}
gcc is unable to see that the conditional and returning 0 can be optimized
away, producing:
movl%edi, %edx
xorl%eax, %eax
negl%edx
testl %edi, %edi
cmovne %edx, %eax
ret
For the record, I found out the above when I was testing what gcc would do with
this function:
int a(int input)
{
int value = 0;
for(int n = input; n != 0; ++n)
++value;
return value;
}
gcc is able to optimize that into the same asm code as above, but no further
(not even if the conditional is written explicitly, as written in the first
function above.)
[Bug libstdc++/58196] New: std::align is missing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58196
Bug ID: 58196
Summary: std::align is missing
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: augustorighetto at gmail dot com
g++ 4.8.1 can't find std::align in .
$ g++ --version
g++ (Ubuntu 4.8.1-2ubuntu1~12.04) 4.8.1
Copyright (C) 2013 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
#include
#include
#include
int main(int argc, char* argv[]) {
float* f = nullptr;
size_t space = 10;
if (std::align(2, sizeof(float), f, space)) {
std::cout << "yes" << std::endl;
} else {
std::cout << "no" << std::endl;
}
return EXIT_SUCCESS;
}
$ g++ -o foo -std=c++11 Main.cpp
Main.cpp: In function ‘int main(int, char**)’:
Main.cpp:8:9: error: ‘align’ is not a member of ‘std’
if (std::align(2, sizeof(float), f, space)) {
^
[Bug c++/58178] variant function name was used for user defined constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58178 --- Comment #4 from Paolo Carlini --- But we can't reproduce the issue on x86_64-linux. My grep gives: 00400742 W _ZN4baseC1Ev 00400742 W _ZN4baseC2Ev are you on linux? Please provide information about your target, otherwise this issue will be closed very soon.
[Bug libstdc++/58196] std::align is missing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58196 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Paolo Carlini --- Yes. But the implementation status table clearly says NO: http://gcc.gnu.org/onlinedocs/libstdc++/manual/status.html#status.iso.2011 and generally we don't use Bugzilla to track unimplemented features.
[Bug c++/58194] default argument for constructor outside of class DR 1344
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58194 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |SUSPENDED Last reconfirmed||2013-08-19 Ever confirmed|0 |1 --- Comment #1 from Paolo Carlini --- The issue is still in drafting status, thus I'm suspending this.
[Bug fortran/53655] [OOP] "default initializer" warnings
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53655 janus at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |janus at gcc dot gnu.org Summary|[OOP] CLASS-related |[OOP] "default initializer" |warnings: "__copy" defined |warnings |but not used; "default | |initializer" warnings | --- Comment #6 from janus at gcc dot gnu.org --- The patch in comment 4 regtests cleanly. Will commit as obvious.
[Bug other/58197] New: subversion-1.8.x breaks script contrib/gcc_update
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58197
Bug ID: 58197
Summary: subversion-1.8.x breaks script contrib/gcc_update
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: winfried.mag...@t-online.de
Hi,
installing subversion-1.8.x breaks checkout of the svn-repository because
'svn info' adds an additional line.
The command used:
svn co svn://gcc.gnu.org/svn/gcc/branches/gcc-4_8-branch gcc-4.8-branch
(cd gcc-4.8-branch; ./contrib/gcc_update)
the diff for 'svn info' with subversion-1.7.11 and subversion-1.8.1:
# diff -u svn-info-1711 svn-info-181
--- svn-info-1711 2013-08-19 22:10:59.480215273 +0200
+++ svn-info-1812013-08-19 22:09:48.011278900 +0200
@@ -1,6 +1,7 @@
Path: .
Working Copy Root Path: /home/winfried/gcc-svn/gcc-4.8-branch
URL: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_8-branch
+Relative URL: ^/branches/gcc-4_8-branch
Repository Root: svn://gcc.gnu.org/svn/gcc
Repository UUID: 138bc75d-0d04-0410-961f-82ee72b054a4
Revision: 201852
This results in a broken gcc/REVISION which breaks compilation because
it's used to generate version-header:
# diff -ur -x.svn gcc-4.8-svn1711/gcc/REVISION gcc-4.8-svn18x/gcc/REVISION
--- gcc-4.8-svn1711/gcc/REVISION2013-08-19 20:35:03.353241599 +0200
+++ gcc-4.8-svn18x/gcc/REVISION 2013-08-19 21:34:33.115310266 +0200
@@ -1 +1,2 @@
-[gcc-4_8-branch revision 201852]
+[gcc-4_8-branch
+gcc-4_8-branch revision 201854]
the script-part from contrib/gcc_update matches twice for /URL:/
branch=`$GCC_SVN info | sed -ne "/URL:/ {
s,.*/trunk,trunk,
s,.*/branches/,,
s,.*/tags/,,
p
}"`
using 'sh -x contrib/gcc_update' has the following diff:
# diff -u up.out.1711 up.out.181
++ svn info
@@ -33,13 +32,15 @@
s,.*/tags/,,
p
}'
-+ branch=gcc-4_8-branch
++ branch='gcc-4_8-branch
+gcc-4_8-branch'
+ rm -f LAST_UPDATED gcc/REVISION
+ date
++ TZ=UTC
++ date
-+ echo 'Mon Aug 19 20:12:31 UTC 2013 (revision 201855)'
-+ echo '[gcc-4_8-branch revision 201855]'
++ echo 'Mon Aug 19 20:14:22 UTC 2013 (revision 201855)'
++ echo '[gcc-4_8-branch
+gcc-4_8-branch revision 201855]'
A trivial fix would be something like /^URL:/ but I don't know
enough about ancient subversion-releases to be sure the line
has always started with '^URL:'.
[Bug other/58197] subversion-1.8.x breaks script contrib/gcc_update
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58197 Winfried Magerl changed: What|Removed |Added CC||winfried.mag...@t-online.de Severity|normal |trivial
[Bug c++/58178] variant function name was used for user defined constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58178 --- Comment #5 from chihin ko --- Oracle Solaris 10 8/11 s10x_u10wos_17b X86 DW_AT_producer "GNU C++ 4.8.1 -mtune=generic -march=pentium4 -g"
[Bug fortran/57798] [4.8/4.9 Regression] Incorrect handling of sum over first dimension of a product of automatic arrays
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57798 Thomas Koenig changed: What|Removed |Added CC||mikael at gcc dot gnu.org --- Comment #2 from Thomas Koenig --- Mikael, this seems to be your area of expertise. Do you have any idea?
[Bug fortran/54578] [OOP] -Wunused-function warnings for __copy functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54578 janus at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||janus at gcc dot gnu.org Resolution|--- |FIXED --- Comment #1 from janus at gcc dot gnu.org --- I think this may have been fixed by r192620.
[Bug c++/58178] variant function name was used for user defined constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58178 --- Comment #6 from chihin ko --- On Linux: pirandello 934> cat /etc/*release* Enterprise Linux Enterprise Linux Server release 5.4 (Carthage) cat: /etc/lsb-release.d: Is a directory Red Hat Enterprise Linux Server release 5.4 (Tikanga) /usr/bin/g++ -v Using built-in specs. Target: x86_64-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-libgcj-multifile --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --enable-plugin --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --with-cpu=generic --host=x86_64-redhat-linux Thread model: posix gcc version 4.1.2 20080704 (Red Hat 4.1.2-46)
[Bug fortran/54224] Warn for unused (private) module variables and internal procedures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54224 --- Comment #18 from janus at gcc dot gnu.org --- Comment 14 and 15 is fixed on 4.9 trunk with r200950 (cf. PR 52669).
[Bug fortran/54224] Warn for unused internal procedures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54224 janus at gcc dot gnu.org changed: What|Removed |Added Summary|Warn for unused (private) |Warn for unused internal |module variables and|procedures |internal procedures | --- Comment #19 from janus at gcc dot gnu.org --- Still open: Comment 13.
[Bug c++/58178] variant function name was used for user defined constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58178 Paolo Carlini changed: What|Removed |Added CC||ebotcazou at gcc dot gnu.org --- Comment #7 from Paolo Carlini --- Thus Solaris (current Linux targets are fine, we know that). Maybe Eric can have a look.
[Bug middle-end/57287] GCC 4.9.0 fails to build GDB on Ubuntu 12.04
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57287
meadori at gcc dot gnu.org changed:
What|Removed |Added
CC||meadori at gcc dot gnu.org
--- Comment #14 from meadori at gcc dot gnu.org ---
(In reply to hmb from comment #13)
> Created attachment 30201 [details]
> preprocessed source code
>
> Attaching the preprocessed source code
Here is a reduction (as of trunk today):
$ cat test.c
#include
#include
struct node
{
struct node *next;
char *name;
} *list;
struct node *list;
struct node *head (void);
sigjmp_buf *bar (void);
int baz (void)
{
struct node *n;
int varseen = 0;
list = head ();
for (n = list; n; n = n->next)
{
if (!varseen)
varseen = 1;
sigjmp_buf *buf = bar ();
__sigsetjmp (*buf, 1);
}
if (!varseen)
return 0;
return 1;
}
$ i686-pc-linux-gnu-gcc --version
i686-pc-linux-gnu-gcc (GCC) 4.9.0 20130819 (experimental)
Copyright (C) 2013 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ i686-pc-linux-gnu-gcc -Wall -O2 -c test.c
test.c: In function 'baz':
test.c:26:19: warning: 'buf' may be used uninitialized in this function
[-Wmaybe-uninitialized]
sigjmp_buf *buf = bar ();
^
[Bug c++/36266] C++ typedef misplaced in DWARF information
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36266 --- Comment #3 from Paolo Carlini --- Cary?
[Bug lto/58084] [4.9 Regression] FAIL: gcc.dg/torture/pr8081.c -O2 -flto -fno-use-linker-plugin -flto-partition=none (internal compiler error)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58084 Hans-Peter Nilsson changed: What|Removed |Added Target|arm-none-eabi, |arm-none-eabi, |powerpc64-linux,|powerpc64-linux, |i386-pc-solaris2.10 |i386-pc-solaris2.10, ||cris-axis-elf Last reconfirmed|2013-08-08 00:00:00 |2013-08-20 0:00 CC||hp at gcc dot gnu.org Component|regression |lto Summary|FAIL: |[4.9 Regression] FAIL: |gcc.dg/torture/pr8081.c |gcc.dg/torture/pr8081.c |-O2 -flto |-O2 -flto |-fno-use-linker-plugin |-fno-use-linker-plugin |-flto-partition=none|-flto-partition=none |(internal compiler error) |(internal compiler error) --- Comment #6 from Hans-Peter Nilsson --- Marking properly as regression, correcting component and adding target cris-axis-elf.
[Bug middle-end/58096] [4.9 Regression] gcc.dg/tree-ssa/attr-alias.c fails with r201439
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58096 Hans-Peter Nilsson changed: What|Removed |Added Target|powerpc64-linux,|powerpc64-linux, |x86_64-unknown-linux-gnu, |x86_64-unknown-linux-gnu, |i386-pc-solaris2.10 |i386-pc-solaris2.10, ||cris-axis-elf CC||hp at gcc dot gnu.org --- Comment #4 from Hans-Peter Nilsson --- Adding another target that's regressing as described.
[Bug fortran/57904] [4.9 Regression] Bogus(?) "invokes undefined behavior" warning with Fortran's finalization wrapper (gfortran.dg/class_48.f90)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57904 Hans-Peter Nilsson changed: What|Removed |Added CC||hp at gcc dot gnu.org Summary|Bogus(?) "invokes undefined |[4.9 Regression] Bogus(?) |behavior" warning with |"invokes undefined |Fortran's finalization |behavior" warning with |wrapper |Fortran's finalization |(gfortran.dg/class_48.f90) |wrapper ||(gfortran.dg/class_48.f90) --- Comment #2 from Hans-Peter Nilsson --- I'm guessing this fails for all ILP32 targets as described; at least ARM, CRIS, PowerPC and m68k as well. Adjusting title to properly mark as regression.
[Bug c++/36266] C++ typedef misplaced in DWARF information
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36266 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jakub at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #4 from Jakub Jelinek --- Dup. *** This bug has been marked as a duplicate of bug 40109 ***
[Bug debug/40109] Incorrect debug info nesting for typedef statements within namespaces
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40109 Jakub Jelinek changed: What|Removed |Added CC||j...@red-bean.com --- Comment #7 from Jakub Jelinek --- *** Bug 36266 has been marked as a duplicate of this bug. ***
[Bug lto/58084] [4.9 Regression] FAIL: gcc.dg/torture/pr8081.c -O2 -flto -fno-use-linker-plugin -flto-partition=none (internal compiler error)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58084 --- Comment #7 from Hans-Peter Nilsson --- For the record, I'm logging the following regression for cris-axis-elf in this PR as well, because: 1: It's lto 2: The regression is observed introduced in the same interval locally: (201466:201470] 3: While likely reproducible with a complete toolchain, last I looked -save-temps didn't do much to help lto debuggability, nor was there equivalent machinery, so not seeing it as helpful in a separate PR. I'll make it a separate PR if I see separate changes in behavior (like torture/pr8081.c fixed but torture/pr48661.C not). Running /tmp/hpautotest-gcc0/gcc/gcc/testsuite/g++.dg/torture/dg-torture.exp ... FAIL: g++.dg/torture/pr48661.C -O2 -flto -fno-use-linker-plugin -flto-partition=none (internal compiler error) FAIL: g++.dg/torture/pr48661.C -O2 -flto -fno-use-linker-plugin -flto-partition=none (test for excess errors) FAIL: g++.dg/torture/pr48661.C -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects (internal compiler error) FAIL: g++.dg/torture/pr48661.C -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects (test for excess errors) WARNING: g++.dg/torture/pr48661.C -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects compilation failed to produce executable In g++.log: Executing on host: /tmp/hpautotest-gcc1/cris-elf/gccobj/gcc/testsuite/g++/../../xg++ -B/tmp/hpautotest-gcc1/cris-elf/gccobj/gcc/testsuite/g++/../../ /tmp/hpautotest-gcc1/gcc/gcc/testsuite/g++.dg/torture/pr48661.C -fno-diagnostics-show-caret -fdiagnostics-color=never -nostdinc++ -I/tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/libstdc++-v3/include/cris-elf -I/tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/libstdc++-v3/include -I/tmp/hpautotest-gcc1/gcc/libstdc++-v3/libsupc++ -I/tmp/hpautotest-gcc1/gcc/libstdc++-v3/include/backward -I/tmp/hpautotest-gcc1/gcc/libstdc++-v3/testsuite/util -fmessage-length=0 -O2 -flto -fno-use-linker-plugin -flto-partition=none -isystem /tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/./newlib/targ-include -isystem /tmp/hpautotest-gcc1/gcc/newlib/libc/include -B/tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/./libgloss/cris/ -L/tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/./libgloss/cris -L/tmp/hpautotest-gcc1/gcc/libgloss/cris -B/tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/./newlib/ -L/tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/./newlib -sim3 -L/tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/./libstdc++-v3/src/.libs -B/tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/./libstdc++-v3/src/.libs -lm -o ./pr48661.exe(timeout = 300) In member function '_ZTv0_n12_NK1D1mEv': lto1: internal compiler error: Segmentation fault 0x7ea965 crash_signal /tmp/hpautotest-gcc1/gcc/gcc/toplev.c:335 0x524936 contains_struct_check /tmp/hpautotest-gcc1/gcc/gcc/tree.h:3803 0x524936 fold_build_pointer_plus_loc /tmp/hpautotest-gcc1/gcc/gcc/tree.h:5860 0x524936 thunk_adjust /tmp/hpautotest-gcc1/gcc/gcc/cgraphunit.c:1297 0x5264c3 expand_thunk(cgraph_node*) /tmp/hpautotest-gcc1/gcc/gcc/cgraphunit.c:1440 0x526d5b assemble_thunks_and_aliases /tmp/hpautotest-gcc1/gcc/gcc/cgraphunit.c:1549 0x526daa assemble_thunks_and_aliases /tmp/hpautotest-gcc1/gcc/gcc/cgraphunit.c:1565 0x526f42 expand_function /tmp/hpautotest-gcc1/gcc/gcc/cgraphunit.c:1675 0x527cb0 expand_all_functions /tmp/hpautotest-gcc1/gcc/gcc/cgraphunit.c:1717 0x527cb0 compile() /tmp/hpautotest-gcc1/gcc/gcc/cgraphunit.c:2054 0x4acbd6 lto_main() /tmp/hpautotest-gcc1/gcc/gcc/lto/lto.c:3843 $ c++filt _ZTv0_n12_NK1D1mEv virtual thunk to D::m() const (Shouldn't the "In member function" error message refer to the demangled name?)
[Bug middle-end/58143] wrong code at -O3 on x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58143 Bernd Edlinger changed: What|Removed |Added CC||bernd.edlinger at hotmail dot de --- Comment #4 from Bernd Edlinger --- Created attachment 30674 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30674&action=edit slightly simplified test case attached is a slightly simplified test case. The problem seems to start in the optimizer pass 097t.lim1 where the following expression is identified as loop-invariant of loop 3. Moving statement _23 = -2147483648 - c.1_22; (cost 1) out of loop 3. unfortunatley it is executed unconditionally now. later the optimizer pass 110t.ivcanon uses the possible overflow in this statement as an argument, why the loop must be executed exactly once. Induction variable (int) 2147483647 + 1 * iteration does not wrap in statement _23 = -2147483648 - prephitmp_8; in loop 2. Statement _23 = -2147483648 - prephitmp_8; is executed at most 0 (bounded by 0) + 1 times in loop 2. and shortly after that an apparently pointless loop-exit is removed. Removed pointless exit: if (prephitmp_8 != 0) however that is based on a worng assumption, and causes worng code.
[Bug middle-end/58143] wrong code at -O3 on x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58143 --- Comment #5 from Bernd Edlinger --- Summary: tree-ssa-loop-im.c moves code, out of an if statement inside the loop it it can not cause side effects or faults, but it does not care of integer overflows. this seems to be an optimization! BUT tree-ssa-loop-niter.c (infer_loop_bounds_from_signedness) does assume that the code will never execute integer additions or subtractions with the intention to use the result as modulo 2^32, thus ignoring overflow. It seems that -O3 and -fno-strict-overflow will fix the code. however this comment in tree.h points to another problem: IMPORTANT NOTE: Any optimization based on TYPE_OVERFLOW_UNDEFINED must issue a warning based on warn_strict_overflow. In some cases it will be appropriate to issue the warning immediately, and in other cases it will be appropriate to simply set a flag and let the caller decide whether a warning is appropriate or not. this example does not generate any warnings, not with -Wall and not with -Wstrict-overflow...
[Bug target/57865] Broken _save64gpr and _rest64gpr usage
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57865 Alan Modra changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Alan Modra --- Fixed mainline and 4.8. 4.7 doesn't need the patch.
[Bug libstdc++/58196] std::align is missing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58196 --- Comment #2 from Augusto Righetto --- Hi Paolo, I apologize for filling a bug for an unimplemented feature. However, if you take a look at http://gcc.gnu.org/gcc-4.8/cxx0x_status.html, you'll see that "Alignment support" is marked as available on GCC 4.8. Having two different tables to track down features is confusing. Thanks, Augusto
[Bug c++/58198] New: duplicate codes generated for variant function and base function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58198 Bug ID: 58198 Summary: duplicate codes generated for variant function and base function Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: chihin.ko at oracle dot com Created attachment 30675 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30675&action=edit test case This problem was fixed after g++ 4.4, I file this bug is only for book keeping. test case was attached. pirandello 1017> nm a.out | grep mybase 00400528 T _ZN6mybase10mybasefuncEv 0040054e T _ZN6mybaseC1Ev <=== base function 0040053a T _ZN6mybaseC2Ev <=== variant function base function (_ZN6mybaseC1Ev) and variant function (_ZN6mybaseC2Ev) should have same addresses, but they're not. Use gdb to debug a.out, shows bpt stop in variant function instead of base function: (gdb) b mybase::mybase Breakpoint 1 at 0x400542: file base.cc, line 21. (2 locations) (gdb) run Starting program: /net/benjamin2.us.oracle.com/export/ws/jeanko/dinstall/maxirun/intel-Linux/pirandello-chko/results/Customlist_list.master.maxi/gplus_base.dbx,gcc/a.out Breakpoint 1, mybase (this=0x7fff1343ed50) at base.cc:21 21mybaseint = ; (gdb) disassemb $pc Dump of assembler code for function mybase: 0x0040053a : push %rbp 0x0040053b : mov%rsp,%rbp 0x0040053e : mov%rdi,-0x8(%rbp) 0x00400542 : mov-0x8(%rbp),%rax 0x00400546 : movl $0x15b3,(%rax) 0x0040054c : leaveq 0x0040054d : retq End of assembler dump. (gdb) # disassemble base function address shows both functions has exact same codes (gdb) disassemb 0x40054e Dump of assembler code for function mybase: 0x0040054e : push %rbp 0x0040054f : mov%rsp,%rbp 0x00400552 : mov%rdi,-0x8(%rbp) 0x00400556 : mov-0x8(%rbp),%rax 0x0040055a : movl $0x15b3,(%rax) 0x00400560 : leaveq 0x00400561 : retq End of assembler dump. (gdb)
[Bug c++/58188] ICE in gimple_add_tmp_var, at gimplify.c:738
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58188 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #1 from Marek Polacek --- Hm, I can't seem to reproduce it. Is this vanilla gcc?
