[Bug target/61411] [NEON] ICE in reload_cse_simplify_operands, at postreload.c:411

[amker.cheng at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61411

--- Comment #3 from bin.cheng  ---
Then I think it's a latent bug in LRA.  It should consult back-end about
legitimized address expressions.

[Bug c/53119] -Wmissing-braces wrongly warns about universal zero initializer {0}

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53119

Marek Polacek  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||mpolacek at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #15 from Marek Polacek  ---
Should be fixed.

[Bug middle-end/56574] False possibly uninitialized variable warning

[luto at mit dot edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56574

Andy Lutomirski  changed:

   What|Removed |Added

 CC||luto at mit dot edu

--- Comment #7 from Andy Lutomirski  ---
I think this has gotten worse in newer GCC versions.  I'm up to six independent
triggers of this bug in my tree.

[Bug target/61300] powerpc64le miscompile with K&R-style function definition at -O0

[amodra at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61300

--- Comment #8 from Alan Modra  ---
Author: amodra
Date: Fri Jun  6 01:04:22 2014
New Revision: 211296

URL: http://gcc.gnu.org/viewcvs?rev=211296&root=gcc&view=rev
Log:
PR target/61300
* doc/tm.texi.in (INCOMING_REG_PARM_STACK_SPACE): Document.
* doc/tm.texi: Regenerate.
* function.c (INCOMING_REG_PARM_STACK_SPACE): Provide default.
Use throughout in place of REG_PARM_STACK_SPACE.
* config/rs6000/rs6000.c (rs6000_reg_parm_stack_space): Add
"incoming" param.  Pass to rs6000_function_parms_need_stack.
(rs6000_function_parms_need_stack): Add "incoming" param, ignore
prototype_p when incoming.  Use function decl when incoming
to handle K&R style functions.
* config/rs6000/rs6000.h (REG_PARM_STACK_SPACE): Adjust.
(INCOMING_REG_PARM_STACK_SPACE): Define.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/rs6000-protos.h
trunk/gcc/config/rs6000/rs6000.c
trunk/gcc/config/rs6000/rs6000.h
trunk/gcc/doc/tm.texi
trunk/gcc/doc/tm.texi.in
trunk/gcc/function.c

[Bug c/53119] -Wmissing-braces wrongly warns about universal zero initializer {0}

[bugdal at aerifal dot cx]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53119

--- Comment #14 from Rich Felker  ---
In C++, the correct zero initializer is {}, not {0}. I'm not an expert in C++
but I think {0} in C++ might even be a constraint violation unless the brace
level happens to match.

[Bug c/53119] -Wmissing-braces wrongly warns about universal zero initializer {0}

[nightstrike at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53119

nightstrike  changed:

   What|Removed |Added

 CC||nightstrike at gmail dot com

--- Comment #13 from nightstrike  ---
This is related to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36750

Can someone update the see also field?

Also, can this change be applied to c++ as well? Initializing a c struct in c++
code exhibits the same behavior.

[Bug other/61427] Fail to build due to #error GATHER_STATISTICS must be defined

[Torsten at Robitzki dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61427

--- Comment #1 from Torsten Robitzki  ---
I've tried the same configuration with gcc 4.8.3. The same error occurs in the
config.log, but this time the build stops with:

g++  -I../../libcpp -I. -I../../libcpp/../include -I./../intl
-I../../libcpp/include  -g -O2 -W -Wall -Wwrite-strings
-Wmissing-format-attribute -pedantic -Wno-long-long  -fno-exceptions -fno-rtti
-I../../libcpp -I. -I../../libcpp/../include -I./../intl -I../../libcpp/include
 -c -o charset.o -MT charset.o -MMD -MP -MF .deps/charset.Tpo
../../libcpp/charset.c
In file included from ../../libcpp/charset.c:22:
../../libcpp/include/cpplib.h:265:3: error: #error "Cannot find a least-32-bit
signed integer type"
In file included from ../../libcpp/charset.c:22:
../../libcpp/include/cpplib.h:267: error: ‘CPPCHAR_SIGNED_T’ does not name a
type
../../libcpp/include/cpplib.h:268: error: ‘CPPCHAR_SIGNED_T’ does not name a
type
../../libcpp/include/cpplib.h:777: error: ‘cppchar_t’ does not name a type
../../libcpp/include/cpplib.h:788: error: ‘cppchar_t’ does not name a type
../../libcpp/include/cpplib.h:808: error: ‘HOST_WIDE_INT’ does not name a type
../../libcpp/include/cpplib.h:812: error: ‘cpp_num_part’ does not name a type
../../libcpp/include/cpplib.h:813: error: ‘cpp_num_part’ does not name a type
../../libcpp/include/cpplib.h:966: error: ‘cppchar_t’ does not name a type

[Bug libstdc++/61424] std::regex matches right to left, not leftmost longest

[timshen at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61424

--- Comment #2 from Tim Shen  ---
Sorry, the preference of results of "|" is actually arbitrary. I'll fix it
later.

[Bug c++/61421] Invalid -O2 optimization breaks program

[mimamer at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61421

--- Comment #18 from mimamer at gmail dot com ---
Ah? I didn't figure that was allowed per strict aliasing rules. But it still
doesn't solve one problem:

inline T *dequeue() {
node *head = anchor.next;
anchor.next = head->next;
head->next->prev = &anchor;
return (T *)head;
};

The last typecast is invalid when the list is empty and thus returns the
anchor, a special element that so far I checked with equality to list2::end():
inline T* end() const { return (T *)&anchor; }

But it is a huge step forward as checking for an empty list in dequeue() is
just ok so as to return NULL instead of the anchor.

[Bug other/61427] New: Fail to build due to #error GATHER_STATISTICS must be defined

[Torsten at Robitzki dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61427

Bug ID: 61427
   Summary: Fail to build due to #error GATHER_STATISTICS must be
defined
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Torsten at Robitzki dot de

Hello,
I try to build an arm cross compiler on OSX. The used compiler is gcc version
4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.11.00). After
./configure the compiler with: 

 sudo ../configure --target=$target --prefix=$prefix \
--disable-shared --disable-threads \
--with-gcc --with-gnu-ld --with-gnu-as --with-dwarf2 \
--enable-languages=c,c++ \
--enable-multilib --with-newlib \
--with-headers=../../newlib-2.1.0/newlib/libc/include \
--disable-libssp --disable-libstdcxx-pch \
--disable--vtable-verify \
--without-libstdcxx \
--disable-libmudflap --disable-libgomp -v

the build brakes with:

g++ -c  -DIN_GCC_FRONTEND -g -O2 -DIN_GCC  -DCROSS_DIRECTORY_STRUCTURE 
-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wwrite-strings
-Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long
-Wno-variadic-macros -Wno-overlength-strings   -DHAVE_CONFIG_H -I. -Ic
-I../../gcc -I../../gcc/c -I../../gcc/../include -I./../intl
-I../../gcc/../libcpp/include  -I../../gcc/../libdecnumber
-I../../gcc/../libdecnumber/dpd -I../libdecnumber -I../../gcc/../libbacktrace  
 -o c/c-lang.o -MT c/c-lang.o -MMD -MP -MF c/.deps/c-lang.TPo
../../gcc/c/c-lang.c
In file included from ../../gcc/tree-core.h:26,
 from ../../gcc/tree.h:23,
 from ../../gcc/c/c-lang.c:25:
../../gcc/statistics.h:25:2: error: #error GATHER_STATISTICS must be defined
…

when searching the config.log for "error", I find: 

  conftest.cpp:11:2: error: #error -static-libstdc++ not implemented
  | #error -static-libstdc++ not implemented

could this be a bug in the gcc build?

Kind reagards,

Torsten

[Bug c++/61421] Invalid -O2 optimization breaks program

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61421

--- Comment #17 from Andrew Pinski  ---
(In reply to mimamer from comment #16)
> Ah ok, but that doesn't solve my problem as I will eventually need to cast a
> node pointer back to T (either at the caller or the callee side). So there
> _is_ no efficient solution with strict aliasing rules. Which makes it kinda
> broken, IMO.

No that cast works iff the original type of the variable was T and in your case
the only time it was not T is when it is anchor so it should just work
correctly.

[Bug c++/61421] Invalid -O2 optimization breaks program

[mimamer at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61421

--- Comment #16 from mimamer at gmail dot com ---
Ah ok, but that doesn't solve my problem as I will eventually need to cast a
node pointer back to T (either at the caller or the callee side). So there _is_
no efficient solution with strict aliasing rules. Which makes it kinda broken,
IMO.

[Bug c++/61421] Invalid -O2 optimization breaks program

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61421

--- Comment #15 from Andrew Pinski  ---
template class list2
{
  public:
struct node {
node*next;
node*prev;
};

nodeanchor;

  public:
/* API */
}

struct Obj : list2::node {
/* obj-specific elements */
}

list2main_list;

[Bug c++/61421] Invalid -O2 optimization breaks program

[mimamer at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61421

--- Comment #14 from mimamer at gmail dot com ---
Can you explain what you mean by "use type node inside the struct node"?
Because I still cannot see an (efficient) way for solving this problem.

[Bug c++/61421] Invalid -O2 optimization breaks program

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61421

Andrew Pinski  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |INVALID

--- Comment #13 from Andrew Pinski  ---
Invalid as explained.

[Bug c++/61421] Invalid -O2 optimization breaks program

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61421

--- Comment #12 from Andrew Pinski  ---
(In reply to mimamer from comment #11)
> In short form,
> 
> template class list2
> {
>   public:
>   struct node {
>   T   *next;
>   T   *prev;
>   };
> 
>   nodeanchor;
> 
>   public:
>   /* API */
> }
> 
> struct Obj : list2::node {
>   /* obj-specific elements */
> }
> 
> list2main_list;
> 
> So, anchor is of type list2::node while Obj is derived from
> list2::node.

Oh you are upcasting from node to T but the variable is of node type only and
not T.  So this is invalid because of that.  

You need to use either type node inside the struct node or change anchor to
type T instead.

[Bug c++/61421] Invalid -O2 optimization breaks program

[mimamer at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61421

--- Comment #11 from mimamer at gmail dot com ---
In short form,

template class list2
{
  public:
struct node {
T*next;
T*prev;
};

nodeanchor;

  public:
/* API */
}

struct Obj : list2::node {
/* obj-specific elements */
}

list2main_list;

So, anchor is of type list2::node while Obj is derived from
list2::node.

[Bug libstdc++/61424] std::regex matches right to left, not leftmost longest

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61424

--- Comment #1 from Jonathan Wakely  ---
A slight variation:

#include 
#include 

using namespace std;

int main()
{
  regex_constants::syntax_option_type grammar[] = {
regex_constants::ECMAScript, regex_constants::extended,
regex_constants::awk, regex_constants::egrep
  };
  for (auto g : grammar)
  {
regex re("tour|tournament|tourn", g);
const char str[] = "tournament";
cmatch m;
if (regex_search(str, m, re))
  cout << m[0] << endl;
else
  cout << "-" << endl;
  }
}

ECMAscript should match "tour", the POSIX ERE grammars should match
"tournament"

Instead we match "tourn" for all grammars.

[Bug c++/43453] Initialization of char array with string literal fails in mem-initializer

[jason at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43453

--- Comment #9 from Jason Merrill  ---
Author: jason
Date: Thu Jun  5 20:55:44 2014
New Revision: 211290

URL: http://gcc.gnu.org/viewcvs?rev=211290&root=gcc&view=rev
Log:
PR c++/43453
* decl.c (check_initializer): Collapse a TREE_LIST here.
* typeck2.c (store_init_value): Not here.

Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl.c
trunk/gcc/cp/typeck2.c

[Bug libstdc++/61426] [C++11] std::deque requires more from allocator than the standard provides.

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61426

--- Comment #2 from Jonathan Wakely  ---
std::list and std::string don't meet the C++11 allocator reqs either, please
don't report them ;-)

[Bug libstdc++/61426] [C++11] std::deque requires more from allocator than the standard provides.

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61426

--- Comment #1 from Jonathan Wakely  ---
Yes, this is well known and documented

[Bug libstdc++/61425] std::regex ignores backslash when using basic or grep grammars

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61425

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #3 from Jonathan Wakely  ---
Grr, sorry for the noise. ALl my BSD boxen actually use GNU grep. AIX grep
doesn't support \| in BREs, so I think std::regex is behaving correctly.

[Bug libstdc++/61426] New: [C++11] std::deque requires more from allocator than the standard provides.

[ppluzhnikov at google dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61426

Bug ID: 61426
   Summary: [C++11] std::deque requires more from allocator than
the standard provides.
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ppluzhnikov at google dot com

Google ref: b/15420505

Section 23.3.3.1 of C++11 shows the following typedef members of deque,
among others:

   typedef typename allocator_traits::pointer pointer;
   typedef typename allocator_traits::const_pointer const_pointer;

Table 28 in section 17.6.3.5 shows that the `pointer` and `const_pointer`
members of allocator_traits have defaults, and therefore by the text in
17.6.3.5.2 the allocator type is not required to define these.

We should be able to use a custom allocator type with deque without defining
these. For what it's worth, cppreference.com agrees; it calls them optional
and doesn't include them in its minimal example (grep "SimpleAllocator"):

   http://en.cppreference.com/w/cpp/concept/Allocator

Above allocator works for std::vector and std::map, but not std::deque
(using trunk GCC @r211286).


Test case:

#include 

template 
struct SimpleAllocator {
  typedef Tp value_type;
  SimpleAllocator(/*ctor args*/);
  template  SimpleAllocator(const SimpleAllocator& other);
  Tp* allocate(std::size_t n);
  void deallocate(Tp* p, std::size_t n);

#ifdef REBIND
  template
  struct rebind {
typedef SimpleAllocator other;
  };
#endif

};
template 
bool operator==(const SimpleAllocator&, const SimpleAllocator&);
template 
bool operator!=(const SimpleAllocator&, const SimpleAllocator&);

#include 

typedef std::deque > IntDeque;
std::size_t foo(IntDeque& d)
{
  d.push_back(1);
  d.pop_front();
  return d.max_size();
}


/gcc-svn-r211286/bin/g++ -c t.cc -DDEQUE -std=c++11 
In file included from /gcc-svn-r211286/include/c++/4.10.0/deque:64:0,
 from t.cc:24:
/gcc-svn-r211286/include/c++/4.10.0/bits/stl_deque.h: In instantiation of
'class std::_Deque_base >':
/gcc-svn-r211286/include/c++/4.10.0/bits/stl_deque.h:735:11:   required from
'class std::deque >'
t.cc:29:4:   required from here
/gcc-svn-r211286/include/c++/4.10.0/bits/stl_deque.h:490:61: error: no class
template named 'rebind' in 'struct SimpleAllocator'
   typedef typename _Alloc::template rebind<_Tp*>::other _Map_alloc_type;
 ^
... many more ...

In addition to 'rebind', 'construct' and 'destroy', std::deque currently
also requires 'pointer', 'const_pointer', 'reference', 'const_reference'
and 'max_size', as can be seen by building with:

/gcc-svn-r211286/bin/g++ -c t.cc -DDEQUE -std=c++11 -DREBIND

[Bug libstdc++/61425] std::regex ignores backslash when using basic or grep grammars

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61425

--- Comment #2 from Jonathan Wakely  ---
Hmm, I guess I shouldn't trust man pages, a POSIX BRE doesn't allow \|

Both GNU and BSD grep do allow 'a\|b' in a BRE though ... still trying to
determine if it should be allowed for the grep grammar or f this bug's just
invalid...

[Bug c++/61421] Invalid -O2 optimization breaks program

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61421

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2014-06-05
 Ever confirmed|0   |1

--- Comment #10 from Andrew Pinski  ---
(In reply to mimamer from comment #9)
> Now that I have read enough about aliasing rules I realize that they are
> considerably fucked up and that their is no way to efficiently downcast
> without violating strict aliasing rules. 

I don't see any downcasting, all I see is side casting; at least with your code
sections so far.

How are list2::node and T declared?  Does the first element of node a T or
inherits from T?  If not there is no downcasting, it is rather side casting and
that is what makes the code undefined.

[Bug libstdc++/61425] std::regex ignores backslash when using basic or grep grammars

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61425

--- Comment #1 from Jonathan Wakely  ---
Correction: it ignores it with -std=gnu++11, it throws regex_error with
-std=c++11

So it's treating \| as illegal, which is wrong for a POSIX BRE.

[Bug libstdc++/61425] New: std::regex ignores backslash when using basic or grep grammars

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61425

Bug ID: 61425
   Summary: std::regex ignores backslash when using basic or grep
grammars
   Product: gcc
   Version: 4.9.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
CC: timshen at gcc dot gnu.org

#include 
#include 

using namespace std;

int main()
{
  regex_constants::syntax_option_type grammar[] = {
regex_constants::basic, regex_constants::grep
  };
  for (auto g : grammar)
  {
regex re("a\\|b", g);
const char str[] = "a|b";
cmatch m;
if (regex_search(str, m, re))
  cout << m.size() << ' ' << m[0] << endl;
  }
}

There should be two matches, "a" and "b", instead there's only one:

1 a|b
1 a|b

The backslash seems to be ignored.

[Bug libstdc++/61424] New: std::regex matches right to left, not leftmost longest

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61424

Bug ID: 61424
   Summary: std::regex matches right to left, not leftmost longest
   Product: gcc
   Version: 4.9.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org

#include 
#include 

using namespace std;

int main()
{
  regex_constants::syntax_option_type grammar[] = {
regex_constants::ECMAScript, regex_constants::extended,
regex_constants::awk, regex_constants::egrep
  };
  for (auto g : grammar)
  {
regex re("tournament|tour", g);
const char str[] = "tournament";
cmatch m;
regex_search(str, m, re);
cout << m[0] << endl;
  }
}

This prints:

tour
tour
tour
tour

ECMAscript should check alternations left to right, and POSIX has the leftmost,
longest rule
(http://www.boost.org/doc/libs/1_55_0/libs/regex/doc/html/boost_regex/syntax/leftmost_longest_rule.html)

[Bug c++/61421] Invalid -O2 optimization breaks program

[mimamer at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61421

--- Comment #9 from mimamer at gmail dot com ---
Now that I have read enough about aliasing rules I realize that they are
considerably fucked up and that their is no way to efficiently downcast without
violating strict aliasing rules. In explanation, you need to copy your data out
and back (which takes time), or implement an instance of a derived class in the
first place (which consumes memory). Yes, my code is efficiency-critical.
Hooray for retarded aliasing rules. (If I don't care about efficiency I could
just as well switch to Java, which gives all the safety that one needs.)

[Bug testsuite/61415] PowerPC test gcc.target/powerpc/tfmode_off.c fails if -mlong-double-64

[bergner at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61415

Peter Bergner  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2014-06-05
   Assignee|meissner at gcc dot gnu.org|bergner at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Peter Bergner  ---
The same problem exists for the gcc.target/powerpc/pack02.c test case.  The
correct soslution is to create a longdouble128 dg-require-effective-target and
add that to both test cases.  In addition, we should also disable the
__builtin_unpack_longdouble and __builtin_pack_longdouble builtins when
-mlong-double-128 is not in effect.  I'm testing a patch.

[Bug c/53119] -Wmissing-braces wrongly warns about universal zero initializer {0}

[law at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53119

--- Comment #12 from Jeffrey A. Law  ---
Author: law
Date: Thu Jun  5 19:36:03 2014
New Revision: 211289

URL: http://gcc.gnu.org/viewcvs?rev=211289&root=gcc&view=rev
Log:
2014-06-05  S. Gilles  

PR c/53119
* c-typeck.c (push_init_level, process_init_element,
pop_init_level): Correct check for zero initialization, move
missing brace warning to respect zero initialization.

PR c/53119
* gcc.dg/pr53119.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/pr53119.c
Modified:
trunk/gcc/c/ChangeLog
trunk/gcc/c/c-typeck.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/61421] Invalid -O2 optimization breaks program

[mimamer at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61421

--- Comment #8 from mimamer at gmail dot com ---
As concerns -fno-strict-aliasing, I have to put it before -O2. Sorry for the
mixup.

[Bug c++/61421] Invalid -O2 optimization breaks program

[mimamer at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61421

--- Comment #7 from mimamer at gmail dot com ---
Violation of aliasing or not, the problem arises prior to the downcasting from
list2::node* to T*:
T *head = anchor.next;
anchor.next = head->next;
head->next->prev = (T *)&anchor;  // where did head->next become NULL???
where anchor is defined as
struct node {
T*next;
T*prev;
} anchor;
I don't see actually why this should be invalid under any (retarded) aliasing
rules. If Andrew or any of the other experts here could point out to me how the
problem can be solved _without_ fundamentally changing the implementation of
list2 (such as specifying anchor as of type T) I would be very grateful. Thanks
a LOT in advance!

Also, again, why does -fno-strict-aliasing (placed _after_ -O2) not have any
effect?

[Bug debug/52472] ICE: in convert_debug_memory_address, at cfgexpand.c:2491

[law at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52472

--- Comment #9 from Jeffrey A. Law  ---
Author: law
Date: Thu Jun  5 18:34:43 2014
New Revision: 211288

URL: http://gcc.gnu.org/viewcvs?rev=211288&root=gcc&view=rev
Log:
PR target/52472
* cfgexpand.c (expand_debug_expr): Use address space of nested
TREE_TYPE for ADDR_EXPR and MEM_REF.

PR target/52472
* gcc.target/avr/pr52472.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/avr/pr52472.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/cfgexpand.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/61289] [4.9/4.10 Regression] Bad jump threading generates infinite loop

[law at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61289

--- Comment #3 from Jeffrey A. Law  ---
Author: law
Date: Thu Jun  5 18:25:02 2014
New Revision: 211287

URL: http://gcc.gnu.org/viewcvs?rev=211287&root=gcc&view=rev
Log:
PR tree-optimization/61289
* tree-ssa-threadedge.c (invalidate_equivalences): Remove SRC_MAP and
DST_MAP parameters.   Invalidate by walking all the SSA_NAME_VALUES
looking for those which match LHS.  All callers changed.
(record_temporary_equivalences_from_phis): Remove SRC_MAP and DST_MAP
parameters and code which manipulated them.  All callers changed.
(record_temporary_equivalences_from_stmts_at_dest): Remove SRC_MAP
and DST_MAP parameters.  Simplify invalidation code by just calling
invalidate_equivalences.  All callers changed.
(thread_across_edge): Simplify now that we don't need to maintain
the map of equivalences to invalidate.

PR tree-optimization/61289
* g++.dg/pr61289.C: New test.
* g++.dg/pr61289-2.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/pr61289-2.c
trunk/gcc/testsuite/g++.dg/pr61289.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-threadedge.c

[Bug c++/61421] Invalid -O2 optimization breaks program

[mimamer at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61421

--- Comment #6 from mimamer at gmail dot com ---
Btw, C++ doesn't give me any aliasing warnings even with -Wstrict-aliasing=1.

[Bug c++/56961] stack overflow in gimplifier with volatile field

[paolo.carlini at oracle dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56961

Paolo Carlini  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Assignee|paolo.carlini at oracle dot com|unassigned at gcc dot 
gnu.org

--- Comment #12 from Paolo Carlini  ---
Fixed for 4.10.0.

[Bug c++/56961] stack overflow in gimplifier with volatile field

[paolo at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56961

--- Comment #11 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Thu Jun  5 17:34:48 2014
New Revision: 211286

URL: http://gcc.gnu.org/viewcvs?rev=211286&root=gcc&view=rev
Log:
/cp
2014-06-05  Richard Biener  
Paolo Carlini  

PR c++/56961
* cp-gimplify.c (cp_gimplify_expr, [MODIFY_EXPR]): Rework
handling of empty classes.

/testsuite
2014-06-05  Richard Biener  
Paolo Carlini  

PR c++/56961
* g++.dg/parse/pr56961.C: New.

Added:
trunk/gcc/testsuite/g++.dg/parse/pr56961.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-gimplify.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/61421] Invalid -O2 optimization breaks program

[mimamer at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61421

--- Comment #5 from mimamer at gmail dot com ---
T is derived from list2::node, and yes, I'm "up"casting from node to T.
There is no other way around it in the implementation, and if this causes a
problem with aliasing then I don't know what it's good for. Any input
appreciated.

[Bug c++/61343] [C++11] Missing default initialization for class with default constructor

[jason at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61343

--- Comment #1 from Jason Merrill  ---
Author: jason
Date: Thu Jun  5 17:30:51 2014
New Revision: 211284

URL: http://gcc.gnu.org/viewcvs?rev=211284&root=gcc&view=rev
Log:
PR c++/61343
* decl.c (check_initializer): Maybe clear
DECL_INITIALIZED_BY_CONSTANT_EXPRESSION_P.

Added:
trunk/gcc/testsuite/g++.dg/tls/thread_local9.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl.c

[Bug lto/61334] [4.10 Regression] lto-cgraph.c:976:68: error: 'strnlen' was not declared in this scope

[ro at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61334

--- Comment #6 from Rainer Orth  ---
It would be good to get this patch in now: without it, bootstrap on at least
one primary platform is broken.

  Rainer

[Bug c++/61421] Invalid -O2 optimization breaks program

[mimamer at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61421

--- Comment #4 from mimamer at gmail dot com ---
Indeed, this is alias-related. Two questions:

(1) What is a concrete solution for this problem when -fstrict-aliasing is
being used? How should I change my code? (Sorry, I am no expert on this.)

(2) Why is -fno-strict-aliasing being ignored when placed after -O2, just as I
had it all the time in my Makefile?

[Bug target/46219] Generate indirect jump instruction on x86-64

[ktietz at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46219

Kai Tietz  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||ktietz at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #5 from Kai Tietz  ---
Fixed.

[Bug target/46219] Generate indirect jump instruction on x86-64

[ktietz at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46219

--- Comment #4 from Kai Tietz  ---
Author: ktietz
Date: Thu Jun  5 17:03:52 2014
New Revision: 211283

URL: http://gcc.gnu.org/viewcvs?rev=211283&root=gcc&view=rev
Log:
2014-06-05  Kai Tietz  
Richard Henderson  

PR target/46219
* config/i386/predicates.md (memory_nox32_operand): Add memory_operand
checking for !TARGET_X32.
* config/i386/i386.md (UNSPEC_PEEPSIB): New unspec constant.
(sibcall_intern): New define_insn, plus required peepholes.
(sibcall_pop_intern): Likewise.
(sibcall_value_intern): Likewise.
(sibcall_value_pop_intern): Likewise.

2014-06-05  Kai Tietz  

PR target/46219
* gcc.target/i386/sibcall-4.c: Remove xfail.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.md
trunk/gcc/config/i386/predicates.md
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/i386/sibcall-4.c

[Bug sanitizer/61422] False Asan positive in libopus

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61422

--- Comment #7 from Jakub Jelinek  ---
You still have:
  tree shadow_ptr_type = shadow_ptr_types[ real_size_in_bytes == 16 ? 1 : 0];
instead of:
  tree shadow_ptr_type = shadow_ptr_types[real_size_in_bytes == 16 ? 1 : 0];
And, I can't really reproduce using your testcase, so either you have local
patches other than this (I think Yuri Gribov has been working on something in
this area), or it really would be better to use a testcase with explicit 16
byte unaligned access (or both). Still no point to use * 1, or "\n" in the asm
pattern ("" is good enough).

That said, patches should be posted to gcc-patches mailing list.

[Bug c++/61421] Invalid -O2 optimization breaks program

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61421

--- Comment #3 from Andrew Pinski  ---
This seems alias related. Can you make sure you are not violating c/c++ alias
rules. Mainly make sure T and typeof(anchor) can alias.

[Bug sanitizer/61422] False Asan positive in libopus

[m.zakirov at samsung dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61422

--- Comment #6 from Marat Zakirov  ---
Created attachment 32898
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=32898&action=edit
Proposed patch

Try this. It is mostly the same. No additional patches is needed. I hope it's
reproducible.

[Bug sanitizer/61422] False Asan positive in libopus

[m.zakirov at samsung dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61422

--- Comment #5 from Marat Zakirov  ---
Thank you for your quick response Jacub. Actually I take this issue from
existing ffmpeg source so the test is just a truncated version. 

Following fail in my 4.10 without discovered fix:

cat test.c

#define N   4
#define M   16

int main ()
{
  int  i = 1, j = 3;
  char ind[N][M];
  __builtin_memset( ind, 0, M * N);
  __asm ("\n"
   : "+m"(i), "+m"(j));
  __builtin_memcpy (ind[j], ind[i], M * 1);
  return 0;
}

gcc test.c -fsanitize=address -static-libasan 
./a.out

[Bug c++/61421] Invalid -O2 optimization breaks program

[mimamer at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61421

--- Comment #2 from mimamer at gmail dot com ---
Turns out the problems arise in different places but only in the
list2::dequeue() function:

inline T *dequeue() {
//asm volatile("":::"memory");
T *head = anchor.next;
anchor.next = head->next;
head->next->prev = (T *)&anchor;
#if 1//(defined(DEBUG) || defined(_DEBUG)) && !defined(NDEBUG)
if ( head != (T *)&anchor )
head->prev = head->next = NULL;
#endif
return head;
};

Uncommenting the memory barrier resolves all issues.

[Bug c++/61421] Invalid -O2 optimization breaks program

[mimamer at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61421

--- Comment #1 from mimamer at gmail dot com ---
A minimalistic version that breaks with all -O2 flags set:

Starting from an empty main_list:

Node *node;
//asm volatile("":::"memory");
while ( (node = main_list.dequeue()) != main_list.end() )
_dprintf("");

Uncomment the memory barrier and it works.

[Bug sanitizer/61422] False Asan positive in libopus

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61422

--- Comment #4 from Jakub Jelinek  ---
If you want a testcase that crashes even for me with current trunk, then e.g.:
struct S { char c[16]; } __attribute__((packed));

__attribute__((noinline, noclone)) struct S
foo (struct S *p)
{
  asm volatile ("" : : "r" (p) : "memory");
  return *p;
}

int
main ()
{
  struct S a __attribute__((aligned (16)));
  struct S b __attribute__((aligned (16)));
  __builtin_memset (&b, 0, sizeof b);
  a = foo (&b);
  asm volatile ("" : : "m" (a), "m" (b));
  return 0;
}

[Bug sanitizer/61422] False Asan positive in libopus

[m.zakirov at samsung dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61422

--- Comment #3 from Marat Zakirov  ---
I fix it.

[Bug sanitizer/61422] False Asan positive in libopus

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61422

--- Comment #2 from Jakub Jelinek  ---
Comment on attachment 32896
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=32896
Proposed patch

Can't reproduce it, are you sure you don't have extra patches in the tree
(stringops currently don't use the the real_size_in_bytes != size_in_bytes
accesses).

The fix is good, except for the bogus whitespace after [ and incorrect testcase
(you should be really using "+m" instead of "=m", otherwise the compiler could
optimize away the stores of 1 or 3.  Also, please don't add * sizeof (char)
there, that is * 1 by definition.  And please use __builtin_memcpy instead of
unprototyped memcpy.  And copying around uninitialized bytes probably isn't a
good idea either, so you should first memset it or fill in or something.

[Bug c/61423] Incorrect conversion from unsigned int to floating point

[lvqcl.mail at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61423

--- Comment #1 from lvqcl.mail at gmail dot com ---
Created attachment 32897
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=32897&action=edit
test program

[Bug c/61423] New: Incorrect conversion from unsigned int to floating point

[lvqcl.mail at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61423

Bug ID: 61423
   Summary: Incorrect conversion from unsigned int to floating
point
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lvqcl.mail at gmail dot com

The attached program works incorrectly when compiled for i686 with '-O3 -msse2'
or '-O1 -ftree-vectorize -msse2'.

GCC compiles the function

#define N 1024
static unsigned int A[N];
double func (void)
{
unsigned int sum = 0;
unsigned i;
double t;

for (i = 0; i < N; i++) sum += A[i];

t = sum; /* uint32 -> double */
return t;
}

into the following:

01:pxor%xmm0, %xmm0
02:movl$_A, %eax
03: L2:
04:paddd(%eax), %xmm0
05:addl$16, %eax
06:cmpl$_A+4096, %eax
07:jneL2
08:movdqa%xmm0, %xmm1
09:subl$28, %esp
10:psrldq$8, %xmm1
11:paddd%xmm1, %xmm0
12:movdqa%xmm0, %xmm1
13:psrldq$4, %xmm1
14:paddd%xmm1, %xmm0
15:movq%xmm0, 8(%esp)
16:fildq8(%esp)
17:addl$28, %esp
18:ret

After the line 07: xmm0 contains four partial sums.
After the line 14: lower 4 bytes of xmm0 contain the total sum, the rest 12
bytes contain garbage.
Lines 15 and 16: *eight* bytes from xmm0 are stored in memory and then loaded
into an FPU register.

According to the message from Robert Kausch (
http://lists.xiph.org/pipermail/flac-dev/2014-June/004723.html ) this bug
exists since GCC 4.4.

[Bug sanitizer/61422] False Asan positive in libopus

[m.zakirov at samsung dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61422

--- Comment #1 from Marat Zakirov  ---
Created attachment 32896
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=32896&action=edit
Proposed patch

Only tested with asan testsuite on x64.

[Bug sanitizer/61422] New: False Asan positive in libopus

[m.zakirov at samsung dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61422

Bug ID: 61422
   Summary: False Asan positive in libopus
   Product: gcc
   Version: 4.10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: m.zakirov at samsung dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org

Bug is reproducible on simple test like:

//Issue was taken from libopus, ffmpeg library

#define NLSF_QUANT_DEL_DEC_STATES   4
#define MAX_LPC_ORDER   16

int main()
{
int  ind_min_max = 1, ind_max_min = 3;
char ind[ NLSF_QUANT_DEL_DEC_STATES ][ MAX_LPC_ORDER ];
__asm ("\n"
 : "=m"(ind_min_max), "=m"(ind_max_min));
memcpy( ind[ ind_max_min ], ind[ ind_min_max ], MAX_LPC_ORDER * sizeof(
char ) );
return 0;
}

Output will be:

==20809==ERROR: AddressSanitizer: unknown-crash on address 0x7fff92804b00 at pc
0x4f934d bp 0x7fff92804a20 sp 0x7fff92804a00
WRITE of size 16 at 0x7fff92804b00 thread T0
#0 0x4f934c in main
(/home/mzakirov/proj/found_bugs/asan_bug/res.out+0x4f934c)
#1 0x7f32dd7d776c in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x2176c)
#2 0x40c308 (/home/mzakirov/proj/found_bugs/asan_bug/res.out+0x40c308)

Address 0x7fff92804b00 is located in stack of thread T0 at offset 208 in frame
#0 0x4f921b in main
(/home/mzakirov/proj/found_bugs/asan_bug/res.out+0x4f921b)

  This frame has 3 object(s):
[32, 36) 'ind_min_max'
[96, 100) 'ind_max_min'
[160, 224) 'ind' <== Memory access at offset 208 is inside this variable
HINT: this may be a false positive if your program uses some custom stack
unwind mechanism or swapcontext
  (longjmp and C++ exceptions *are* supported)
SUMMARY: AddressSanitizer: unknown-crash ??:0 main
Shadow bytes around the buggy address:
  0x1000724f8910: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1000724f8920: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1000724f8930: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1000724f8940: 00 00 00 00 00 00 f1 f1 f1 f1 04 f4 f4 f4 f2 f2
  0x1000724f8950: f2 f2 04 f4 f4 f4 f2 f2 f2 f2 00 00 00 00 00 00
=>0x1000724f8960:[00]00 f3 f3 f3 f3 00 00 00 00 00 00 00 00 00 00
  0x1000724f8970: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1000724f8980: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1000724f8990: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1000724f89a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1000724f89b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:   00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:   fa
  Heap right redzone:  fb
  Freed heap region:   fd
  Stack left redzone:  f1
  Stack mid redzone:   f2
  Stack right redzone: f3
  Stack partial redzone:   f4
  Stack after return:  f5
  Stack use after scope:   f8
  Global redzone:  f9
  Global init order:   f6
  Poisoned by user:f7
  Container overflow:  fc
  ASan internal:   fe
==20809==ABORTING

[Bug c++/61421] New: Invalid -O2 optimization breaks program

[mimamer at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61421

Bug ID: 61421
   Summary: Invalid -O2 optimization breaks program
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mimamer at gmail dot com

Created attachment 32895
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=32895&action=edit
disassembly of faulty binary snippet

It seems that C++ carries out an invalid optimization when compiled with -O2
that breaks the following code snippet:

_dprintf("p %p, n %p, t %p\n", include_list2.head()->prev,
include_list2.head()->next, include_list2.end());
while ( (node = include_list2.dequeue()) != include_list2.end() ) {
//asm volatile("":::"memory");
main_list.insert_at( &iterator->main_node, &node->main_node );
iterator = node;
}
_dprintf("p %p, n %p, t %p\n", include_list2.head()->prev,
include_list2.head()->next, include_list2.end());

Output:
p 0x007f9e44, n 0x007f9e44, t 0x007f9e44
p 0x007f9e44, n 0x, t 0x007f9e44

Expected output:
p 0x007f9e44, n 0x007f9e44, t 0x007f9e44
p 0x007f9e44, n 0x007f9e44, t 0x007f9e44

Explanation: include_list2 implements a simple doubly-linked list, which
happens to be empty at the beginning (i.e., the head's previous and next
pointers both point to the list's anchor, returned by end()). dequeue() thus
should return the anchor, which equals end() (i.e., the while loop should not
be entered). So, nothing should have changed after the loop, yet the anchor's
next pointer suddenly has become zero. Adding the memory barrier (i.e.,
uncommenting the line with the asm statement) gives the expected result.

Disassambled binary output for the snippet is attached, once in its faulty
version and once with the memory barrier. A minimal implementation of list2 is
attached as well. All in one file (why can't I submit more than one?).

[Bug fortran/61420] [4.7/4.8/4.9/4.10 Regression] type bound procedure with pass attribute, that returns a procedure pointer, fails to compile

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61420

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-06-05
Summary|type bound procedure with   |[4.7/4.8/4.9/4.10
   |pass attribute, that|Regression] type bound
   |returns a procedure |procedure with pass
   |pointer, fails to compile   |attribute, that returns a
   ||procedure pointer, fails to
   ||compile
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
No error with r162456 (2010-07-23), error with r1635293 (2010-08-24). No
obvious culprit. Still present at r211262.

[Bug fortran/61420] New: type bound procedure with pass attribute, that returns a procedure pointer, fails to compile

[robert.rosenberg at nrl dot navy.mil]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61420

Bug ID: 61420
   Summary: type bound procedure with pass attribute, that returns
a procedure pointer, fails to compile
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: robert.rosenberg at nrl dot navy.mil

Created attachment 32894
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=32894&action=edit
defines type bound procedure that returns a procedure pointer

I was writing some sample code that defines a function that returns a pointer
procedure. 

When I compile the code with Intel Ifort.14.x/15.x it complains saying that
this exact feature is not supported.

When I compile with GNU gfortran49, it compiles and runs fine. But when I
insert the statement, 'implicit none' at the beginning of the code, the code
fails to compile. If I then use an implicit procedure pointer interface, it
again runs fine. 

I include the code as an attachment

[Bug ipa/61393] [trans-mem] O3 optimization level constant propagation problem

[jamborm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61393

Martin Jambor  changed:

   What|Removed |Added

Version|4.8.3   |4.10.0

--- Comment #5 from Martin Jambor  ---
OK, so this is now "fixed" on release branches but still failing on
trunk.  On trunk we'd like to fix this properly, see my comments above
bout copying tm_clone flag during cgraph_node cloning.

[Bug fortran/61418] [4.9/4.10 Regression] HDF5 build failure with -flto: libgfortran.spec: attempt to rename spec 'lib' to already defined spec 'liborig'

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61418

--- Comment #16 from Richard Biener  ---
Author: rguenth
Date: Thu Jun  5 14:28:23 2014
New Revision: 211281

URL: http://gcc.gnu.org/viewcvs?rev=211281&root=gcc&view=rev
Log:
2014-06-05  Richard Biener  

PR fortran/61418
* gfortranspec.c (spec_file): Remove.
(find_spec_file): Likewise.
(lang_specific_driver): Do not look for specs file in -L
or append -specs command line argument.
(lang_specific_pre_link): Always %:include libgfortran.spec.

Modified:
branches/gcc-4_9-branch/gcc/fortran/ChangeLog
branches/gcc-4_9-branch/gcc/fortran/gfortranspec.c

[Bug fortran/61418] [4.9/4.10 Regression] HDF5 build failure with -flto: libgfortran.spec: attempt to rename spec 'lib' to already defined spec 'liborig'

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61418

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #15 from Richard Biener  ---
Fixed.

[Bug fortran/61418] [4.9/4.10 Regression] HDF5 build failure with -flto: libgfortran.spec: attempt to rename spec 'lib' to already defined spec 'liborig'

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61418

--- Comment #14 from Richard Biener  ---
Author: rguenth
Date: Thu Jun  5 14:27:20 2014
New Revision: 211280

URL: http://gcc.gnu.org/viewcvs?rev=211280&root=gcc&view=rev
Log:
2014-06-05  Richard Biener  

PR fortran/61418
* gfortranspec.c (spec_file): Remove.
(find_spec_file): Likewise.
(lang_specific_driver): Do not look for specs file in -L
or append -specs command line argument.
(lang_specific_pre_link): Always %:include libgfortran.spec.

Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/gfortranspec.c

[Bug c++/56961] stack overflow in gimplifier with volatile field

[paolo.carlini at oracle dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56961

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |paolo.carlini at oracle 
dot com
   Target Milestone|--- |4.10.0

--- Comment #10 from Paolo Carlini  ---
Handling it.

[Bug target/61411] [NEON] ICE in reload_cse_simplify_operands, at postreload.c:411

[vmakarov at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61411

--- Comment #2 from Vladimir Makarov  ---
(In reply to bin.cheng from comment #1)
> The patch can fix the issue, but problem is why GCC/lra generated
> register-indexing ([reg+reg]) addressing mode for V8HImode in the first
> place.  Since without this patch, the address expression is illegal and
> shouldn't be generated.  I didn't look into LRA's code and am not very sure
> whether this patch is covering the problem.

LRA does a lot of RTL transformations during its work.  One transformation can
be rematerialization -- changing one reg (usually a spilled pseudo) on
equivalent expression, e.g. sum of two regs or even more complex expression. 
That is how such address can occur during LRA work.  But LRA should do all
necessary transformations to get the right address after all.

[Bug c/61419] Hello World program compilation leads to internal compiler error

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61419

--- Comment #3 from Richard Biener  ---
I suggest to file a bug in Fedoras bugzilla then.

[Bug c/61419] Hello World program compilation leads to internal compiler error

[jerriclynsjohn at outlook dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61419

--- Comment #2 from Jerric Lyns John  ---
Its an issue with FC19 and not wayland.

[Bug target/61330] [4.10 Regression] Thumb ICE for case 920507-1.c

[jgreenhalgh at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61330

jgreenhalgh at gcc dot gnu.org changed:

   What|Removed |Added

 Target||aarch64*-*-*, arm*-*-*,
   ||powerpc*-*-*
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-06-05
 CC||jgreenhalgh at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #3 from jgreenhalgh at gcc dot gnu.org ---
Confirmed across aarch64* and arm*.

[Bug target/61330] [4.10 Regression] Thumb ICE for case 920507-1.c

[jgreenhalgh at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61330

jgreenhalgh at gcc dot gnu.org changed:

   What|Removed |Added

 CC||sch...@linux-m68k.org

--- Comment #2 from jgreenhalgh at gcc dot gnu.org ---
*** Bug 61394 has been marked as a duplicate of this bug. ***

[Bug middle-end/61394] [4.10 regression] ICE in symtab_get_node

[jgreenhalgh at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61394

jgreenhalgh at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||jgreenhalgh at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #2 from jgreenhalgh at gcc dot gnu.org ---
Duplicates [Bug target/61330] [4.10 Regression] Thumb ICE for case 920507-1.c

*** This bug has been marked as a duplicate of bug 61330 ***

[Bug sanitizer/61408] r205695 breaks packaging step of Firefox 24 ESR on Ubuntu Lucid building with ASan

[gk at torproject dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61408

--- Comment #7 from Georg Koppen  ---
(In reply to Jakub Jelinek from comment #6)
> I'd say there is no point in doing that.  Just build the compiler-rt library
> and link it in statically (-static-libasan) with gcc instead of the gcc one.

Hmm... how do I do that exactly? I have some libclang_rt.* in
Release+Asserts/lib/clang/3.5.0/lib/linux but seem not to be able to get that
going...

And I don't get any Firefox version between 24 and trunk compiled with 3.5.0
(for different reasons), thus that way is blocked as well atm.

[Bug c++/61004] [4.10 Regression] Spurious warning: dereferencing type-punned pointer

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61004

--- Comment #9 from Richard Biener  ---
Author: rguenth
Date: Thu Jun  5 12:42:29 2014
New Revision: 211272

URL: http://gcc.gnu.org/viewcvs?rev=211272&root=gcc&view=rev
Log:
2014-06-05  Richard Biener  

PR c++/61004
* typeck.c (cp_build_indirect_ref): Do not emit strict-aliasing
warnings for accessing empty classes.

* g++.dg/diagnostic/pr61004.C: New testcase.

Added:
trunk/gcc/testsuite/g++.dg/diagnostic/pr61004.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/typeck.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/61004] [4.10 Regression] Spurious warning: dereferencing type-punned pointer

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61004

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #8 from Richard Biener  ---
Fixed.

[Bug c++/56961] stack overflow in gimplifier with volatile field

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56961

--- Comment #9 from Richard Biener  ---
(In reply to Richard Biener from comment #8)
> (In reply to Richard Biener from comment #7)
> > I suggest
> > 
> > Index: gcc/cp/cp-gimplify.c
> > ===
> > --- gcc/cp/cp-gimplify.c(revision 211262)
> > +++ gcc/cp/cp-gimplify.c(working copy)
> > @@ -630,18 +630,8 @@ cp_gimplify_expr (tree *expr_p, gimple_s
> >Also drop volatile variables on the RHS to avoid infinite
> >recursion from gimplify_expr trying to load the value.  */
> > if (!TREE_SIDE_EFFECTS (op1)
> > -   || (DECL_P (op1) && TREE_THIS_VOLATILE (op1)))
> > +   || TREE_THIS_VOLATILE (op1))
> >   *expr_p = op0;
> > -   else if (TREE_CODE (op1) == MEM_REF
> > -&& TREE_THIS_VOLATILE (op1))
> > - {
> > -   /* Similarly for volatile MEM_REFs on the RHS.  */
> > -   if (!TREE_SIDE_EFFECTS (TREE_OPERAND (op1, 0)))
> > - *expr_p = op0;
> > -   else
> > - *expr_p = build2 (COMPOUND_EXPR, TREE_TYPE (*expr_p),
> > -   TREE_OPERAND (op1, 0), op0);
> > - }
> > else
> >   *expr_p = build2 (COMPOUND_EXPR, TREE_TYPE (*expr_p),
> > op0, op1);
> 
> This might of course drop arbitrary side-effects of op1 such as
> a volatile load from a.b[foo()] where foo () would be dropped.
> 
> So it isn't really correct.

The following should preserve those.

Index: gcc/cp/cp-gimplify.c
===
--- gcc/cp/cp-gimplify.c(revision 211262)
+++ gcc/cp/cp-gimplify.c(working copy)
@@ -629,18 +629,14 @@ cp_gimplify_expr (tree *expr_p, gimple_s

   Also drop volatile variables on the RHS to avoid infinite
   recursion from gimplify_expr trying to load the value.  */
-   if (!TREE_SIDE_EFFECTS (op1)
-   || (DECL_P (op1) && TREE_THIS_VOLATILE (op1)))
+   if (!TREE_SIDE_EFFECTS (op1))
  *expr_p = op0;
-   else if (TREE_CODE (op1) == MEM_REF
-&& TREE_THIS_VOLATILE (op1))
+   else if (TREE_THIS_VOLATILE (op1)
+&& (REFERENCE_CLASS_P (op1) || DECL_P (op1)))
  {
-   /* Similarly for volatile MEM_REFs on the RHS.  */
-   if (!TREE_SIDE_EFFECTS (TREE_OPERAND (op1, 0)))
- *expr_p = op0;
-   else
- *expr_p = build2 (COMPOUND_EXPR, TREE_TYPE (*expr_p),
-   TREE_OPERAND (op1, 0), op0);
+   *expr_p = build2 (COMPOUND_EXPR, TREE_TYPE (*expr_p),
+ op0, build_fold_addr_expr (op1));
+
  }
else
  *expr_p = build2 (COMPOUND_EXPR, TREE_TYPE (*expr_p),

[Bug c++/56961] stack overflow in gimplifier with volatile field

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56961

--- Comment #8 from Richard Biener  ---
(In reply to Richard Biener from comment #7)
> I suggest
> 
> Index: gcc/cp/cp-gimplify.c
> ===
> --- gcc/cp/cp-gimplify.c(revision 211262)
> +++ gcc/cp/cp-gimplify.c(working copy)
> @@ -630,18 +630,8 @@ cp_gimplify_expr (tree *expr_p, gimple_s
>Also drop volatile variables on the RHS to avoid infinite
>recursion from gimplify_expr trying to load the value.  */
> if (!TREE_SIDE_EFFECTS (op1)
> -   || (DECL_P (op1) && TREE_THIS_VOLATILE (op1)))
> +   || TREE_THIS_VOLATILE (op1))
>   *expr_p = op0;
> -   else if (TREE_CODE (op1) == MEM_REF
> -&& TREE_THIS_VOLATILE (op1))
> - {
> -   /* Similarly for volatile MEM_REFs on the RHS.  */
> -   if (!TREE_SIDE_EFFECTS (TREE_OPERAND (op1, 0)))
> - *expr_p = op0;
> -   else
> - *expr_p = build2 (COMPOUND_EXPR, TREE_TYPE (*expr_p),
> -   TREE_OPERAND (op1, 0), op0);
> - }
> else
>   *expr_p = build2 (COMPOUND_EXPR, TREE_TYPE (*expr_p),
> op0, op1);

This might of course drop arbitrary side-effects of op1 such as
a volatile load from a.b[foo()] where foo () would be dropped.

So it isn't really correct.

[Bug c++/56961] stack overflow in gimplifier with volatile field

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56961

--- Comment #7 from Richard Biener  ---
I suggest

Index: gcc/cp/cp-gimplify.c
===
--- gcc/cp/cp-gimplify.c(revision 211262)
+++ gcc/cp/cp-gimplify.c(working copy)
@@ -630,18 +630,8 @@ cp_gimplify_expr (tree *expr_p, gimple_s
   Also drop volatile variables on the RHS to avoid infinite
   recursion from gimplify_expr trying to load the value.  */
if (!TREE_SIDE_EFFECTS (op1)
-   || (DECL_P (op1) && TREE_THIS_VOLATILE (op1)))
+   || TREE_THIS_VOLATILE (op1))
  *expr_p = op0;
-   else if (TREE_CODE (op1) == MEM_REF
-&& TREE_THIS_VOLATILE (op1))
- {
-   /* Similarly for volatile MEM_REFs on the RHS.  */
-   if (!TREE_SIDE_EFFECTS (TREE_OPERAND (op1, 0)))
- *expr_p = op0;
-   else
- *expr_p = build2 (COMPOUND_EXPR, TREE_TYPE (*expr_p),
-   TREE_OPERAND (op1, 0), op0);
- }
else
  *expr_p = build2 (COMPOUND_EXPR, TREE_TYPE (*expr_p),
op0, op1);

[Bug c++/56961] stack overflow in gimplifier with volatile field

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56961

--- Comment #6 from Richard Biener  ---
The C++ gimplify langhook gimplifies the gimplifier generated

  vol.1 = b.fields

as

  vol.1, b.fields;

so it isn't a manifestation of the issue but a fallout of the attempt to
fix it in the C++ gimplifier...  it drops the assignment but leaves the
load from the volatile in place (as side-effect to be preserved?).  But
then we gimplify that again ... producing vol.2 = b.fields ... and on we go.

[Bug c++/56961] stack overflow in gimplifier with volatile field

[paolo.carlini at oracle dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56961

--- Comment #5 from Paolo Carlini  ---
I think this is another manifestation of the issue discussed in cp-gimplify.c:

/* Remove any copies of empty classes.  We check that the RHS
   has a simple form so that TARGET_EXPRs and non-empty
   CONSTRUCTORs get reduced properly, and we leave the return
   slot optimization alone because it isn't a copy (FIXME so it
   shouldn't be represented as one).

   Also drop volatile variables on the RHS to avoid infinite
   recursion from gimplify_expr trying to load the value.  */

note that it happens only when struct foo is empty...

[Bug fortran/61418] [4.9/4.10 Regression] HDF5 build failure with -flto: libgfortran.spec: attempt to rename spec 'lib' to already defined spec 'liborig'

[rguenther at suse dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61418

--- Comment #13 from rguenther at suse dot de  ---
On Thu, 5 Jun 2014, trippels at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61418
> 
> --- Comment #12 from Markus Trippelsdorf  ---
> (In reply to Richard Biener from comment #11)
> > Patch posted.
> 
> Hmm, I see no patch. Forgot to post?

Oops, posted to fortran@ only.

[Bug fortran/61418] [4.9/4.10 Regression] HDF5 build failure with -flto: libgfortran.spec: attempt to rename spec 'lib' to already defined spec 'liborig'

[trippels at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61418

--- Comment #12 from Markus Trippelsdorf  ---
(In reply to Richard Biener from comment #11)
> Patch posted.

Hmm, I see no patch. Forgot to post?

[Bug c++/61038] g++ -E is unusable with UDL strings

[emsr at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61038

--- Comment #14 from emsr at gcc dot gnu.org ---
Author: emsr
Date: Thu Jun  5 11:17:25 2014
New Revision: 211267

URL: http://gcc.gnu.org/viewcvs?rev=211267&root=gcc&view=rev
Log:
PR c++/61038
I was asked to combine the escape logic for regular chars and strings
with the escape logic for user-defined literals chars and strings.
I just forgot the first time.

I forgot the ChangeLog!

Modified:
trunk/libcpp/ChangeLog

[Bug c++/61038] g++ -E is unusable with UDL strings

[emsr at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61038

--- Comment #13 from emsr at gcc dot gnu.org ---
Author: emsr
Date: Thu Jun  5 11:12:08 2014
New Revision: 211266

URL: http://gcc.gnu.org/viewcvs?rev=211266&root=gcc&view=rev
Log:
PR c++/61038
I was asked to combine the escape logic for regular chars and strings
with the escape logic for user-defined literals chars and strings.
I just forgot the first time.

Modified:
trunk/libcpp/macro.c

[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file

[thomas.preudhomme at arm dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320

--- Comment #30 from Thomas Preud'homme  ---
Can you run the test manually under gdb and tell me what is the value for the
"out" variable in hex format?

[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file

[ro at CeBiTec dot Uni-Bielefeld.DE]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320

--- Comment #29 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #28 from Thomas Preud'homme  ---
> (In reply to r...@cebitec.uni-bielefeld.de from comment #22)
>> > --- Comment #21 from Thomas Preud'homme > > com> ---
>> >
>> > There is a patch for bswap-2.c ready [0]. I'm just waiting for Andreas to
>> > confirm me it works for him on m68k. I'd be interested in knowing if that
>> > solves your issue as well.
>> >
>> > [0] https://gcc.gnu.org/ml/gcc-patches/2014-05/msg02519.html
>> 
>> I'm giving both patches combined a try right now, though SPARC bootstrap
>> will take 7+ hours to complete.
>
> Did it work?

The bootstrap did, but the bswap-2.c execution failures remain, although
I applied both of your patches.

Rainer

[Bug c/61419] Hello World program compilation leads to internal compiler error

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61419

--- Comment #1 from Richard Biener  ---
I suspect that wayland uses a GCC plugin not compatible with GCC 4.8.

[Bug c/61419] Hello World program compilation leads to internal compiler error

[jerriclynsjohn at outlook dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61419

Jerric Lyns John  changed:

   What|Removed |Added

   Severity|blocker |critical

[Bug c/61419] New: Hello World program compilation leads to internal compiler error

[jerriclynsjohn at outlook dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61419

Bug ID: 61419
   Summary: Hello World program compilation leads to internal
compiler error
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: blocker
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jerriclynsjohn at outlook dot com

Created attachment 32893
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=32893&action=edit
Config.log file

Description of problem:
gcc-4.8.2-7.fc19.i686 giving internal compiler error for C codes. Even for a
simple hello world program.

Version-Release number of selected component (if applicable):
gcc-4.8.2-7.fc19.i686

How reproducible:
Everytime i try to compile any C program, even a hello world program

Steps to Reproduce:
1. Create a hello world program
2. Compile
3. ERROR!

Actual results:
cc1: internal compiler error: in make_pass_instance, at passes.c:1032
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


Expected results:
"Hello World!"

Additional info:
My main intention was to build the Wayland source code and found that the gcc
on my machine is not working even after i tried to remove and re-install the
gcc. This is very much reproducible and is hindering my present work. I'm
attaching the Config.log that i got while compiling the Wayland source

[Bug testsuite/61319] The tests c-c++-common/ubsan/float-cast-overflow-(1|2|4).c fail on x86_64-apple-darwin*

[kyukhin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61319

--- Comment #17 from Kirill Yukhin  ---
Author: kyukhin
Date: Thu Jun  5 10:24:22 2014
New Revision: 211263

URL: http://gcc.gnu.org/viewcvs?rev=211263&root=gcc&view=rev
Log:
gcc/
PR tree-optimization/61319
* tree-if-conv.c (is_cond_scalar_reduction): Add missed check that
stmt belongs to loop.

gcc/testsuite/
* gcc.dg/torture/pr61319.c: New test.


Added:
trunk/gcc/testsuite/gcc.dg/torture/pr61391.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-if-conv.c

[Bug fortran/61418] [4.9/4.10 Regression] HDF5 build failure with -flto: libgfortran.spec: attempt to rename spec 'lib' to already defined spec 'liborig'

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61418

Richard Biener  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org

--- Comment #11 from Richard Biener  ---
Patch posted.

[Bug fortran/61418] [4.9/4.10 Regression] HDF5 build failure with -flto: libgfortran.spec: attempt to rename spec 'lib' to already defined spec 'liborig'

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61418

Richard Biener  changed:

   What|Removed |Added

 CC|rguenther at suse dot de   |rguenth at gcc dot 
gnu.org

--- Comment #10 from Richard Biener  ---
But I'm not really familiar with this lang-specific specs additions.

libgomp for example simply does

%{fopenmp|ftree-parallelize-loops=*:%:include(libgomp.spec)%(link_gomp)}\

thus doesn't bother with finding the specs file in the library search path.

Maybe that code copied from libjava is really old, crufty and not necessary at
all and gfortran should simply add a link spec similar to the one above.

[Bug fortran/61418] [4.9/4.10 Regression] HDF5 build failure with -flto: libgfortran.spec: attempt to rename spec 'lib' to already defined spec 'liborig'

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61418

--- Comment #9 from Richard Biener  ---
Index: gfortranspec.c
===
--- gfortranspec.c  (revision 211228)
+++ gfortranspec.c  (working copy)
@@ -449,12 +449,6 @@ For more information about these matters

 #endif

-  /* Read the specs file corresponding to libgfortran.
- If we didn't find the spec file on the -L path, we load it
- via lang_specific_pre_link.  */
-  if (spec_file)
-append_option (OPT_specs_, spec_file, 1);
-
   if (verbose && g77_new_decoded_options != g77_x_decoded_options)
 {
   fprintf (stderr, _("Driving:"));
@@ -473,8 +467,17 @@ For more information about these matters
 int
 lang_specific_pre_link (void)
 {
-  free (spec_file);
-  if (spec_file == NULL && library)
+  if (!library)
+return 0;
+
+  if (spec_file)
+{
+  char cmd = asprintf (&cmd, "%%:include(%s)", spec_file);
+  do_spec (cmd);
+  free (cmd);
+  free (spec_file);
+}
+  else if (library)
 do_spec ("%:include(libgfortran.spec)");

   return 0;

[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file

[thomas.preudhomme at arm dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320

--- Comment #28 from Thomas Preud'homme  ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #22)
> > --- Comment #21 from Thomas Preud'homme  
> > ---
> >
> > There is a patch for bswap-2.c ready [0]. I'm just waiting for Andreas to
> > confirm me it works for him on m68k. I'd be interested in knowing if that
> > solves your issue as well.
> >
> > [0] https://gcc.gnu.org/ml/gcc-patches/2014-05/msg02519.html
> 
> I'm giving both patches combined a try right now, though SPARC bootstrap
> will take 7+ hours to complete.

Did it work?

[Bug fortran/61418] [4.9/4.10 Regression] HDF5 build failure with -flto: libgfortran.spec: attempt to rename spec 'lib' to already defined spec 'liborig'

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61418

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|NEW
  Component|driver  |fortran
   Assignee|rguenth at gcc dot gnu.org |unassigned at gcc dot 
gnu.org

--- Comment #8 from Richard Biener  ---
(In reply to Richard Biener from comment #7)
> gfortranspec.c does
> 
> case OPT_L:
>   if (!spec_file)
> spec_file = find_spec_file (decoded_options[i].arg);
>   break;
> ...
>   /* Read the specs file corresponding to libgfortran.
>  If we didn't find the spec file on the -L path, we load it
>  via lang_specific_pre_link.  */
>   if (spec_file)
> append_option (OPT_specs_, spec_file, 1);
> 
> seemingly copied from Java I guess.  lang_specific_pre_link doesn't add
> -specs.

Oh, and that of course conflicts with manually adding -specs=libgfortran.spec.\
That is, the symtom is the same as if you do

> gfortran-4.8 t.o -shared -fPIC 
> -specs=/usr/lib64/gcc/x86_64-suse-linux/4.8/libgfortran.spec 
gfortran-4.8: fatal error:
/usr/lib64/gcc/x86_64-suse-linux/4.8/libgfortran.spec: attempt to rename spec
‘lib’ to already defined spec ‘liborig’
compilation terminated.

Really a long-standing gfortran and java driver issue.

[Bug c/56724] sub-optimal location in error

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56724

--- Comment #14 from Marek Polacek  ---
Author: mpolacek
Date: Thu Jun  5 09:35:05 2014
New Revision: 211261

URL: http://gcc.gnu.org/viewcvs?rev=211261&root=gcc&view=rev
Log:
PR c/56724
* c-typeck.c (convert_for_assignment): Use expr_loc for ic_argpass.

* gcc.dg/pr56724-3.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr56724-3.c
Modified:
trunk/gcc/c/ChangeLog
trunk/gcc/c/c-typeck.c
trunk/gcc/testsuite/ChangeLog

[Bug driver/61418] [4.9/4.10 Regression] HDF5 build failure with -flto: libgfortran.spec: attempt to rename spec 'lib' to already defined spec 'liborig'

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61418

--- Comment #7 from Richard Biener  ---
gfortranspec.c does

case OPT_L:
  if (!spec_file)
spec_file = find_spec_file (decoded_options[i].arg);
  break;
...
  /* Read the specs file corresponding to libgfortran.
 If we didn't find the spec file on the -L path, we load it
 via lang_specific_pre_link.  */
  if (spec_file)
append_option (OPT_specs_, spec_file, 1);

seemingly copied from Java I guess.  lang_specific_pre_link doesn't add
-specs.

int
lang_specific_pre_link (void)
{
  free (spec_file);
  if (spec_file == NULL && library)
do_spec ("%:include(libgfortran.spec)");

  return 0;
}

I suppose it could simply do

 do_spec ("%:include()");

instead.

[Bug driver/61418] [4.9/4.10 Regression] HDF5 build failure with -flto: libgfortran.spec: attempt to rename spec 'lib' to already defined spec 'liborig'

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61418

Richard Biener  changed:

   What|Removed |Added

  Component|lto |driver

--- Comment #6 from Richard Biener  ---
Though the issue is probably that they get into COLLECT_GCC_OPTIONS at all
(they only get there with that weird -L path).  And they also get there
with 4.8 and without -flto, but only with that weird path.

And that's probably not a regression at all.

Btw, the patch will likely break users purposely using -specs=

[Bug lto/61418] [4.9/4.10 Regression] HDF5 build failure with -flto: libgfortran.spec: attempt to rename spec 'lib' to already defined spec 'liborig'

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61418

Richard Biener  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org

--- Comment #5 from Richard Biener  ---
Index: gcc/lto-wrapper.c
===
--- gcc/lto-wrapper.c   (revision 210514)
+++ gcc/lto-wrapper.c   (working copy)
@@ -719,6 +719,12 @@ run_gcc (unsigned argc, char *argv[])
  /* We generate new intermediate output, drop this arg.  */
  continue;

+   case OPT_specs_:
+ /* Drop spec overrides from the original link command, we'll
+re-introduce them when doing the real link.  Otherwise
+this will confuse the LTO driver, see PR61418.  */
+ continue;
+
case OPT_save_temps:
  debug = 1;
  break;

[Bug ipa/61393] [trans-mem] O3 optimization level constant propagation problem

[jamborm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61393

--- Comment #4 from Martin Jambor  ---
Author: jamborm
Date: Thu Jun  5 09:13:56 2014
New Revision: 211260

URL: http://gcc.gnu.org/viewcvs?rev=211260&root=gcc&view=rev
Log:
2014-06-05  Martin Jambor  

PR ipa/61393
* ipa-cp.c (determine_versionability): Pretend that tm_clones are
not versionable.


Modified:
branches/gcc-4_9-branch/gcc/ChangeLog
branches/gcc-4_9-branch/gcc/ipa-cp.c

[Bug ipa/61393] [trans-mem] O3 optimization level constant propagation problem

[jamborm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61393

--- Comment #3 from Martin Jambor  ---
Author: jamborm
Date: Thu Jun  5 09:12:14 2014
New Revision: 211259

URL: http://gcc.gnu.org/viewcvs?rev=211259&root=gcc&view=rev
Log:
2014-06-05  Martin Jambor  

PR ipa/61393
* ipa-cp.c (determine_versionability): Pretend that tm_clones are
not versionable.


Modified:
branches/gcc-4_8-branch/gcc/ChangeLog
branches/gcc-4_8-branch/gcc/ipa-cp.c