[Bug bootstrap/57609] S/390 ESA mode bootstrap failure since r197266
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57609 Andreas Krebbel krebbel at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Andreas Krebbel krebbel at gcc dot gnu.org --- Fixed with r200196 http://gcc.gnu.org/ml/gcc-patches/2013-06/msg01114.html
[Bug bootstrap/57609] S/390 ESA mode bootstrap failure since r197266
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57609 Andreas Krebbel krebbel at gcc dot gnu.org changed: What|Removed |Added Status|RESOLVED|CLOSED --- Comment #3 from Andreas Krebbel krebbel at gcc dot gnu.org --- Fixed.
[Bug bootstrap/57603] Bootstrap fail on s390x segfault in fold_marked_statements
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57603 Andreas Krebbel krebbel at gcc dot gnu.org changed: What|Removed |Added Status|RESOLVED|CLOSED --- Comment #3 from Andreas Krebbel krebbel at gcc dot gnu.org --- Closed.
[Bug bootstrap/57603] Bootstrap fail on s390x segfault in fold_marked_statements
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57603 Andreas Krebbel krebbel at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Andreas Krebbel krebbel at gcc dot gnu.org --- Does not occur with r201325 anymore.
[Bug fortran/57710] [OOP] _vptr not set for allocatable CLASS components
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57710
--- Comment #2 from janus at gcc dot gnu.org ---
(In reply to Tobias Burnus from comment #0)
The following code (minus the IF condition) shows that _vptr is not set for
the allocatable component:
y.x._data = 0B;
there should be - but isn't - additionally: y.x._vptr = __vtab_m_T;
Without the BLOCK, the dump shows:
static struct t2 y = {.x={._vptr=__vtab_m_T}};
y.x._data = 0B;
y.ii = 123;
while with the BLOCK one gets:
struct t2 y;
try
{
y.x._data = 0B;
y.ii = 123;
L.1:;
}
Can't we do a 'static' initialization (of _vptr *and* _data) in both cases? As
in
struct t2 y = {.x={._vptr=__vtab_m_T,._data = 0B}}
For this gfc_class_null_initializer (from class.c) could be used ...
[Bug bootstrap/57604] LRA related bootstrap comparison failure on s390x --with-arch=zEC12
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57604 Andreas Krebbel krebbel at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #4 from Andreas Krebbel krebbel at gcc dot gnu.org --- Fixed with r200227: 2013-06-19 Vladimir Makarov vmaka...@redhat.com PR bootstrap/57604 * lra.c (emit_add3_insn, emit_add2_insn): New functions. (lra_emit_add): Use the functions. Add comment about Y as an address segment.
[Bug fortran/57710] [OOP] [F08] _vptr not set for allocatable CLASS component inside BLOCK
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57710 janus at gcc dot gnu.org changed: What|Removed |Added Summary|[OOP] _vptr not set for |[OOP] [F08] _vptr not set |allocatable CLASS |for allocatable CLASS |components |component inside BLOCK --- Comment #3 from janus at gcc dot gnu.org --- (In reply to Tobias Burnus from comment #0) Additionally, the test case as is (with IF condition), currently crashes with: internal compiler error: in gfc_conv_component_ref, at fortran/trans-expr.c:1654 Also the ICE occurs only with the BLOCK construct. Slightly reduced test case: module m type t end type type t2 class(t), allocatable :: x end type end module use m type(t) :: z block type(t2) :: y if (.not. same_type_as(y%x, z)) call abort () end block end
[Bug middle-end/46399] Missing type promotion for library call argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46399 Andreas Krebbel krebbel at gcc dot gnu.org changed: What|Removed |Added Status|RESOLVED|CLOSED --- Comment #4 from Andreas Krebbel krebbel at gcc dot gnu.org --- Closed.
[Bug middle-end/46399] Missing type promotion for library call argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46399 Andreas Krebbel krebbel at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #2 from Andreas Krebbel krebbel at gcc dot gnu.org --- Fixed.
[Bug middle-end/46399] Missing type promotion for library call argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46399 --- Comment #3 from Andreas Krebbel krebbel at gcc dot gnu.org --- Closed.
[Bug rtl-optimization/57559] [4.9 Regression] S/390: ICE with lra
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57559 Andreas Krebbel krebbel at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #1 from Andreas Krebbel krebbel at gcc dot gnu.org --- Cannot be reproduced with r201360 anymore.
[Bug rtl-optimization/57960] S/390: LRA ICE building glibc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57960 Andreas Krebbel krebbel at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #4 from Andreas Krebbel krebbel at gcc dot gnu.org --- Fixed with r201243 2013-07-25 Vladimir Makarov vmaka...@redhat.com PR rtl-optimization/57960 * lra-constraints.c (process_alt_operands): Use the right mode when checking strict_low. 2013-07-25 Vladimir Makarov vmaka...@redhat.com PR rtl-optimization/57960 * gcc.target/s390/pr57960.c: New.
[Bug bootstrap/58035] New: LRA: S/390: Ada bootstrap fail
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58035 Bug ID: 58035 Summary: LRA: S/390: Ada bootstrap fail Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: krebbel at gcc dot gnu.org Tested with r201329. Ada bootstraps with LRA disabled. When enabling LRA bootstrap fails with: xgcc: internal compiler error: Segmentation fault (program gnat1) 0x8000fb75 execute /home/andreas/clean/gcc-head/gcc/gcc.c:2824 0x8000fe37 do_spec_1 /home/andreas/clean/gcc-head/gcc/gcc.c:4616 0x80013145 process_brace_body /home/andreas/clean/gcc-head/gcc/gcc.c:5873 0x80013145 handle_braces /home/andreas/clean/gcc-head/gcc/gcc.c:5787 0x800110b5 do_spec_1 /home/andreas/clean/gcc-head/gcc/gcc.c:5270 0x80013145 process_brace_body /home/andreas/clean/gcc-head/gcc/gcc.c:5873 0x80013145 handle_braces /home/andreas/clean/gcc-head/gcc/gcc.c:5787 0x800110b5 do_spec_1 /home/andreas/clean/gcc-head/gcc/gcc.c:5270 0x800103fb do_spec_1 /home/andreas/clean/gcc-head/gcc/gcc.c:5375 0x80013145 process_brace_body /home/andreas/clean/gcc-head/gcc/gcc.c:5873 0x80013145 handle_braces /home/andreas/clean/gcc-head/gcc/gcc.c:5787 0x800110b5 do_spec_1 /home/andreas/clean/gcc-head/gcc/gcc.c:5270 0x80013145 process_brace_body /home/andreas/clean/gcc-head/gcc/gcc.c:5873 0x80013145 handle_braces /home/andreas/clean/gcc-head/gcc/gcc.c:5787 0x800110b5 do_spec_1 /home/andreas/clean/gcc-head/gcc/gcc.c:5270 0x80012557 do_spec_2 /home/andreas/clean/gcc-head/gcc/gcc.c:4317 0x80013a3b do_spec(char const*) /home/andreas/clean/gcc-head/gcc/gcc.c:4284 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See http://gcc.gnu.org/bugs.html for instructions. make[7]: *** [s-auxdec.o] Error 4
[Bug rtl-optimization/58036] New: [meta-bug] alias.c:base_alias_check says stack accesses with different base registers don't alias
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58036 Bug ID: 58036 Summary: [meta-bug] alias.c:base_alias_check says stack accesses with different base registers don't alias Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: amylaar at gcc dot gnu.org Blocks: 53705, 58029, 50063, 54921
[Bug c++/58037] New: sizeof... accepted only in some contexts
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58037
Bug ID: 58037
Summary: sizeof... accepted only in some contexts
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: nmm1 at cam dot ac.uk
With 4.8.1:
templateint ... Dims
class weeble {
static constexpr int Ranks[sizeof...(Dims)] = {Dims...};
const int rank = sizeof...(Dims);
};
weeble3,5 x;
produces:
junk.cpp:4:22: error: expected ';' at end of member declaration
const int rank = sizeof...(Dims);
^
junk.cpp:4:28: error: expected unqualified-id before '...' token
const int rank = sizeof...(Dims);
^
junk.cpp:4:22: error: expected primary-expression at end of input
const int rank = sizeof...(Dims);
^
That doesn't look right, especially as that use of sizeof... is almost
straight out of the standard.
For what it is worth, -v produces:
Using built-in specs.
COLLECT_GCC=/home/nmm/GCC/bin/g++
COLLECT_LTO_WRAPPER=/home/nmm/GCC/libexec/gcc/x86_64-unknown-linux-gnu/4.8.1/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --prefix=/home/nmm/GCC --disable-bootstrap
--enable-languages=c,c++,fortran --enable-werror=yes --disable-decimal-float
Thread model: posix
gcc version 4.8.1 (GCC)
[Bug c++/58037] sizeof... accepted only in some contexts
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58037 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Keywords||rejects-valid Status|UNCONFIRMED |NEW Last reconfirmed||2013-07-31 Version|unknown |4.8.1 Ever confirmed|0 |1 Known to fail||4.7.3, 4.8.1, 4.9.0
[Bug c++/58037] sizeof... accepted only in some contexts
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58037
--- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org ---
The compiler only rejects it when the member is non-static and uses = for the
initializer.
As a workaround you can use a braced-init-list as the initializer for the
member:
const int rank { sizeof...(Dims) };
[Bug fortran/55887] [OOP][F08] ICE with CLASS and data-target pointer association in (default) initialization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55887 --- Comment #4 from janus at gcc dot gnu.org --- PR 57036 is very much related to this one ...
[Bug fortran/55887] [OOP][F08] ICE with CLASS and data-target pointer association in (default) initialization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55887 --- Comment #5 from janus at gcc dot gnu.org --- (In reply to janus from comment #4) PR 57036 is very much related to this one ... Sorry, that should have been: PR 57306
[Bug libstdc++/58038] New: std::this_thread::sleep_until can cause inifinite sleep
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58038
Bug ID: 58038
Summary: std::this_thread::sleep_until can cause inifinite
sleep
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: mario.biel...@tu-dresden.de
Created attachment 30576
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30576action=edit
Small test case, build with g++ -std=c++0x
When using sleep_until() I get an bug with unsigned long scalar representations
of a duration. If this duratoiin is in past, then you get an overflow in the
length of the argument for sleep_for(). This causes an almost infinte sleep,
instead of a fast return.
I solved this with defining two seperate implementions for sleep_until using
enable_if.
#
/// sleep_until for signed representations
templatetypename _Clock, typename _Duration
inline
typename std::enable_ifstd::is_signedtypename _Duration::rep::value,
void::type
sleep_until(const chrono::time_point_Clock, _Duration __atime)
{
sleep_for(__atime - _Clock::now());
}
/// sleep_until for unsigned representations
templatetypename _Clock, typename _Duration
inline
typename std::enable_ifstd::is_unsignedtypename _Duration::rep::value,
void::type
sleep_until(const chrono::time_point_Clock, _Duration __atime)
{
typename _Clock::time_point _now = _Clock::now();
// check if we should sleep till a time point in past
if(__atime _now)
// if not, procede as usual
sleep_for(__atime - _now);
}
#
Sorry for not providing a .patch file, as I'm hacked my local installed
headers.
[Bug c++/58037] sizeof... accepted only in some contexts
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58037 --- Comment #2 from Nick Maclaren nmm1 at cam dot ac.uk --- Thanks. That's simpler than my workaround.
[Bug rtl-optimization/58034] glibc nptl/tst-cleanup2 fail due to scheduling
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58034 David Edelsohn dje at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-07-31 CC||dje at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from David Edelsohn dje at gcc dot gnu.org --- Confirmed.
[Bug libstdc++/58038] std::this_thread::sleep_until can cause inifinite sleep
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58038 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org --- I think this should be fixed in chrono not thread
[Bug c++/57673] pack sizeof ... groups ellipsis with preceding expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57673 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||nmm1 at cam dot ac.uk --- Comment #5 from Paolo Carlini paolo.carlini at oracle dot com --- *** Bug 58037 has been marked as a duplicate of this bug. ***
[Bug middle-end/57748] [4.8/4.9 Regression] ICE on ARM with -mfloat-abi=softfp -mfpu=neon
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57748 --- Comment #9 from Martin Jambor jamborm at gcc dot gnu.org --- Created attachment 30577 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30577action=edit Simple x86_64 testcase Simple x86_64 testcase triggering the ICE.
[Bug c++/58037] sizeof... accepted only in some contexts
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58037 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com --- Dup. Already fixed in mainline. *** This bug has been marked as a duplicate of bug 57673 ***
[Bug libstdc++/58038] std::this_thread::sleep_until can cause inifinite sleep
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58038
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2013-07-31
Ever confirmed|0 |1
--- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org ---
On second thoughts, chrono is doing everything as specified by the standard.
It seems unfortunate that we need this, but I don't immediately see any way
around it. I think I'd prefer to do this than use SFINAE:
templatetypename _Clock, typename _Duration
inline void
sleep_until(const chrono::time_point_Clock, _Duration __atime)
{
auto __now = _Clock::now();
// check if we should sleep till a time point in past
if (std::is_unsignedtypename _Duration::rep::value __atime = __now)
return;
sleep_for(__atime - __now);
}
[Bug libstdc++/56627] class hash instead of struct hash
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56627 --- Comment #13 from Paolo Carlini paolo.carlini at oracle dot com --- Jon, I have two spare minutes and if you don't mind I'm taking care of the stupid change myself.
[Bug libstdc++/56627] class hash instead of struct hash
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56627 --- Comment #14 from Jonathan Wakely redi at gcc dot gnu.org --- Sure, I was going to do it this evening but please go ahead, thanks.
[Bug libstdc++/58038] std::this_thread::sleep_until can cause inifinite sleep
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58038
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
--- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org ---
Or we could just check unconditionally, which handles situations where the
clock is adjusted while sleeping:
/// sleep_until
templatetypename _Clock, typename _Duration
inline void
sleep_until(const chrono::time_point_Clock, _Duration __atime)
{
auto __now = _Clock::now();
while (__now __atime)
{
sleep_for(__atime - __now);
__now = _Clock::now();
}
}
I have another timing related bug to fix so will deal with this too.
[Bug libstdc++/56627] class hash instead of struct hash
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56627 --- Comment #15 from Paolo Carlini paolo.carlini at oracle dot com --- Done for 4.8.2 and 4.9.0.
[Bug libstdc++/58038] std::this_thread::sleep_until can cause inifinite sleep
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58038 --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com --- Thanks!
[Bug rtl-optimization/58034] glibc nptl/tst-cleanup2 fail due to scheduling
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58034 --- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org --- if (_setjmp (jmpbuf)) I wonder if this is due to _setjmp not being marked as return twice.
[Bug rtl-optimization/58034] glibc nptl/tst-cleanup2 fail due to scheduling
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58034 --- Comment #3 from David Edelsohn dje at gcc dot gnu.org --- I wonder if this is due to _setjmp not being marked as return twice. Is that a missing decoration in the GLIBC declaration?
[Bug rtl-optimization/58034] glibc nptl/tst-cleanup2 fail due to scheduling
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58034 --- Comment #4 from Andrew Pinski pinskia at gcc dot gnu.org --- (In reply to Andrew Pinski from comment #2) if (_setjmp (jmpbuf)) I wonder if this is due to _setjmp not being marked as return twice. Looking at special_function_p, it should return ECF_RETURNS_TWICE for that decl if I read the code correctly as it disregards the _ and then matches setjmp.
[Bug testsuite/57591] gcc-4.8 libbacktrace btest failure on Linux ppc64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57591 --- Comment #5 from acrux acrux at linuxmail dot org --- same failure with gcc-4.8-20130725
[Bug c++/57532] [4.8/4.9 regression] operator broken when used on rvalues
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57532 Salamanderrake salamanderrake at gmail dot com changed: What|Removed |Added CC||salamanderrake at gmail dot com --- Comment #4 from Salamanderrake salamanderrake at gmail dot com --- Is there a patch to get this working with gcc 4.8.1? How far back into the history will the patch need to reach.
[Bug middle-end/57748] [4.8/4.9 Regression] ICE on ARM with -mfloat-abi=softfp -mfpu=neon
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57748
--- Comment #10 from Martin Jambor jamborm at gcc dot gnu.org ---
The problem is that the type of the record that contains the scalar
data we are accessing has non-BLK mode despite that we are not
accessing a part of it. This is because it has a zero sized trailing
array:
typedef struct S { V a; V b[0]; } P __attribute__((aligned (1)));
in the x86_64-linux example from comment #9, and
struct resolved_chain {
u64 nr;
struct resolved_ip ips[0];
};
in the original testcase.
Because it has non-BLK mode, it passes the condition in
expand-assignment that is there to handle accesses to small,
scalar-sized structures (or even arrays) which should be written to
memory through movmisalign_optab. E.g. to access an element of a
vector.
However, in these testcases, the structure we are writing to is bigger
than a scalar. I wonder why structures with trailing zero-sized
arrays have non-BLK mode. I think that is the root of the problem,
actually.
[Bug middle-end/57748] [4.8/4.9 Regression] ICE on ARM with -mfloat-abi=softfp -mfpu=neon
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57748 --- Comment #11 from Martin Jambor jamborm at gcc dot gnu.org --- (In reply to Bernd Edlinger from comment #8) (In reply to Martin Jambor from comment #7) In any event, it is clear that the code in expand_assignment cannot cope with unaligned tem and non-NULL offset. So currently I'm considering the following patch, although I am not really sure it is enough (it does fix the ICE, though). If you can run the testcase on the platform, would you run it with this patch applied, please? No, unfortunately I can only look at the assembler listing. But wait a moment... If the object is assumed to be unaligned here this patch will likely just compute the unaligned address, add the offset, and store the result there without any special precautions. While the code in the if statement seems to store the expression on a register and move that register to the final destination. Well, I believe this unaligned arrays are generally broken. consider this example: With or without the patch? If without the patch and you are reasonably confident the output is indeed wrong, please open a new PR (and CC me, I'm interested) because this particular ICE is certainly caused by trailing zero sized arrays. I have tried reproducing your problem with x86_64 MMX vectors but couldn't. I do not have access to an ARM machine to verify myself. Thanks.
[Bug c++/57532] [4.8/4.9 regression] operator broken when used on rvalues
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57532 --- Comment #5 from Paolo Carlini paolo.carlini at oracle dot com --- Just search gcc-patches around the date of Comment #3, no? http://gcc.gnu.org/ml/gcc-patches/2013-07/msg00372.html
[Bug target/53513] SH Target: Add support for fschg and fpchg insns
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53513 --- Comment #2 from Oleg Endo olegendo at gcc dot gnu.org --- See also PR 29349.
[Bug libfortran/58020] Code for handling IEEE exceptions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58020 richard.koolhans at gmail dot com changed: What|Removed |Added CC||richard.koolhans at gmail dot com --- Comment #10 from richard.koolhans at gmail dot com --- 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.
[Bug fortran/57710] [OOP] [F08] _vptr not set for allocatable CLASS component inside BLOCK
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57710
--- Comment #4 from janus at gcc dot gnu.org ---
(In reply to janus from comment #2)
Can't we do a 'static' initialization (of _vptr *and* _data) in both cases?
As in
struct t2 y = {.x={._vptr=__vtab_m_T,._data = 0B}}
For this gfc_class_null_initializer (from class.c) could be used ...
... we would just have to enable this for the BLOCK case in gfc_get_symbol
decl. However, I'm not sure if this is really the way to go.
Otherwise, one should do the (non-static) initialization of the _vptr via
gfc_nullify_alloc_comp.
[Bug fortran/58001] Make it possible to silence Extension: Tab character in format warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58001
--- Comment #9 from Steve Kargl sgk at troutmask dot apl.washington.edu ---
The following patch causes gfortran to treat a tab within
a FORMAT statement that same as it does elsewhere for the
appearance of a nonconforming use of tab. The two tet
cases have been adjusted.
Index: gcc/fortran/io.c
===
--- gcc/fortran/io.c(revision 201382)
+++ gcc/fortran/io.c(working copy)
@@ -192,23 +192,14 @@ unget_char (void)
/* Eat up the spaces and return a character. */
static char
-next_char_not_space (bool *error)
+next_char_not_space ()
{
char c;
do
{
error_element = c = next_char (NONSTRING);
- if (c == '\t')
-{
- if (gfc_option.allow_std GFC_STD_GNU)
-gfc_warning (Extension: Tab character in format at %C);
- else
-{
- gfc_error (Extension: Tab character in format at %C);
- *error = true;
- return c;
-}
-}
+ if (!gfc_option.warn_tabs c == '\t')
+ gfc_warning (Nonconforming tab character in FORMAT at %C);
}
while (gfc_is_whitespace (c));
return c;
@@ -226,7 +217,6 @@ format_lex (void)
char c, delim;
int zflag;
int negative_flag;
- bool error = false;
if (saved_token != FMT_NONE)
{
@@ -235,7 +225,7 @@ format_lex (void)
return token;
}
- c = next_char_not_space (error);
+ c = next_char_not_space ();
negative_flag = 0;
switch (c)
@@ -245,7 +235,7 @@ format_lex (void)
/* Falls through. */
case '+':
- c = next_char_not_space (error);
+ c = next_char_not_space ();
if (!ISDIGIT (c))
{
token = FMT_UNKNOWN;
@@ -256,7 +246,7 @@ format_lex (void)
do
{
- c = next_char_not_space (error);
+ c = next_char_not_space ();
if (ISDIGIT (c))
value = 10 * value + c - '0';
}
@@ -286,7 +276,7 @@ format_lex (void)
do
{
- c = next_char_not_space (error);
+ c = next_char_not_space ();
if (ISDIGIT (c))
{
value = 10 * value + c - '0';
@@ -321,7 +311,7 @@ format_lex (void)
break;
case 'T':
- c = next_char_not_space (error);
+ c = next_char_not_space ();
switch (c)
{
case 'L':
@@ -349,7 +339,7 @@ format_lex (void)
break;
case 'S':
- c = next_char_not_space (error);
+ c = next_char_not_space ();
if (c != 'P' c != 'S')
unget_char ();
@@ -357,7 +347,7 @@ format_lex (void)
break;
case 'B':
- c = next_char_not_space (error);
+ c = next_char_not_space ();
if (c == 'N' || c == 'Z')
token = FMT_BLANK;
else
@@ -419,7 +409,7 @@ format_lex (void)
break;
case 'E':
- c = next_char_not_space (error);
+ c = next_char_not_space ();
if (c == 'N' )
token = FMT_EN;
else if (c == 'S')
@@ -449,7 +439,7 @@ format_lex (void)
break;
case 'D':
- c = next_char_not_space (error);
+ c = next_char_not_space ();
if (c == 'P')
{
if (!gfc_notify_std (GFC_STD_F2003, DP format
@@ -472,7 +462,7 @@ format_lex (void)
break;
case 'R':
- c = next_char_not_space (error);
+ c = next_char_not_space ();
switch (c)
{
case 'C':
@@ -513,9 +503,6 @@ format_lex (void)
break;
}
- if (error)
-return FMT_ERROR;
-
return token;
}
Index: gcc/testsuite/gfortran.dg/fmt_tab_1.f90
===
--- gcc/testsuite/gfortran.dg/fmt_tab_1.f90(revision 201382)
+++ gcc/testsuite/gfortran.dg/fmt_tab_1.f90(working copy)
@@ -1,6 +1,9 @@
-! { dg-do run }
+! { dg-do compile }
+! { dg-options -Wtabs }
! PR fortran/32987
program TestFormat
write (*, 10)
- 10 format ('Hello ','bug!') ! { dg-warning Extension: Tab character
in format }
+! There is a tab character before 'bug'. This is accepted without
+! the -Wno-tabs option or a -std= option.
+ 10 format ('Hello ','bug!')
end
Index: gcc/testsuite/gfortran.dg/fmt_tab_2.f90
===
--- gcc/testsuite/gfortran.dg/fmt_tab_2.f90(revision 201382)
+++ gcc/testsuite/gfortran.dg/fmt_tab_2.f90(working copy)
@@ -2,6 +2,6 @@
! { dg-options -std=f2003 }
! PR fortran/32987
program TestFormat
-write (*, 10) ! { dg-error FORMAT label 10 at .1. not defined }
- 10 format ('Hello ','bug!') ! { dg-error Extension: Tab character in
format }
+write (*, 10)
+ 10 format ('Hello ','bug!') ! { dg-warning tab character in FORMAT
}
end
[Bug fortran/57306] [OOP] [F08] ICE on valid with class pointer initialization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57306 --- Comment #6 from janus at gcc dot gnu.org --- An updated patch was posted here: http://gcc.gnu.org/ml/fortran/2013-07/msg00135.html
[Bug fortran/57306] [OOP] [F08] ICE on valid with class pointer initialization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57306 --- Comment #7 from janus at gcc dot gnu.org --- Here is a reduced version of the test case from http://gcc.gnu.org/ml/fortran/2013-07/msg00103.html, which for some reason still ICEs: type :: c end type c type(c), target :: x class(c), pointer :: px = x if (.not. associated(px)) call abort() end internal compiler error: in expand_expr_real_1, at expr.c:9361 end ^ 0x764cdd expand_expr_real_1(tree_node*, rtx_def*, machine_mode, expand_modifier, rtx_def**) /home/janus/gcc49/trunk/gcc/expr.c:9356 0x76b7b7 expand_expr /home/janus/gcc49/trunk/gcc/expr.h:444 0x76b7b7 expand_expr_addr_expr_1 /home/janus/gcc49/trunk/gcc/expr.c:7587 0x762a59 expand_expr_addr_expr /home/janus/gcc49/trunk/gcc/expr.c:7710 0x762a59 expand_expr_real_1(tree_node*, rtx_def*, machine_mode, expand_modifier, rtx_def**) /home/janus/gcc49/trunk/gcc/expr.c:10451 0xabcfca expand_expr /home/janus/gcc49/trunk/gcc/expr.h:444 0xabcfca output_constant /home/janus/gcc49/trunk/gcc/varasm.c:4665 0xabcfca output_constant(tree_node*, unsigned long, unsigned int) /home/janus/gcc49/trunk/gcc/varasm.c:4566 0xabdb4b output_constructor_regular_field /home/janus/gcc49/trunk/gcc/varasm.c:4912 0xabdb4b output_constructor /home/janus/gcc49/trunk/gcc/varasm.c:5191 0xac1981 assemble_variable(tree_node*, int, int, int) /home/janus/gcc49/trunk/gcc/varasm.c:2113 0xac2259 varpool_assemble_decl(varpool_node*) /home/janus/gcc49/trunk/gcc/varpool.c:347 0x6d9f12 output_in_order /home/janus/gcc49/trunk/gcc/cgraphunit.c:1788 0x6d9f12 compile() /home/janus/gcc49/trunk/gcc/cgraphunit.c:2024 0x6da184 finalize_compilation_unit() /home/janus/gcc49/trunk/gcc/cgraphunit.c:2106 0x82b04c write_global_declarations() /home/janus/gcc49/trunk/gcc/langhooks.c:322 0x5f82bf gfc_write_global_declarations /home/janus/gcc49/trunk/gcc/fortran/f95-lang.c:263
[Bug c++/57362] [4.8/4.9 Regression] unsupported __attribute__((target())) values appear to cause loop and/or pathological behavior
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57362 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||jason at gcc dot gnu.org Resolution|--- |FIXED --- Comment #7 from Jason Merrill jason at gcc dot gnu.org --- Fixed for 4.8.2 (r201388) and 4.9.
[Bug fortran/57306] [OOP] [F08] ICE on valid with class pointer initialization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57306 --- Comment #8 from janus at gcc dot gnu.org --- (In reply to janus from comment #7) Here is a reduced version of the test case from http://gcc.gnu.org/ml/fortran/2013-07/msg00103.html, which for some reason still ICEs: type :: c end type c type(c), target :: x class(c), pointer :: px = x if (.not. associated(px)) call abort() end Putting this inside a subroutine, one gets: class(c), pointer :: px = x 1 Error: Pointer initialization target at (1) must have the SAVE attribute Giving 'x' the SAVE attribute makes both versions compile without error. I guess the original version is still valid, since 'x' should implicitly get the SAVE attribute [1]. However, without the explicit SAVE declaration, it is not shown as 'static' in the dump. [1] F08, section 5.3.16: A variable, common block, or procedure pointer declared in the scoping unit of a main program, module, or submodule implicitly has the SAVE attribute, which may be confirmed by explicit specification.
[Bug fortran/57306] [OOP] [F08] ICE on valid with class pointer initialization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57306 --- Comment #9 from janus at gcc dot gnu.org --- (In reply to janus from comment #8) Giving 'x' the SAVE attribute makes both versions compile without error. I guess the original version is still valid, since 'x' should implicitly get the SAVE attribute [1]. However, without the explicit SAVE declaration, it is not shown as 'static' in the dump. Problem is: We currently don't make variables in the main program SAVE_IMPLICT yet. There is a patch in PR 55207 comment 3 which does this. Applying it (in addition to the patch from comment 6) makes the ICE in comment 7 go away. Unfortunately it had a couple of regressions, see in particular PR 55207 comment 6.
[Bug fortran/55207] Automatic deallocation of variables declared in the main program
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55207 janus at gcc dot gnu.org changed: What|Removed |Added Status|RESOLVED|REOPENED Last reconfirmed||2013-07-31 Resolution|FIXED |--- Ever confirmed|0 |1 --- Comment #8 from janus at gcc dot gnu.org --- (In reply to janus from comment #7) I think this PR has been fixed by r199643. Reopening. Auto-dealloc has indeed been fixed by the above commit. However, variables in the main program are still not SAVE_IMPLICIT, which makes problems e.g. in PR 57306. I think we need the patch in comment 6 after all. But how do we get rid of the remaining regressions?
[Bug fortran/37336] Fortran 2003: Finish derived-type finalization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37336 Bug 37336 depends on bug 55207, which changed state. Bug 55207 Summary: Automatic deallocation of variables declared in the main program http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55207 What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |---
[Bug target/51244] [SH] Inefficient conditional branch and code around T bit
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51244
--- Comment #65 from Oleg Endo olegendo at gcc dot gnu.org ---
(In reply to Oleg Endo from comment #64)
would be simplified to this:
mov.l @(4,r4),r1
tst r1,r1 // T = @(4,r4) == 0
.L3:
bt/s.L5
mov #1,r1
cmp/hi r1,r5
bf/s.L9
mov #0,r0
rts
nop
.L2:
mov.l @r4,r1
bra .L3
tst r1,r1 // T = @(r4) == 0
Sorry, I got confused. The above is wrong. One of the T bit inversions can't
be eliminated in this case.
It should be:
mov.l @(4,r4),r1
.L3:
tst r1,r1
bt/s.L5
mov #1,r1
cmp/hi r1,r5
bf/s.L9
mov #0,r0
rts
nop
.L2:
mov.l @r4,r1
tst r1,r1
bra .L3
movtr1
Or SH2A:
mov.l @(4,r4),r1
tst r1,r1
.L3:
bt/s.L5
mov #1,r1
cmp/hi r1,r5
bf/s.L9
mov #0,r0
rts
nop
.L2:
mov.l @r4,r1
tst r1,r1
bra .L3
nott
However, my original 'optimized' asm snippet is valid if the reduced test case
is changed to:
static inline int
blk_oversized_queue (int* q)
{
if (q[2])
return q[1] == 0; // instead of != 0
return q[0] == 0;
}
The current trunk version eliminates the movt/tst insns and produces correct
code by accident. It can be simplified even more:
mov.l @(4,r4),r1
.L3:
tst r1,r1
bt/s.L5
mov #1,r1
cmp/hi r1,r5
bf/s.L9
mov #0,r0
rts
nop
.L2:
bra .L3
mov.l @r4,r1
I'm trying to come up with a patch that implements t bit tracing in order to
handle those scenarios.
[Bug c++/17729] [4.7/4.8/4.9 Regression] Duplicate __attribute__((deprecated)) warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17729 --- Comment #29 from Paolo Carlini paolo.carlini at oracle dot com --- Iain?
[Bug rtl-optimization/58034] glibc nptl/tst-cleanup2 fail due to scheduling
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58034
Alan Modra amodra at gmail dot com changed:
What|Removed |Added
Known to work||4.7.2
Known to fail||4.8.1, 4.8.2, 4.9.0
--- Comment #5 from Alan Modra amodra at gmail dot com ---
This somewhat reduced testcase fails with mainline.
#include setjmp.h
#include signal.h
static sigjmp_buf jmpbuf;
static void
sig_handler (int signo)
{
siglongjmp (jmpbuf, 1);
}
int
main (void)
{
char *p = 0;
struct sigaction sa;
sa.sa_handler = sig_handler;
sigemptyset (sa.sa_mask);
sa.sa_flags = SA_SIGINFO;
if (sigaction (SIGSEGV, sa, 0))
return 1;
if (setjmp (jmpbuf))
return 0;
__builtin_memcpy (p, abc, 4);
return 1;
}
[Bug middle-end/57748] [4.8/4.9 Regression] ICE on ARM with -mfloat-abi=softfp -mfpu=neon
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57748 --- Comment #12 from Bernd Edlinger bernd.edlinger at hotmail dot de --- (In reply to Martin Jambor from comment #11) Well, I believe this unaligned arrays are generally broken. consider this example: With or without the patch? If without the patch and you are reasonably confident the output is indeed wrong, please open a new PR (and CC me, I'm interested) because this particular ICE is certainly caused by trailing zero sized arrays. I have tried reproducing your problem with x86_64 MMX vectors but couldn't. I do not have access to an ARM machine to verify myself. Thanks. My example just produces wrong code. I tried everything, trunk with or without the patch does not matter, and it does not hit the ICE at all, but I tried to write the example to go into the if-statement here, and was somehow surprised, it produces wrong code instead. Your example aborts without the patch, and correctly produces 16 strb instructions with the patch. That means that store_field can handle unaligned address in to_rtx in *some* cases. Is this if-statement a work around for something, that should have been fixed in store_field instead? I'm chasing problems with unaligned structures that exist on the ARM GCC but not on Intel. All that started probably in 2011 with GCC 4.6, and meanwhile I'm concerned, because new processors arrive all the time and we must soon fix that or think of alternatives to GCC :-( I started with the discovery that volatile accesses to packed structure members are completely broken: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56341 However this seems to be a similar but completely different bug. I will file it today. PS: If you want to build a cross compiler for ARM, I can help you out with eCos sys-include headers, if that is present in the install tree, the cross-compiler can be built on X86_64 too.
[Bug tree-optimization/58039] New: -ftree-vectorizer make a loop crash on non-aligned memory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58039 Bug ID: 58039 Summary: -ftree-vectorizer make a loop crash on non-aligned memory Product: gcc Version: unknown Status: UNCONFIRMED Severity: major Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: bar at mariadb dot org Created attachment 30578 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30578action=edit The program that repeats the report crash If I compile the attached program using: gcc -Wall -O2 -fno-inline -ftree-vectorize -ftree-vectorizer-verbose=2 a.c it crashes with segmentation fault. $ gcc --version gcc (GCC) 4.7.2 20120921 (Red Hat 4.7.2-2) Processor: Intel® Core™ i7-3520M CPU @ 2.90GHz × 4 The program is a minimal extract from the MariaDB-10.0 sources that reproduces the crash. The GCC flags that are actually used in the debug build of MariaDB are: gcc -Wall -O3 -fno-inline a.c but after tracking it down we noticed that the actually reason is -ftree-vectorize.
[Bug tree-optimization/58039] -ftree-vectorizer make a loop crash on non-aligned memory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58039 --- Comment #1 from Alexander Barkov bar at mariadb dot org --- The bug is known to repeat on the following operating systems: - Fedora 17 - Ubuntu 13.04 - OpenSUSE 11.1
