https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61386
--- Comment #2 from Akim Demaille ---
Well, I never hacked in GCC. I can try, time permitting...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63461
--- Comment #6 from Akos Kiss ---
Thanks for the feedback!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63429
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63465
Bug ID: 63465
Summary: Demangler crash (GDB PR 17455)
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61386
--- Comment #3 from Manuel López-Ibáñez ---
(In reply to Akim Demaille from comment #2)
> Well, I never hacked in GCC. I can try, time permitting...
Never too late to try. This one should be easy if you know how to use a
debugger. Just add a br
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54303
Clément Péron changed:
What|Removed |Added
CC||peron.clem at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63347
--- Comment #4 from Jonathan Larmour ---
I have just double-checked, and my gcc 4.8.3 definitely doesn't generate the
'tstl', but it looks like you're bang on right about how gcc was configured: I
configured it with --with-arch=cf. Sorry I should
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63464
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63464
--- Comment #2 from rguenther at suse dot de ---
On Mon, 6 Oct 2014, jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63464
>
> Jakub Jelinek changed:
>
>What|Removed |Added
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63380
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63381
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63440
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63439
Richard Biener changed:
What|Removed |Added
Target||armv7-a
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63434
--- Comment #1 from Richard Biener ---
Patches should be sent to gcc-patches@
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56846
--- Comment #9 from Yvan Roux ---
Author: yroux
Date: Mon Oct 6 12:25:14 2014
New Revision: 215929
URL: https://gcc.gnu.org/viewcvs?rev=215929&root=gcc&view=rev
Log:
/libstdc++-v3/
2014-10-06 Yvan Roux
Backport from trunk r215101.
2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63209
--- Comment #3 from Yvan Roux ---
Author: yroux
Date: Mon Oct 6 12:40:10 2014
New Revision: 215932
URL: https://gcc.gnu.org/viewcvs?rev=215932&root=gcc&view=rev
Log:
/gcc/
2014-10-06 Yvan Roux
Backport from trunk r215136.
2014-09-10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63439
--- Comment #2 from Bernd Edlinger ---
Created attachment 33652
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33652&action=edit
vect-33.c.116t.vect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63352
--- Comment #12 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #11 from Dominique d'Humieres ---
> Comment 7 confirms my guess that there is a rounding problem on
> i386-sun-solaris2.11 (the test is three-year old and succeeds on all
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62265
--- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #3 from Teresa Johnson ---
> I believe this was fixed by the following commit:
>
> r214848 | uros | 2014-09-03 00:58:17 -0700 (Wed, 03 Sep 2014) | 4 lines
> Changed paths:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63440
--- Comment #2 from R. Diez ---
Yes, I would enable -fmerge-constants with -Og.
I would do it even for -O0. Merging constants should be safe, and it saves
precious program space when generating debug builds for small embedded targets.
Besides,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61759
--- Comment #4 from Douglas Mencken ---
In 4.9.1, it's not :2792 but :2793 ---
vcl/osx/a11yselectionwrapper.cxx:31:61: internal compiler error: in
objc_eh_runtime_type, at objc/objc-next-runtime-abi-01.c:2793
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62022
Bug 62022 depends on bug 62023, which changed state.
Bug 62023 Summary: [5 regression] 30_threads/condition_variable_any/50862.cc
FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62023
What|Removed |Added
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62023
Rainer Orth changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62022
Rainer Orth changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63409
Rainer Orth changed:
What|Removed |Added
Target|x86_64-*-* |x86_64-*-*,
|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63459
--- Comment #4 from Richard Biener ---
I think a method call always has this != NULL so you'd infer this != NULL
after the call with a ASSERT_EXPR.
With the pattern stuff you can't really write "any call with some nonnull
attribute on it" so you
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63450
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63454
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63448
Richard Biener changed:
What|Removed |Added
Keywords||ra
Target|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60406
--- Comment #14 from Dominik Vogt ---
> I'm not really happy with Dominik's patch because 1) it doesn't work when
> configuring with --enable-sjlj-exceptions;
Why is that important?
> 2) the current code almost always works, even on S/390, but
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60406
--- Comment #15 from boger at us dot ibm.com ---
The testcase recover.go continues to fail on both ppc64 LE & BE with the new
patch https://codereview.appspot.com/153950043.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59987
--- Comment #2 from Jonathan Wakely ---
Author: redi
Date: Mon Oct 6 15:55:53 2014
New Revision: 215952
URL: https://gcc.gnu.org/viewcvs?rev=215952&root=gcc&view=rev
Log:
2014-10-06 Rüdiger Sonderfeld
Jonathan Wakely
PR libstd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59987
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55250
--- Comment #3 from paolo at gcc dot gnu.org ---
Author: paolo
Date: Mon Oct 6 16:13:41 2014
New Revision: 215954
URL: https://gcc.gnu.org/viewcvs?rev=215954&root=gcc&view=rev
Log:
/cp
2014-10-06 Paolo Carlini
PR c++/55250
* semanti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55250
Paolo Carlini changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55004
Bug 55004 depends on bug 55250, which changed state.
Bug 55250 Summary: [C++0x] enum declarations within constexpr function are
allowed, constexpr declarations are not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55250
What|Remove
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63409
--- Comment #7 from Martin Liška ---
Yeah, sorry for wrong dg argument. There's new version that should work
correctly. If not regression will be seen, I will commit the patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63409
--- Comment #8 from Martin Liška ---
Created attachment 33653
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33653&action=edit
Fix patch2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60406
--- Comment #16 from Ian Lance Taylor ---
>> I'm not really happy with Dominik's patch because 1) it doesn't work when
>> configuring with --enable-sjlj-exceptions;
>
> Why is that important?
It's not very important but it's still a point to con
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59717
Marek Polacek changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63466
Bug ID: 63466
Summary: sstream is very slow
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63464
--- Comment #3 from Jakub Jelinek ---
Created attachment 33654
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33654&action=edit
gcc5-pr63464.patch
Untested patch to avoid the subtraction of info.range_min from index.
Might not always be a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63467
Bug ID: 63467
Summary: should have asm statement that does not prevent
vectorization
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63467
--- Comment #1 from Andrew Pinski ---
Try asm volatile ("":::); instead. Asms without any ::: are considered
clobbering memory.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63467
--- Comment #2 from Andi Kleen ---
It's the same with asm("" :::);
At least the vectorizer bombs out on any asm.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63418
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63420
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63467
--- Comment #3 from Andrew Pinski ---
Ok doing this works:
asm("":"+r"(t)::);
But it looks like it should not vectorize due to the number of iterations
happening for that asm has changed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63420
--- Comment #2 from Jakub Jelinek ---
Can you explain where in the documentation you find it though?
I can't find any wording like that.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63467
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63467
--- Comment #6 from Andi Kleen ---
For the marker case it's enough if it just stays in the same position in the
basic block and does get duplicated if the BB gets too.
That's somewhat special semantics, that is why I think it would need some way
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63467
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63466
--- Comment #1 from Marc Glisse ---
To be a bit less unfair, you could pull the declarations of the 3 variables out
of the loop. Even if optimizations are possible, I doubt we can go anywhere
near the C perf...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63466
--- Comment #2 from Andi Kleen ---
Looking at the profile there's plenty of room for optimization. e.g. not using
getc/ungetc, but directly accessing the buffer, or maybe even some kind of
template specialization.
With the variables pulled out i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63448
Jakub Jelinek changed:
What|Removed |Added
Priority|P3 |P1
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63435
--- Comment #5 from Jan Hubicka ---
There are three problems in 4.9 and earlier
- the aliases are produced incorrectly because AIX's as alias keyword does
not do what is expected
(it does kind of syntactic replacement combined with somethin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61886
--- Comment #11 from Jan Hubicka ---
Hi,
this patch implements the lowring. Each call with warn attribute triggers code
in cgraphunit that inserts call to bulitin_warning/error that is output at
expansion time.
Do we have way to define bulitin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61886
--- Comment #12 from Jakub Jelinek ---
On Mon, Oct 06, 2014 at 10:22:21PM +0200, Jan Hubicka wrote:
> this patch implements the lowring. Each call with warn attribute triggers
> code
> in cgraphunit that inserts call to bulitin_warning/error th
mudflap --disable-libssp --enable-checking
Thread model: posix
gcc version 5.0.0 20141006 (experimental) [trunk revision 215958] (GCC)
$ ./xgcc -B. ~/ice.i -O3 -mfpu=neon -march=armv7-a -mfloat-abi=softfp
/home/ryan/ice.i: In function 'bar':
/home/ryan/ice.i:52:1: internal c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36312
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=61886
--- Comment #13 from Jan Hubicka ---
Hi,
I am testing this variant of the patch.
For gcc-4.9 branch it may make sense to enable the new patch for LTO only.
Index: internal-fn.c
===
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61886
--- Comment #14 from Jakub Jelinek ---
On Mon, Oct 06, 2014 at 11:55:23PM +0200, Jan Hubicka wrote:
> Hi,
> I am testing this variant of the patch.
> For gcc-4.9 branch it may make sense to enable the new patch for LTO only.
Not printing the inl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63347
Mikael Pettersson changed:
What|Removed |Added
CC||mikpelinux at gmail dot com
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61886
--- Comment #15 from Jan Hubicka ---
> On Mon, Oct 06, 2014 at 11:55:23PM +0200, Jan Hubicka wrote:
> > Hi,
> > I am testing this variant of the patch.
> > For gcc-4.9 branch it may make sense to enable the new patch for LTO only.
>
> Not printi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63469
Bug ID: 63469
Summary: Automatic reallocation of allocatable scalar length
even when substring implicitly specified
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61886
--- Comment #16 from Jakub Jelinek ---
On Tue, Oct 07, 2014 at 12:18:24AM +0200, Jan Hubicka wrote:
> > On Mon, Oct 06, 2014 at 11:55:23PM +0200, Jan Hubicka wrote:
> > > Hi,
> > > I am testing this variant of the patch.
> > > For gcc-4.9 branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61886
--- Comment #17 from Jan Hubicka ---
>
> %K in the format string, assuming the call has locus with the right block,
> should do that. At least with -g, without -g or with LTO it will be less
> accurate.
Yep, for that I need a tree to pass in.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49766
Manuel López-Ibáñez changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53934
--- Comment #3 from Manuel López-Ibáñez ---
*** Bug 49766 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #53 from Kazumoto Kojima ---
(In reply to Oleg Endo from comment #52)
> Created attachment 33632 [details]
> Reduced case of error: in assign_by_spills, at lra-assigns.c:1335 with -m4
> -ml -O2
.ira dump of the test case has the line
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #54 from Kazumoto Kojima ---
Created attachment 33657
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33657&action=edit
A possible workaround
The patch is trying to fix the result of decompose_mem_address
so as not to assign IND
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63454
--- Comment #3 from Ai Azuma ---
(In reply to Daniel Krügler from comment #1)
> I don't see any ICE for gcc 5.0.0 20141004 (experimental). Could you retry
> that one?
I am still seeing the ICE with 5.0.0 20141005 (experimental).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63432
--- Comment #17 from Teresa Johnson ---
I'm going to finish testing my patch, which passes regular
x86_64-unknown-linux-gnu bootstrap + regression tests. I am still
trying to get the lto profiledbootstrap to work. I found some
workarounds for the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61886
--- Comment #18 from Jan Hubicka ---
Hi,
actually I can just add the location to the first argument to avoid the need
to build extra tree...
Somewhat ugly, but seems to work.
Index: internal-fn.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63409
--- Comment #9 from Uroš Bizjak ---
(In reply to Martin Liška from comment #8)
> Created attachment 33653 [details]
> Fix patch2
Yes, this patch works for me.
75 matches
Mail list logo
