[Bug c++/57673] New: pack sizeof ... groups ellipsis with preceding expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57673
Bug ID: 57673
Summary: pack sizeof ... groups ellipsis with preceding
expression
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: potswa at mac dot com
In this example, template g compiles without issue but each member in d chokes
the parser. The only difference is grouping parentheses, which shouldn't be
significant.
There may be more than one issue. A left paren seems to get the parser into a
good state to accept sizeof ... , but it starts in a bad state at the beginning
of an initializer, and seeing a qualified-id puts it into a bad state.
(Reversing the order of subexpressions and writing ( sizeof ... ( p ) - i::m )
does not produce an error.)
struct i { static constexpr int m = 5; };
template int ... p
struct g {
static constexpr int m = i::m - ( sizeof ... ( p ) );
int n = ( sizeof ... ( p ) );
};
template int ... p
struct d {
static constexpr int m = ( i::m - sizeof ... ( p ) );
int n = sizeof ... ( p );
};
[Bug rtl-optimization/57497] [4.9 Regression] ICE in lra_create_new_reg_with_unique_value, at lra.c:155
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57497 --- Comment #3 from Antoine Balestrat antoine.balestrat at gmail dot com --- This bug looks unreproducible with the current trunk.
[Bug c++/57673] pack sizeof ... groups ellipsis with preceding expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57673 --- Comment #1 from David Krauss potswa at mac dot com --- Oops, g::m does not need to be static constexpr to produce an error; the specifiers should be removed to produce a minimal test.
[Bug lto/57290] [4.9 Regression] After r198333 the aermod runtime is ~10% slower when compiled with -fprotect-parens and -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57290 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #4 from Dominique d'Humieres dominiq at lps dot ens.fr --- At revision 200321 I get (3) 17.83 (5) 17.82 Closing as FIXED.
[Bug rtl-optimization/50749] Auto-inc-dec does not find subsequent contiguous mem accesses
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50749
--- Comment #14 from Oleg Endo olegendo at gcc dot gnu.org ---
Just wanted to clarify the reason why the examples in the description have
'-fno-ivopts', as it caused some confusion on the mailing list:
int test_0 (char* p, int c)
{
int r = 0;
r += *p++;
r += *p++;
r += *p++;
return r;
}
compiled with -m4 -O2:
mov.b @(1,r4),r0
mov.b @r4,r1
add r0,r1
mov.b @(2,r4),r0
rts
add r1,r0
compiled with -m4 -Os:
mov.b @(1,r4),r0
mov.b @r4,r2
add r0,r2
mov.b @(2,r4),r0
add r0,r2
rts
mov r2,r0
As seen above, the memory accesses are turned into reg+disp addressing,
although on SH using post-inc addressing would be cheaper (as it is also
reported 'sh_address_cost').
Turning off ivopts leaves the post-inc addressing and points out the original
problem of this PR. I believe that the proper fix for this would be having PR
56590 fixed.
[Bug fortran/52413] Incorrect behavior of FRACTION when applied to a constant
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52413 --- Comment #3 from Dominique d'Humieres dominiq at lps dot ens.fr --- Tentative patch. Not regression tested, yet. I have applied the patch in comment #1 on top of revision 200321. I have regtested without regression and tested thet this PR is fixed for all the available kinds (4, 8, 10, and 16). Steven, would it help if I do the packaging and the submission on your behalf (someone will have to commit after approval)?
[Bug fortran/53957] Polyhedron 11 benchmark: MP_PROP_DESIGN twice as long as other compiler
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53957 --- Comment #14 from Dominique d'Humieres dominiq at lps dot ens.fr --- Anthony, could you provide a reduced test showing the problem?
[Bug fortran/53035] ICE with deferred-length module variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53035 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|NEW |WAITING --- Comment #7 from Dominique d'Humieres dominiq at lps dot ens.fr --- The tests in comments #4 and #5 compile with revision 187834 (2012-05-24), but not with revision 187440 (2012-05-13). Could you test that your application compiles with gfortran 4.8.1?
[Bug fortran/48303] [Legacy] Support Character constants in DATA statement for non-character variables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48303 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|NEW |WAITING --- Comment #4 from Dominique d'Humieres dominiq at lps dot ens.fr --- No activity since more than two years. IMO this should go under the section 6.2 Extensions not implemented in GNU Fortran of the manual. I can submit a draft patch for this PR if someone is will to fix my Frenglish and formatting issues and do the commit.
[Bug fortran/44345] ICE in fold_convert_loc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44345 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Dominique d'Humieres dominiq at lps dot ens.fr --- The code is now rejected with 4.8.0 Confirmed. Closing as FIXED. Please reopen if I am wrong.
[Bug libstdc++/57674] New: wrong distribution for std::binomial_distribution::operator()(g,param)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57674 Bug ID: 57674 Summary: wrong distribution for std::binomial_distribution::operator()(g,param) Product: gcc Version: 4.7.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: schlaffi at users dot sourceforge.net Created attachment 30337 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30337action=edit example where bindist(gen,param) fails std::binomial_distribution::operator()(g,param) produces an invalid statistic. It uses the old probability p_old if param.p.5 and otherwise 1-p_old. Looks like a typo. That is, dist(gen,para2); gives distribution 1: p = 0.8, f = 0.798828 distribution 2: p = 0.3, f = 0.206055 while dist.param(para2);dist(gen); gives distribution 1: p = 0.8, f = 0.324219 distribution 2: p = 0.3, f = 0.295898 I briefly checked the SVN, there does not seem to be a change since v2.7.8.
[Bug fortran/40958] module files too large
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40958 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|NEW |WAITING --- Comment #12 from Dominique d'Humieres dominiq at lps dot ens.fr --- Joost, is it fixed after revision 198023? If yes, could you close the PR as FIXED?
[Bug libstdc++/57674] wrong distribution for std::binomial_distribution::operator()(g,param)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57674 schlaffi at users dot sourceforge.net changed: What|Removed |Added Version|4.7.2 |lno --- Comment #1 from schlaffi at users dot sourceforge.net --- i mean v4.7.2 :o
[Bug fortran/28105] Check for memory allocations bigger than size_t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28105 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #12 from Dominique d'Humieres dominiq at lps dot ens.fr --- Since gfortran 4.8.1 up to trunk I get pr28105.f90:1:0: error: size of variable 'm' is too large real(4), dimension(1025*1024*1024) :: m when compiling real(4), dimension(1025*1024*1024) :: m m = 0. print *, m(1025*1024*1024) end with -m32. Revision 187017 (2012-05-01) does not give any error, but revision 187060 (2012-05-02) does. Closing as FIXED. Please reopen if I am wrong.
[Bug fortran/13615] -Wuninitialized produces wrong error message for characters
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13615
Dominique d'Humieres dominiq at lps dot ens.fr changed:
What|Removed |Added
Status|NEW |WAITING
--- Comment #11 from Dominique d'Humieres dominiq at lps dot ens.fr ---
At revision 200321, I still get no warning for tests as in comment #7 and
pr13615_1.f90:3:0: warning: 'c[1]{lb: 1 sz: 1}' is used uninitialized in this
function [-Wuninitialized]
as in comment #8. What dump(s) would be necessary for any progress for this PR?
[Bug fortran/13615] -Wuninitialized produces wrong error message for characters
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13615
--- Comment #12 from Manuel López-Ibáñez manu at gcc dot gnu.org ---
(In reply to Dominique d'Humieres from comment #11)
At revision 200321, I still get no warning for tests as in comment #7 and
pr13615_1.f90:3:0: warning: 'c[1]{lb: 1 sz: 1}' is used uninitialized in
this function [-Wuninitialized]
as in comment #8. What dump(s) would be necessary for any progress for this
PR?
The SSA built is:
warn_character (character(kind=1)D.24[1:1] restrict dD.1877,
integer(kind=4)D.8 _dD.1876)
{
character(kind=1)D.24 cD.1878[1:1];
character(kind=1)D.24 _2;
;; basic block 2, loop depth 0, count 0, freq 0, maybe hot
;;prev block 0, next block 1, flags: (NEW, REACHABLE)
;;pred: ENTRY (FALLTHRU)
;; starting at line 3
[z.f : 3:0] # VUSE .MEM_1(D)
_2 = [z.f : 3] cD.1878[1]{lb: 1 sz: 1};
[z.f : 3:0] # .MEM_4 = VDEF .MEM_1(D)
[z.f : 3] [z.f : 3] *d_3(D)[1]{lb: 1 sz: 1} = _2;
# .MEM_5 = VDEF .MEM_4
cD.1878 ={v} {CLOBBER};
[z.f : 4:0] # VUSE .MEM_5
return;
;;succ: EXIT
}
as you can see, the middle-end somehow thinks that the function reads from
uninitialized memory. If this is the fault of gfortran or the middle-end, I
really don't know. Perhaps Richard or Jakub have better idea of what is going
on.
[Bug target/57631] [patch] spurious warning for avr interrupts with asm labels
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57631 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added CC||manu at gcc dot gnu.org --- Comment #11 from Manuel López-Ibáñez manu at gcc dot gnu.org --- (In reply to pebbles from comment #9) I would like to learn to find out if this is a bug and contribute a fix to the gcc sources. At the moment building gcc loads my computer for a day, and it is difficult to develop on. I plan to pursue this when I am set up better, but if anybody else ever cares about it they should look at it. You can use the GCC Farm for gcc development for free. http://gcc.gnu.org/wiki/CompileFarm There are scripts that simplify building and testing patches. See contrib/patch_test.sh and other scripts in that directory. You can also use my own script http://gcc.gnu.org/wiki/ManuelL%C3%B3pezIb%C3%A1%C3%B1ez?action=AttachFiledo=viewtarget=gccfarming
[Bug other/57675] New: Complex division of NaN by zero not handled correctly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57675
Bug ID: 57675
Summary: Complex division of NaN by zero not handled correctly
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: ian at airs dot com
The rules in C99 Annex G say that if either part of a complex number is
infinity, then the whole number is treated as infinity. The rules imply but do
not clearly state that an operation involving a NaN should yield a NaN.
However, this program aborts:
__complex double f (__complex double, __complex double)
__attribute__ ((noinline));
__complex double
f (__complex double a, __complex double b)
{
return a / b;
}
int
main ()
{
__complex double c = f (__builtin_nan() + 1.0i, 0);
if (__builtin_isinf (__real__ c) || __builtin_isinf (__imag__ c))
abort ();
exit (0);
}
Computing NaN+1.0i / 0+0i yields NaN+Inf*I. The rules of Annex G say that the
latter is infinity. But the result of dividing a NaN by 0 should be NaN, just
as the result of any operation involving NaN should be NaN.
[Bug other/57675] Complex division of NaN by zero not handled correctly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57675 Ian Lance Taylor ian at airs dot com changed: What|Removed |Added CC||jsm28 at gcc dot gnu.org --- Comment #1 from Ian Lance Taylor ian at airs dot com --- Adding Joseph in case he has any comment on the standards-based argument.
[Bug fortran/50538] formal argument cannot be same as procedure name (r178939)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50538 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-06-22 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr --- Still present at revision 200321.
[Bug fortran/50542] gfortran should detect violation of Fortran 95 R536 (r178939)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50542 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-06-22 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr --- Still present at revision 200321.
[Bug fortran/50546] gfortran should not accept missing operator (r178939)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50546 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr --- With gfortran 4.7.3 up to trunk, I get use m, only : operator(+) 1 Error: Intrinsic operator '+' referenced at (1) not found in module 'm' Closing as fixed. Please reopen if I am wrong.
[Bug fortran/50549] should detect different type parameters in structure constructors (r178939)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50549 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-06-22 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr --- Still present at revision 200321.
[Bug fortran/50550] does not recognize pointer variable at initialization (r178939)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50550 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-06-22 Ever confirmed|0 |1 --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr --- Still present at revision 200321.
[Bug fortran/50551] Argumentless NULL() cannot be used with assumed-length dummy (r178939)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50551 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-06-22 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr --- Still present at revision 200321.
[Bug fortran/52413] Incorrect behavior of FRACTION when applied to a constant
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52413 --- Comment #4 from Steve Kargl sgk at troutmask dot apl.washington.edu --- On Sat, Jun 22, 2013 at 12:57:56PM +, dominiq at lps dot ens.fr wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52413 --- Comment #3 from Dominique d'Humieres dominiq at lps dot ens.fr --- Tentative patch. Not regression tested, yet. I have applied the patch in comment #1 on top of revision 200321. I have regtested without regression and tested thet this PR is fixed for all the available kinds (4, 8, 10, and 16). Steven, would it help if I do the packaging and the submission on your behalf (someone will have to commit after approval)? I do not have any problems if you want to pick up where I left off with this bug. I simply do not have much time for gfortran anymore.
[Bug fortran/50552] type name cannot be statement function dummy argument (r178939)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50552 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2013-06-22 Ever confirmed|0 |1 --- Comment #4 from Dominique d'Humieres dominiq at lps dot ens.fr --- I am traveling in Korea, and I cannot look at the standard now. If you believe this is a non-issue then please close it. Before I close this PR as INVALID, could someone have a look at it?
[Bug fortran/50555] synonymous namelist/statement function dummy argument not allowed (r178939)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50555 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-06-22 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr --- Still present at revision 200321.
[Bug fortran/50525] gfortran should not allow early reference to entry dummy argument (r178939)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50525 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-06-22 Ever confirmed|0 |1 --- Comment #4 from Dominique d'Humieres dominiq at lps dot ens.fr --- Still present at revision 200321.
[Bug rtl-optimization/57676] New: ICE: Maximum number of LRA constraint passes is achieved (30)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57676
Bug ID: 57676
Summary: ICE: Maximum number of LRA constraint passes is
achieved (30)
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: antoine.balestrat at gmail dot com
Using GCC 4.9.0 as of 20130622 :
$ cat lra.c
int a, b, c;
void f(p1)
{
for(;;)
{
if(p1 ? : (c /= 0))
{
int d;
for(; d; d++)
{
for(b = 0; b 4; b++)
p1 /= p1;
lbl:
while(a);
}
}
if((c = 1))
goto lbl;
}
}
$ xgcc -w -O2 -funroll-loops lra.c
lra.c: In function ‘f’:
lra.c:23:1: internal compiler error: Maximum number of LRA constraint passes is
achieved (30)
}
^
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
[Bug libstdc++/57674] wrong distribution for std::binomial_distribution::operator()(g,param)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57674 --- Comment #2 from schlaffi at users dot sourceforge.net --- Created attachment 30338 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30338action=edit corrected version of the example file sorry, forgot one line, the output should be distribution 1: p = 0.8, f = 0.798828 distribution 2: p = 0.3, f = 0.206055 (bad) vs. distribution 1: p = 0.8, f = 0.793945 distribution 2: p = 0.3, f = 0.308594 (good)
[Bug fortran/31139] sum(w_re(1:nn,1)*fi(i(1:nn, ii))) up to 3.5x slower than C version
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31139 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|NEW |WAITING --- Comment #8 from Dominique d'Humieres dominiq at lps dot ens.fr --- I have not tested this with latest trunk, but I wonder if any of the recent optimization work has improved this. Can it be closed yet? A quick test on a 2.5Ghz Core2Duo at revision 200321 with -Ofast shows Fortran: 0.330040932 c_sse: 0.225150943 c_struct: 0.227035046 and with -Ofast -funroll-loops Fortran: 0.213014960 c_sse: 0.223238945 c_struct: 0.209081888 The change occured between 4.5 and 4.6 (note that 4.6 and 4.7 gives 0.263675928 without -funroll-loops). Is this still an issue?
[Bug fortran/31298] F2003: use mod, operator(+) = operator(.userOp.) not supported
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31298 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|NEW |WAITING --- Comment #16 from Dominique d'Humieres dominiq at lps dot ens.fr --- Should not this PR be closed as FIXED (no activity for the past five years)?
[Bug fortran/31298] F2003: use mod, operator(+) = operator(.userOp.) not supported
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31298 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |NEW --- Comment #17 from Tobias Burnus burnus at gcc dot gnu.org --- (In reply to Dominique d'Humieres from comment #16) Should not this PR be closed as FIXED (no activity for the past five years)? Of course not. It's still not implemented. By that argument, we could also close bugs about UTIO or submodules as FIXED because they haven't be implemented either.
[Bug other/57675] Complex division of NaN by zero not handled correctly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57675 --- Comment #2 from joseph at codesourcery dot com joseph at codesourcery dot com --- N1399 has a detailed analysis of issues with complex multiply and divide in C99. There was no consensus to adopt requirements in that detail, but N1496 was adopted with a more minimal fix for (1.0+1.0*I)/(0.0+NAN*I). It appears that the GCC implementation does not suffer the particular issue being addressed in N1496. http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1399.txt http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1496.htm I believe the model in N1399 (and more generally for NaNs in C99/C11 and the draft TS 18661 bindings to IEEE 754-2008; see e.g. how hypot(NaN, Inf) works) is that NaN+1.0i is considered (for a quiet NaN) to be unspecified-real+1.0i. Dividing by zero then gives an unspecified (or not fully specified) infinity, so a result with one part infinity and one part NaN seems appropriate.
[Bug libstdc++/57674] wrong distribution for std::binomial_distribution::operator()(g,param)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57674 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2013-06-22 Assignee|unassigned at gcc dot gnu.org |paolo.carlini at oracle dot com Target Milestone|--- |4.8.2 Ever confirmed|0 |1 --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com --- Thanks. It's indeed a stupid bug, but I would call it thinko more than typo (in jargon): what is happening is that the operator (_M_waiting in particular) is using the _M_q of the distribution itself (stored in _M_param._M_q), instead of that coming with param, aka param._M_q. I'll fix it asap.
[Bug driver/57652] [4.7/4.8/4.9 Regression] collect2 does not clean up temporary files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57652 David Edelsohn dje at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Known to work||4.7.4, 4.8.2 Resolution|--- |FIXED --- Comment #3 from David Edelsohn dje at gcc dot gnu.org --- Patch committed and backported.
[Bug c++/57677] New: Fstream should be allowed to move when returned from a function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57677 Bug ID: 57677 Summary: Fstream should be allowed to move when returned from a function Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: mikhail_semenov at hotmail dot com Created attachment 30339 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30339action=edit The program should compile and run for the ifstream.txt described above Similar to the bug 53626 (reported before for version 4.7.0) for C++11. The fstream should be able to open and be returned from a function: move should be allowed to be used in this case. The program should run with the following file contents (ifstream.txt): My File Some types are not amenable to copy semantics but can still be made movable. For example: (1)fstream (2)unique_ptr (non-shared, non-copyable ownership) (3)A type representing a thread of execution
[Bug libstdc++/53626] [C++11] move assignment for ifstream
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53626 --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com --- *** Bug 57677 has been marked as a duplicate of this bug. ***
[Bug c++/57677] Fstream should be allowed to move when returned from a function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57677 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com --- Dup. *** This bug has been marked as a duplicate of bug 53626 ***
[Bug other/57675] Complex division of NaN by zero not handled correctly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57675 Ian Lance Taylor ian at airs dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #3 from Ian Lance Taylor ian at airs dot com --- Closing as being C standard conformant. Now I have to decide what to do with Go.
[Bug fortran/40958] module files too large
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40958 Janne Blomqvist jb at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |REOPENED --- Comment #13 from Janne Blomqvist jb at gcc dot gnu.org --- (In reply to Dominique d'Humieres from comment #12) Joost, is it fixed after revision 198023? If yes, could you close the PR as FIXED? With the introduction of the temp buffer for parsing modules the excessive lseek() calls have been eliminated, and with the introduction of compressed module files the total size of module files on disk have been reduced by an order of magnitude for large projects. However, the fundamental(?) issue of module sizes growing exponentially with deep module hierarchies still remains. The solution to that is to not include transitive dependencies, which in turn would require a module cache for good performance. Whether that is worth doing, and who is willing and able to do it, is unclear.
[Bug c++/57678] New: too many errors for bad template parameter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57678
Bug ID: 57678
Summary: too many errors for bad template parameter
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: manu at gcc dot gnu.org
templateint N int foo(int a) { return N; }
void bar(void)
{
foox(5);
}
triggers:
test.cpp:5:9: error: ‘x’ was not declared in this scope
foox(5);
^
test.cpp:5:13: error: no matching function for call to ‘foo(int)’
foox(5);
^
test.cpp:5:13: note: candidate is:
test.cpp:1:21: note: templateint N int foo(int)
templateint N int foo(int a) { return N; }
^
test.cpp:1:21: note: template argument deduction/substitution failed:
test.cpp:5:13: error: template argument 1 is invalid
foox(5);
^
The second error is not useful (and the last error should be a note), why
even try to match the function call if the template argument was invalid?
Is there any case where the template argument is invalid and the invalidity is
not triggered by a previous error?
Clang:
test.cpp:5:9: error: use of undeclared identifier 'x'
foox(5);
^
[Bug c++/57678] too many errors for bad template parameter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57678 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- I think this is due to once a undeclared decl has been found, its type becomes int which I think is just wrong. We should use error_mark_node and then handle the fall out from there. There have been a few bugs with errors like this which points to the same issue of treating undeclared decls as ints.
[Bug c++/57038] Latest libreoffice compilation fails with enabled LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57038 --- Comment #29 from Jan Hubicka hubicka at ucw dot cz --- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57038 --- Comment #28 from Martin Liška marxin.liska at gmail dot com --- Gdb instruction dump of ScDocument::CalcAll, place where SIGSEGV was received is marked with '', address: 0x2aaab390c19d ?? ??0x2aaab390c188 _ZN10ScDocument7CalcAllEv+8push %rbp ?? ??0x2aaab390c189 _ZN10ScDocument7CalcAllEv+9mov%rdi,%rbp ?? ??0x2aaab390c19d _ZN10ScDocument7CalcAllEv+29 mov0x1c8(%rbp),%rbx OK, so it seems to ICE on reading RBP+0x1c8 where RBP is the first parameter of CalcAll, so it is necessary to debug why it is wrong. I think you can just LTO re-link with -g and get source level debugging... Did you check if non-LTO build works? Honza
[Bug c++/57038] Latest libreoffice compilation fails with enabled LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57038 --- Comment #30 from Jan Hubicka hubicka at gcc dot gnu.org --- BTW the first parameter is this pointer ;)
[Bug libstdc++/57674] wrong distribution for std::binomial_distribution::operator()(g,param)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57674 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com --- Fixed mainline and 4.8.2.
[Bug c++/57679] New: c++11: ICE on template type alias to enum
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57679
Bug ID: 57679
Summary: c++11: ICE on template type alias to enum
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: schlaffi at users dot sourceforge.net
struct B{ enum C{}; };
template typename T using A=typename T::C;
AB d;
triggers an ICE:
y.cc:3:4: internal compiler error: Segmentation fault
I would expect that this is even valid code? The struct B embedding is not
needed --- I just thought that using A=T look very wired. llvm compiles
without complains.
[Bug c++/57208] Latest chromium compilation fails with enabled LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57208 --- Comment #21 from Martin Liška marxin.liska at gmail dot com --- Ltrans grep marxin@marxinbox /ssd/chrome-dumps $ grep _ZN3net12_GLOBAL__N_113DnsTCPAttempt12OnIOCompleteEi chrome.ltrans* Binary file chrome.ltrans16.o matches chrome.ltrans16.s:leaq _ZN3net12_GLOBAL__N_113DnsTCPAttempt12OnIOCompleteEi(%rip), %rax chrome.ltrans29.000i.cgraph: References: _ZN3net12_GLOBAL__N_113DnsTCPAttempt12OnIOCompleteEi/8859591 (addr) chrome.ltrans29.000i.cgraph: References: _ZN3net12_GLOBAL__N_113DnsTCPAttempt12OnIOCompleteEi/8859591 (addr) chrome.ltrans29.000i.cgraph: References: _ZN3net12_GLOBAL__N_113DnsTCPAttempt12OnIOCompleteEi/8859591 (addr) chrome.ltrans29.000i.cgraph: References: _ZN3net12_GLOBAL__N_113DnsTCPAttempt12OnIOCompleteEi/8859591 (addr) chrome.ltrans29.000i.cgraph: Called by: _ZN3net12_GLOBAL__N_113DnsTCPAttempt12OnIOCompleteEi/8859591 (1.00 per call) _ZN3net12_GLOBAL__N_113DnsTCPAttempt5StartERKN4base8CallbackIFviEEE.lto_priv.62289/8859580 (0.62 per call) chrome.ltrans29.000i.cgraph:_ZN3net12_GLOBAL__N_113DnsTCPAttempt12OnIOCompleteEi/8859591 (OnIOComplete) @0x7ff6f304a5f0 chrome.ltrans29.000i.cgraph: References: _ZN3net12_GLOBAL__N_113DnsTCPAttempt12OnIOCompleteEi/8859591 (addr) chrome.ltrans29.000i.cgraph: References: _ZN3net12_GLOBAL__N_113DnsTCPAttempt12OnIOCompleteEi/8859591 (addr) chrome.ltrans29.000i.cgraph: References: _ZN3net12_GLOBAL__N_113DnsTCPAttempt12OnIOCompleteEi/8859591 (addr) chrome.ltrans29.000i.cgraph: References: _ZN3net12_GLOBAL__N_113DnsTCPAttempt12OnIOCompleteEi/8859591 (addr) chrome.ltrans29.000i.cgraph: References: _ZN3net12_GLOBAL__N_113DnsTCPAttempt12OnIOCompleteEi/8859591 (addr) chrome.ltrans29.000i.cgraph: Called by: _ZN3net12_GLOBAL__N_113DnsTCPAttempt12OnIOCompleteEi/8859591 (1.00 per call) _ZN3net12_GLOBAL__N_113DnsTCPAttempt5StartERKN4base8CallbackIFviEEE.lto_priv.62289/8859580 (0.62 per call) chrome.ltrans29.000i.cgraph:_ZN3net12_GLOBAL__N_113DnsTCPAttempt12OnIOCompleteEi/8859591 (OnIOComplete) @0x7ff6f304a5f0 chrome.ltrans29.000i.cgraph: References: _ZN3net12_GLOBAL__N_113DnsTCPAttempt12OnIOCompleteEi/8859591 (addr) chrome.ltrans29.000i.cgraph:_ZN3net12_GLOBAL__N_113DnsTCPAttempt12OnIOCompleteEi/8859591 (OnIOComplete) @0x7ff6f304a5f0 chrome.ltrans29.000i.cgraph: References: _ZN3net12_GLOBAL__N_113DnsTCPAttempt12OnIOCompleteEi/8859591 (addr) chrome.ltrans29.045i.cp:;; Function OnIOComplete (_ZN3net12_GLOBAL__N_113DnsTCPAttempt12OnIOCompleteEi, funcdef_no=1376, decl_uid=894468, symbol_order=8859591) chrome.ltrans29.047i.inline:;; Function OnIOComplete (_ZN3net12_GLOBAL__N_113DnsTCPAttempt12OnIOCompleteEi, funcdef_no=1376, decl_uid=894468, symbol_order=8859591) Binary file chrome.ltrans29.o matches chrome.ltrans29.s:leaq _ZN3net12_GLOBAL__N_113DnsTCPAttempt12OnIOCompleteEi(%rip), %rsi chrome.ltrans29.s:leaq _ZN3net12_GLOBAL__N_113DnsTCPAttempt12OnIOCompleteEi(%rip), %rsi chrome.ltrans29.s:.type _ZN3net12_GLOBAL__N_113DnsTCPAttempt12OnIOCompleteEi, @function chrome.ltrans29.s:_ZN3net12_GLOBAL__N_113DnsTCPAttempt12OnIOCompleteEi: chrome.ltrans29.s:.size _ZN3net12_GLOBAL__N_113DnsTCPAttempt12OnIOCompleteEi, .-_ZN3net12_GLOBAL__N_113DnsTCPAttempt12OnIOCompleteEi
[Bug c++/57208] Latest chromium compilation fails with enabled LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57208 --- Comment #22 from Martin Liška marxin.liska at gmail dot com --- Created attachment 30340 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30340action=edit chrome.ltrans16.s
[Bug c++/57679] c++11: ICE on template type alias to enum
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57679 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Known to work||4.8.0, 4.9.0 Resolution|--- |FIXED --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com --- This is fixed in 4.8.0.
[Bug c++/57208] Latest chromium compilation fails with enabled LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57208
--- Comment #23 from Jan Hubicka hubicka at gcc dot gnu.org ---
It seems late optimizers translate
cloning Bind to
_ZN4base4BindIMN3net12_GLOBAL__N_113DnsTCPAttemptEFviENS_8internal17UnretainedWrapperIS3_NS_8CallbackINS6_9BindStateINS6_13FunctorTraitsIT_E12RunnableTypeENSD_7RunTypeEFvNS6_19CallbackParamTraitsIT0_E11StorageTypeEEE14UnboundRunTypeEEESC_RKSH_.constprop.12480
Bind (struct
{
void DnsTCPAttempt::T2bc0a (struct DnsTCPAttempt *, int) * __pfn;
long int __delta;
} functor, const struct UnretainedWrapper p1)
{
void DnsTCPAttempt::T2bc0a (struct DnsTCPAttempt *, int) * method$__pfn;
long int method$__delta;
bb 2:
method$__pfn_10 = MEM[(const struct )functor];
method$__delta_11 = MEM[(const struct )functor + 8];
_5 = operator new (40);
_12 = MEM[(struct RefCountedThreadSafe *)_5 + 8B].D.4332;
__base_ctor (_12);
MEM[(struct BindStateBase *)_5]._vptr.BindStateBase = MEM[(void
*)_ZTVN4base8internal13BindStateBaseE + 16B];
MEM[(struct BindState *)_5].D.961227._vptr.BindStateBase = MEM[(void
*)_ZTVN4base8internal9BindStateINS0_15RunnableAdapterIMN3net12_GLOBAL__N_113DnsTCPAttemptEFviEEEFvPS5_iEFvNS0_17UnretainedWrapperIS5_E
+ 16B];
MEM[(struct BindState *)_5 + 16B] = method$__pfn_10;
MEM[(struct BindState *)_5 + 24B] = method$__delta_11;
MEM[(struct BindState *)_5].p1_ = *p1_6(D);
_13 = _8(D)-D.42504;
__base_ctor (_13, _5);
_8(D)-D.42504.polymorphic_invoke_ = Run;
return _8(D);
}
into
.globl
_ZN4base4BindIMN3net12_GLOBAL__N_113DnsTCPAttemptEFviENS_8internal17UnretainedWrapperIS3_NS_8CallbackINS6_9BindStateINS6_13FunctorTraitsIT_E12RunnableTypeENSD_7RunType
.hidden
_ZN4base4BindIMN3net12_GLOBAL__N_113DnsTCPAttemptEFviENS_8internal17UnretainedWrapperIS3_NS_8CallbackINS6_9BindStateINS6_13FunctorTraitsIT_E12RunnableTypeENSD_7RunType
.type
_ZN4base4BindIMN3net12_GLOBAL__N_113DnsTCPAttemptEFviENS_8internal17UnretainedWrapperIS3_NS_8CallbackINS6_9BindStateINS6_13FunctorTraitsIT_E12RunnableTypeENSD_7RunType
_ZN4base4BindIMN3net12_GLOBAL__N_113DnsTCPAttemptEFviENS_8internal17UnretainedWrapperIS3_NS_8CallbackINS6_9BindStateINS6_13FunctorTraitsIT_E12RunnableTypeENSD_7RunTypeEFvNS6_19Callbac
.LFB10639:
.cfi_startproc
pushq %rbp
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
movq%rcx, %rbp
pushq %rbx
.cfi_def_cfa_offset 24
.cfi_offset 3, -24
movq%rdi, %rbx
movl$40, %edi
subq$8, %rsp
.cfi_def_cfa_offset 32
call_Znwm@PLT
movl$0, 8(%rax)
movq%rax, %rsi
leaq
16+_ZTVN4base8internal9BindStateINS0_15RunnableAdapterIMN3net12_GLOBAL__N_113DnsTCPAttemptEFviEEEFvPS5_iEFvNS0_17UnretainedWrapperIS5_E.lto_priv.73096(%rip),
%rax
movq$0, 24(%rsi)
movq%rbx, %rdi
movq%rax, (%rsi)
leaq_ZN3net12_GLOBAL__N_113DnsTCPAttempt12OnIOCompleteEi(%rip),
%rax
movq%rax, 16(%rsi)
movq0(%rbp), %rax
movq%rax, 32(%rsi)
call_ZN4base8internal12CallbackBaseC2EPNS0_13BindStateBaseE
leaq
_ZN4base8internal7InvokerILi1ENS0_9BindStateINS0_15RunnableAdapterIMN3net12_GLOBAL__N_113DnsTCPAttemptEFviEEEFvPS6_iEFvNS0_17UnretainedWrapperIS6_ESB_E3RunEPNS0_13Bind
movq%rax, 8(%rbx)
addq$8, %rsp
.cfi_def_cfa_offset 24
movq%rbx, %rax
popq%rbx
.cfi_def_cfa_offset 16
popq%rbp
.cfi_def_cfa_offset 8
ret
.cfi_endproc
.LFE10639:
So someone folds
MEM[(struct BindStateBase *)_5]._vptr.BindStateBase = MEM[(void
*)_ZTVN4base8internal13BindStateBaseE + 16B];
MEM[(struct BindState *)_5].D.961227._vptr.BindStateBase = MEM[(void
*)_ZTVN4base8internal9BindStateINS0_15RunnableAdapterIMN3net12_GLOBAL__N_113DnsTCPAttemptEFviEEEFvPS5_iEFvNS0_17UnretainedWrapperIS5_E
+ 16B];
MEM[(struct BindState *)_5 + 16B] = method$__pfn_10;
MEM[(struct BindState *)_5 + 24B] = method$__delta_11;
MEM[(struct BindState *)_5].p1_ = *p1_6(D);
into reference to the symbol that is in other ltrans and not seen by
partitioning...
[Bug c++/57208] Latest chromium compilation fails with enabled LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57208 --- Comment #24 from Jan Hubicka hubicka at ucw dot cz --- does this patch help?
[Bug libstdc++/57674] wrong distribution for std::binomial_distribution::operator()(g,param)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57674 --- Comment #5 from schlaffi at users dot sourceforge.net --- yes, it's fixed :) I tested various examples (also large param.t).
[Bug c++/57677] Fstream should be allowed to move when returned from a function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57677 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org --- As I said on your other bug, this is documented as missing, you don't need to report a dup of your own bug :)
[Bug middle-end/56888] memcpy implementation optimized as a call to memcpy
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56888 Jeff Cook j...@deseret-tech.com changed: What|Removed |Added CC||j...@deseret-tech.com --- Comment #9 from Jeff Cook j...@deseret-tech.com --- FYI this issue affects WINE. A workaround has been contributed as a modification to WINE's configuration scripts. See http://bugs.winehq.org/show_bug.cgi?id=33521 .
[Bug libstdc++/53631] [C++11] regex is unimplemented
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53631 Simbaba zhaoxi.du at gmail dot com changed: What|Removed |Added CC||zhaoxi.du at gmail dot com --- Comment #14 from Simbaba zhaoxi.du at gmail dot com --- Most guy need this feature, but just partial implemented. However, we have many choice, maybe CLANG or posix, or perl-regex.
[Bug target/57680] New: xgcc terminates with SIGILL
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57680 Bug ID: 57680 Summary: xgcc terminates with SIGILL Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: jojelino at gmail dot com Host: i686-pc-cygwin Target: i686-pc-cygwin Build: i686-pc-cygwin $ gdb --args ./xgcc -B./ -B/usr/i686-pc-cygwin/bin/ -isystem /usr/i686-pc-cygwin/include -isystem /usr/i686-pc-cygwin/sys-include -L/tmp/gcc/host-i686-pc-cygwin/gcc/../ld -dumpspecs GNU gdb (GDB) 7.6.50.20130508-cvs (cygwin-special) Copyright (C) 2013 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as i686-cygwin. Type show configuration for configuration details. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/... warning: the current range check setting does not match the language. Whether backtraces should continue past the entry point of a program is off. Reading symbols from /tmp/gcc/host-i686-pc-cygwin/gcc/xgcc...done. warning: File /tmp/gcc/host-i686-pc-cygwin/gcc/.gdbinit auto-loading has been declined by your `auto-load safe-path' set to $debugdir:$datadir/auto-load. To enable execution of this file add add-auto-load-safe-path /tmp/gcc/host-i686-pc-cygwin/gcc/.gdbinit line to your configuration file /home/Administrator/.gdbinit. To completely disable this security protection add set auto-load safe-path / line to your configuration file /home/Administrator/.gdbinit. For more information about this security protection see the Auto-loading safe path section in the GDB manual. E.g., run from the shell: info (gdb)Auto-loading safe path (gdb) r Starting program: /tmp/gcc/host-i686-pc-cygwin/gcc/xgcc -B./ -B/usr/i686-pc-cygwin/bin/ -isystem /usr/i686-pc-cygwin/include -isystem /usr/i686-pc-cygwin/sys-include -L/tmp/gcc/host-i686-pc-cygwin/gcc/../ld -dumpspecs [New Thread 3320.0xdf4] warning: the debug information found in /usr/bin/cygwin1.dbg does not match /usr/bin/cygwin1.dll (CRC mismatch). [New Thread 3320.0x1dc8] *asm: . .. ... Program received signal SIGILL, Illegal instruction. 0x0046e010 in __deregister_frame_info_bases ( begin=0x611623b5 __call_exitprocs+245) at ../.././libgcc/unwind-dw2-fde.c:185 185 for (p = unseen_objects; *p ; p = (*p)-next) (gdb) bt #0 0x0046e010 in __deregister_frame_info_bases ( begin=0x611623b5 __call_exitprocs+245) at ../.././libgcc/unwind-dw2-fde.c:185 #1 0x013aa8e8 in ?? () Backtrace stopped: previous frame inner to this frame (corrupt stack?)
[Bug target/57680] [META-BUG][target]deregister_frame_fn is set to invalid address in cygming-crtbegin.c:__gcc_deregister_frame due to unknown reason.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57680 gee jojelino at gmail dot com changed: What|Removed |Added Summary|deregister_frame_fn is set |[META-BUG][target]deregiste |to invalid address in |r_frame_fn is set to |cygming-crtbegin.c:__gcc_de |invalid address in |register_frame due to |cygming-crtbegin.c:__gcc_de |unknown reason. |register_frame due to ||unknown reason. --- Comment #1 from gee jojelino at gmail dot com --- bootstrap failed with faulting libgcc static library. Dump of assembler code for function __gcc_deregister_frame: 0x00401160 +0: push %ebp 0x00401161 +1: mov%esp,%ebp 0x00401163 +3: sub$0x18,%esp 0x00401166 +6: movl $0x475000,(%esp) 0x0040116d +13:call *0x5a0480 0x00401173 +19:mov$0x46e010,%edx = 0x00401178 +24:sub$0x4,%esp 0x0040117b +27:test %eax,%eax 0x0040117d +29:je 0x401195 __gcc_deregister_frame+53 0x0040117f +31:movl $0x475047,0x4(%esp) 0x00401187 +39:mov%eax,(%esp) 0x0040118a +42:call *0x5a0484 0x00401190 +48:sub$0x8,%esp 0x00401193 +51:mov%eax,%edx 0x00401195 +53:test %edx,%edx 0x00401197 +55:je 0x4011a2 __gcc_deregister_frame+66 0x00401199 +57:movl $0x591000,(%esp) 0x004011a0 +64:call *%edx 0x004011a2 +66:leave 0x004011a3 +67:ret (gdb) i li *0x46e010 Line 185 of ../.././libgcc/unwind-dw2-fde.c starts at address 0x46e00f __deregister_frame_info_bases+159 and ends at 0x46e020 __deregister_frame_info. why cygming-crtbegin.c:154 set invalid function pointer address??? it should be __deregister_frame_info (gdb) x/i __deregister_frame_info 0x46e020 __deregister_frame_info: jmp0x46df70 __deregister_frame_info_bases i think gcc is corrupted in calculating function pointer address. and the failed bootstrap was using gcc with following version. Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/i686-pc-cygwin/4.9.0/lto-wrapper.exe Target: i686-pc-cygwin Configured with: ./configure --config-cache --prefix=/usr --disable-win32-registry --enable-threads=single --enable-languages=c,c++,lto,fortran --with-win32-nlsapi=unicode --enable-tls --disable-bootstrap --enable-shared --disable-sjlj-exceptions --enable-gomp --enable-cloog-backend=isl LTLDFLAGS=-no-undefined lt_cv_deplibs_check_method=pass_all : (reconfigured) ./configure --config-cache --prefix=/usr --disable-win32-registry --enable-threads=win32 --with-win32-nlsapi=unicode --enable-tls --disable-bootstrap --enable-shared --disable-sjlj-exceptions --enable-gomp --enable-cloog-backend=isl LTLDFLAGS=-no-undefined lt_cv_deplibs_check_method=pass_all --enable-languages=c,c++,fortran,lto --no-create --no-recursion Thread model: single gcc version 4.9.0 20130516 (experimental) (GCC)
[Bug target/57680] [META-BUG][target]deregister_frame_fn is set to invalid address in cygming-crtbegin.c:__gcc_deregister_frame due to unknown reason.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57680 --- Comment #2 from gee jojelino at gmail dot com --- (gdb) x/i 0x46e010 0x46e010 __deregister_frame_info_bases+160:fs which is cause of SIGILL
[Bug fortran/53957] Polyhedron 11 benchmark: MP_PROP_DESIGN twice as long as other compiler
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53957 --- Comment #15 from Anthony Falzone prop_design at yahoo dot com --- (In reply to Dominique d'Humieres from comment #14) Anthony, could you provide a reduced test showing the problem? Hi Dominique, About the most reduced I can think of is PROP_DESIGN_ANALYSIS. It contains the core calculations that are required to determine aircraft propeller performance. PROP_DESIGN_ANALYSIS_BENCHMARK just adds some looping options that in my mind could run in parallel. However, I don't know anything about parallel programming and when I tried some Fortran compilers with auto-parallelization non of them can pick up on the loops that too me seem obviously parallel. So what I think and what is currently feasible with auto-parallelization are not the same. In any event, I have noticed that just using O3 optimizations there is a substantial difference between Intel Fortran and gfortran. So I am just confirming what Tobias is saying here in this bug report. If PROP_DESIGN_ANALYSIS_BENCHMARK is too complex of a test case for you the only thing I can think to do is take PROP_DESIGN_ANALYSIS and strip out most of the end parts where various outputs are created. So the program would just take the inputs run the minimum calculations with the least looping possible and output pretty much nothing. It wouldn't be hard for me to do something like that if it would be of any benefit to you, I'm not sure. Also, if there is anything programming wise that you would like changed for some reason as far as Fortran syntax, I can try that too. My knowledge of Fortran is fairly basic. I tried to stick strictly to Fortran 77, since that is what I was trained in and have a lot of experience with. I don't know any other programming languages or even any other versions of Fortran such as 90/95 etc... Anthony
