http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57275
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57278
Steven Bosscher changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56833
Steven Bosscher changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55237
Steven Bosscher changed:
What|Removed |Added
URL|http://gcc.gnu.org/viewcvs/ |http://gcc.gnu.org/viewcvs/
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56976
--- Comment #2 from Akim Demaille ---
Maybe I don't know, even after having read several times the section you
pointed me to. In particular I see nothing there which could explain why using
foo() instead of foo{} would give different results.
FW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57283
Bug ID: 57283
Summary: missing typedefs in specialized std::mem_fn for member
variables
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57276
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57281
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57281
Richard Biener changed:
What|Removed |Added
Keywords||wrong-code
Target|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57260
--- Comment #12 from Lee Duhem ---
(In reply to rsand...@gcc.gnu.org from comment #11)
> Created attachment 30116 [details]
> Candidate patch
>
> Here's the patch I'm testing. Lee, could you check that it
> fixes the original libglx problem?
Th
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57283
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57281
Richard Biener changed:
What|Removed |Added
Component|target |rtl-optimization
Summary|[4.9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57281
--- Comment #4 from Steven Bosscher ---
(In reply to Richard Biener from comment #2)
> messes up the IV value - the store of the upper half of the long long
> extended b into *pretmp_18 invalidates b (%eax) but that value is then
> still used for
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57284
Bug ID: 57284
Summary: ICE with "find_array_spec: unused as (1)" in
conjunction with size() intrinsic on class dummy
parameter shape
Product: gcc
Version: 4.9.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57285
Bug ID: 57285
Summary: ICe on invalid: "gfc_array_dimen_size(): Bad
dimension" due to size() intrinsic with invalid dim on
class() dummy argument
Product: gcc
Vers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57285
--- Comment #1 from Lorenz Hüdepohl ---
Created attachment 30120
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30120&action=edit
Minimal test case
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57284
--- Comment #1 from Lorenz Hüdepohl ---
Might be related to Bug #57285
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57283
--- Comment #2 from Lin Yi-Li ---
Sorry I missed that 'pm is a pointer to member function...'.
I know that C++11 has lambda, but using std::mem_fn is sometimes much clear.
But according to standard, value from std::mem_fn for variable will not be
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56265
--- Comment #13 from Martin Jambor ---
Redirecting to builtin_unreachable committed as revision 198926.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55237
--- Comment #11 from Frédéric Buclin ---
What's the max value of a register name? r31?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57281
Eric Botcazou changed:
What|Removed |Added
CC||ebotcazou at gcc dot gnu.org
--- Comment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55237
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #12
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57281
--- Comment #6 from Richard Biener ---
(In reply to Eric Botcazou from comment #5)
> > postreload leaves a REG_DEAD note on the
> >
> > (insn 19 78 21 4 (parallel [
> > (set (mem:DI (reg/f:SI 3 bx [orig:68 D.1736 ] [68]) [4 *_18+0 S8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57281
--- Comment #7 from Eric Botcazou ---
> Which means that split has to do that?
Presumably, yes. peephole2 already does it.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55237
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Comme
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55237
--- Comment #14 from Frédéric Buclin ---
On the other hand, you are free to not click on a register name which is
linkified.
frename-registers
-fno-strict-overflow -o /tmp/ccEheGnn.s
[New Thread 16040.0x374c]
[New Thread 16040.0x1e20]
GNU C (GCC) version 4.9.0 20130515 (experimental) (i686-pc-cygwin)
compiled by GNU C version 4.9.0 20130515 (experimental), GMP version
5.0.2, MPFR version 3.2.0-dev, MPC version
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57283
--- Comment #3 from Jonathan Wakely ---
(In reply to Lin Yi-Li from comment #2)
> Sorry I missed that 'pm is a pointer to member function...'.
>
> I know that C++11 has lambda, but using std::mem_fn is sometimes much clear.
You can still use std
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55237
--- Comment #15 from stevenb.gcc at gmail dot com ---
> --- Comment #14 from Frédéric Buclin ---
> On the other hand, you are free to not click on a register name which is
> linkified.
That is true, but it's a bit distracting.
Let's not bike she
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57286
Richard Biener changed:
What|Removed |Added
CC||glisse at gcc dot gnu.org
Compo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57286
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56807
Kai Tietz changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57287
Bug ID: 57287
Summary: GCC 4.9.0 fails to build GDB on Ubuntu 12.04
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57283
--- Comment #4 from Jonathan Wakely ---
N.B. you can also do it with a nested std::bind expression and std::logical_not
std::bind(std::logical_not(),
std::bind(std::mem_fn(&cls::value), std::placeholders::_1))
in C++14 that means you c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57287
hmb changed:
What|Removed |Added
Severity|normal |blocker
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57288
Bug ID: 57288
Summary: cfi_restore should precede cfi_def_cfa_offset
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: trivial
Priority: P3
Component: tar
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57287
Pedro Alves changed:
What|Removed |Added
CC||palves at redhat dot com
--- Comment #1 fro
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57286
--- Comment #3 from Marc Glisse ---
Intuitively, I'd say:
@@ -10041,7 +10041,7 @@
if (TREE_CODE (arg1) == COND_EXPR
|| TREE_CODE (arg1) == VEC_COND_EXPR
- || COMPARISON_CLASS_P (arg1))
+ || (COMPARISON_CLASS_P (arg1) && !
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57287
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57284
Tobias Burnus changed:
What|Removed |Added
Keywords||ice-on-valid-code
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56776
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |4.8.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56782
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |4.8.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56852
Richard Biener changed:
What|Removed |Added
Priority|P3 |P4
Target Milestone|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56919
Richard Biener changed:
What|Removed |Added
Priority|P3 |P4
Target Milestone|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56939
Richard Biener changed:
What|Removed |Added
Priority|P3 |P4
Target Milestone|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57019
Richard Biener changed:
What|Removed |Added
Priority|P3 |P4
Target Milestone|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57042
Richard Biener changed:
What|Removed |Added
Priority|P3 |P4
Target Milestone|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57101
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |4.8.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57129
Richard Biener changed:
What|Removed |Added
Priority|P3 |P4
Target Milestone|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57199
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |4.8.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57217
Richard Biener changed:
What|Removed |Added
Priority|P3 |P4
Target Milestone|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56033
--- Comment #9 from Dominique d'Humieres ---
> The following snippet fixes the
> cls_unit_va.c failure for me: ...
Confirmed on powerpc-apple-darwin9. Thanks for the fix.
> I've included the complete patch in i386-pc-solaris2.* bootstraps, too,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57221
Richard Biener changed:
What|Removed |Added
Target||arm-bionic-eabi
Target Milestone|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57289
Bug ID: 57289
Summary: ICE during 454.calculix compilation with -O3 -flto
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56971
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |4.9.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56033
--- Comment #10 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #9 from Dominique d'Humieres ---
[...]
>> I've included the complete patch in i386-pc-solaris2.* bootstraps, too,
>> and saw no regressions, so I suggest you post the compl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56966
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56976
--- Comment #3 from Daniel Krügler ---
(In reply to Akim Demaille from comment #2)
You are right, I misread your code example in the haste. I agree that this is
not related to CWG 1604 (we have no mixed case) and I think it is clear that
both init
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57289
Richard Biener changed:
What|Removed |Added
Keywords||lto
Component|lto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57290
Bug ID: 57290
Summary: [4.9 Regression] After r198333 the aermod runtime is
~10% slower when compiled with -fprotect-parens and
-flto
Product: gcc
Version: 4.9.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56776
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57290
--- Comment #1 from rguenther at suse dot de ---
On Wed, 15 May 2013, dominiq at lps dot ens.fr wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57290
>
> Bug ID: 57290
>Summary: [4.9 Regression] After r198333 the aer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57285
janus at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56976
Paolo Carlini changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment #4 f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56033
Rainer Orth changed:
What|Removed |Added
URL||http://gcc.gnu.org/ml/gcc-p
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57284
janus at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57290
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |4.9.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57289
Martin Jambor changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56782
--- Comment #3 from Dodji Seketeli ---
A candidate patch was sent to
http://gcc.gnu.org/ml/gcc-patches/2013-05/msg00841.html for this.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56833
Jorn Wolfgang Rennecke changed:
What|Removed |Added
Keywords||patch
--- Comment #3 from Jorn W
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57291
Bug ID: 57291
Summary: Failure in build stages 2 and 3 concerning pseudo-op:
.balign
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
P
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57292
Bug ID: 57292
Summary: Failure in build after stage 3, concerning libitm.la
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Componen
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57276
Martin Jambor changed:
What|Removed |Added
Status|NEW |ASSIGNED
URL|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57124
Yuri Rumyantsev changed:
What|Removed |Added
CC||ysrumyan at gmail dot com
--- Comment #
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56033
--- Comment #12 from Dominique d'Humieres ---
> I just suggested that you post it since
> it's almost completely your work, but am fine with doing it myself.
Well, my work has been only to test the recipe in comment #5 for the trivial
cases. The
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56919
Janne Blomqvist changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57286
--- Comment #4 from Marc Glisse ---
Shorter testcase:
typedef long vec __attribute__((vector_size(16)));
vec f(vec x){
return (x<0)|1;
}
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57293
Bug ID: 57293
Summary: [4.8/4.9 Regression] not needed frame pointers on
IA-32 (performance regression?)
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31952
Paolo Carlini changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
CC|jason at gcc
Assignee: unassigned at gcc dot gnu.org
Reporter: dcb314 at hotmail dot com
Created attachment 30123
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30123&action=edit
C source code
I just tried to compile the package plymouth-0.8.9-0.2013.03.26.0
on gcc-4.9 trunk dated 2013051
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57295
Bug ID: 57295
Summary: target c6x-elf // internal compiler error: in
extract_insn, at recog.c:2150
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: bloc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57294
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Known to work|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57296
Bug ID: 57296
Summary: Infinite loop in do while when using -O2
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57290
--- Comment #2 from Dominique d'Humieres ---
There is a lot of noise in these numbers(?)
Well, AFAICT aermod.f90 has a "non-monotonic" behavior for the different
optimizations: when playing with --param max-inline-insns-auto=xx, the
execution ti
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57297
Bug ID: 57297
Summary: FAIL: gfortran.dg/select_type_4.f90 -O2 execution
test
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priorit
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49146
--- Comment #4 from Ben Woodard ---
Created attachment 30127
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30127&action=edit
Patch from Ariel that prevents the segv
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57298
Bug ID: 57298
Summary: GOMP_CPU_AFFINITY will not work when system has >1024
cores
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Pri
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57298
--- Comment #1 from Steffen Persvold ---
Created attachment 30128
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30128&action=edit
Proposed patch to fix >1024 processor system support
This patch modifies
libgomp/config/linux/affinity.c
libg
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49146
--- Comment #5 from Ben Woodard ---
Ariel,
In talking to the engineers regarding this, they would like _builtin_expect
hints to tell the compiler to generate code saying that hitting this is
unlikely.
http://blog.man7.org/2012/10/how-much-do-bu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57295
Andrew Pinski changed:
What|Removed |Added
Component|c |target
Severity|blocker
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57299
Bug ID: 57299
Summary: Inline assembly memory dependencies produce spurious
loads, register pressure, compilation failures
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57287
Andrew Pinski changed:
What|Removed |Added
Component|c |middle-end
Severity|blocker
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57299
--- Comment #1 from Andrew Pinski ---
I think you are wrong in how many registers that inline-asm uses. It uses 4
registers, two each to hold y and x which have to be loaded into a register
from the stack.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57296
--- Comment #1 from Dominique d'Humieres ---
Works for me on x86_64-apple-darwin10 (OSX 10.6.8) for both 4.8.0 and trunk.
Where did you get your gfortran? Does -fno-aggressive-loop-optimizations help?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57299
--- Comment #2 from Chris Mihelich ---
The asm statement uses only two registers. Of the six inputs and outputs, only
"r" (p) and "r" (q) are registers; the four "=m" and "m" entries only declare
that memory is read or written in the assembly cod
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57299
--- Comment #3 from Andrew Pinski ---
(In reply to Chris Mihelich from comment #2)
> The asm statement uses only two registers. Of the six inputs and outputs,
> only "r" (p) and "r" (q) are registers; the four "=m" and "m" entries only
> declare
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57297
Mikael Morin changed:
What|Removed |Added
CC||mikael at gcc dot gnu.org
--- Comment #1 f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57296
--- Comment #2 from Antti-Pekka Hynninen
---
(In reply to Dominique d'Humieres from comment #1)
> Works for me on x86_64-apple-darwin10 (OSX 10.6.8) for both 4.8.0 and trunk.
> Where did you get your gfortran? Does -fno-aggressive-loop-optimizati
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57299
--- Comment #4 from Chris Mihelich ---
Yes indeed, x is loaded from the stack into edi, and y is loaded from the stack
into esi, as the register variable declarations specified. That's two
registers. Where are the other two?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57299
--- Comment #5 from Andrew Pinski ---
(In reply to Chris Mihelich from comment #4)
> Yes indeed, x is loaded from the stack into edi, and y is loaded from the
> stack into esi, as the register variable declarations specified. That's two
> registe
1 - 100 of 114 matches
Mail list logo
