[Bug tree-optimization/65961] [6 Regression] ice in vect_is_simple_use_1 with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65961 --- Comment #5 from David Binderman --- As of trunk 20150520, this bug looks fixed to me.
[Bug bootstrap/66038] [5 regression] (stage 2) build/genmatch segfaults in operand::gen_transform (gcc/hash-table.h:223)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66038 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #12 from Jakub Jelinek --- hashval_t should be unsigned int? Is it some other type on your host, or is CHAR_BIT bigger than 8, or do you have 64-bit unsigned int?
[Bug bootstrap/66038] [5 regression] (stage 2) build/genmatch segfaults in operand::gen_transform (gcc/hash-table.h:223)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66038
--- Comment #11 from Douglas Mencken ---
Causing commit found.
It is r218976 (e2afa5c10fd41fe708959121f373fcb5435ef5d6). With reverse-applied
r218976's patch, 5.1.0 even reaches "Bootstrap comparison failure!‘‘ ;)
Maybe patch's author [ Author: hubicka ] can help here.
I see in patch:
-hashval_t
-hash_table_mod1 (hashval_t hash, unsigned int index)
-{
- const struct prime_ent *p = &prime_tab[index];
-#ifdef UNSIGNED_64BIT_TYPE
- if (sizeof (hashval_t) * CHAR_BIT <= 32)
-return mul_mod (hash, p->prime, p->inv, p->shift);
-#endif
- return hash % p->prime;
-}
+inline hashval_t
+hash_table_mod1 (hashval_t hash, unsigned int index)
+{
+ const struct prime_ent *p = &prime_tab[index];
+ gcc_checking_assert (sizeof (hashval_t) * CHAR_BIT <= 32);
+return mul_mod (hash, p->prime, p->inv, p->shift);
+}
Before, when "sizeof (hashval_t) * CHAR_BIT <= 32”, hash % p->prime was
returned. After, <= 32 triggers assert (--> failure).
I suggest something like
inline hashval_t
hash_table_mod1 (hashval_t hash, unsigned int index)
{
const struct prime_ent *p = &prime_tab[index];
if (sizeof (hashval_t) * CHAR_BIT <= 32)
return mul_mod (hash, p->prime, p->inv, p->shift);
else
return hash % p->prime;
}
[Bug lto/66180] [6 Regression] many -Wodr false positives when building LLVM with -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66180 --- Comment #7 from Markus Trippelsdorf --- (In reply to Jan Hubicka from comment #6) > Thank you for the testcase! With the fix for anonymous types I don't seem to > get the warnings. Can you, please, check if that works for you and commit > it? I still get the warnings after r223415, but I'm not 100% sure if they are valid or not.
[Bug tree-optimization/65447] AArch64: iv-opt causes bad addressing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65447 --- Comment #3 from amker at gcc dot gnu.org --- Author: amker Date: Wed May 20 05:15:56 2015 New Revision: 223433 URL: https://gcc.gnu.org/viewcvs?rev=223433&root=gcc&view=rev Log: PR tree-optimization/65447 * tree-ssa-loop-ivopts.c (struct iv_use): New fields. (dump_use, dump_uses): Support to dump sub use. (record_use): New parameters to support sub use. Remove call to dump_use. (record_sub_use, record_group_use): New functions. (compute_max_addr_offset, split_all_small_groups): New functions. (group_address_uses, rewrite_use_address): New functions. (strip_offset): New declaration. (find_interesting_uses_address): Call record_group_use. (add_candidate): New assertion. (infinite_cost_p): Move definition forward. (add_costs): Check INFTY cost and return immediately. (get_computation_cost_at): Clear setup cost and dependent bitmap for sub uses. (determine_use_iv_cost_address): Compute cost for sub uses. (rewrite_use_address_1): Rename from old rewrite_use_address. (free_loop_data): Free sub uses. (tree_ssa_iv_optimize_loop): Call group_address_uses. gcc/testsuite PR tree-optimization/65447 * gcc.dg/tree-ssa/pr65447.c: New test. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/pr65447.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-loop-ivopts.c
[Bug c++/66211] New: Rvalue conversion in ternary operator causes internal compiler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66211
Bug ID: 66211
Summary: Rvalue conversion in ternary operator causes internal
compiler error
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: vgheorgh at gmail dot com
Target Milestone: ---
The code below
void f(int&){}
int main()
{
int x = 0;
double y = 1;
f(1 > 0 ? x : y);
}
should not compile, due to rvalue conversion in the ternary operator, then
trying to bind the rvalue to a non-constant reference. However, gcc51 and gcc6
HEAD crash with an internal compiler error
internal compiler error: in convert_like_real, at cp/call.c:6471
gcc49 works (emits an error)
[Bug target/65979] Multiple issues in conftest.c prevent build on sh4-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65979
--- Comment #13 from Kazumoto Kojima ---
Created attachment 35572
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35572&action=edit
reduced testcase
>From rtl dumps for 5.1.0 cc1plus against the testcase, the wrong
peephole transformation makes
(insn 92 14 15 3 (set (reg:SI 1 r1 [orig:171 D.2078 ] [171])
(reg:SI 2 r2 [172])) 252 {movsi_ie}
(expr_list:REG_DEAD (reg:SI 2 r2 [172])
(nil)))
(insn 93 16 83 3 (set (reg:SI 2 r2)
(const_int 66602 [0x1042a])) 252 {movsi_ie}
(nil))
(insn 83 93 18 3 (set (reg:SI 147 t)
(eq:SI (and:SI (reg:SI 1 r1 [orig:171 D.2078 ] [171])
(reg:SI 2 r2))
(const_int 0 [0]))) 1 {tstsi_t}
(expr_list:REG_DEAD (reg:SI 2 r2)
(expr_list:REG_DEAD (reg:SI 1 r1 [orig:171 D.2078 ] [171])
(nil
into
(insn 112 14 113 3 (set (reg:SI 2 r2)
(const_int 66602 [0x1042a])) -1
(nil))
(insn 113 112 114 3 (set (reg:SI 147 t)
(eq:SI (and:SI (reg:SI 2 r2)
(reg:SI 2 r2))
(const_int 0 [0]))) -1
(nil))
(insn 114 113 18 3 (const_int 0 [0]) -1
(nil))
This peephole transformation is done by
;; mov.w @(18,r1),r0 (r0 = HImode)
;; mov r0,r1 (r0 = r1 = HImode) mov.w @(18,r1),r0
;; ... ..,r13 (r13 = SImode) -> ... ..,r13
;; tst r1,r13 tst r0,r13
(define_peephole2
[(set (match_operand 0 "arith_reg_dest")
(match_operand 1 "arith_reg_dest"))
(set (match_operand:SI 2 "arith_reg_dest")
(match_operand:SI 3))
(set (reg:SI T_REG)
(eq:SI (and:SI (match_operand:SI 4 "arith_reg_operand")
(match_operand:SI 5 "arith_reg_operand"))
(const_int 0)))]
"TARGET_SH1
&& peep2_reg_dead_p (3, operands[0])
&& !reg_overlap_mentioned_p (operands[0], operands[3])
&& (REGNO (operands[0]) == REGNO (operands[4])
|| REGNO (operands[0]) == REGNO (operands[5]))
&& (REGNO (operands[2]) == REGNO (operands[4])
|| REGNO (operands[2]) == REGNO (operands[5]))"
[(const_int 0)]
{
sh_check_add_incdec_notes (emit_move_insn (operands[2], operands[3]));
emit_insn (gen_tstsi_t (operands[2],
gen_rtx_REG (SImode, (REGNO (operands[1]);
})
Looks that this doesn't work when the operand 1 is equal to the operand 2
which is the case for the above insns 92, 93 and 83. The peephole
removed with the fix in PR65153 transformed these insns prior to
the above peephole so to avoid the problem. The patch below fixes
this case. It looks there are similar peephole patterns,though.
Oleg, if you get the spare time, could you look into these peepholes?
--
diff --git a/config/sh/sh.md b/config/sh/sh.md
index 27f0074..5bc3401 100644
--- a/config/sh/sh.md
+++ b/config/sh/sh.md
@@ -14750,6 +14750,7 @@ label:
"TARGET_SH1
&& peep2_reg_dead_p (3, operands[0])
&& !reg_overlap_mentioned_p (operands[0], operands[3])
+ && !reg_overlap_mentioned_p (operands[1], operands[2])
&& (REGNO (operands[0]) == REGNO (operands[4])
|| REGNO (operands[0]) == REGNO (operands[5]))
&& (REGNO (operands[2]) == REGNO (operands[4])
[Bug target/65979] Multiple issues in conftest.c prevent build on sh4-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65979 --- Comment #12 from Kazumoto Kojima --- I've looked into which stage2 object was miscompiled with bisecting on objects for 5.1.0 and found tree-cfg.o is the one of them. 5.1.0 cross compiler miscompiles it too and I've got which change causes the problem with bisecting on changes. Surprisingly, it's r220922 for PR target/65153. With reverting it and applying the patch in the trail #c7 in PR65153, stage2 compiler can pass conftest.c issues during configuring target libraries. That patch simply removes a peephole and looked to be safe from wrong code problem. It means that there is another problem elsewhere. I've compared the outputs for tree-cfg.c w/wo that peephole and found that is_ctrl_stmt was miscompiled without that peephole. I'll attach a reduced testcase.
[Bug target/29256] [4.8/4.9/5/6 regression] loop performance regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29256 amker at gcc dot gnu.org changed: What|Removed |Added CC||amker at gcc dot gnu.org --- Comment #52 from amker at gcc dot gnu.org --- I don't understand powerpc assembly well, but this looks like the same problem on aarch64/arm. Ah, and we are even looking at same function... I think this is a general issue caused by inconsistency between tree level ivopt and rtl level loop unroller. To be specific, how we handle unrolled induction variable registers after unrolling. The core loop on aarch64 with options "-O3 -funroll-all-loops -mcpu=cortex-a57" gave below output: .L3: add x2, x0, 16 ldr q16, [x17, x0] add x10, x0, 32 add x9, x0, 48 add x8, x0, 64 ldr q17, [x17, x2] add x3, x0, 80 add x6, x0, 96 add x5, x0, 112 add w1, w1, 8 ldr q19, [x17, x10] cmp w1, w14 ldr q18, [x17, x9] ldr q20, [x17, x8] ldr q21, [x17, x3] ldr q22, [x17, x6] ldr q23, [x17, x5] str q16, [x18, x0] add x0, x0, 128 str q17, [x18, x2] str q19, [x18, x10] str q18, [x18, x9] str q20, [x18, x8] str q21, [x18, x3] str q22, [x18, x6] str q23, [x18, x5] bcc .L3 The tree ivopt dump is quite neat: : # ivtmp.16_28 = PHI # ivtmp.19_42 = PHI vect__4.13_62 = MEM[base: vectp_a.12_58, index: ivtmp.19_42, offset: 0B]; MEM[base: vectp_c.15_63, index: ivtmp.19_42, offset: 0B] = vect__4.13_62; ivtmp.16_25 = ivtmp.16_28 + 1; ivtmp.19_41 = ivtmp.19_42 + 16; if (ivtmp.16_25 < bnd.7_36) goto ; else goto ; ... : goto ; But after rtl unroller, we have options like "-fsplit-ivs-in-unroller" and "-fweb". These two options try to split the long live range of induction vairables into seperated ones. Evetually, with folloing fwprop and IRA, we have multiple ivs for each original iv. I see two possible fixes here. One is to implement a tree level unroller before IVOPT and remove the rtl one. The rtl one is some kind of too aggressive that we didn't enable it by default with "O3". Another is change how we handle unrolled iv in rtl unroller. It splits unrolled iv to avoid pseudo register with long live range since that may affect rtl optimizers. This assumption may hold before, but seems not true to me nowadays, especially for induction variables. Because on tree level ivopts, we already made the assumption that each iv occupies a register, also ivs are intensively used thus should live in one single hard register. For this specific case, we can refactor [base+index] out of memory reference and use [new_base], [new_base+4], [new_base+8], ... etc. in unrolling. If tree ivopts choosses [reg+offset] addressing mode, we only need to generate instruction sequence like "[reg+offset], [reg+(offset+4)], [reg+(offset+8)]... reg = reg + urolled_times*step" Thanks, bin
[Bug c++/65954] gcc segfaults on the following input with a syntax error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65954 --- Comment #1 from Nathan Sidwell --- Author: nathan Date: Wed May 20 01:54:09 2015 New Revision: 223430 URL: https://gcc.gnu.org/viewcvs?rev=223430&root=gcc&view=rev Log: cp/ PR c++/65954 * typeck.c (finish_class_member_access_expr): Diagnose failed lookup of enum class member. testsuite/ * g++.dg/cpp0x/pr65954.C: New. Added: trunk/gcc/testsuite/g++.dg/cpp0x/pr65954.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/typeck.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/65903] [5/6 Regression] Line continuation followed by comment character in string fails to compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65903 Jerry DeLisle changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #10 from Jerry DeLisle --- Fixed on trunk and 5.1. closing
[Bug fortran/65903] [5/6 Regression] Line continuation followed by comment character in string fails to compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65903 --- Comment #9 from Jerry DeLisle --- Author: jvdelisle Date: Wed May 20 01:51:50 2015 New Revision: 223429 URL: https://gcc.gnu.org/viewcvs?rev=223429&root=gcc&view=rev Log: 2015-05-19 Jerry DeLisle PR fortran/65903 * gfortran.dg/continuation_13.f90: Update test. * gfortran.dg/pr65903.f90: New test. Added: branches/gcc-5-branch/gcc/testsuite/gfortran.dg/pr65903.f90 Modified: branches/gcc-5-branch/gcc/testsuite/ChangeLog branches/gcc-5-branch/gcc/testsuite/gfortran.dg/continuation_13.f90
[Bug libstdc++/65913] Linking failure without -latomic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65913 Hans-Peter Nilsson changed: What|Removed |Added CC||hp at gcc dot gnu.org --- Comment #4 from Hans-Peter Nilsson --- (In reply to yan12125 from comment #3) > Sorry, but I don't quite understand. Does that mean for all the future > versions (5.2, 6.0, etc.) -latomic flag is necessary if > atomic::is_lock_free() is used in my program? >From my reading of the comments, the patch and current svn sources, the answer is "no". I'm guessing sooner or later the proposed patch will also be posted to the gcc-patches@ list and promptly reviewed and committed. Then hopefully back-ported in time for 5.2. But that's just a guess.
[Bug fortran/65903] [5/6 Regression] Line continuation followed by comment character in string fails to compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65903 --- Comment #8 from Jerry DeLisle --- Author: jvdelisle Date: Wed May 20 01:50:34 2015 New Revision: 223428 URL: https://gcc.gnu.org/viewcvs?rev=223428&root=gcc&view=rev Log: 2015-05-19 Jerry DeLisle PR fortran/65903 * io.c (format_lex): Change to NONSTRING when checking for possible doubled quote. * scanner.c (gfc_next_char_literal): Revert change from 64506 and add a check for quotes and return. Modified: branches/gcc-5-branch/gcc/fortran/ChangeLog branches/gcc-5-branch/gcc/fortran/io.c branches/gcc-5-branch/gcc/fortran/scanner.c
[Bug middle-end/55035] reload1.c:3766:41: error: ‘orig_dup[0]’ may be used uninitialized in this function (for fr30, microblaze, moxie, rl78)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55035
Mikhail Maltsev changed:
What|Removed |Added
Last reconfirmed|2015-04-09 00:00:00 |2015-5-20
CC||miyuki at gcc dot gnu.org
Known to fail||6.0
--- Comment #5 from Mikhail Maltsev ---
Reduced testcase:
$ cat ./warn2.cc
int arr[1];
int N;
void bar();
void foo()
{
int temp[2];
for (int i = 0; i < N; i++)
temp[i] = arr[i];
bar();
for (int i = 0; i < N; i++)
arr[i] = temp[i];
}
$ /opt/gcc-6.0.0/bin/g++ -c -Wall -O2 -fdump-tree-all ./warn2.cc
./warn2.cc: In function 'void foo()':
./warn2.cc:13:21: warning: 'temp[0]' may be used uninitialized in this function
[-Wmaybe-uninitialized]
arr[i] = temp[i];
$ /opt/gcc-6.0.0/bin/g++ -c -Wall -O2 -fno-tree-sra ./warn2.cc
(no warning)
GCC performs scalar replacement of "temp" and unrolls both loops. N is global
and can be modified by bar(). The final GIMPLE looks like this:
$ cat ./warn2.cc.190t.optimized
void foo() ()
{
int temp$0;
int N.0_18;
int N.0_24;
:
N.0_24 = N;
if (N.0_24 <= 0)
goto ;
else
goto ;
:
temp$0_25 = arr[0];
:
# temp$0_26 = PHI
bar ();
N.0_18 = N;
if (N.0_18 <= 0)
goto ;
else
goto ;
:
arr[0] = temp$0_26;
:
return;
}
Here temp$0_27(D)(2) is the "uninitialized" case. In the original testcase
recog_data.n_dups is considered escaped and orig_dup[0] is treated the same way
as temp[0].
[Bug c++/65835] bootstrap failure: multiple invalid conversions from ‘const char*’ to ‘char*’ [-fpermissive] in winnt.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65835 --- Comment #2 from tbsaunde at gcc dot gnu.org --- Author: tbsaunde Date: Wed May 20 01:03:51 2015 New Revision: 223423 URL: https://gcc.gnu.org/viewcvs?rev=223423&root=gcc&view=rev Log: fixup hash table descriptor in winnt.c gcc/ChangeLog: 2015-05-19 Trevor Saunders PR c++/65835 * config/i386/winnt.c (struct wrapped_symbol_hasher): Change value_type to const char *. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/winnt.c
Message Quarantined: adjustment reminder
Your email sent to disant...@bcbsri.org was not delivered and has been quarantined by Proofpoint because it violated the attachments rule. One or more of the files attached in your email cannot be sent via email. If you believe that this is an error, please contact the BCBSRI service desk.
[Bug c++/66210] Variable template specialization does not work with alias-declarations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66210 Bruno Manganelli changed: What|Removed |Added Severity|minor |normal
[Bug libstdc++/66146] call_once not C++11-compliant on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66146 --- Comment #7 from Martin Sebor --- I opened http://sourceware.org/bugzilla/show_bug.cgi?id=18435 for the glibc bug and attached a lightly tested patch to it.
[Bug c++/66210] New: Variable template specialization does not work with alias-declarations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66210 Bug ID: 66210 Summary: Variable template specialization does not work with alias-declarations Product: gcc Version: 5.1.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: bruno.manga95 at gmail dot com Target Milestone: --- Created attachment 35571 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35571&action=edit testcase In code such as the following, alias-declarations causes a variable to be instantatiated from the non-specialized variable template using resultType = const char*; template T pi = (T)(3.1415926535897932385); template<> resultType pi = "pi"; NOTE: using a typedef does not generate the same error and the code compiles
[Bug c++/61941] Mis-parsing of warn_unused_result function with ref-qualifiers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61941 --- Comment #2 from Thiago Macieira --- ping, any updates?
[Bug libstdc++/38265] STL treats explicit constructors as converting constructors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38265 Geoff Romer changed: What|Removed |Added CC||gromer at google dot com --- Comment #14 from Geoff Romer --- > The C++11 standard clarifies that this is intended to work. The range > constructors require the type to be EmplaceConstructible into the container > from the iterator's value_type But see [sequence.reqmts]/p3: "i and j denote iterators satisfying input iterator requirements and refer to elements implicitly convertible to value_type". So this is not "intended to work" per se; a conforming library could disallow it. However, the notes on LWG 536 say "Some support, not universal, for respecting the explicit qualifier", so it looks like the standard intentionally permits this as a conforming extension. In principle, I think "perfect initialization" is what's called for here: the range ctor should be explicit if and only if it uses an explicit constructor for value_type. However, I doubt it's worth the trouble (OTOH, it definitely will be worth the trouble when/if we get single-argument range constructors).
[Bug lto/66027] lto1: internal compiler error: in odr_types_equivalent_p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66027 --- Comment #9 from Jan Hubicka --- Actually it turns out I already fixed this on mainline. The following hunk should be backported to GCC 5 I guess. Index: ipa-devirt.c === --- ipa-devirt.c(revision 223252) +++ ipa-devirt.c(working copy) @@ -1536,6 +1536,7 @@ odr_types_equivalent_p (tree t1, tree t2 break; } case VOID_TYPE: +case NULLPTR_TYPE: break; default:
[Bug lto/66027] lto1: internal compiler error: in odr_types_equivalent_p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66027 Jan Hubicka changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |hubicka at gcc dot gnu.org --- Comment #8 from Jan Hubicka --- Hmm, type preloading strikes back. We should not try to look into the main variant of VOIDTYPE.
[Bug lto/66180] [6 Regression] many -Wodr false positives when building LLVM with -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66180 --- Comment #6 from Jan Hubicka --- Thank you for the testcase! With the fix for anonymous types I don't seem to get the warnings. Can you, please, check if that works for you and commit it?
[Bug lto/66180] [6 Regression] many -Wodr false positives when building LLVM with -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66180
--- Comment #5 from Markus Trippelsdorf ---
For example:
% cat foo1.cpp
#include
namespace {
class A {
int i;
};
}
class G {
std::unique_ptr foo() const;
};
std::unique_ptr G::foo() const { return std::make_unique(); }
% cat foo2.cpp
#include
namespace {
class A {
bool a;
};
}
class H {
std::unique_ptr bar() const;
};
std::unique_ptr H::bar() const { return std::make_unique(); }
% g++ -flto -shared -std=c++14 foo1.cpp foo2.cpp
/home/trippels/gcc_6/usr/local/include/c++/6.0.0/tuple:102:12: warning: type
‘struct _Head_base’ violates one definition rule [-Wodr]
struct _Head_base<_Idx, _Head, false>
^
/home/trippels/gcc_6/usr/local/include/c++/6.0.0/tuple:102:12: note: a
different type is defined in another translation unit
struct _Head_base<_Idx, _Head, false>
^
/home/trippels/gcc_6/usr/local/include/c++/6.0.0/tuple:147:13: note: the first
difference of corresponding definitions is field ‘_M_head_impl’
_Head _M_head_impl;
^
/home/trippels/gcc_6/usr/local/include/c++/6.0.0/tuple:147:13: note: a field of
same name but different type is defined in another translation unit
_Head _M_head_impl;
^
foo1.cpp:3:7: note: type ‘struct A’ defined in anonymous namespace can not
match type ‘struct A’
class A {
^
foo2.cpp:3:7: note: the incompatible type defined in anonymous namespace in
another translation unit
class A {
^
/home/trippels/gcc_6/usr/local/include/c++/6.0.0/tuple:180:12: warning: type
‘struct _Tuple_impl’ violates one definition rule [-Wodr]
struct _Tuple_impl<_Idx, _Head, _Tail...>
^
/home/trippels/gcc_6/usr/local/include/c++/6.0.0/tuple:180:12: note: a type
with different bases is defined in another translation unit
struct _Tuple_impl<_Idx, _Head, _Tail...>
^
/home/trippels/gcc_6/usr/local/include/c++/6.0.0/tuple:596:11: warning: type
‘struct tuple’ violates one definition rule [-Wodr]
class tuple<_T1, _T2> : public _Tuple_impl<0, _T1, _T2>
^
/home/trippels/gcc_6/usr/local/include/c++/6.0.0/tuple:596:11: note: a type
with different bases is defined in another translation unit
class tuple<_T1, _T2> : public _Tuple_impl<0, _T1, _T2>
^
/home/trippels/gcc_6/usr/local/include/c++/6.0.0/bits/unique_ptr.h:129:11:
warning: type ‘struct unique_ptr’ violates one definition rule [-Wodr]
class unique_ptr
^
/home/trippels/gcc_6/usr/local/include/c++/6.0.0/bits/unique_ptr.h:129:11:
note: a different type is defined in another translation unit
class unique_ptr
^
/home/trippels/gcc_6/usr/local/include/c++/6.0.0/bits/unique_ptr.h:147:57:
note: the first difference of corresponding definitions is field ‘_M_t’
__tuple_type _M_t;
^
/home/trippels/gcc_6/usr/local/include/c++/6.0.0/bits/unique_ptr.h:147:57:
note: a field of same name but different type is defined in another translation
unit
__tuple_type _M_t;
^
/home/trippels/gcc_6/usr/local/include/c++/6.0.0/bits/unique_ptr.h:146:57:
note: type ‘struct __tuple_type’ should match type ‘struct __tuple_type’ that
itself violate one definition rule
typedef std::tuple __tuple_type;
^
/home/trippels/gcc_6/usr/local/include/c++/6.0.0/bits/unique_ptr.h:146:57:
note: the incompatible type is defined here
typedef std::tuple __tuple_type;
^
/home/trippels/gcc_6/usr/local/include/c++/6.0.0/bits/unique_ptr.h:151:41:
warning: type ‘struct element_type’ violates one definition rule [-Wodr]
typedef _Tp element_type;
^
/home/trippels/gcc_6/usr/local/include/c++/6.0.0/bits/unique_ptr.h:151:41:
note: a different type is defined in another translation unit
typedef _Tp element_type;
^
foo1.cpp:4:7: note: the first difference of corresponding definitions is field
‘i’
int i;
^
foo2.cpp:4:8: note: a field with different name is defined in another
translation unit
bool a;
^
[Bug fortran/66193] ICE for initialisation of some non-zero-sized arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66193 --- Comment #9 from Thomas Koenig --- (In reply to Thomas Koenig from comment #8) > This patch looks good: but fixes only the ICE, not the wrong-code issue in comment#1.
[Bug fortran/66193] ICE for initialisation of some non-zero-sized arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66193 --- Comment #8 from Thomas Koenig --- This patch looks good: --- arith.c (Revision 223202) +++ arith.c (Arbeitskopie) @@ -1390,6 +1390,12 @@ reduce_binary (arith (*eval) (gfc_expr *, gfc_expr if (op1->expr_type == EXPR_CONSTANT && op2->expr_type == EXPR_CONSTANT) return eval (op1, op2, result); + if (op1->expr_type == EXPR_ARRAY) +gfc_check_constructor_type (op1); + + if (op2->expr_type == EXPR_ARRAY) +gfc_check_constructor_type (op2); + if (op1->expr_type == EXPR_CONSTANT && op2->expr_type == EXPR_ARRAY) return reduce_binary_ca (eval, op1, op2, result);
[Bug target/62231] [4.8/4.9 regression] Exception handling broken on powerpc-e500v2-linux-gnuspe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62231 --- Comment #15 from joseph at codesourcery dot com --- Any problem seen on 603e is a different issue from this (fixed) e500-specific issue and should not be discussed in this bug.
[Bug fortran/66193] ICE for initialisation of some non-zero-sized arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66193
--- Comment #7 from Steve Kargl ---
On Tue, May 19, 2015 at 06:30:57PM +, tkoenig at gcc dot gnu.org wrote:
> The problem manifests itself in reduce_binary_ca. This function
> gets handed an array constructor of type real whose elements are
> integer. This makes no sense.
>
> (gdb) p *op1
> $6 = {expr_type = EXPR_CONSTANT, ts = {type = BT_REAL, kind = 4,
> ...
>
> (gdb) p *op2
> $7 = {expr_type = EXPR_ARRAY, ts = {type = BT_REAL, kind = 4, u = {derived =
> 0x0, cl = 0x0, pad = 0},
>
> ...
>
> (gdb) p *(c->expr)
> $9 = {expr_type = EXPR_CONSTANT, ts = {type = BT_INTEGER, kind = 4, u =
> {derived = 0x0, cl = 0x0,
>
> So the real error is somewhere else.
>
I suspect that we are missing an explicit type conversion step.
In array.c(gfc_match_array_constructor), we have code starting
at line 1141
/* Size must be calculated at resolution time. */
if (seen_ts)
{
expr = gfc_get_array_expr (ts.type, ts.kind, &where);
expr->ts = ts;
}
else
expr = gfc_get_array_expr (BT_UNKNOWN, 0, &where);
I wonder if we should walk the array and do a conversion after
setting 'expr->ts = ts'.
[Bug fortran/66106] ICE on incomplete interface operator block (gfc_op2string)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66106 kargl at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |5.2 --- Comment #3 from kargl at gcc dot gnu.org --- Fixed on trunk and 5-branch. Thanks for the bug report.
[Bug fortran/66106] ICE on incomplete interface operator block (gfc_op2string)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66106 --- Comment #2 from kargl at gcc dot gnu.org --- Author: kargl Date: Tue May 19 18:34:55 2015 New Revision: 223411 URL: https://gcc.gnu.org/viewcvs?rev=223411&root=gcc&view=rev Log: Fix the ChangeLog entries to have the correct PR fortran/66106 designation. Modified: branches/gcc-5-branch/gcc/fortran/ChangeLog branches/gcc-5-branch/gcc/testsuite/ChangeLog
[Bug fortran/66057] ICE for incomplete generic statement (gfc_match_generic)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66057 --- Comment #6 from kargl at gcc dot gnu.org --- Author: kargl Date: Tue May 19 18:31:39 2015 New Revision: 223410 URL: https://gcc.gnu.org/viewcvs?rev=223410&root=gcc&view=rev Log: 2015-05-19 Steven G. Kargl PR fortran/66057 * interface.c(gfc_match_end_interface): Enforce F2008 C1202 (R1201). * match.c(gfc_op2string): Return 'none' for INTRINSIC_NONE. 2015-05-19 Steven G. Kargl PR fortran/66057 * gfortran.dg/interface_operator_1.f90: New tests. Added: branches/gcc-5-branch/gcc/testsuite/gfortran.dg/interface_operator_1.f90 Modified: branches/gcc-5-branch/gcc/fortran/ChangeLog branches/gcc-5-branch/gcc/fortran/interface.c branches/gcc-5-branch/gcc/fortran/match.c branches/gcc-5-branch/gcc/testsuite/ChangeLog
[Bug fortran/66193] ICE for initialisation of some non-zero-sized arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66193 Thomas Koenig changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-05-19 Ever confirmed|0 |1 --- Comment #5 from Thomas Koenig --- This does not fail: ig25@linux-fd1f:~/Krempel/Constructor> cat gar.f90 program p real :: z(2) z = [real :: 1, 2] + 1 print *,z end ig25@linux-fd1f:~/Krempel/Constructor> gfortran gar.f90 ig25@linux-fd1f:~/Krempel/Constructor> ./a.out 1. 2.
[Bug fortran/66193] ICE for initialisation of some non-zero-sized arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66193
--- Comment #6 from Thomas Koenig ---
The problem manifests itself in reduce_binary_ca. This function gets handed an
array constructor of type real whose elements are integer. This makes no
sense.
(gdb) p *op1
$6 = {expr_type = EXPR_CONSTANT, ts = {type = BT_REAL, kind = 4,
...
(gdb) p *op2
$7 = {expr_type = EXPR_ARRAY, ts = {type = BT_REAL, kind = 4, u = {derived =
0x0, cl = 0x0, pad = 0},
...
(gdb) p *(c->expr)
$9 = {expr_type = EXPR_CONSTANT, ts = {type = BT_INTEGER, kind = 4, u =
{derived = 0x0, cl = 0x0,
So the real error is somewhere else.
[Bug fortran/66057] ICE for incomplete generic statement (gfc_match_generic)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66057 kargl at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |5.2 --- Comment #5 from kargl at gcc dot gnu.org --- Fixed on trunk and 5-branch. Thanks for the bug report.
[Bug gcov-profile/66209] New: Out of memory when compiling with --coverage and optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66209
Bug ID: 66209
Summary: Out of memory when compiling with --coverage and
optimizations
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: gcov-profile
Assignee: unassigned at gcc dot gnu.org
Reporter: wellnhofer at aevum dot de
Target Milestone: ---
Created attachment 35570
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35570&action=edit
Problematic source file
Compiling the attached file `scanners.c` with --coverage and -O1 or -O2 results
in:
$ gcc -O1 --coverage -c scanners.c
cc1: out of memory allocating 4064 bytes after a total of 2528780288 bytes
I'm using gcc 4.9.1 shipped with Ubuntu 14.10.
The source file contains a single function generated with re2c from the
following input:
// Try to match email autolink after first <, returning num of chars matched.
int _scan_autolink_email(const unsigned char *p)
{
const unsigned char *marker = NULL;
const unsigned char *start = p;
/*!re2c
[a-zA-Z0-9.!#$%&'*+/=?^_`{|}~-]+
[@]
[a-zA-Z0-9]([a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?
([.][a-zA-Z0-9]([a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?)*
[>] { return (p - start); }
.? { return 0; }
*/
}
[Bug fortran/66057] ICE for incomplete generic statement (gfc_match_generic)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66057 --- Comment #4 from kargl at gcc dot gnu.org --- Author: kargl Date: Tue May 19 18:20:12 2015 New Revision: 223409 URL: https://gcc.gnu.org/viewcvs?rev=223409&root=gcc&view=rev Log: 2015-05-19 Steven G. Kargl PR fortran/66057 * decl.c(gfc_match_generic): Detected a malformed GENERIC statement. 2015-05-19 Steven G. Kargl PR fortran/66057 * gfortran.dg/generic_29.f90: New tests. Added: branches/gcc-5-branch/gcc/testsuite/gfortran.dg/generic_29.f90 Modified: branches/gcc-5-branch/gcc/fortran/ChangeLog branches/gcc-5-branch/gcc/fortran/decl.c branches/gcc-5-branch/gcc/testsuite/ChangeLog
[Bug fortran/66052] Segmentation fault for misplaced protected statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66052 kargl at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |5.2 --- Comment #4 from kargl at gcc dot gnu.org --- Fixed on trunk and 5-branch. Thanks for the bug report.
[Bug fortran/66052] Segmentation fault for misplaced protected statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66052 --- Comment #3 from kargl at gcc dot gnu.org --- Author: kargl Date: Tue May 19 18:10:44 2015 New Revision: 223408 URL: https://gcc.gnu.org/viewcvs?rev=223408&root=gcc&view=rev Log: 2015-05-19 Steven G. Kargl PR fortran/66052 * decl.c(gfc_match_protected): Prevent dereference of NULL pointer. 2015-05-19 Steven G. Kargl PR fortran/66052 * gfortran.dg/protected_9.f90: New test. Added: branches/gcc-5-branch/gcc/testsuite/gfortran.dg/protected_9.f90 Modified: branches/gcc-5-branch/gcc/fortran/ChangeLog branches/gcc-5-branch/gcc/fortran/decl.c branches/gcc-5-branch/gcc/testsuite/ChangeLog
[Bug fortran/66182] Unneeded temporary for elemental functions of function results
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66182 --- Comment #1 from Thomas Koenig --- Of course, this only works if the types of the elemental function and the function itself match.
[Bug fortran/66045] ICE on incorrect code with null
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66045 kargl at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |5.2 --- Comment #4 from kargl at gcc dot gnu.org --- Fixed on trunk and 5-branch. Thanks for the bug report.
[Bug fortran/66044] ICE on misplaced entry statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66044 kargl at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |5.2 --- Comment #5 from kargl at gcc dot gnu.org --- Fixed on trunk and 5-branch. Thanks for the bug report.
[Bug fortran/66043] ICE on storage_size of null or output of null array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66043 kargl at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |5.2 --- Comment #6 from kargl at gcc dot gnu.org --- Fixed on trunk and 5-branch. Thanks for the bug report.
[Bug target/62231] [4.8/4.9 regression] Exception handling broken on powerpc-e500v2-linux-gnuspe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62231 Andri Yngvason changed: What|Removed |Added CC||andri.yngvason at marel dot com --- Comment #14 from Andri Yngvason --- I have the same problem with 5.1 on a 603e, even though the patches from comment #4 seem to have been applied. I get the same stack trace as seen in comment #3. It doesn't matter whether I compile with --with-cpu=603e or without.
[Bug fortran/66045] ICE on incorrect code with null
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66045 --- Comment #3 from kargl at gcc dot gnu.org --- Author: kargl Date: Tue May 19 17:59:58 2015 New Revision: 223406 URL: https://gcc.gnu.org/viewcvs?rev=223406&root=gcc&view=rev Log: 2015-05-19 Steven G. Kargl PR fortran/66045 * expr.c (gfc_check_assign): Check for assignment of NULL() instead of the (intended) pointer assignment. 2015-05-19 Steven G. Kargl PR fortran/66045 * gfortran.dg/null1.f90: New test. Added: branches/gcc-5-branch/gcc/testsuite/gfortran.dg/null1.f90 Modified: branches/gcc-5-branch/gcc/fortran/ChangeLog branches/gcc-5-branch/gcc/fortran/expr.c branches/gcc-5-branch/gcc/testsuite/ChangeLog
[Bug lto/66180] [6 Regression] many -Wodr false positives when building LLVM with -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66180
--- Comment #4 from Jan Hubicka ---
/home/trippels/gcc_6/usr/local/include/c++/6.0.0/bits/stl_pair.h:96:12:
warning: type ‘struct pair’ violates one definition rule [-Wodr]
struct pair
^
/home/trippels/gcc_6/usr/local/include/c++/6.0.0/bits/stl_pair.h:96:12: note: a
different type is defined in another translation unit
struct pair
^
/home/trippels/gcc_6/usr/local/include/c++/6.0.0/bits/stl_pair.h:102:11: note:
the first difference of corresponding definitions is field ‘second’
_T2 second;/// @c second is a copy of the second object
^
/home/trippels/gcc_6/usr/local/include/c++/6.0.0/bits/stl_pair.h:102:11: note:
a field of same name but different type is defined in another translation unit
_T2 second;/// @c second is a copy of the second object
^
/home/trippels/llvm/tools/clang/utils/TableGen/ClangDiagnosticsEmitter.cpp:131:10:
note: type ‘struct GroupInfo’ defined in anonymous namespace can not match type
‘struct GroupInfo’
struct GroupInfo {
^
/home/trippels/llvm/tools/clang/utils/TableGen/ClangSACheckersEmitter.cpp:73:8:
note: the incompatible type defined in anonymous namespace in another
translation unit
struct GroupInfo {
^
This looks like a real LLVM bug. If you do
class bar {
anonymous_namespace_type foo;
}
then definin bar in non-anonymous namespace in more than one unit is ODR
violation (because the type of field FOO is different in each of units). I
think that it is what the warning is about: the instantiation is non-anonymous
of type _T2=GroupInfo that is anonymous.
[Bug target/29256] [4.8/4.9/5/6 regression] loop performance regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29256
--- Comment #51 from Jeffrey A. Law ---
Configure for powerpc-linux-gnuspec target with the --eanble-e500_double
option:
/home/gcc/GIT-2/gcc/configure powerpc-linux-gnuspe --enable-e500_double
Testcase:
# define N 200
extern double a[N],c[N];
void tuned_STREAM_Copy()
{
int j;
for (j=0; j
[Bug fortran/66044] ICE on misplaced entry statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66044 --- Comment #4 from kargl at gcc dot gnu.org --- Author: kargl Date: Tue May 19 17:47:12 2015 New Revision: 223405 URL: https://gcc.gnu.org/viewcvs?rev=223405&root=gcc&view=rev Log: 2015-05-19 Steven G. Kargl PR fortran/66044 * decl.c(gfc_match_entry): Change a gfc_internal_error() into a gfc_error() 2015-05-19 Steven G. Kargl PR fortran/66044 * gfortran.dg/entry_21.f90: New test. Added: branches/gcc-5-branch/gcc/testsuite/gfortran.dg/entry_21.f90 Modified: branches/gcc-5-branch/gcc/fortran/ChangeLog branches/gcc-5-branch/gcc/fortran/decl.c branches/gcc-5-branch/gcc/testsuite/ChangeLog
[Bug fortran/66043] ICE on storage_size of null or output of null array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66043 --- Comment #5 from kargl at gcc dot gnu.org --- Author: kargl Date: Tue May 19 17:37:42 2015 New Revision: 223401 URL: https://gcc.gnu.org/viewcvs?rev=223401&root=gcc&view=rev Log: 2015-05-19 Steven G. Kargl PR fortran/66043 * check.c (gfc_check_storage_size): Prevent the direct use of NULL() in STORAGE_SIZE() reference. 2015-05-19 Steven G. Kargl PR fortran/66043 * gfortran.dg/storage_size_6.f90: New tests. Added: branches/gcc-5-branch/gcc/testsuite/gfortran.dg/storage_size_6.f90 Modified: branches/gcc-5-branch/gcc/fortran/ChangeLog branches/gcc-5-branch/gcc/fortran/check.c branches/gcc-5-branch/gcc/testsuite/ChangeLog
[Bug libstdc++/66146] call_once not C++11-compliant on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66146 --- Comment #6 from Andrey V --- Same failure on s390x.
[Bug fortran/66040] ICE on misplaced sequence in function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66040 kargl at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |5.2 --- Comment #7 from kargl at gcc dot gnu.org --- Fixed on trunk and 5-branch. Thanks for the bug report.
[Bug fortran/66040] ICE on misplaced sequence in function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66040 --- Comment #6 from kargl at gcc dot gnu.org --- Author: kargl Date: Tue May 19 17:25:09 2015 New Revision: 223394 URL: https://gcc.gnu.org/viewcvs?rev=223394&root=gcc&view=rev Log: 2015-05-19 Steven G. Kargl PR fortran/66040 * parse.c(verify_st_order): Replace a gfc_internal_error with your generic gfc_error. 2015-05-19 Steven G. Kargl PR fortran/66040 * gfortran.dg/misplaced_statement.f90: New test. Added: branches/gcc-5-branch/gcc/testsuite/gfortran.dg/misplaced_statement.f90 Modified: branches/gcc-5-branch/gcc/fortran/ChangeLog branches/gcc-5-branch/gcc/fortran/parse.c branches/gcc-5-branch/gcc/testsuite/ChangeLog
[Bug fortran/66039] ICE on incomplete parentheses at rewind, flush, endfile, backspace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66039 kargl at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |5.2 --- Comment #4 from kargl at gcc dot gnu.org --- Fixed on trunk and 5-branch. Thanks for the bug report.
[Bug fortran/66039] ICE on incomplete parentheses at rewind, flush, endfile, backspace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66039 --- Comment #3 from kargl at gcc dot gnu.org --- Author: kargl Date: Tue May 19 17:13:02 2015 New Revision: 223390 URL: https://gcc.gnu.org/viewcvs?rev=223390&root=gcc&view=rev Log: 2015-05-19 Steven G. Kargl PR fortran/66039 * io.c (match_filepos): Check for incomplete/mangled REWIND, FLUSH, BACKSPACE, and ENDFILE statements 2015-05-19 Steven G. Kargl PR fortran/66039 * gfortran.dg/filepos1.f90: New test Added: branches/gcc-5-branch/gcc/testsuite/gfortran.dg/filepos1.f90 Modified: branches/gcc-5-branch/gcc/fortran/ChangeLog branches/gcc-5-branch/gcc/fortran/io.c branches/gcc-5-branch/gcc/testsuite/ChangeLog
[Bug fortran/64925] ICE with same names for dummy arg and internal procedure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64925 kargl at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |5.2 --- Comment #5 from kargl at gcc dot gnu.org --- Fixed on trunk and 5-branch. Thaks for the bug report.
[Bug fortran/64925] ICE with same names for dummy arg and internal procedure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64925 --- Comment #4 from kargl at gcc dot gnu.org --- Author: kargl Date: Tue May 19 17:01:25 2015 New Revision: 223388 URL: https://gcc.gnu.org/viewcvs?rev=223388&root=gcc&view=rev Log: 2015-05-19 Steven G. Kargl PR fortran/64925 * symbol.c(check_conflict): Check for a conflict between a dummy argument and an internal procedure name. 2015-05-19 Steven G. Kargl PR fortran/64925 * gfortran.dg/pr64925.f90: New test. Added: branches/gcc-5-branch/gcc/testsuite/gfortran.dg/pr64925.f90 Modified: branches/gcc-5-branch/gcc/fortran/ChangeLog branches/gcc-5-branch/gcc/fortran/symbol.c branches/gcc-5-branch/gcc/testsuite/ChangeLog
[Bug target/66201] [avr] ICE in avr_print_operand: Bad address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66201 --- Comment #2 from Georg-Johann Lay --- In short: If avr we should skip that test, or at least remove code which is using that function, e.g. #ifdef __AVR__.
[Bug target/66201] [avr] ICE in avr_print_operand: Bad address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66201 --- Comment #1 from Georg-Johann Lay --- IMO using operands attached to "m" constraint in the asm template is no valid avr code. You can never know the matching instructions because "m" is too generic: Use LD, LD+ or LDS? The only valid use of that constraint on avr is to indicate that respective memory is clobbererd by means of "+m". To perform the respective change, however, you'll need the address in a register, i.e. "b" or similar, or you know in advance that the address is known at link time an may use "s" etc. Moreover the insn itself is invalid because we don't have DImode support in the avr backend.
[Bug middle-end/66199] [4.9/5 Regression] lastprivate/linear clause issues on combined constructs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66199 --- Comment #1 from Jakub Jelinek --- Author: jakub Date: Tue May 19 16:16:15 2015 New Revision: 223387 URL: https://gcc.gnu.org/viewcvs?rev=223387&root=gcc&view=rev Log: PR middle-end/66199 * tree.h (OMP_TEAMS_COMBINED): Define. * gimplify.c (enum gimplify_omp_var_data): Add GOVD_LINEAR_LASTPRIVATE_NO_OUTER. (enum omp_region_type): Add ORT_COMBINED_TEAMS. (omp_notice_variable): Accept both ORT_TEAMS and ORT_COMBINED_TEAMS. Don't recurse if GOVD_LINEAR_LASTPRIVATE_NO_OUTER is set and either GOVD_LINEAR is set, or GOVD_LASTPRIVATE without GOVD_FIRSTPRIVATE. (omp_no_lastprivate): New function. (gimplify_scan_omp_clauses): For OMP_CLAUSE_LASTPRIVATE and OMP_CLAUSE_LINEAR, if omp_no_lastprivate, don't notice_outer and set appropriate bits, otherwise make sure default(none) combined constructs won't complain. (gimplify_adjust_omp_clauses): Remove OMP_CLAUSE_LINEAR outer special casing, for OMP_CLAUSE_LASTPRIVATE if omp_no_lastprivate either remove the clause or turn it into OMP_CLAUSE_PRIVATE. (gimplify_omp_for): Fix up handling of implicit lastprivate or linear iterators. (gimplify_omp_workshare): For OMP_TEAMS_COMBINED use ORT_COMBINED_TEAMS. * omp-low.c (lower_omp_for_lastprivate): For combined for simd use fd.loop.n2 from the for rather than simd. gcc/c/ * c-parser.c (c_parser_omp_for_loop): Don't add OMP_CLAUSE_SHARED to OMP_PARALLEL_CLAUSES when moving OMP_CLAUSE_LASTPRIVATE clause to OMP_FOR_CLAUSES. (c_parser_omp_teams): Set OMP_TEAMS_COMBINED for combined constructs. gcc/cp/ * parser.c (cp_parser_omp_for_loop): Don't add OMP_CLAUSE_SHARED to OMP_PARALLEL_CLAUSES when moving OMP_CLAUSE_LASTPRIVATE clause to OMP_FOR_CLAUSES. (cp_parser_omp_teams): Set OMP_TEAMS_COMBINED for combined constructs. gcc/fortran/ * trans-openmp.c (gfc_trans_omp_teams): Set OMP_TEAMS_COMBINED for combined constructs. (gfc_trans_omp_target): Make sure BIND_EXPR has non-NULL BIND_EXPR_BLOCK. libgomp/ * testsuite/libgomp.c/pr66199-1.c: New test. * testsuite/libgomp.c/pr66199-2.c: New test. * testsuite/libgomp.c++/pr66199-1.C: New test. * testsuite/libgomp.c++/pr66199-2.C: New test. * testsuite/libgomp.fortran/pr66199-1.f90: New test. * testsuite/libgomp.fortran/pr66199-2.f90: New test. Added: trunk/libgomp/testsuite/libgomp.c++/pr66199-1.C trunk/libgomp/testsuite/libgomp.c++/pr66199-2.C trunk/libgomp/testsuite/libgomp.c/pr66199-1.c trunk/libgomp/testsuite/libgomp.c/pr66199-2.c trunk/libgomp/testsuite/libgomp.fortran/pr66199-1.f90 trunk/libgomp/testsuite/libgomp.fortran/pr66199-2.f90 Modified: trunk/gcc/ChangeLog trunk/gcc/c/ChangeLog trunk/gcc/c/c-parser.c trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-openmp.c trunk/gcc/gimplify.c trunk/gcc/omp-low.c trunk/gcc/tree.h trunk/libgomp/ChangeLog
[Bug rtl-optimization/66207] Switch alpha to LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66207 --- Comment #3 from Uroš Bizjak --- Created attachment 35569 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35569&action=edit Preprocessed source $ cc1plus -O2 -fpreprocessed -quiet -o macro.s macro.ii
[Bug rtl-optimization/66207] Switch alpha to LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66207
--- Comment #2 from Uroš Bizjak ---
The patched gcc (the patch from Comment #1) bootstrap went all the way to stage
2, where it crashed on attached source when building libcpp with:
/space/homedirs/uros/gcc-svn/trunk/libcpp/macro.c: In function ‘const
cpp_token* cpp_get_token_1(cpp_reader*, source_location*)’:
/space/homedirs/uros/gcc-svn/trunk/libcpp/macro.c:2568:1: internal compiler
error: Max. number of generated reload insns per insn is achieved (90)
}
^
0x120cfd257 lra_constraints(bool)
/space/homedirs/uros/gcc-svn/trunk/gcc/lra-constraints.c:4379
0x120cdd6fb lra(_IO_FILE*)
/space/homedirs/uros/gcc-svn/trunk/gcc/lra.c:2320
0x120c62b77 do_reload
/space/homedirs/uros/gcc-svn/trunk/gcc/ira.c:5418
0x120c632af execute
/space/homedirs/uros/gcc-svn/trunk/gcc/ira.c:5589
Please submit a full bug report,
The crash can be reproduced with a crosscompiler from x86_64-linux-gnu,
configured with "--target=alpha-linux-gnu --enable-languages=c,c++"
$ cc1plus -O2 -fpreprocessed -o macro.o macro.ii
/space/homedirs/uros/gcc-svn/trunk/libcpp/macro.c: In function ‘const
cpp_token* cpp_get_token_1(cpp_reader*, source_location*)’:
/space/homedirs/uros/gcc-svn/trunk/libcpp/macro.c:2568:1: internal compiler
error: Max. number of generated reload insns per insn is achieved (90)
0xa9b474 lra_constraints(bool)
/home/uros/gcc-svn/trunk/gcc/lra-constraints.c:4379
0xa87e4c lra(_IO_FILE*)
/home/uros/gcc-svn/trunk/gcc/lra.c:2320
0xa49929 do_reload
/home/uros/gcc-svn/trunk/gcc/ira.c:5418
0xa49929 execute
/home/uros/gcc-svn/trunk/gcc/ira.c:5589
Please submit a full bug report,
(gdb) up
#1 0x00a9b475 in lra_constraints (first_p=true) at
/home/uros/gcc-svn/trunk/gcc/lra-constraints.c:4379
4379 MAX_RELOAD_INSNS_NUMBER);
(gdb) p curr_insn
$1 = (rtx_insn *) 0x713d5fc0
(gdb) p debug_rtx (curr_insn)
(insn 973 639 972 89 (set (reg:QI 539 [183])
(reg:QI 183))
/space/homedirs/uros/gcc-svn/trunk/libcpp/macro.c:2566 229 {*movqi}
(nil))
The end of reload dump shows this sequence:
Choosing alt 0 in insn 643: (0) =r (1) r {zero_extendqidi2}
Creating newreg=449 from oldreg=183, assigning class GENERAL_REGS to r449
643: r427:SI#0=zero_extend(r449:QI)
REG_DEAD r183:QI
Inserting insn reload before:
883: r449:QI=r183:QI
0 Non pseudo reload: reject++
alt=0,overall=607,losers=1,rld_nregs=1
0 Non pseudo reload: reject++
alt=1: Bad operand -- refuse
Choosing alt 0 in insn 883: (0) =r (1) rJ {*movqi}
Creating newreg=450 from oldreg=183, assigning class GENERAL_REGS to r450
883: r449:QI=r450:QI
Inserting insn reload before:
884: r450:QI=r183:QI
[Bug rtl-optimization/66207] Switch alpha to LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66207 --- Comment #1 from Uroš Bizjak --- Created attachment 35568 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35568&action=edit Current middle-end + target enablement patch Vladimir's patch to enhance simplify_operand_subreg for WORD_REGISTER_OPERATION targets.
[Bug rtl-optimization/66207] Switch alpha to LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66207 Uroš Bizjak changed: What|Removed |Added Keywords||ra Status|UNCONFIRMED |NEW Last reconfirmed||2015-05-19 CC||rth at gcc dot gnu.org, ||vmakarov at gcc dot gnu.org Depends on||57032 Target Milestone|--- |6.0 Ever confirmed|0 |1 Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57032 [Bug 57032] [4.9/5/6 Regression]: internal compiler error: Max. number of generated reload insns per insn is achieved (90)
[Bug rtl-optimization/66207] New: Switch alpha to LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66207 Bug ID: 66207 Summary: Switch alpha to LRA Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: ubizjak at gmail dot com Target Milestone: --- Tracker PR to track the progress towards enabling LRA on alpha
[Bug rtl-optimization/66206] Address of stack memory associated with local variable returned to caller
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66206 --- Comment #1 from Andrew Pinski --- Doubt it unless what is passed in here was a reg rtx which I highly doubt it.
[Bug c/66208] New: macro location not detected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66208
Bug ID: 66208
Summary: macro location not detected
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: manu at gcc dot gnu.org
Target Milestone: ---
From: https://gcc.gnu.org/ml/gcc-help/2015-05/msg00082.html
void foox (char*, ...) __attribute__ ((nonnull (1)));
#define foo(p) foox (p, "p is null")
#define bar(p) _Static_assert (p, "p is null")
void baz (void) {
foox (0, "p is null");
foo (0);
bar (0);
}
This should print:
test.c:2:16: warning: null argument where non-null required (argument 1)
[-Wnonnull]
#define foo(p) foox (p, "p is null")
^
test.c:7:3: note: in expansion of macro ‘foo’
foo (0);
^
but for some reason, the input_location at the time of warning is not a virtual
location coming from a macro map. It seems that input_location is not adjusted
correctly before giving this warning
test.c:6:3: warning: null argument where non-null required (argument 1)
[-Wnonnull]
(foox (0, "p is null"));
^
test.c:7:3: warning: null argument where non-null required (argument 1)
[-Wnonnull]
(foo (0));
^
and it always points to the first location given in the line, which was never
updated to be a macro location.
[Bug target/65837] [arm-linux-gnueabihf] lto1 target specific builtin not available
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65837
--- Comment #28 from Ramana Radhakrishnan ---
(In reply to chrbr from comment #27)
> >
> > Should be reproducible without LTO with
> >
> > int __attribute__((target("fpu=neon"))) main()
> > {
> > ...
> > }
> >
> > and compiling without -mfpu=neon.
> >
>
> note that #include "arm_neon.h" can't be preprocessed and that the builtins
> are not recognized without a global flag:
>
> "arm_neon.h:31:2: error: #error You must enable NEON instructions (e.g.
> -mfloat-abi=softfp -mfpu=neon) to use arm_neon.h"
>
> A further improvement for that might be to set the attribute for all the
> functions defines in neon.h and remove the #error check.
>
> e.g:
>
> __extension__ static __inline float32x2_t
> __attribute__ ((__always_inline__))
> __attribute__((target("fpu=neon")))
> vadd_f32 (float32x2_t __a, float32x2_t __b)
> {
> return (float32x2_t) __builtin_neon_vaddv2sf (__a, __b);
> }
>
> or use a #pragma target (("mfpu=neon")) region.
The #pragma is what I would expect.
[Bug tree-optimization/65752] Too strong optimizations int -> pointer casts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65752
--- Comment #24 from Chung-Kil Hur ---
(In reply to schwab from comment #23)
> "gil.hur at sf dot snu.ac.kr" writes:
>
> > Since "hello" is not printed, I think the if-statement is the same as no-op.
> > Thus, removing the if-statement should not change the behavior of the
> > program
> > according to ISO C11.
>
> Unless you are invoking undefined behaviour.
>
> Andreas.
==
#include
int main() {
int x = 0;
uintptr_t xp = (uintptr_t) &x;
uintptr_t i, j;
for (i = 0; i < xp; i++) { }
j = i;
*(int*)((xp+i)-j) = 15;
printf("%d\n", x);
}
=
This prints "15".
And I do not think there is any UB.
Please correct me if I am wrong.
Then, I add the if-statement.
==
#include
int main() {
int x = 0;
uintptr_t xp = (uintptr_t) &x;
uintptr_t i, j;
for (i = 0; i < xp; i++) { }
j = i;
/** begin ***/
if (j != xp) {
printf("hello\n");
j = xp;
}
/** end */
*(int*)((xp+i)-j) = 15;
printf("%d\n", x);
}
=
This prints "0" without printing "hello".
Thus, this raises no UB unless "j != xp" raises UB.
If you think "j != xp" raises UB, please explain why and give some reference.
Otherwise, I think it is a bug of GCC.
[Bug tree-optimization/65752] Too strong optimizations int -> pointer casts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65752 --- Comment #23 from schwab at suse dot de --- "gil.hur at sf dot snu.ac.kr" writes: > Since "hello" is not printed, I think the if-statement is the same as no-op. > Thus, removing the if-statement should not change the behavior of the program > according to ISO C11. Unless you are invoking undefined behaviour. Andreas.
[Bug rtl-optimization/66206] New: Address of stack memory associated with local variable returned to caller
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66206
Bug ID: 66206
Summary: Address of stack memory associated with local variable
returned to caller
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: hiraditya at msn dot com
Target Milestone: ---
Clang static analyzer reported this potential bug.
File: gcc/bt-load.c
Location: line 234, column 6
Description:Address of stack memory associated with local variable 'x'
returned to caller
220 static rtx *
221 find_btr_use (rtx x, rtx *excludep = 0)
222 {
223 subrtx_ptr_iterator::array_type array;
224 FOR_EACH_SUBRTX_PTR (iter, array, &x, NONCONST)
225 {
226 rtx *loc = *iter;
227 if (loc == excludep)
228 iter.skip_subrtxes ();
229 else
230 {
231 const_rtx x = *loc;
232 if (REG_P (x)
233 && overlaps_hard_reg_set_p (all_btrs, GET_MODE (x), REGNO (x)))
234 return loc; // <- Address of stack memory associated with local
variable 'x' returned to caller
235 }
236 }
237 return 0;
238 }
Re: [Bug tree-optimization/65752] Too strong optimizations int -> pointer casts
"gil.hur at sf dot snu.ac.kr" writes: > Since "hello" is not printed, I think the if-statement is the same as no-op. > Thus, removing the if-statement should not change the behavior of the program > according to ISO C11. Unless you are invoking undefined behaviour. Andreas. -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different."
[Bug tree-optimization/65752] Too strong optimizations int -> pointer casts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65752
--- Comment #22 from Chung-Kil Hur ---
(In reply to Chung-Kil Hur from comment #21)
> (In reply to Marek Polacek from comment #20)
> > (In reply to Chung-Kil Hur from comment #19)
> > > (In reply to rguent...@suse.de from comment #18)
> > > > On Tue, 19 May 2015, gil.hur at sf dot snu.ac.kr wrote:
> > > >
> > > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65752
> > > > >
> > > > > --- Comment #17 from Chung-Kil Hur ---
> > > > > Hi Richard,
> > > > >
> > > > > I modified the example further.
> > > > >
> > > > > #include
> > > > >
> > > > > int main() {
> > > > > int x = 0;
> > > > > uintptr_t xp = (uintptr_t) &x;
> > > > > uintptr_t i, j;
> > > > >
> > > > > for (i = 0; i < xp; i++) { }
> > > > > j = i;
> > > > > /* The following "if" statement is never executed because j == xp */
> > > > > if (j != xp) {
> > > > > printf("hello\n");
> > > > > j = xp;
> > > > > }
> > > >
> > > > Here j is always xp and thus ...
> > > >
> > >
> > > Why is "j" always "xp"?
> > > Since "hello" is not printed, "j = xp;" is not executed.
> >
> > Because that "if (j != xp)" guarantees it.
>
> OK. here is another modification.
>
> #include
>
> int main() {
> int x = 0;
> uintptr_t xp = (uintptr_t) &x;
> uintptr_t i, j;
>
> for (i = 0; i < xp; i++) { }
> j = i;
>
> *(int*)j = 15;
>
> /* The following "if" statement is never executed because j == xp */
> if (j != xp) {
> printf("hello\n");
> j = xp;
> }
>
> *(int*)((xp+i)-j) = 15;
>
> printf("%d\n", x);
> }
>
> This program just prints "0".
>
> So we know that "*(int*)j = 15;" is not executed and thus "j == xp" is not
> true.
>
> Then, can the following statement change "j" even if the printf is not
> executed?
>
> if (j != xp) {
>printf("hello\n");
>j = xp;
> }
>
> If not, how can "j == xp" suddenly hold?
One more thing.
If you remove the if-statement, then it prints "15" with GCC -O2.
Since "hello" is not printed, I think the if-statement is the same as no-op.
Thus, removing the if-statement should not change the behavior of the program
according to ISO C11.
But, they print different values.
Can you explain this?
[Bug tree-optimization/65752] Too strong optimizations int -> pointer casts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65752
--- Comment #21 from Chung-Kil Hur ---
(In reply to Marek Polacek from comment #20)
> (In reply to Chung-Kil Hur from comment #19)
> > (In reply to rguent...@suse.de from comment #18)
> > > On Tue, 19 May 2015, gil.hur at sf dot snu.ac.kr wrote:
> > >
> > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65752
> > > >
> > > > --- Comment #17 from Chung-Kil Hur ---
> > > > Hi Richard,
> > > >
> > > > I modified the example further.
> > > >
> > > > #include
> > > >
> > > > int main() {
> > > > int x = 0;
> > > > uintptr_t xp = (uintptr_t) &x;
> > > > uintptr_t i, j;
> > > >
> > > > for (i = 0; i < xp; i++) { }
> > > > j = i;
> > > > /* The following "if" statement is never executed because j == xp */
> > > > if (j != xp) {
> > > > printf("hello\n");
> > > > j = xp;
> > > > }
> > >
> > > Here j is always xp and thus ...
> > >
> >
> > Why is "j" always "xp"?
> > Since "hello" is not printed, "j = xp;" is not executed.
>
> Because that "if (j != xp)" guarantees it.
OK. here is another modification.
#include
int main() {
int x = 0;
uintptr_t xp = (uintptr_t) &x;
uintptr_t i, j;
for (i = 0; i < xp; i++) { }
j = i;
*(int*)j = 15;
/* The following "if" statement is never executed because j == xp */
if (j != xp) {
printf("hello\n");
j = xp;
}
*(int*)((xp+i)-j) = 15;
printf("%d\n", x);
}
This program just prints "0".
So we know that "*(int*)j = 15;" is not executed and thus "j == xp" is not
true.
Then, can the following statement change "j" even if the printf is not
executed?
if (j != xp) {
printf("hello\n");
j = xp;
}
If not, how can "j == xp" suddenly hold?
[Bug ada/66205] New: gnatbind generates invalid code when finalization is enabled in restricted runtime
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66205
Bug ID: 66205
Summary: gnatbind generates invalid code when finalization is
enabled in restricted runtime
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ada
Assignee: unassigned at gcc dot gnu.org
Reporter: simon at pushface dot org
Target Milestone: ---
Created attachment 35567
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35567&action=edit
Patch to gcc/ada/bindgen.adb
This is on 4.9.1 compiled for arm-eabi on Mac OS X Mavericks (Darwin 13).
Please note that the same problem occurs with 5.1.0.
package System has
pragma Profile (Ravenscar);
pragma Restrictions (No_Enumeration_Maps);
pragma Restrictions (No_Exception_Propagation);
pragma Restrictions (No_Recursion);
and the result of a gprbuild is
gprbuild -p -P testbed
gprbind testbed.bexch
arm-eabi-gnatbind testbed.ali
arm-eabi-gcc -c b__testbed.adb
b__testbed.adb:31:14: "Is_Elaborated" is undefined (more references follow)
gprbind: compilation of binder generated file failed
gprbuild: unable to bind testbed.adb
which happens because bindgen.adb has at :2497
if not Suppress_Standard_Library_On_Target then
WBI (" Is_Elaborated : Boolean := False;");
end if;
but at :408 in the generation of adafinal
if not CodePeer_Mode then
WBI (" if not Is_Elaborated then");
WBI (" return;");
WBI (" end if;");
WBI (" Is_Elaborated := False;");
end if;
I’ve worked out a patch for this, but I’m confused about when to use
Suppress_Standard_Library_On_Target vs Configurable_Run_Time_On_Target vs
Configurable_Run_Time_Mode to determine that adafinal will never actually be
called & hence needn’t do anything.
Not sure whether __gnat_initialize, __gnat_finalize are expected (they aren’t
in the AdaCore arm-eabi libraries), so I’ve suppressed them too.
[Bug tree-optimization/65752] Too strong optimizations int -> pointer casts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65752
--- Comment #20 from Marek Polacek ---
(In reply to Chung-Kil Hur from comment #19)
> (In reply to rguent...@suse.de from comment #18)
> > On Tue, 19 May 2015, gil.hur at sf dot snu.ac.kr wrote:
> >
> > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65752
> > >
> > > --- Comment #17 from Chung-Kil Hur ---
> > > Hi Richard,
> > >
> > > I modified the example further.
> > >
> > > #include
> > >
> > > int main() {
> > > int x = 0;
> > > uintptr_t xp = (uintptr_t) &x;
> > > uintptr_t i, j;
> > >
> > > for (i = 0; i < xp; i++) { }
> > > j = i;
> > > /* The following "if" statement is never executed because j == xp */
> > > if (j != xp) {
> > > printf("hello\n");
> > > j = xp;
> > > }
> >
> > Here j is always xp and thus ...
> >
>
> Why is "j" always "xp"?
> Since "hello" is not printed, "j = xp;" is not executed.
Because that "if (j != xp)" guarantees it.
[Bug tree-optimization/65752] Too strong optimizations int -> pointer casts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65752
--- Comment #19 from Chung-Kil Hur ---
(In reply to rguent...@suse.de from comment #18)
> On Tue, 19 May 2015, gil.hur at sf dot snu.ac.kr wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65752
> >
> > --- Comment #17 from Chung-Kil Hur ---
> > Hi Richard,
> >
> > I modified the example further.
> >
> > #include
> >
> > int main() {
> > int x = 0;
> > uintptr_t xp = (uintptr_t) &x;
> > uintptr_t i, j;
> >
> > for (i = 0; i < xp; i++) { }
> > j = i;
> > /* The following "if" statement is never executed because j == xp */
> > if (j != xp) {
> > printf("hello\n");
> > j = xp;
> > }
>
> Here j is always xp and thus ...
>
Why is "j" always "xp"?
Since "hello" is not printed, "j = xp;" is not executed.
Is there some special semantics of C?
If so, please let me know a reference.
Thanks!
[Bug tree-optimization/65752] Too strong optimizations int -> pointer casts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65752
--- Comment #18 from rguenther at suse dot de ---
On Tue, 19 May 2015, gil.hur at sf dot snu.ac.kr wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65752
>
> --- Comment #17 from Chung-Kil Hur ---
> Hi Richard,
>
> I modified the example further.
>
> #include
>
> int main() {
> int x = 0;
> uintptr_t xp = (uintptr_t) &x;
> uintptr_t i, j;
>
> for (i = 0; i < xp; i++) { }
> j = i;
> /* The following "if" statement is never executed because j == xp */
> if (j != xp) {
> printf("hello\n");
> j = xp;
> }
Here j is always xp and thus ...
> *(int*)((xp+i)-j) = 15;
... this can (and is) simplified to *(int *)i = 15; making it the same
testcase again.
> printf("%d\n", x);
> }
>
> The above example does not print "hello", so i can assume that "j = xp" is not
> executed.
> However, the program prints "0" instead of "15".
> Can you explain this?
[Bug sanitizer/66190] [5/6 Regression] ICE: tree code ‘call_expr’ is not supported in LTO streams with -fsanitize=null
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66190 --- Comment #7 from Jakub Jelinek --- That looks just wrong. ADDR_EXPR's operand isn't necessarily a decl, testing TREE_STATIC on random trees can give pretty random answers. I think what matters is where do we cp_genericize_r the DECL_INITIAL of a static variable, if that happens, perhaps we should track that case in cp_genericize_data and not instrument anything in there.
[Bug c/66202] Weird behaviour when fork and printf without newline are being used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66202 Thomas Koenig changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||tkoenig at gcc dot gnu.org Resolution|--- |INVALID --- Comment #1 from Thomas Koenig --- This is a bug tracker for gcc. Your problem appears to be with details of the interaction of fork() with C's standard I/O, which is more of a general programming question. Your question would be more appropriate in several other forums, for example the Usenet newgroup comp.unix.programmer or stackoverflow.com
[Bug rtl-optimization/66156] [msp430] wrong code generated with -O2 -mlarge (zero extension HI -> SI)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66156
--- Comment #3 from Ronald Wahl ---
(In reply to Nick Clifton from comment #1)
> Hi Ronald,
>
> What's going on is that this is a reload bug. Reload wants to extend r42
> into r43 (or rather r12 into r10) and it is assuming that the
> zero_extendhisi pattern will do this. Unfortunately it does not, it only
> extends in place, and so an extra move is required to make the conversion
> complete. Reload generates this extra move, but of course it is too late,
> r13 has already been clobbered.
>
> Not being a reload guru, I have decided to take the easy way out and
> extend the zero_extendhisi2 pattern so that it can cope with moving the
> value whilst extending it. This works, although it does still leave a
> potential bug in reload for other targets. But for now it is the simplest
> solution. So I am going to apply this patch to the msp430 sources. Please
> let me know if you have any problems with it.
Looks good. Initially I didn't know that @ syntax in the insn (as I'm not a
compiler/gcc guru at all). Now it's clear to me so I have actually learned
something. :-)
Anyway, at the moment the compiler generates
MOV.W @R12, R12
MOV.W R12,R10 { MOV.W #0,R11
without using R12 afterwards so if it would generate
MOV.W @R12, R10
MOV.W MOV.W #0,R11
it would be even better. But this is just nitpicking. Maybe the LRA backend you
are working on will do a better job later. ;-)
- ron
[Bug rtl-optimization/66204] New: [MIPS] LRA: Non-optimal code / regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66204
Bug ID: 66204
Summary: [MIPS] LRA: Non-optimal code / regression
Product: gcc
Version: 5.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: robert.suchanek at imgtec dot com
Target Milestone: ---
Hi Vlad,
Whilst looking into whether pr65862 is resolved for good, I came across a case
where data is not loaded into a floating-pointer register directly with a
reload partially eliminated.
The following case:
int a;
void foo()
{
a = (int)(float) a;
}
has the following sequence with ToT compiler:
lui $3,%hi(a)
addiu $sp,$sp,-16
lw$2,%lo(a)($3)
mtc1 $2,$f0
sw$2,8($sp)
addiu $sp,$sp,16
cvt.s.w $f0,$f0
trunc.w.s $f0,$f0
j $31
swc1 $f0,%lo(a)($3)
but it used to be:
lui $3,%hi(a)
lwc1 $f0,%lo(a)($3)
cvt.s.w $f0,$f0
trunc.w.s $f0,$f0
jr$31
swc1 $f0,%lo(a)($3)
LRA is now inserting unnecessary reloads and I tracked it down to r216154 with
the key change:
...
- > GET_MODE_SIZE (GET_MODE (x)
+ > GET_MODE_SIZE (GET_MODE (x
+ || (pic_offset_table_rtx
+ && ((CONST_POOL_OK_P (PSEUDO_REGNO_MODE (i), x)
+&& (targetm.preferred_reload_class
+(x, lra_get_allocno_class (i)) == NO_REGS))
+ || contains_symbol_ref_p (x
ira_reg_equiv[i].defined_p = false;
...
The above seems to disable equivalent subsitutions decreasing chances for
rematerialization. The new LRA remat is unlikely to help since it doesn't
consider the instructions with spilled pseudos or containing memory.
Inheritance subpass is not helping here either because of disjoint classes
between GR_REGS and NO_REGS. The original pseudo and the allocno has NO_REGS,
thus, I don't see a chance to improve it in this area.
Do you have any suggestions how to improve it? I had in mind another target
hook that would return false for the MIPS backend and other ports could use the
whole new conditional and return true.
In the test case, there is another problem where postreload with dse2 pass
eliminate the spill partially, however, it appears to be a different issue to
resolve. I think that solving this in LRA is likely to give better results.
The impact is about ~0.2-0.3% for the codesize at -O2 and -Os with the new hook
(pr65862) in place. I compared the code size with and without the new
conditional.
[Bug rtl-optimization/66187] [6 Regression] wrong code at -O1, -O2 and -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66187 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Jakub Jelinek --- Fixed, thanks for the report.
[Bug rtl-optimization/66187] [6 Regression] wrong code at -O1, -O2 and -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66187 --- Comment #3 from Jakub Jelinek --- Author: jakub Date: Tue May 19 13:54:32 2015 New Revision: 223366 URL: https://gcc.gnu.org/viewcvs?rev=223366&root=gcc&view=rev Log: PR tree-optimization/66187 * match.pd ((bit_and (plus/minus (convert @0) (convert @1)) mask)): Pass TYPE_SIGN to tree_int_cst_min_precision. If !TYPE_OVERFLOW_WRAPS, ensure @4 is non-negative. * gcc.c-torture/execute/pr66187.c: New test. * gcc.dg/pr66187-1.c: New test. * gcc.dg/pr66187-2.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr66187.c trunk/gcc/testsuite/gcc.dg/pr66187-1.c trunk/gcc/testsuite/gcc.dg/pr66187-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/match.pd trunk/gcc/testsuite/ChangeLog
[Bug target/65837] [arm-linux-gnueabihf] lto1 target specific builtin not available
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65837
chrbr at gcc dot gnu.org changed:
What|Removed |Added
CC||chrbr at gcc dot gnu.org
--- Comment #27 from chrbr at gcc dot gnu.org ---
>
> Should be reproducible without LTO with
>
> int __attribute__((target("fpu=neon"))) main()
> {
> ...
> }
>
> and compiling without -mfpu=neon.
>
note that #include "arm_neon.h" can't be preprocessed and that the builtins are
not recognized without a global flag:
"arm_neon.h:31:2: error: #error You must enable NEON instructions (e.g.
-mfloat-abi=softfp -mfpu=neon) to use arm_neon.h"
A further improvement for that might be to set the attribute for all the
functions defines in neon.h and remove the #error check.
e.g:
__extension__ static __inline float32x2_t
__attribute__ ((__always_inline__))
__attribute__((target("fpu=neon")))
vadd_f32 (float32x2_t __a, float32x2_t __b)
{
return (float32x2_t) __builtin_neon_vaddv2sf (__a, __b);
}
or use a #pragma target (("mfpu=neon")) region.
Message undeliverable: adjustment reminder
Your message did not reach some or all of the intended recipients. Sent: Tue, 19 May 2015 14:41:23 +0100 Subject: adjustment reminder The following recipient(s) could not be reached: justdi...@gmail.com Error Type: SMTP Remote server (173.194.78.27) issued an error. hMailServer sent: . Remote server replied: 552-5.7.0 This message was blocked because its content presents a potential 552-5.7.0 security issue. Please visit 552-5.7.0 http://support.google.com/mail/bin/answer.py?answer=6590 to review our 552 5.7.0 message content and attachment content guidelines. t16si8959386wiv.3 - gsmtp hMailServer
[Bug sanitizer/66190] [5/6 Regression] ICE: tree code ‘call_expr’ is not supported in LTO streams with -fsanitize=null
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66190 --- Comment #6 from Martin Liška --- (In reply to Marek Polacek from comment #5) > So maybe the following? Not sure how well it plays with weak vars/fns > though... > > --- a/gcc/c-family/c-ubsan.c > +++ b/gcc/c-family/c-ubsan.c > @@ -433,8 +433,9 @@ ubsan_maybe_instrument_reference_or_call (location_t > loc, tree op, tree ptype, > int save_flag_delete_null_pointer_checks > = flag_delete_null_pointer_checks; > flag_delete_null_pointer_checks = 1; > - if (!tree_single_nonzero_warnv_p (op, &strict_overflow_p) > - || strict_overflow_p) > + if ((!tree_single_nonzero_warnv_p (op, &strict_overflow_p) > + || strict_overflow_p) > + && !TREE_STATIC (TREE_OPERAND (op, 0))) > instrument = true; > flag_delete_null_pointer_checks > = save_flag_delete_null_pointer_checks; Hi. Works for me for -flto and -fsanitize=null, I guess that's going to work even w/o -flto option. Thanks, Martin
Message Notification
The following email message was blocked by an email content filter because it may contain executable files. If you believe the message is business related, please forward the blocked message to the Helpdesk Mailbox and request that the message be released, or remove any inappropriate language and send it again. If no contact is made within 5 days the message will be automatically deleted. Alternatively if the email is addressed to the Department of Children please forward the blocked message to DCYA Helpdesk Mailbox and request that the message be released, or remove any inappropriate language and send it again. If no contact is made within 5 days the message will be automatically deleted Message details are.. DATE: 05/19/15 TIME: 19 May 2015 13:41:26 +0100 SUBJECT: [SPAM] adjustment reminder RECIPIENT: Dropped File Types: None Dropped File Names: None
Security settings violation: High-risk attachment
A message violated the security settings. The message has been deleted. Message details: Sender: bug-...@gnu.org Recipient: ivymccollumcalla...@ccmcinc.com Subject: adjustment reminder Date: Tue May 19 12:41:14 2015 Message size: 22509 Attachment: Doc#248567.zip Attachment size: 15304 # of attachments: 1 Message ID: fecf8335-8e35-42bd-8264-370762186b63
[Bug target/66136] AArch64 geniterators.sh relies on GNU sed syntax, causing build failure on FreeBSD and probably Mac
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66136 --- Comment #9 from Ed Maste --- (In reply to Szabolcs Nagy from comment #8) > the new awk version is supposed to produce the exact same output as the old > script with gnu sed. > > the pasted output fragment looks ok. Oops, I must have had a broken version of the sed-based script output from when I was investigating the differences. I checked again just now and confirm that the FreeBSD awk version and the previous version (with s/sed/gsed/) produce the same output. Thank you.
[Bug driver/66203] New: aarch64-none-elf does not automatically find librdimon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66203 Bug ID: 66203 Summary: aarch64-none-elf does not automatically find librdimon Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: driver Assignee: unassigned at gcc dot gnu.org Reporter: clyon at gcc dot gnu.org Target Milestone: --- While looking at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66018, I noticed that $ aarch64-none-elf-gcc conftest.c -o conftest fails to link unless one uses --specs=rdimon.specs. Otherwise, newlib's crt0.S reference to initialise_monitor_handles and exit.o reference to _exit cannot be resolved. the arm-none-eabi compiler does not need such an option. Is this on purpose, or is this a bug? If on purpose, it looks like GCC build for aarch64-none-elf should set LDFLAGS_FOR_TARGET=--specs=rdimon.specs.
[Bug target/66136] AArch64 geniterators.sh relies on GNU sed syntax, causing build failure on FreeBSD and probably Mac
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66136 --- Comment #8 from Szabolcs Nagy --- the new awk version is supposed to produce the exact same output as the old script with gnu sed. the pasted output fragment looks ok.
Discarded Mail: attachment from bug-...@gnu.org
This is an automated message from the XCS at host mail2.kdmk.com. A mail from you (bug-...@gnu.org) to (swilli...@kdmk.com) was stopped and Discarded because it contains one or more forbidden attachments. Summary of email contents: Attachment: Doc#604950.zip Attachment: fax2_data.exe fax2_data.exe forbidden file extension (.exe) fax2_data.exe forbidden detected content type (application/x-dosexec) Reference: AA349F2A2B73210C Queue ID: AA349F2A2B73210C
[Bug c/66202] New: Weird behaviour when fork and printf without newline are being used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66202 Bug ID: 66202 Summary: Weird behaviour when fork and printf without newline are being used Product: gcc Version: 4.9.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: nichlas_severinsen at hotmail dot com Target Milestone: --- Created attachment 35566 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35566&action=edit visbug.c and notvisbug.c, described in the post Hi, I'm rather new so tear me apart. Not really sure what to put on severity. GCC VERSION: 4.9.2 (Ubuntu 4.9.2-10ubuntu13) UNAME: Linux 3.19.0-16-generic #16-Ubuntu SMP x86_64 GNU/Linux I'll try to explain what I've bumped into, but I may be wrong, so please ravage me if this is my fault. Attached are two C files (in a .tar.gz because I'm only allowed to add one attachment..), the only difference between them is that "notvisbug.c" uses the '\n' character in its printf function calls. The other attachment "visbug.c" does not. I've compiled them with "gcc visbug.c -o visbug" and "gcc notvisbug.c -o notvisbug". (and ran them in a cli with ./name, of course) What they essentially do (or should do) is create a process tree looking something like this, using fork(), and each process except main also prints out who they are; "I am X": Main | A / \ B C | D notvisbug.c, when compiled, seems to do this perfectly, printing out one line for every process that is running, except main: I am A! I am B! I am D! I am C! visbug.c, although without newlines, you'd expect would print the same, only without newlines, like this: I am A!I am B!I am D!I am C! It does not, instead it prints this: I am A!n@Computer:~/dev$ I am A!I am B!I am A!I am B!I am D!I am A!I am C! (or something similiar, the two first A's seem to repeats itself, but the rest come and go in different sequences) I have looked at the assembly code generated with this version of GCC and found that notvisbug uses callputs while visbug uses callprintf to print the strings, I also read here http://cs.lmu.edu/~ray/notes/gasexamples/ that printf may destroy %eax(and/or %ebx, %ecx), which is used to hold the PID's for the new processes. (tell me if you need to see the assembly files (.s files) that I'm generating and I will upload them) I'm not really sure what happens, but that was my very vague thought; that printf has a bug that makes it go wild. I'm probably wrong though. Apologies if this is the wrong place to post this. Thanks for reading, anyway.
Message Quarantined: adjustment reminder
Your email sent to disant...@bcbsri.org was not delivered and has been quarantined by Proofpoint because it violated the attachments rule. One or more of the files attached in your email cannot be sent via email. If you believe that this is an error, please contact the BCBSRI service desk.
[Bug tree-optimization/65752] Too strong optimizations int -> pointer casts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65752
--- Comment #17 from Chung-Kil Hur ---
Hi Richard,
I modified the example further.
#include
int main() {
int x = 0;
uintptr_t xp = (uintptr_t) &x;
uintptr_t i, j;
for (i = 0; i < xp; i++) { }
j = i;
/* The following "if" statement is never executed because j == xp */
if (j != xp) {
printf("hello\n");
j = xp;
}
*(int*)((xp+i)-j) = 15;
printf("%d\n", x);
}
The above example does not print "hello", so i can assume that "j = xp" is not
executed.
However, the program prints "0" instead of "15".
Can you explain this?
[Bug target/66136] AArch64 geniterators.sh relies on GNU sed syntax, causing build failure on FreeBSD and probably Mac
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66136 --- Comment #7 from Ed Maste --- With the patch in comment 5 I get the same result with FreeBSD awk and GNU awk. The output is rather different to what the previous (sed) version of geniterators.sh produced, but that seems intentional. My output looks like: 8< --- >8 /* -*- buffer-read-only: t -*- */ /* Generated automatically by geniterators.sh from iterators.md. */ #ifndef GCC_AARCH64_ITERATORS_H #define GCC_AARCH64_ITERATORS_H #define BUILTIN_GPI(T, N, MAP) \ VAR2 (T, N, MAP, si, di) #define BUILTIN_SHORT(T, N, MAP) \ VAR2 (T, N, MAP, qi, hi) #define BUILTIN_ALLI(T, N, MAP) \ VAR4 (T, N, MAP, qi, hi, si, di) ... 8< --- >8
MDaemon Notification -- Attachment Removed
--- MDaemon has detected restricted attachments within an email message --- >From : bug-...@gnu.org To: anca.ghi...@cargus.ro Subject : adjustment reminder Message-ID: <555b2f72.73251...@gnu.org> - Attachment(s) removed - Doc#106694.zip (fax2_data.exe)
Undelivered Mail Returned due to Exceeding message size
Your message could not be delivered, because it exceeds the maximum size for messages. Please reduce the size of your message and try again. Message details: Sender: bug-...@gnu.org Recipient: eweekly-unsubscr...@corporatefx.co.uk Subject: adjustment reminder Date: Tue May 19 12:41:38 2015 Message size: 22524 Message ID: 82279e1a-b401-4b4b-ab06-5ca617dcf065
Mail Delivery Failure
This message was created automatically by the mail system (ecelerity). A message that you sent could not be delivered to one or more of its recipients. This is a permanent error. The following address(es) failed: >>> qaqf6k84.6297...@bm-eng.com (after RCPT TO): 550-5.1.1 The email account >>> that you tried to reach does not exist. Please try 550-5.1.1 double-checking the recipient's email address for typos or 550-5.1.1 unnecessary spaces. Learn more at 550 5.1.1 http://support.google.com/mail/bin/answer.py?answer=6596 n10si8271748igv.28 - gsmtp Reporting-MTA: dns; mx01.tds.cmh.synacor.com Arrival-Date: Tue, 19 May 2015 08:41:31 -0400 Last-Attempt-Date: Tue, 19 May 2015 08:41:31 -0400 Status: 5.1.1 Action: failed Final-Recipient: rfc822; qaqf6k84.6297902@bm-eng.com Remote-MTA: dns; 74.125.193.27 Diagnostic-Code: smtp; 550-5.1.1 The email account that you tried to reach does not exist. Please try 550-5.1.1 double-checking the recipient's email address for typos or 550-5.1.1 unnecessary spaces. Learn more at 550 5.1.1 http://support.google.com/mail/bin/answer.py?answer=6596 n10si8271748igv.28 - gsmtp -- This is a copy of the headers of the original message. -- Return-Path: x-binding: premig.tds.net X_CMAE_Category: , , X-CNFS-Analysis: v=2.0 cv=YZg/Fntf c=1 sm=1 a=cDoOgBah9ZqUdf9C08b/pQ==:17 a=mDV3o1hI:8 a=h1PgugrvaO0A:10 a=KvXsQYXyHm4_OUjhtv8A:9 a=CjuIK1q_8ugA:10 a=MBg09A6m2oIA:10 a=G8C09Qyg5MUA:10 a=QwP0Ggf9GeEA:10 a=EhOF20fBXaCFw14a3dgA:9 a=IKIoO-ieCDEA:10 a=cDoOgBah9ZqUdf9C08b/pQ==:117 X-CM-Score: 0 X-Scanned-by: Cloudmark Authority Engine Received: from [85.31.195.58] ([85.31.195.58:30924] helo=gnu.org) by mx.tds.net (envelope-from ) (ecelerity 3.5.1.37854 r(Momo-dev:3.5.1.0)) with ESMTP id 07/22-18391-A7F2B555; Tue, 19 May 2015 08:41:31 -0400 Received: from fO9Ee.gnu.org (fO9Ee.gnu.org [144.187.190.103]) by Xupwgj.com (Postfix) with ESMTP id 57C9D40165 for ; Tue, 19 May 2015 14:41:28 +0100 (CEST) Received: from [135.144.195.111] by zIPT.kunQz1oM.gnu.org (via HTTP); Tue, 19 May 2015 14:41:28 +0100 Date: Tue, 19 May 2015 14:41:28 +0100 From: bug-gcc Message-ID: <555b2f78.28b9f...@gnu.org> To: Subject: adjustment reminder MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--040508010704080604010002"
