http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57301
--- Comment #2 from Marc Glisse ---
(In reply to Marc Glisse from comment #1)
> How old is your gcc build? (please fill in the version field when reporting
> bugs)
Oups, sorry, you mention it (4.7 and 4.8) in the text.
> This was fixed by Jakub
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57301
--- Comment #1 from Marc Glisse ---
How old is your gcc build? (please fill in the version field when reporting
bugs)
This was fixed by Jakub recently, so if you could check with current trunk...
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57286
--- Comment #6 from gee ---
(In reply to Marc Glisse from comment #3)
> Intuitively, I'd say:
>
> @@ -10041,7 +10041,7 @@
>
>if (TREE_CODE (arg1) == COND_EXPR
> || TREE_CODE (arg1) == VEC_COND_EXPR
> - || COMPARISON_CLASS_
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57286
--- Comment #5 from gee ---
Created attachment 30129
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30129&action=edit
proposed patch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57301
Bug ID: 57301
Summary: bit rotation is not optimized in c but not c++
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57299
--- Comment #9 from Andrew Pinski ---
Oh without optimization 6 registers will be used rather than the 4 that GCC can
do with optimizations turned on.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57299
--- Comment #8 from Chris Mihelich ---
(In reply to Andrew Pinski from comment #7)
> Actually it only needs 4 (and not 6) due to holding of the pointer of y and
> x can happen with only 2 registers.
That's not what GCC is doing, actually. When I
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57299
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
s not have that option.
>
> I'll try to compile gfortran from the source and see if the bug goes away.
Ok, the code works after I compiled gfortran from sources. My current version
is GNU Fortran (GCC) 4.8.1 20130515 (prerelease)
I'm changing the status to resolved.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57294
Marek Polacek changed:
What|Removed |Added
CC||mjambor at suse dot cz
--- Comment #2 fro
lower optimization, or with gcc 4.7 and earlier it works correctly.
$ gcc-trunk -v
Target: x86_64-unknown-linux-gnu
...
gcc version 4.9.0 20130515 (experimental) [trunk revision 198926] (GCC)
$ gcc-trunk -O2 -m32 small.c
$ ./a.out
1
$ gcc-trunk -O3 -m64 small.c
$ ./a.out
1
$ gcc-4.7 -O3 -m32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57278
--- Comment #3 from Shiwen Hu ---
Thanks for the explanations regarding predicated instructions!
How about the sign extension instructions that can be moved out of the loop?
Shiwen
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57260
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57299
--- Comment #6 from Chris Mihelich ---
Ah, but "=m" and "m" operands shouldn't need any register at all: their purpose
is just to declare that a specific piece of memory is written or read in the
assembly code, a declaration that helps the optimiz
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
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=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=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=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=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=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 #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=57287
Andrew Pinski changed:
What|Removed |Added
Component|c |middle-end
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=57295
Andrew Pinski changed:
What|Removed |Added
Component|c |target
Severity|blocker
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=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=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=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=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=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=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=57294
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Known to work|
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
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=31952
Paolo Carlini changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
CC|jason at gcc
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=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=56919
Janne Blomqvist changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
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=57124
Yuri Rumyantsev changed:
What|Removed |Added
CC||ysrumyan at gmail dot com
--- Comment #
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=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=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=56833
Jorn Wolfgang Rennecke changed:
What|Removed |Added
Keywords||patch
--- Comment #3 from Jorn W
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=57289
Martin Jambor changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
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=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=56033
Rainer Orth changed:
What|Removed |Added
URL||http://gcc.gnu.org/ml/gcc-p
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=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=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=56776
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
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=57289
Richard Biener changed:
What|Removed |Added
Keywords||lto
Component|lto
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=56966
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
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=56971
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |4.9.0
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=57221
Richard Biener changed:
What|Removed |Added
Target||arm-bionic-eabi
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=57217
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=57129
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=57042
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=56939
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=56852
Richard Biener changed:
What|Removed |Added
Priority|P3 |P4
Target Milestone|---
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=56776
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |4.8.1
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=57287
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
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
Pedro Alves changed:
What|Removed |Added
CC||palves at redhat dot com
--- Comment #1 fro
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
hmb changed:
What|Removed |Added
Severity|normal |blocker
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
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=56807
Kai Tietz changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
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=57286
Richard Biener changed:
What|Removed |Added
CC||glisse at gcc dot gnu.org
Compo
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=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
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=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.
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=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=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=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
Eric Botcazou changed:
What|Removed |Added
CC||ebotcazou at gcc dot gnu.org
--- Comment
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=56265
--- Comment #13 from Martin Jambor ---
Redirecting to builtin_unreachable committed as revision 198926.
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=57284
--- Comment #1 from Lorenz Hüdepohl ---
Might be related to Bug #57285
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=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
1 - 100 of 114 matches
Mail list logo