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
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=58040
Daniel Krügler changed:
What|Removed |Added
CC||daniel.kruegler@googlemail.
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=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=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=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=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=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=32197
Paolo Carlini changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
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=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=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=37140
Paolo Carlini changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
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=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=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 #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=55956
Dominique d'Humieres changed:
What|Removed |Added
Status|SUSPENDED |WAITING
--- Comment #5 from Domini
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=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=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=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=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=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=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=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=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=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=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=58041
Bill Schmidt changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
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=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=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=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=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 #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=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 #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 #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 #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 #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=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 #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=58041
--- Comment #17 from Bill Schmidt ---
Excellent! Thanks for the confirmation.
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=54537
Peter Bergner changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
URL|
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=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=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=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=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=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
--- 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 #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=58046
Paolo Carlini changed:
What|Removed |Added
Keywords||ice-on-invalid-code
Status|UN
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=57779
Paolo Carlini changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
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
: 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=58049
David Edelsohn changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
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=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=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=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=58053
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
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=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=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
69 matches
Mail list logo
