[Bug c++/70435] section attribute of a function template is not honored.

2021-11-26 Thread lts-rudolph at gmx dot de via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70435

Klaus Rudolph  changed:

   What|Removed |Added

 CC||lts-rudolph at gmx dot de

--- Comment #8 from Klaus Rudolph  ---
Bug still present in 11.2.1

[Bug c++/59716] variadic template multiple parameter pack expansion fails

2021-11-26 Thread lts-rudolph at gmx dot de via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59716

Klaus Rudolph  changed:

   What|Removed |Added

 Resolution|FIXED   |---
 Status|RESOLVED|REOPENED

--- Comment #3 from Klaus Rudolph  ---
The attached code again did not compile from gcc 10.x.x

 https://godbolt.org/z/sbej6GeY1

No the error message is:

: In instantiation of 'CheckVariadic,
std::tuple<_Types ...> >::CheckVariadic(T1 ..., T2 ..., T1 ...) [with T1 =
{int, float}; T2 = {char, void*}]':
:53:115:   required from here
:47:116: error: invalid use of pack expansion expression
   47 | CheckVariadic( T1... args1, T2... args2, T1... args3):
DebugPrinter< T1, T2, T1...>(args1, args2..., args1)... {}
  |

[Bug c++/96204] gcc complains about private member access in SFINAE context

2020-07-15 Thread lts-rudolph at gmx dot de 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96204

--- Comment #1 from Klaus Rudolph  ---
Maybe related to: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64335

[Bug c++/96204] New: gcc complains about private member access in SFINAE context

2020-07-15 Thread lts-rudolph at gmx dot de 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96204

Bug ID: 96204
   Summary: gcc complains about private member access in SFINAE
context
   Product: gcc
   Version: 10.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lts-rudolph at gmx dot de
  Target Milestone: ---

gcc complains with following error in the example code:

main.cpp:59:72: error: 'void Child::setAttr(int)' is private within this
context
   59 | struct has_set_attr_method().setAttr(1))>> {
  |  
~^~~
main.cpp:85:14: note: declared private here
   85 | void setAttr(int x) {
  |  ^~~
main.cpp:59:72: error: 'void Child::setAttr(int)' is private within this
context
   59 | struct has_set_attr_method().setAttr(1))>> {
  |  
~^~~
main.cpp:85:14: note: declared private here
   85 | void setAttr(int x) {
  |  ^~~
main.cpp:59:72: error: 'void Child::setAttr(int)' is private within this
context
   59 | struct has_set_attr_method().setAttr(1))>> {
  |  
~^~~
main.cpp:85:14: note: declared private here
   85 | void setAttr(int x) {


Full code example:

---
template >
struct has_set_attr_method {
static constexpr bool value = false;
};
template 
struct has_set_attr_method().setAttr(1))>> {
static constexpr bool value = true;
};

struct Parent
{
public:
template
static void create(){   
auto obj = T::create();
if constexpr(has_set_attr_method::value) {
cout << "has setAttr" << endl;
} else {
cout << "no setAttr" << endl;
}
}
};

struct Child : public Parent {
public:
friend class Parent;
static auto create() {
return Child();
}

private:
void setAttr(int x) {
}
};

int main(int argc, char const *argv[]) {
Parent::create();
return 0;
}

---

Interestingly the failure depends on "friend" declaration inside "Child".

[Bug c++/94554] spurious -Waddress warning within "if constexpr" function-null compares

2020-07-10 Thread lts-rudolph at gmx dot de 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94554

Klaus Rudolph  changed:

   What|Removed |Added

 CC||lts-rudolph at gmx dot de

--- Comment #4 from Klaus Rudolph  ---
The code can be modified to be well formed if changed to:

if constexpr (F != nullptr )) {

g++ still emits the bogus warning in that case which is a bug I believe!

[Bug c++/96111] checking type of attribute with concepts results in compilation error or ICE

2020-07-08 Thread lts-rudolph at gmx dot de 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96111

--- Comment #1 from Klaus Rudolph  ---
The error massages are valid as 

as got by an answr on SO (
https://stackoverflow.com/questions/62791460/checking-type-of-attribute-with-concepts
)


[expr.prim.req.compound]/1.3

If the return-type-requirement is present, then:
Substitution of template arguments (if any) into the
return-type-requirement is performed.
The immediately-declared constraint ([temp.param]) of the
type-constraint for decltype((E)) shall be satisfied.

E is our expression, namely n.value.

Now, decltype(n.value) is char or int, that's because decltype has a special
rule for class member access and id expressions. But decltype((n.value)) is
char& or int&. The value category is encoded in the type of decltype when
dealing with a general expression (such as a parenthesized class member
access).

BUT: That we see an ICE on current trunk is a bug!

[Bug c++/96111] New: checking type of attribute with concepts results in compilation error or ICE

2020-07-08 Thread lts-rudolph at gmx dot de 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96111

Bug ID: 96111
   Summary: checking type of attribute with concepts results in
compilation error or ICE
   Product: gcc
   Version: 10.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lts-rudolph at gmx dot de
  Target Milestone: ---

Code fails to compile with gcc 10.1.1 ( unexpected compile error messages )
and compilation fails with ICE on current trunk

if checking in the requirement with only the commented lines, everything works
fine.  

compiled with: g++ --std=c++20 main.cpp -O2 -g 

struct N
{
char value;
auto Get() { return value; }
};

struct M
{
int value;
auto Get() { return value; }
};

void func3( auto n ) 
requires requires
{
//{ n.Get() } -> std::same_as;
{ n.value } -> std::same_as;
}
{
std::cout << __PRETTY_FUNCTION__ << std::endl;
}


void func3( auto n ) 
requires requires 
{
//{ n.Get() } -> std::same_as;
{ n.value } -> std::same_as;
}
{
std::cout << __PRETTY_FUNCTION__ << std::endl;
}

int main()
{
func3( n );
func3( m );
}

[Bug c++/88417] New: partial specialization of static template variable inside class template gives wrong result

2018-12-08 Thread lts-rudolph at gmx dot de 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88417

Bug ID: 88417
   Summary: partial specialization of static template variable
inside class template gives wrong result
   Product: gcc
   Version: 8.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lts-rudolph at gmx dot de
  Target Milestone: ---

If I do a partial template variable specialization inside a template class I
got the wrong results and/or if no unspecialised version is provided I got a
linker error.

 template < typename T>
class X
{
public:
T i;
X(T _i): i{_i}{}

operator T(){ return i; }
};

template < typename T2 >
class Y
{
public:
template 
static X x_in_y;
};

template< typename T2>
template< typename T>
X Y::x_in_y{200};

template<>
template<>
X Y::x_in_y{100};

template<>
template<>
X Y::x_in_y{101};

// this partial specialization is never seen, but compiles without error
template<  >
template< typename T >
X Y::x_in_y{77};


int main()
{
std::cout << Y::x_in_y << std::endl;
std::cout << Y::x_in_y << std::endl;

std::cout << Y::x_in_y << std::endl;
std::cout << Y::x_in_y << std::endl;
}

expected result:
101
100
200
77

[Bug libitm/63907] libitm/config/posix/rwlock.cc doesn't compile

2016-10-18 Thread lts-rudolph at gmx dot de 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63907

--- Comment #10 from Klaus Rudolph  ---
Created attachment 39830
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39830=edit
preprocessed file rwlock.ii

Add rwlock.ii file as requested.

[Bug libitm/63907] libitm/config/posix/rwlock.cc doesn't compile

2016-10-18 Thread lts-rudolph at gmx dot de 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63907

--- Comment #9 from Klaus Rudolph  ---
hi all,

> Gesendet: Freitag, 14. Oktober 2016 um 10:32 Uhr
> Von: "redi at gcc dot gnu.org" 
> An: lts-rudo...@gmx.de
> Betreff: [Bug libitm/63907] libitm/config/posix/rwlock.cc doesn't compile
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63907
> 
> --- Comment #6 from Jonathan Wakely  ---
> See https://gcc.gnu.org/bugs/
> 


How can I add "-save-temps" to the gcc build process itself. Because the bug is
compiling the libitm library from the compiler compilation itself. Anything
which can be done with "./configure" or must the Makefiles be patched? I have
no idea how to set this additional CFLAG/CXXFLAG or similar.

Regards
 Klaus

[Bug libitm/63907] libitm/config/posix/rwlock.cc doesn't compile

2016-10-14 Thread lts-rudolph at gmx dot de 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63907

--- Comment #5 from Klaus Rudolph  ---
Hi Andrew,

> Andrew Pinski  changed:
> 
>What|Removed |Added
> 
>  Status|NEW |WAITING
> 
> --- Comment #4 from Andrew Pinski  ---
> How does this work for everyone else?  Can you attach the preprocessed source?

What exactly do you want to have? Complete build path after configure?

Sorry for my stupid question!

Regards
 Klaus

[Bug libitm/63907] libitm/config/posix/rwlock.cc doesn't compile

2016-08-12 Thread lts-rudolph at gmx dot de 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63907

Klaus Rudolph  changed:

   What|Removed |Added

  Known to fail||4.9.2, 6.1.0

--- Comment #3 from Klaus Rudolph  ---
Still did *NOT* work for gcc 6.1.0

[Bug libstdc++/71098] New: uniform initialization for nested tuples work in c++11/14 mode but should only work >=c++17

2016-05-13 Thread lts-rudolph at gmx dot de 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71098

Bug ID: 71098
   Summary: uniform initialization for nested tuples work in
c++11/14 mode but should only work >=c++17
   Product: gcc
   Version: 6.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lts-rudolph at gmx dot de
  Target Milestone: ---

uniform initialization for nested std::tuple works in c++11/14 mode but should
work not before c++17.

The following line compiles without warning/error in --std=c++11/14

std::tuple<std::tuple<int,float> > t2{{ 1,2.2}};

[Bug libstdc++/71096] New: std::get did not work for nested derived classes from std::tuple if one element is empty

2016-05-13 Thread lts-rudolph at gmx dot de 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71096

Bug ID: 71096
   Summary: std::get did not work for nested derived classes from
std::tuple if one element is empty
   Product: gcc
   Version: 6.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lts-rudolph at gmx dot de
  Target Milestone: ---

Created attachment 38482
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38482=edit
minimum example to compile

If you derive from std::tuple and use this class nested, std::get fails if
there is a empty tuple inside the outside tuple.

Please see code for clarification :-)

#include 

template 
struct TypeContainer : std::tuple
{
};

int main()
{
std::get<0>(TypeContainer<TypeContainer<>>{});
}

Compile fails with:

/opt/linux-gnu_6.1.0/bin/g++ --std=c++14 main.cpp -O0 -g -o go 
main.cpp: In function 'int main()':
main.cpp:10:53: error: no matching function for call to
'get(TypeContainer<TypeContainer<> >)'
 std::get<0>(TypeContainer<TypeContainer<>>{});

...

/opt/linux-gnu_6.1.0/include/c++/6.1.0/tuple|1235 col 5| note:   template
argument deduction/substitution failed:
main.cpp|10 col 53| note:   'std::tuple<_Elements ...>' is an ambiguous base
class of 'TypeContainer<TypeContainer<> >'
||  std::get<0>(TypeContainer<TypeContainer<>>{});
||  ^

[Bug c++/59716] variadic template multiple parameter pack expansion fails

2015-08-03 Thread lts-rudolph at gmx dot de 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59716

--- Comment #1 from Klaus Rudolph lts-rudolph at gmx dot de ---
Bug is still present 2015-08-03 ( sorry, can't change last reconfirmed
entry?!

[Bug c++/63907] New: libitm/config/posix/rwlock.cc doesn't compile

2014-11-17 Thread lts-rudolph at gmx dot de 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63907

Bug ID: 63907
   Summary: libitm/config/posix/rwlock.cc doesn't compile
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lts-rudolph at gmx dot de
Target: powerpc-unknown-linux-gnu

While compiling gcc for target powerpc-unknown-linux-gnu I got:

This seems to be an already fixed bug #52510.



libtool: compile: 
/home/krud/own_components/gcc_install/gccinst013ma/gcc-4.9.2/build_powerpc-unknown-linux-gnu_4.9.2/./gcc/xg++
-B/home/krud/own_components/gcc_install/gccinst013ma/gcc-4.9.2/build_powerpc-unknown-linux-gnu_4.9.2/./gcc/
-nostdinc++ -nostdinc++
-I/home/krud/own_components/gcc_install/gccinst013ma/gcc-4.9.2/build_powerpc-unknown-linux-gnu_4.9.2/powerpc-unknown-linux-gnu/libstdc++-v3/include/powerpc-unknown-linux-gnu
-I/home/krud/own_components/gcc_install/gccinst013ma/gcc-4.9.2/build_powerpc-unknown-linux-gnu_4.9.2/powerpc-unknown-linux-gnu/libstdc++-v3/include
-I/home/krud/own_components/gcc_install/gccinst013ma/gcc-4.9.2/libstdc++-v3/libsupc++
-I/home/krud/own_components/gcc_install/gccinst013ma/gcc-4.9.2/libstdc++-v3/include/backward
-I/home/krud/own_components/gcc_install/gccinst013ma/gcc-4.9.2/libstdc++-v3/testsuite/util
-L/home/krud/own_components/gcc_install/gccinst013ma/gcc-4.9.2/build_powerpc-unknown-linux-gnu_4.9.2/powerpc-unknown-linux-gnu/libstdc++-v3/src
-L/home/krud/own_components/gcc_install/gccinst013ma/gcc-4.9.2/build_powerpc-unknown-linux-gnu_4.9.2/powerpc-unknown-linux-gnu/libstdc++-v3/src/.libs
-L/home/krud/own_components/gcc_install/gccinst013ma/gcc-4.9.2/build_powerpc-unknown-linux-gnu_4.9.2/powerpc-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs
-B/opt/powerpc-unknown-linux-gnu_4.9.2/powerpc-unknown-linux-gnu/bin/
-B/opt/powerpc-unknown-linux-gnu_4.9.2/powerpc-unknown-linux-gnu/lib/ -isystem
/opt/powerpc-unknown-linux-gnu_4.9.2/powerpc-unknown-linux-gnu/include -isystem
/opt/powerpc-unknown-linux-gnu_4.9.2/powerpc-unknown-linux-gnu/sys-include
-DHAVE_CONFIG_H -I. -I../../../libitm -I../../../libitm/config/powerpc
-I../../../libitm/config/posix -I../../../libitm/config/generic
-I../../../libitm -mhtm -Wall -pthread -Werror -std=gnu++0x -funwind-tables
-fno-exceptions -fno-rtti -fabi-version=4 -g -O2 -D_GNU_SOURCE -MT rwlock.lo
-MD -MP -MF .deps/rwlock.Tpo -c ../../../libitm/config/posix/rwlock.cc  -fPIC
-DPIC -o .libs/rwlock.o
../../../libitm/config/posix/rwlock.cc: In constructor
‘GTM::gtm_rwlock::gtm_rwlock()’:
../../../libitm/config/posix/rwlock.cc:40:17: error: no matching function for
call to ‘pthread_cond_t::pthread_cond_t(brace-enclosed initializer list)’
 w_writers (0)

[Bug c++/57694] [c++11] constexpr constructor does not work with const address of own member

2014-05-23 Thread lts-rudolph at gmx dot de 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57694

Klaus Rudolph lts-rudolph at gmx dot de changed:

   What|Removed |Added

Version|4.8.1   |4.9.0
  Known to fail|4.9.0   |4.8.3

--- Comment #1 from Klaus Rudolph lts-rudolph at gmx dot de ---
I retested the problem with 4.9.0 and got

sorry, unimplemented: use of the value of the object being constructed in a
constant expression

[Bug c++/59716] New: variadic template multiple parameter pack expansion fails

2014-01-07 Thread lts-rudolph at gmx dot de 
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59716

Bug ID: 59716
   Summary: variadic template multiple parameter pack expansion
fails
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lts-rudolph at gmx dot de

Created attachment 31770
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31770action=edit
full source code example

Multiple parameter pack expansion for variadic templates is broken since 4.8.x
versions. The parameter pack expansion itself works with g++ 4.7.x. But the
order of expanded parms was wrong. This bug was fixed in 4.8.x but mutiple
expansion is now broken.

The code fails with the follwing results:

/opt/linux-gnu_4.9-20140105/bin/g++ --std=c++11 zwei.cpp -O0 -g -pedantic -Wall
-o go2
zwei.cpp: In instantiation of 'CheckVariadicstd::tuple_Elements ...,
std::tuple_Elements ... ::CheckVariadic(T1 ..., T2 ..., T1 ...) [with T1 =
{int, float}; T2 = {char, void*}]':
zwei.cpp:53:115:   required from here
zwei.cpp:47:116: error: mismatched argument pack lengths while expanding
'DebugPrinterT1, T2, T1 ...'
 CheckVariadic( T1... args1, T2... args2, T1... args3): DebugPrinter
T1, T2, T1...(args1, args2..., args1)... {}

The problem occurs in this line of code:
CheckVariadic( T1... args1, T2... args2, T1... args3): DebugPrinter T1, T2,
T1...(args1, args2..., args1)... {}

The attachment compiles with clang3.3  clang3.4 as expected.

[Bug c++/57694] New: [c++11] constexpr constructor do not work with const address of own member

2013-06-24 Thread lts-rudolph at gmx dot de 
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57694

Bug ID: 57694
   Summary: [c++11] constexpr constructor do not work with const
address of own member
   Product: gcc
   Version: 4.8.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lts-rudolph at gmx dot de

The following code results in
error: field initializer is not constant



class A
{   
private:
int a;
const int* const aptr;

public:
constexpr A( int _a):
a(_a)
   , aptr( a)   // why aptr could not be initialized? 
{}  
};  

class Data { } d1; 

class B
{   
private:
Data* dptr1;

public:
constexpr B(Data* _p): dptr1( _p) {}

};  

class Use 
{   
static constexpr A a{2};   // fail! error: field initializer is not
constant
static constexpr B b{d1}; // works
};

[Bug c++/57695] New: [c++11] generalized attributes with avr __progmem__

2013-06-24 Thread lts-rudolph at gmx dot de 
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57695

Bug ID: 57695
   Summary: [c++11] generalized attributes with avr __progmem__
   Product: gcc
   Version: 4.8.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lts-rudolph at gmx dot de

The two statements:
extern const X x __attribute__ ((__progmem__)) = { 1 };  // works as expected
extern const X x [[__progmem__]] = { 1 };// warning  broken
code

See the following description to get working example.

The following code compiles as expected with avr-g++ 4.8.1: (code must split in
different translation units to see any result, because the optimizer will
remove all effects while inlining the instructions)

x.h:

struct X
{
uint8_t a;
};

x.cpp:

extern const X x __attribute__ ((__progmem__)) = { 1 };

main.cpp:

#include x.h
extern const X x __attribute__ (( __progmem__ )); 

int main()
{   
PORTB = pgm_read_byte( (x.a));
return 0;
}

results in (objdump -d):

001a x:
  1a:   01 00   ..
  ...

  2e:   ea e1   ldi r30, 0x1A   ; 26
  30:   f0 e0   ldi r31, 0x00   ; 0
  32:   c8 95   lpm

the result is fine.

Using generalized attributes do NOT work:

extern const X x [[__progmem__]] = { 1 };

this results in a warning x.cpp:8:32: warning: 'progmem' attribute directive
ignored [-Wattributes] and the code is broken because the var x is stored to
ram instead of flash.

[Bug c++/57695] [c++11] generalized attributes with avr __progmem__

2013-06-24 Thread lts-rudolph at gmx dot de 
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57695

Klaus Rudolph lts-rudolph at gmx dot de changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #2 from Klaus Rudolph lts-rudolph at gmx dot de ---
@Jakub:

[[gnu::__progmem__]]  works!
[[gnu::progmem]] fails.

Thanks a lot!

[Bug c++/53304] New: use of std::future results to relocation error with symbol _ZTINSt13__future_base19_Async_state_commonE

2012-05-10 Thread lts-rudolph at gmx dot de 
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53304

 Bug #: 53304
   Summary: use of std::future results to relocation error with
symbol _ZTINSt13__future_base19_Async_state_commonE
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: lts-rudo...@gmx.de


The example did not run if compiled with 4.7.0 but runs as expected with 4.6.3

Error:
krud@x:~/test/c++/c++11/thread_future_promise$ go
go: relocation error: go: symbol _ZTINSt13__future_base19_Async_state_commonE,
version GLIBCXX_3.4.17 not defined in file libstdc++.so.6 with link time
reference

comiled with

 start makefile 
all: go

#CXX=/opt/linux-gnu_4.6.3/bin/g++
CXX=/opt/linux-gnu_4.7.0/bin/g++
CXXFLAGS=-pthread -std=c++0x -O2 -g 
LDFLAGS=-pthread -g


go: main.o
$(CXX) $ $(LDFLAGS) -o go

--- end Makefile 

--- start main.cpp 

#include iostream

#define _GLIBCXX_USE_NANOSLEEP
#include thread
#include future

using namespace std;

int main()
{
   futureint retval= async( [] { this_thread::sleep_for( chrono::seconds(1));
return 42; } );

cout  Result   retval.get()  endl;

return 0;
}
-- end main.cpp ---

[Bug c++/53304] use of std::future results to relocation error with symbol _ZTINSt13__future_base19_Async_state_commonE

2012-05-10 Thread lts-rudolph at gmx dot de 
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53304

Klaus Rudolph lts-rudolph at gmx dot de changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #2 from Klaus Rudolph lts-rudolph at gmx dot de 2012-05-10 
14:57:07 UTC ---
 You need to tell the dynamic linker how to find the 4.7 libs

You are right. ld.so.config points to older build of pre-release version of gcc
4.7. Status could be changed to invalid.

[Bug target/44643] ice in c-typeck.c

2011-03-31 Thread lts-rudolph at gmx dot de 
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44643

Klaus Rudolph lts-rudolph at gmx dot de changed:

   What|Removed |Added

 CC||lts-rudolph at gmx dot de

--- Comment #7 from Klaus Rudolph lts-rudolph at gmx dot de 2011-03-31 
07:53:25 UTC ---
The problem occurs also with avr-libc-1.7.1 with gcc 4.6.0 release.

[Bug c/23574] New: insn does not sat

2005-08-26 Thread lts-rudolph at gmx dot de 
isfy its constraint message while compiling newlib
X-Bugzilla-Reason: CC

The above mentioned error occur while:

My system is set up with compiler gcc-4.0.1 build on linux for native linux
On this system I build the binutils and crosscompiler for target m68hc12.
After compiling this gcc-m68hc12 compiler I tried to compile newlib.
While compiling newlib I got:

make[7]: Entering directory `/home/rudolphk/avrdownload/newlib-1.13.0/build/m68h
c12/m68hc11/mshort/newlib/libc/stdio'
m68hc12-gcc -B/home/rudolphk/avrdownload/newlib-1.13.0/build/m68hc12/m68hc11/msh
ort/newlib/ -isystem /home/rudolphk/avrdownload/newlib-1.13.0/build/m68hc12/m68h
c11/mshort/newlib/targ-include -isystem /home/rudolphk/avrdownload/newlib-1.13.0
/newlib/libc/include  -m68hc11 -mshort -DPACKAGE=\newlib\ -DVERSION=\1.13.0\
  -I. -I../../../../../../../newlib/libc/stdio  -DPREFER_SIZE_OVER_SPEED -Os -mr
elax -DNO_EXEC -DABORT_PROVIDED -DSMALL_MEMORY -DMISSING_SYSCALL_NAMES -fno-buil
tin-O2 -g -O2  -O2 -g -O2  -m68hc11 -mshort -fshort-enums -c ../../../../../
../../newlib/libc/stdio/vfprintf.c
../../../../../../../newlib/libc/stdio/vfprintf.c: In function '_vfprintf_r':
../../../../../../../newlib/libc/stdio/vfprintf.c:1221: error: insn does not sat
isfy its constraints:
(insn 4215 146 4213 14 ../../../../../../../newlib/libc/stdio/vfprintf.c:555 (pa
rallel [
(set (reg:DF 14 *_.d1)
(mem/s/u:DF (symbol_ref:HI (C.1.2987) var_decl 0x402aea20 C.1
) [74 C.1+0 S8 A8]))
(clobber (scratch:HI))
]) 18 {movdf_internal} (nil)
(nil))
../../../../../../../newlib/libc/stdio/vfprintf.c:1221: internal compiler error:
 in reload_cse_simplify_operands, at postreload.c:391


I set up my native linux compiler with:
./configure --prefix=/opt/linux
The cross compiler for m68hc12 was set up with:
./configure --prefix=/opt/m68hc1x --enable-languages=c,c++
The newlib was configured with:
./configure --prefix=/opt/m68hc1x

Used Tools and Compiler/Library-Versions: 
gcc 4.0.1
newlib 1.13.0
binutils 2.16

Sorry that I have problems answering the correct host/taget/build triplet
question :-(

Thanks
   Klaus

-- 
   Summary: insn does not sat
isfy its constraint message while compiling newlib
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: lts-rudolph at gmx dot de
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: i386-linux-gnu
  GCC host triplet: i386-linux-gnu
GCC target triplet: m68hc12


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23574

[Bug target/18798] global register variable: register is used for function calls

2004-12-03 Thread lts-rudolph at gmx dot de 

--- Additional Comments From lts-rudolph at gmx dot de  2004-12-03 08:39 
---
I think you are not right :-)

The gcc docs say that it is possible to overwrite the abi with ffixed-reg!

It is also an example given (qsort) which comes from external library. The
examples says that you have to recompile the library with giving the ffixed-reg
option and the resulting lib is compatible with the compiled program which uses
a global register variable.

Here is the original text from 3.4.3 online doc:
snip
Defining a global register variable in a certain register reserves that register
entirely for this use, at least within the current compilation. The register
will not be allocated for any other purpose in the functions in the current
compilation. The register will not be saved and restored by these functions.
Stores into this register are never deleted even if they would appear to be
dead, but references may be deleted or moved or simplified.

It is not safe to access the global register variables from signal handlers, or
from more than one thread of control, because the system library routines may
temporarily use the register for other things (unless you recompile them
specially for the task at hand).

It is not safe for one function that uses a global register variable to call
another such function foo by way of a third function lose that was compiled
without knowledge of this variable (i.e. in a different source file in which the
variable wasn't declared). This is because lose might save the register and put
some other value there. For example, you can't expect a global register variable
to be available in the comparison-function that you pass to qsort, since qsort
might have put something else in that register. (If you are prepared to
recompile qsort with the same global register variable, you can solve this 
problem.)

If you want to recompile qsort or other source files which do not actually use
your global register variable, so that they will not use that register for any
other purpose, then it suffices to specify the compiler option -ffixed-reg. You
need not actually add a global register declaration to their source code.
snap

Maybe the documentation should changed or the bug should be accepted.
The documentation says that also the ABI behaviour could be overwritten.

Regards,
   Klaus

-- 
   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18798

[Bug target/18798] global register variable: register is used for function calls

2004-12-02 Thread lts-rudolph at gmx dot de 

--- Additional Comments From lts-rudolph at gmx dot de  2004-12-02 21:12 
---
Created an attachment (id=7665)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7665action=view)
only one sourcefile needed, no others attatched

Simply use source file with avr-gcc and look for using of register r13.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18798

[Bug target/18798] global register variable: register is used for function calls

2004-12-02 Thread lts-rudolph at gmx dot de 

--- Additional Comments From lts-rudolph at gmx dot de  2004-12-02 21:43 
---
(In reply to comment #2)
 I think this is invalid, does -ffixed-reg=r13 fix the problem?

No, also using ffixed-regs will result in wrong code. 
As I saw in source (avr.c) the register allocation for functions
is not notify the fixed_regs[] field.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18798