https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65979
Oleg Endo changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66211
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66038
--- Comment #13 from rguenther at suse dot de ---
On Wed, 20 May 2015, jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66038
>
> Jakub Jelinek changed:
>
>What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65961
--- Comment #6 from Richard Biener ---
It might be mitigated for the testcase in question but the underlying problem
didn't get fixed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66211
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66209
Richard Biener changed:
What|Removed |Added
Blocks||64928
--- Comment #1 from Richard Biene
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65979
--- Comment #15 from Oleg Endo ---
(In reply to Oleg Endo from comment #14)
>
> I think the check operands[1] / operands[2] check should go into the
> preparation statement. operands[0] is dying after this peephole, so I guess
> this should wor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65752
--- Comment #25 from Richard Biener ---
(In reply to Chung-Kil Hur from comment #24)
> (In reply to schwab from comment #23)
> > "gil.hur at sf dot snu.ac.kr" writes:
> >
> > > Since "hello" is not printed, I think the if-statement is the same
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66211
--- Comment #3 from Richard Biener ---
So we fold (and did fold before) 1 > 0 ? x : y to (float) x (thus an rvalue).
Then later we call ocp_convert on that requesting a conversion to int which
does
810 converted = fold_if_not_in_templa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60936
Markus Eisenmann changed:
What|Removed |Added
CC||meisenmann.lba@fh-salzburg.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66193
--- Comment #10 from Gerhard Steinmetz
---
Perhaps it's better to make one factor larger.
Maybe the following will help.
$ cat zz1.f90
program p
real :: z(2)
z = 10 + [real :: 1, 2]
print *, z
end
# you may check your pa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62231
--- Comment #16 from Andri Yngvason ---
Sorry, Joseph, I wasn't sure if this issue was fixed or not since the status is
"NEW". I'll report a new issue.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65979
--- Comment #16 from Kazumoto Kojima ---
(In reply to Oleg Endo from comment #15)
Thanks for a quick look!
> However, I think that the emit_move_insn could also be a source of hidden
> problems. For instance, if the captured insn
Also argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66038
--- Comment #14 from Douglas Mencken ---
sizeof(hashval_t) = 4, CHAR_BIT = 8
Just checked it manually. Built with patch subset, genmatch problem is here
again. It isn't related to changes in hash_table_mod1 & hash_table_mod2.
What's left? abort
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66212
Bug ID: 66212
Summary: Exception handling broken on powerpc
Product: gcc
Version: 5.1.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: libgcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66038
--- Comment #15 from Douglas Mencken ---
I'm going to surround calls to gcc_[checking_]assert (in gcc/hash-table.*) with
#ifdef ENABLE_CHECKING {--disable-checking is in my config already}. Let's see
where it lands.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66038
--- Comment #16 from Andreas Schwab ---
> After, <= 32 triggers assert (--> failure).
This is backwards. The failure case is sizeof (hashval_t) * CHAR_BIT > 32.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66213
Bug ID: 66213
Summary: unsigned char value range can be greater than sizeof
unsigned char
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66213
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65752
--- Comment #26 from Chung-Kil Hur ---
Thanks for the detailed explanations.
> The C standard only guarantees that you can convert a pointer to uintptr_t
> and back, it doesn't guarantee that you can convert a modified uintptr_t
> back to
> a po
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65979
--- Comment #17 from John Paul Adrian Glaubitz ---
Thanks a lot guys for working on this! I'm really glad you're doing this :).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66214
Bug ID: 66214
Summary: [6 Regression] ICE verify_type failed with -O0 -g via
gen_type_die_with_usage's dwarf2out.c:20250
Product: gcc
Version: 6.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66214
Tobias Burnus changed:
What|Removed |Added
Known to work||5.1.0
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65752
--- Comment #27 from Chung-Kil Hur ---
(In reply to Chung-Kil Hur from comment #26)
> Thanks for the detailed explanations.
>
> > The C standard only guarantees that you can convert a pointer to uintptr_t
> > and back, it doesn't guarantee that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66212
--- Comment #1 from Andri Yngvason ---
I've now compiled the same toolchain for i686 and I have the same issue there,
so I assume that I'm doing something wrong. It's hard to pin down what I'm
doing wrong though. Everything seems to be linked cor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66213
--- Comment #2 from zh__ ---
Yep, sorry. My bad.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66038
--- Comment #17 from rguenther at suse dot de ---
On Wed, 20 May 2015, dougmencken at gmail dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66038
>
> --- Comment #14 from Douglas Mencken ---
> sizeof(hashval_t) = 4, CHAR_BIT = 8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60936
--- Comment #13 from Jonathan Wakely ---
Created attachment 35575
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35575&action=edit
Lightweight __throw_out_of_range_fmt for non-verbose builds
This is what I had in mind.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65752
--- Comment #28 from rguenther at suse dot de ---
On Wed, 20 May 2015, gil.hur at sf dot snu.ac.kr wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65752
>
> --- Comment #27 from Chung-Kil Hur ---
> (In reply to Chung-Kil Hur from comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38265
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66215
Bug ID: 66215
Summary: [4.8/4.9/5/6 Regression] Wrong after label NOP
emission for -mhotpatch
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66215
--- Comment #1 from Martin Liška ---
Following testcase is wrongly compiled event with -O2 optimization level.
$ cat o2-test-case.c
static int a;
int t(int tt)
{
switch (tt)
{
case 1: return a;
}
return 0;
}
$ ./xgcc -B. -mhotpatc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66215
--- Comment #2 from Martin Liška ---
(In reply to Martin Liška from comment #1)
> Following testcase is wrongly compiled event with -O2 optimization level.
>
> $ cat o2-test-case.c
> static int a;
>
> int t(int tt)
> {
> switch (tt)
> {
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66216
Bug ID: 66216
Summary: Defaulted Operators and contructors not working with
aligned attribute
Product: gcc
Version: 5.1.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66215
Andreas Krebbel changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29256
--- Comment #53 from Bill Schmidt ---
I'm not a fan of a tree-level unroller. It's impossible to make good decisions
about unroll factors that early. But your second approach sounds quite
promising to me.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66217
Bug ID: 66217
Summary: PowerPC rotate/shift/mask instructions not optimal
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52144
chrbr at gcc dot gnu.org changed:
What|Removed |Added
Blocks||59884
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59884
chrbr at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66216
Jonathan Wakely changed:
What|Removed |Added
Keywords||ice-on-valid-code,
|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66211
Richard Biener changed:
What|Removed |Added
CC||jason at redhat dot com
Vers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52742
Jonathan Wakely changed:
What|Removed |Added
Known to work||4.8.1
Known to fail|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66218
Bug ID: 66218
Summary: [c++-concepts] "inconsistent deduction for ‘auto’"
with a partial-concept-id in a deduction constraint
Product: gcc
Version: 6.0
Status: UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66219
Bug ID: 66219
Summary: The gcc generated section start/stop pointers become
undefined when option -flto is used
Product: gcc
Version: 4.8.4
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66211
--- Comment #5 from Jakub Jelinek ---
Perhaps just guard this particular match.pd pattern with GIMPLE guard for now
(until the delayed C++ folding is committed)?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52144
chrbr at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66214
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62216
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66220
Bug ID: 66220
Summary: -Wmisleading-indentation false/inconsistent warning
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65837
chrbr at gcc dot gnu.org changed:
What|Removed |Added
Depends on||52144
--- Comment #29 from chr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66220
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65835
tprince at computer dot org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56926
--- Comment #11 from asmwarrior ---
Today, I did the same test as in comment 6 with a more recent gcc
5.1(http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/dongsheng-daily/5.x/gcc-5-win32_5.1.1-2015
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66215
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66146
--- Comment #8 from Jonathan Wakely ---
NetBSD 5 and DragonFly BSD fail the test too. I'm going to make libstdc++
assume pthread_once is not exception-aware unless specifically told otherwise
for targets where we know it works, such as x86-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66221
Bug ID: 66221
Summary: [CHKP, 6 regression] lto1: error: type variant has
different TYPE_ARG_TYPES
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: norma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66180
--- Comment #8 from Markus Trippelsdorf ---
If I change foo1.cpp from comment5 to:
#include
namespace first{
class A {
int i;
};
}
using namespace first;
class G {
std::unique_ptr foo() const;
};
std::unique_ptr G::foo() const { return std:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66215
--- Comment #4 from Andreas Krebbel ---
(In reply to Jakub Jelinek from comment #3)
> IMHO the nops should go immediately before the first real instruction in the
> function. The point of not emitting it earlier is so that the nops are
> already
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66078
--- Comment #2 from Jason Merrill ---
Ping? I think this is now the only thing preventing me from throwing the
switch to default C++14.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66146
Rich Felker changed:
What|Removed |Added
CC||bugdal at aerifal dot cx
--- Comment #9 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66146
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66146
--- Comment #11 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #4)
> Thanks, Martin. So maybe something like this:
>
> --- a/libstdc++-v3/include/std/mutex
> +++ b/libstdc++-v3/include/std/mutex
> @@ -726,7 +738,17 @@ _GLIBCX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64928
Nick Wellnhofer changed:
What|Removed |Added
CC||wellnhofer at aevum dot de
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66209
Nick Wellnhofer changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66146
--- Comment #12 from Rich Felker ---
Jakub, this is not the place to discuss the pros and cons of musl or other
particular implementations; libstdc++ needs to support many which do not have
the glibc-specific semantics you want. In particular the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64928
Bug 64928 depends on bug 66209, which changed state.
Bug 66209 Summary: Out of memory when compiling with --coverage and
optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66209
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65548
--- Comment #38 from vehre at gcc dot gnu.org ---
Author: vehre
Date: Wed May 20 14:56:47 2015
New Revision: 223445
URL: https://gcc.gnu.org/viewcvs?rev=223445&root=gcc&view=rev
Log:
gcc/fortran/ChangeLog:
2015-05-19 Andre Vehreschild
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66217
David Edelsohn changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39478
--- Comment #3 from Daniel Frey ---
Just a reminder that the error message is basically still the same with GCC 4.9
and does not help to understand the cause of the error. Especially real-world
cases are therefore extremely hard to understand!
I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66222
Bug ID: 66222
Summary: gcc error: invalid use of '__builtin_va_arg_pack ()'
at -O2 and up & pass at noopt
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66222
--- Comment #1 from Tong Liu ---
//av.h
/*av.h
*
*Copyright (c) 1991-1999, Larry Wall
*
*You may distribute under the terms of either the GNU General Public
*License or the Artistic License, as specified in the README file.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66038
--- Comment #18 from Douglas Mencken ---
> try without --disable-checking
Okay, doing it now.
Meanwhile. Why ``sizeof (hashval_t) * CHAR_BIT'' cannot be checked at configure
time, not at buildtime nor runtime?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66223
Bug ID: 66223
Summary: Diagnostic of pure virtual function call broken,
including __cxa_pure_virtual
Product: gcc
Version: 5.1.0
Status: UNCONFIRMED
Severity: n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66038
--- Comment #19 from Jakub Jelinek ---
(In reply to Douglas Mencken from comment #18)
> > try without --disable-checking
> Okay, doing it now.
>
> Meanwhile. Why ``sizeof (hashval_t) * CHAR_BIT'' cannot be checked at
> configure time, not at bui
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66222
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66220
--- Comment #2 from David Malcolm ---
Thanks.
I ran into a variant of this whilst testing -Wmisleading-indentation on the
linux kernel, where a preprocessor macro conditionalizes the "if/else"; here's
the test case I reduced it to:
/* This vari
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39478
--- Comment #4 from Manuel López-Ibáñez ---
(In reply to Daniel Frey from comment #3)
> instead. I'd still like to see GCC to hint at the loop when trying to
> complete types where the completion of A requires a completed B and the
> completion o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66223
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39478
--- Comment #5 from Daniel Frey ---
I don't know if it is possible for GCC to know, but it feels like it should
know. If one type needs to instantiate another type, this goes on until either
everything worked or GCC stops to instantiate a sub-typ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66220
David Malcolm changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |dmalcolm at gcc dot
gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66224
Bug ID: 66224
Summary: PowerPC _GLIBCXX_READ_MEM_BARRIER too weak
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66224
David Edelsohn changed:
What|Removed |Added
Target||powerpc*-*-*
Status|UNCONFI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66145
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66078
--- Comment #3 from Jonathan Wakely ---
Author: redi
Date: Wed May 20 17:11:03 2015
New Revision: 223449
URL: https://gcc.gnu.org/viewcvs?rev=223449&root=gcc&view=rev
Log:
PR libstdc++/66078
* include/bits/stl_iterator.h (__make_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66078
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65730
--- Comment #2 from jcmvbkbc at gcc dot gnu.org ---
Author: jcmvbkbc
Date: Wed May 20 18:56:14 2015
New Revision: 223452
URL: https://gcc.gnu.org/viewcvs?rev=223452&root=gcc&view=rev
Log:
Fix PR target/65730
2015-05-20 Max Filippov
gcc/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65730
jcmvbkbc at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66038
--- Comment #20 from Douglas Mencken ---
I'm lost. “Vanilla” 5.1.0 configured without --disable-checking went thru
stage2 w/o any issue...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66225
Bug ID: 66225
Summary: libgcc/config/rs6000/morecore.S will not build on
systems with an older assembler
Product: gcc
Version: 5.1.1
Status: UNCONFIRMED
Severit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66225
Michael Meissner changed:
What|Removed |Added
Priority|P3 |P2
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66225
--- Comment #1 from Michael Meissner ---
Created attachment 35580
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35580&action=edit
Proposed patch to fix the problem
I just wrote this patch, and I'm starting a bootstrap build with it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66216
--- Comment #2 from James Almer ---
(In reply to Jonathan Wakely from comment #1)
> And now it gives an ICE on trunk, so it's regressed from rejects-valid to
> ice-on-valid-code:
>
> a.cc:1:7: internal compiler error: canonical types differ for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66226
Bug ID: 66226
Summary: Incorrect code generation ppc, later assignment causes
calling argument corruption
Product: gcc
Version: 4.9.3
Status: UNCONFIRMED
Severi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66227
Bug ID: 66227
Summary: [OOP] EXTENDS_TYPE_OF n returns wrong result for
polymorphic variable allocated to extended type
Product: gcc
Version: 5.1.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66212
--- Comment #2 from Jim Wilson ---
libgcc should be built with debug info by default, but the one in /lib is
probably stripped. Try setting LD_LIBRARY_PATH to point at the gcc-5.1
libraries that you built, instead of using the default ones provi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66225
--- Comment #2 from Michael Meissner ---
The proposed patch allows the big endian powerpc build to build and install.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65979
--- Comment #18 from Oleg Endo ---
(In reply to Kazumoto Kojima from comment #16)
>
> Also arguments of emit_move_insn must have the same integer modes.
>
> if (reg_overlap_mentioned_p (operands[1], operands[2]))
> std::swap (operands[0],
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66226
Andrew Pinski changed:
What|Removed |Added
Component|c |target
--- Comment #1 from Andrew Pinski
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66228
Bug ID: 66228
Summary: Compiling simple program with -flto -O1 causes mad
behaviour
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: normal
P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66229
Bug ID: 66229
Summary: LTO fails with -fauto-profile on mcf
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
1 - 100 of 118 matches
Mail list logo
