https://gcc.gnu.org/bugzilla/show_bug.cgi?id=323
--- Comment #198 from Manuel López-Ibáñez ---
(In reply to Vincent Lefèvre from comment #197)
> (In reply to Manuel López-Ibáñez from comment #196)
> > Also, the official FAQ for this (https://gcc.gnu.org/bugs/#nonbugs_general)
> > is seriously lac
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64447
H.J. Lu changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=323
--- Comment #197 from Vincent Lefèvre ---
(In reply to Manuel López-Ibáñez from comment #196)
> Also, the official FAQ for this (https://gcc.gnu.org/bugs/#nonbugs_general)
> is seriously lacking info and outdated. From now on, I'll point people to:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63681
--- Comment #6 from Yaakov Selkowitz ---
(In reply to Mikael Pettersson from comment #5)
> The ICE on bfin-elf started for 4.9 with r204985, and stopped for 5.0 with
> r210683. Backporting r210683 to current 4.9 branch is easy and fixes the
> IC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64447
Markus Trippelsdorf changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=6
Markus Trippelsdorf changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64384
--- Comment #4 from mity ---
Daniel, COM interface should be, by definition, language agnostic. COM can be
called from C++ as well as from C, and also COM object may be implemented in
C++ as well as C. This implies that (at least for stdcall, as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64388
--- Comment #3 from dave.anglin at bell dot net ---
Hi H.J.,
On 2014-12-30, at 3:13 PM, hjl.tools at gmail dot com wrote:
> Can you add such a hook?
I'm sorry but realistically I don't have the spare time to work on this bug.
Dave
--
John Davi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64451
Bug ID: 64451
Summary: tic6x-elf: ICE in extract_insn, at recog.c:2202
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64384
daniel.c.klauer at web dot de changed:
What|Removed |Added
CC||daniel.c.klauer at web dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64450
--- Comment #2 from Andrew Pinski ---
(In reply to Marc Glisse from comment #1)
> See also PR61734, Eric already tried in May.
Maybe it is easier to handle now with simplify-and-match.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64450
--- Comment #1 from Marc Glisse ---
See also PR61734, Eric already tried in May.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64416
--- Comment #1 from joseph at codesourcery dot com ---
The Procedure Call Standard for the ARM Architecture does not include a
128-bit floating-point type, so if you want to support such a type in GCC
for ARM you should first work with arm.e...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64450
Ville Voutilainen changed:
What|Removed |Added
Keywords||missed-optimization
Stat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64450
Bug ID: 64450
Summary: Optimize 0>=p-q to q>=p for char*p,*q;
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64447
--- Comment #4 from Jan Hubicka ---
Hi,
the problem is that estimate_function_body_sizes frees ipa_free_all_node_params
when called late via add_new_function.
the following patch should fix it.
Honza
Index: ipa-inline-analysis.c
===
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64447
John David Anglin changed:
What|Removed |Added
CC||danglin at gcc dot gnu.org
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64388
H.J. Lu changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64388
--- Comment #1 from dave.anglin at bell dot net ---
On 2014-12-23, at 12:31 PM, hjl.tools at gmail dot com wrote:
> On Linux/x86-64, r219037 caused
>
> FAIL: gcc.dg/pr44194-1.c scan-rtl-dump dse1 "global deletions = (2|3)"
> FAIL: gcc.dg/pr44194
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64447
--- Comment #2 from David Edelsohn ---
Analyzing compilation unit
Performing interprocedural optimizations
<*free_lang_data>
/home/dje/src/src/libstdc++-v3/src/c++98/bitmap_allocator.cc: At global scope:
/home/dje/src/src/libstdc++-v
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64449
Bug ID: 64449
Summary: /usr/ccs/bin/ld: Unsatisfied symbols:
std::basic_string,
std::allocator >::copy(wchar_t*, unsigned
long, unsigned long)
Product:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64438
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=323
Manuel López-Ibáñez changed:
What|Removed |Added
URL||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49263
--- Comment #24 from Oleg Endo ---
Author: olegendo
Date: Tue Dec 30 19:11:42 2014
New Revision: 219113
URL: https://gcc.gnu.org/viewcvs?rev=219113&root=gcc&view=rev
Log:
gcc/testsuite/
PR target/49263
* gcc.target/sh/sh.exp (check_effec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64442
Manuel López-Ibáñez changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=323
Manuel López-Ibáñez changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49263
--- Comment #23 from Oleg Endo ---
Author: olegendo
Date: Tue Dec 30 18:44:27 2014
New Revision: 219111
URL: https://gcc.gnu.org/viewcvs?rev=219111&root=gcc&view=rev
Log:
gcc/testsuite/
PR target/49263
* gcc.target/sh/pr49263-1.c: New.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63596
--- Comment #3 from Andrew Pinski ---
(In reply to Jiong Wang from comment #2)
> we are also lack of initialization for va_list_gpr_counter_field and
> va_list_vpr_counter_field, thus currently the whole tree-stdarg optimization
> doesn't work fo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64448
Bug ID: 64448
Summary: New middle-end pattern breaks vector BIF folding on
AArch64.
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Pri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53987
--- Comment #8 from Oleg Endo ---
Author: olegendo
Date: Tue Dec 30 17:26:18 2014
New Revision: 219110
URL: https://gcc.gnu.org/viewcvs?rev=219110&root=gcc&view=rev
Log:
gcc/testsuite/
PR target/53987
* gcc.target/sh/pr53987-1.c: New.
A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64443
--- Comment #3 from Tejas Belagod ---
(In reply to Andrew Pinski from comment #1)
> >This commit seems to be breaking libstdc++-v3 runs on AArch64.
>
> Is this under Linux or with newlib?
newlib. When run on a fast-model(simulator) they fail by
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64438
--- Comment #2 from Tejas Belagod ---
(In reply to Jonathan Wakely from comment #1)
> That's strange, it should only affect targets that define
> _GLIBCXX_HAVE_BROKEN_VSWPRINTF i.e. only mingw
>
> What are the full errors in the libstdc++-v3/tes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63596
--- Comment #2 from Jiong Wang ---
we are also lack of initialization for va_list_gpr_counter_field and
va_list_vpr_counter_field, thus currently the whole tree-stdarg optimization
doesn't work for AArch64, and lots of other targets, like arm, sp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64447
David Edelsohn changed:
What|Removed |Added
Priority|P3 |P1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64447
Bug ID: 64447
Summary: [5 Regression] FAIL: gcc.dg/vect/slp-9.c
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ipa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64442
Colin Pitrat changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64443
--- Comment #2 from Jonathan Wakely ---
Probably the same issue as PR 64368 so it's probably a problem with the non-gnu
clocale model.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64412
--- Comment #17 from Uroš Bizjak ---
(In reply to H.J. Lu from comment #16)
> > > This is generated in the backend:
> >
> > Yes, but the question is, why somehow similar testcase legitimizes the
> > address correctly with -fpic, while the origin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64438
--- Comment #1 from Jonathan Wakely ---
That's strange, it should only affect targets that define
_GLIBCXX_HAVE_BROKEN_VSWPRINTF i.e. only mingw
What are the full errors in the libstdc++-v3/testsuite/libstdc++.log file?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64368
--- Comment #12 from Jonathan Wakely ---
Apologies, I should read emails more carefully when I'm ill, or not respond at
all!
I plan to spend time on this later this week. HNY all!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64412
--- Comment #16 from H.J. Lu ---
(In reply to Uroš Bizjak from comment #15)
> (In reply to H.J. Lu from comment #14)
>
> > This is generated in the backend:
>
> Yes, but the question is, why somehow similar testcase legitimizes the
> address co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64446
--- Comment #1 from petschy at gmail dot com ---
One subtlety:
template
struct Base3
{
};
struct Foo3 : Base3
{
};
In this case complaining about missing template params is probably
inappropriate, since Base3<> is perfectly valid.
So on second
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64442
--- Comment #3 from Mikael Pettersson ---
See PR323 and https://gcc.gnu.org/bugs/#known
You could experiment with -ffloat-store, -mpc64, or -msse2 (if your CPU
supports SSE2, which it should if it isn't ancient).
Severity: minor
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: petschy at gmail dot com
When compiling the under code, g++ gives a misleading error message:
$ g++-5.0.0 -Wall 20141230-templ_base.cpp
20141230-templ_base.cpp:7:1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64445
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64445
Bug ID: 64445
Summary: virtual functions polymorphism
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64412
--- Comment #15 from Uroš Bizjak ---
(In reply to H.J. Lu from comment #14)
> This is generated in the backend:
Yes, but the question is, why somehow similar testcase legitimizes the address
correctly with -fpic, while the original testcase doe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=6
Markus Trippelsdorf changed:
What|Removed |Added
Target Milestone|--- |5.0
--- Comment #1 from Markus Tri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=6
Bug ID: 6
Summary: [5 Regression] ICE: in inline_merge_summary, at
ipa-inline-analysis.c:3611
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64443
--- Comment #1 from Andrew Pinski ---
>This commit seems to be breaking libstdc++-v3 runs on AArch64.
Is this under Linux or with newlib?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64412
--- Comment #14 from H.J. Lu ---
(In reply to Uroš Bizjak from comment #13)
> (In reply to H.J. Lu from comment #12)
> > Created attachment 34361 [details]
> > A new patch
> >
> > Please try the new patch.
>
> No, this approach is wrong. ix86_f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64442
--- Comment #2 from Colin Pitrat ---
Yes I'm building on i686.
But I thought -O1 and -O2 were safe optimization that weren't supposed to
change the behaviour.
Moreover, I'm surprised that providing the list of -f flags -O1 is supposed to
enable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64412
Uroš Bizjak changed:
What|Removed |Added
Component|target |middle-end
--- Comment #13 from Uroš Bizja
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64443
Bug ID: 64443
Summary: New std::string implementation breaks tests on
AArch64.
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50156
Manuel López-Ibáñez changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50156
Bug 50156 depends on bug 50139, which changed state.
Bug 50139 Summary: in-tree GMP/PPL/CLooG is misconfigured
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50139
What|Removed |Added
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50139
Manuel López-Ibáñez changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64442
--- Comment #1 from Mikael Pettersson ---
Are you compiling on 32-bit x86? I can reproduce on m68k, but not on x86_64
(even with -m32) or on ARMv5. I suspect you're seeing the effects of excess
precision of the x87 FPU (much like the m68k FPU).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64440
Manuel López-Ibáñez changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64442
Bug ID: 64442
Summary: -O1 modify output of a simple computation with
rounding
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: normal
Priori
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64434
--- Comment #11 from Yuri Rumyantsev ---
Created attachment 34363
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34363&action=edit
patch to fix issue
This patch fixed almost all issues related to operand canonicalization.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64432
--- Comment #9 from Joost VandeVondele
---
reading the standard, indeed it seems like count_rate can be real as well...
same rules here *4 -> _4 *8 -> _8.
As a side remark the following generates a slightly outdated error:
> cat test.f90
COMPL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64432
Joost VandeVondele changed:
What|Removed |Added
CC||Joost.VandeVondele at mat dot
ethz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64441
Bug ID: 64441
Summary: A match_results returns an incorrect sub_match if the
sub_match::matched is false
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity:
64 matches
Mail list logo
