http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58054
--- Comment #1 from Andrew Pinski ---
Looks like they changed how base classes are handled in C++ for C++11.
98 says this:
[class.friend]/2
"Also, because the base-clause of the friend class is not
part of its member declarations, the base-clau
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58054
Bug ID: 58054
Summary: 11.3 Friends, example from standard not compiled
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57306
--- Comment #12 from janus at gcc dot gnu.org ---
(In reply to Tobias Burnus from comment #10)
> > Putting this inside a subroutine, one gets:
> >
> > class(c), pointer :: px => x
> > 1
> > Error: Pointer initializa
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58053
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58053
Bug ID: 58053
Summary: Bogus "error ... is private ... within this context"
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compon
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58052
Bug ID: 58052
Summary: Copy initialization using conversion operator does not
find correct candidates for initialization of final
result
Product: gcc
Version: 4.8.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58051
Bug ID: 58051
Summary: No named return value optimization when returned
object is implicitly converted
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58050
Bug ID: 58050
Summary: RVO fails when calling static function through unnamed
temporary
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58049
David Edelsohn changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: dje at gcc dot gnu.org
In file included from
/tmp/20130801/powerpc-ibm-aix7.1.0.0/libstdc++-v3/include/
debug/safe_sequence.h:34:0,
from
/nasfarm/edelsohn
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041
--- Comment #19 from Martin Jambor ---
(In reply to Bill Schmidt from comment #15)
> Bernd, Mikael, Martin: Could you please test this on your respective
> targets?
Well, "my target" is x86_64 but yes, it works.
(In reply to Bill Schmidt from
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57779
Paolo Carlini changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58047
Paolo Carlini changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58046
Paolo Carlini changed:
What|Removed |Added
Keywords||ice-on-invalid-code
Status|UN
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57306
--- Comment #11 from janus at gcc dot gnu.org ---
(In reply to Tobias Burnus from comment #10)
> > Putting this inside a subroutine, one gets:
> >
> > class(c), pointer :: px => x
> > 1
> > Error: Pointer initializa
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55207
--- Comment #12 from janus at gcc dot gnu.org ---
(In reply to Tobias Burnus from comment #11)
>
> + if ((gfc_current_state () == COMP_MODULE
> + || gfc_current_state () == COMP_PROGRAM)
>
> I haven't tried the patch, but does it work corr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57306
--- Comment #10 from Tobias Burnus ---
> Putting this inside a subroutine, one gets:
>
> class(c), pointer :: px => x
> 1
> Error: Pointer initialization target at (1) must have the SAVE attribute
That sounds like
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55207
Tobias Burnus changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
--- Comment #11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57994
--- Comment #13 from Vincent Lefèvre ---
A difference that may occur in the future if the C library adds a rsqrt
function (based on the IEEE 754-2008 rSqrt function) or constant folding is
used on builtins: in MPFR, mpfr_rec_sqrt on -0 gives +Inf,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57963
--- Comment #1 from Vladimir Makarov ---
Thanks, Andreas. I've reproduced the bug. I hope to fix it on this week.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57710
--- Comment #5 from Tobias Burnus ---
(In reply to janus from comment #2)
> Can't we do a 'static' initialization (of _vptr *and* _data) in both cases?
Well, you need to free and finalize the variable - hence, it cannot be static.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54537
Peter Bergner changed:
What|Removed |Added
Status|RESOLVED|CLOSED
--- Comment #2 from Peter Bergner
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54537
Peter Bergner changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
URL|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041
--- Comment #18 from Mikael Pettersson ---
(In reply to Bill Schmidt from comment #15)
> Bernd, Mikael, Martin: Could you please test this on your respective
> targets?
This patch eliminates the misalignment faults for me on both ARMv5TE and SPA
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041
--- Comment #17 from Bill Schmidt ---
Excellent! Thanks for the confirmation.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041
--- Comment #16 from Bernd Edlinger ---
(In reply to Bill Schmidt from comment #15)
> Bernd, Mikael, Martin: Could you please test this on your respective
> targets?
Congatulations!
it works.
If I compile with -mno-unaligned-access all accesse
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57997
--- Comment #7 from Paolo Carlini ---
I think so, yes. Your help is welcome anyway, worst case, we'll apply the
changes for the next release series instead of 4.9. In a few hours I will send
you privately the questionnaire to request the official
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041
--- Comment #15 from Bill Schmidt ---
Bernd, Mikael, Martin: Could you please test this on your respective targets?
Index: gcc/gimple-ssa-strength-reduction.c
===
--- gcc/gimple-ssa
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041
--- Comment #14 from Bill Schmidt ---
(In reply to Bernd Edlinger from comment #13)
> Hi,
>
> just one question, how about the -m[no-]unaligned-access option?
>
> If -munaligned-access had been given the code was almost right,
> I mean AFAIK ldr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041
--- Comment #13 from Bernd Edlinger ---
Hi,
just one question, how about the -m[no-]unaligned-access option?
If -munaligned-access had been given the code was almost right,
I mean AFAIK ldr/str should be handled in hardware but ldmia generates
a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041
--- Comment #12 from Bill Schmidt ---
...which apparently is not quite right, since the candidates still appear in
the table. Hm. But you get the idea -- do the check earlier.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041
--- Comment #11 from Bill Schmidt ---
Hi Martin,
Your assumptions are correct, but I'm not sure this is the best place to handle
it. It looks like what you are doing is replacing one already correct memory
reference with another, both of which w
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041
--- Comment #10 from Martin Jambor ---
Created attachment 30587
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30587&action=edit
x86_64-linux testcase
To prove the point, this is an x86_64-linux testcase. I will
bootstrap and test the patch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57997
--- Comment #6 from Roy Stogner ---
Copyright assignment shouldn't be a problem. The one serious non-technical
problem is going to be finding time to work on a patch.
The only technical issue I've discovered so far is that making this robust wit
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041
--- Comment #9 from Martin Jambor ---
More specifically, if I am correct assuming that the MEM_REF
replace_ref builds always accesses exactly the same memory as the
previous access *expr does (and only the address is computed better)
and that *exp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58048
Mikael Pettersson changed:
What|Removed |Added
CC||mikpe at it dot uu.se
--- Comment #1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58048
Bug ID: 58048
Summary: internal compiler error: Max. number of generated
reload insns per insn is achieved (90)
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
S
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041
--- Comment #8 from Martin Jambor ---
I believe that you need to set alignment of the type of MEM_REFs you
create in replace_ref along the lines it is done in
build_ref_for_offset in tree-sra.c.
I wonder whether STRICT_ALIGNMENT has really any me
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041
Bill Schmidt changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58047
Bug ID: 58047
Summary: parse error with typedef introduced from base class
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58020
--- Comment #12 from richard.koolhans at gmail dot com ---
Thanks for doing the test with -O3. That is what I see, also. My tests show:
With -O0 everything works.
With -O1 everything runs but there are some failures.
With -O2 everything runs but
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58046
Bug ID: 58046
Summary: template operator= in SFINAE class
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
A
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55207
janus at gcc dot gnu.org changed:
What|Removed |Added
Attachment #28620|0 |1
is obsolete|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55207
--- Comment #9 from janus at gcc dot gnu.org ---
(In reply to janus from comment #8)
> I think we need the patch in comment 6 after all. But how do we get rid of
> the remaining regressions?
Simplest solution: Move the code in these test cases fro
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58043
--- Comment #3 from janus at gcc dot gnu.org ---
The WRITE of the second element in main is translated into:
_gfortran_transfer_real_write (&dt_parm.7, (real(kind=4) *) &((struct adof_t *)
dofs._data.data + (sizetype) ((dofs._data.offset + 1) * (
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58043
--- Comment #2 from janus at gcc dot gnu.org ---
Here is a reduced test case, which demonstrates the same problem in a somewhat
more compact manner:
program main
implicit none
type :: adof_t
real :: grd(1:2)
end type
class(adof_t),
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57748
--- Comment #13 from Martin Jambor ---
Created attachment 30583
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30583&action=edit
Untested fix
This is how I'd like to fix the problem if the patch passes bootstrap
and testing (on x86_64-linux,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58045
Bug ID: 58045
Summary: gcc 4.8 produces an undefined reference to an inline
function
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
P
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58043
janus at gcc dot gnu.org changed:
What|Removed |Added
Keywords||wrong-code
Status|U
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58044
Bug ID: 58044
Summary: -mno-see2avx does not seems to work
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: inline-asm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55956
Dominique d'Humieres changed:
What|Removed |Added
Status|SUSPENDED |WAITING
--- Comment #5 from Domini
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041
--- Comment #6 from Bill Schmidt ---
I'll investigate. It may be a day or two before I can get to it, but this is
pretty clearly my issue.
Thanks,
Bill
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58020
--- Comment #11 from Dominique d'Humieres ---
> The issues have hopefully been resolved and are now in the package.
> See http://mathalacarte.com/hpcconsult
> Thanks for the comments made above. Give feedback where it makes sense.
When c_contr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041
--- Comment #5 from Mikael Pettersson ---
I see the exact same failure pattern on sparc64-linux: 4.7 generates working
code, 4.8 and 4.9 generate code that SIGBUS:es, failure starts with r190037,
-m32 or -m64 makes no difference.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041
Mikael Pettersson changed:
What|Removed |Added
CC||wschmidt at gcc dot gnu.org
--- Comme
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37140
Paolo Carlini changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37140
Paolo Carlini changed:
What|Removed |Added
CC|fabien at gcc dot gnu.org |
--- Comment #7 from Paolo Carlini
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36266
Paolo Carlini changed:
What|Removed |Added
CC|gcc-bugs at gcc dot gnu.org|ccoutant at gcc dot
gnu.org
--- C
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34624
Paolo Carlini changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|gcc-bugs at g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32197
Paolo Carlini changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57734
--- Comment #1 from Paolo Carlini ---
This isn't just about returning, eg:
typedef eclass_alias test;
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58040
Paolo Carlini changed:
What|Removed |Added
CC||fabien at gcc dot gnu.org
--- Comment #2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041
Mikael Pettersson changed:
What|Removed |Added
CC||mikpe at it dot uu.se
--- Comment #3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58043
Bug ID: 58043
Summary: Incorrect behaviour of polymorphic array
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58042
Bug ID: 58042
Summary: MinGW GCC produces problematic x64 executable with -O2
-static -flto -m64
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041
--- Comment #2 from Bernd Edlinger ---
Sandra,
this seems to be unrelated to your strict-volatile-bitfields patch,
as it happens with or without that patch.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58040
Daniel Krügler changed:
What|Removed |Added
CC||daniel.kruegler@googlemail.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041
--- Comment #1 from Bernd Edlinger ---
Created attachment 30579
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30579&action=edit
test case to show the bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041
Bug ID: 58041
Summary: Unaligned access to arrays in packed structure
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: mid
69 matches
Mail list logo
