digitalmars.D.learn - Internal Compiler Error Help
- Saurabh Das (20/20) May 21 2015 Hello,
- Andrea Fontana (2/23) May 21 2015
- Saurabh Das (9/9) May 21 2015 Thanks!
- John Colvin (13/24) May 21 2015 make that
- John Colvin (2/30) May 21 2015 s/irrelevant/irrespective/
- Saurabh Das (15/27) May 21 2015 The original expression was a candidate in a genetic programming
- Saurabh Das (8/8) May 21 2015 PS: The original expression:
- ketmar (16/25) May 21 2015 (TicksTenMinutesNormalized)))*(((AvgPriceChangeNormalized)*(0.0868))*
- John Colvin (6/14) May 21 2015 fair enough. I thought normally you'd want to have some sort of
- Saurabh Das (16/21) May 21 2015 Yes - our evaluation criteria gives bonus points for simpler
- Kagamin (1/1) May 21 2015 If you're looking for speed, how about ldc?
- Saurabh Das (3/4) May 21 2015 Absolutely - we are working on getting it to compile on ldc
- Kagamin (5/5) May 21 2015 double foo(double b)
- Jonathan M Davis via Digitalmars-d-learn (4/6) May 21 2015 Yes. You should never see an ICE, and the compiler should never segfault...
Hello, We have been working on a genetic programming project, and occasionally the compiler fails and gives an internal error. I've captured and reduced one of these down to a single expression. See http://dpaste.dzfl.pl/e7a66aa067ab (reduced_expr.d) When I compile this file using: dmd -c -O reduced_expr.d It says: DMD 2.066.1] Internal error: backend/cod1.c 1562 DMD 2.067.1] Internal error: backend/cod1.c 1567 The compile succeeds without the '-O' flag. Am I correct in assuming that an internal error in the compiler should be filed as a bug report? As you can see, the expression is a massive ugly thing, as is often the case with genetic programming. I'd like to reduce this expression further before filing said bug report. I recall seeing a project on this forum which automatically figures out the simplest program which causes a compile failure. Can someone kindly point me to it? Thanks, Saurabh
May 21 2015
https://github.com/CyberShadow/DustMite/wiki On Thursday, 21 May 2015 at 08:28:30 UTC, Saurabh Das wrote:Hello, We have been working on a genetic programming project, and occasionally the compiler fails and gives an internal error. I've captured and reduced one of these down to a single expression. See http://dpaste.dzfl.pl/e7a66aa067ab (reduced_expr.d) When I compile this file using: dmd -c -O reduced_expr.d It says: DMD 2.066.1] Internal error: backend/cod1.c 1562 DMD 2.067.1] Internal error: backend/cod1.c 1567 The compile succeeds without the '-O' flag. Am I correct in assuming that an internal error in the compiler should be filed as a bug report? As you can see, the expression is a massive ugly thing, as is often the case with genetic programming. I'd like to reduce this expression further before filing said bug report. I recall seeing a project on this forum which automatically figures out the simplest program which causes a compile failure. Can someone kindly point me to it? Thanks, Saurabh
May 21 2015
Thanks! Wow, dustmite is really useful. It reduces the expression down to: double someFunction(double AvgPriceChangeNormalized, double TicksTenMinutesNormalized) { return (TicksTenMinutesNormalized?1:AvgPriceChangeNormalized)?1:TicksTenMinutesNormalized/(TicksTenMinutesNormalized==0)==0; } Which gives a compiler error: Internal error: backend/cod1.c 1562
May 21 2015
On Thursday, 21 May 2015 at 08:55:45 UTC, Saurabh Das wrote:Thanks! Wow, dustmite is really useful. It reduces the expression down to: double someFunction(double AvgPriceChangeNormalized, double TicksTenMinutesNormalized) { return (TicksTenMinutesNormalized?1:AvgPriceChangeNormalized)?1:TicksTenMinutesNormalized/(TicksTenMinutesNormalized==0)==0; } Which gives a compiler error: Internal error: backend/cod1.c 1562make that double foo(double a, double b) { return (b ? 1 : a) ? 1 : b / (b == 0) == 0; } and please submit to https://issues.dlang.org That expression is, not to put too fine a point on it, mad. The operator precedence itself is giving me a headache, let alone the division of a double by a boolean... I'm pretty sure it doesn't do what you want it to, unless what you want is seriously weird. As a matter of fact, i'm pretty sure that expression evaluates to 1, irrelevant of the values of the two variables.
May 21 2015
On Thursday, 21 May 2015 at 10:24:59 UTC, John Colvin wrote:On Thursday, 21 May 2015 at 08:55:45 UTC, Saurabh Das wrote:s/irrelevant/irrespective/Thanks! Wow, dustmite is really useful. It reduces the expression down to: double someFunction(double AvgPriceChangeNormalized, double TicksTenMinutesNormalized) { return (TicksTenMinutesNormalized?1:AvgPriceChangeNormalized)?1:TicksTenMinutesNormalized/(TicksTenMinutesNormalized==0)==0; } Which gives a compiler error: Internal error: backend/cod1.c 1562make that double foo(double a, double b) { return (b ? 1 : a) ? 1 : b / (b == 0) == 0; } and please submit to https://issues.dlang.org That expression is, not to put too fine a point on it, mad. The operator precedence itself is giving me a headache, let alone the division of a double by a boolean... I'm pretty sure it doesn't do what you want it to, unless what you want is seriously weird. As a matter of fact, i'm pretty sure that expression evaluates to 1, irrelevant of the values of the two variables.
May 21 2015
Submitted: https://issues.dlang.org/show_bug.cgi?id=14613and please submit to https://issues.dlang.orgThe original expression was a candidate in a genetic programming population - a result of trial and error / "natural" selection over a few generations. The dustmite-reduced expression is really weird I agree - I don't know what to make of it. I've reported it as I found it. The otiginal expression is not so wierd, it just haphazardly long. It doesn't do any strange divides or compares. In either case, it shouldn't compile normally without the '-O' and fail to compile with it. We managed a 1000x speed up over Java on our genetic programming system by using D, but this compile failure is preventing us from using the release / optimised builds :(( Thanks, SaurabhThat expression is, not to put too fine a point on it, mad. The operator precedence itself is giving me a headache, let alone the division of a double by a boolean... I'm pretty sure it doesn't do what you want it to, unless what you want is seriously weird. As a matter of fact, i'm pretty sure that expression evaluates to 1, irrelevant of the values of the two variables.s/irrelevant/irrespective/
May 21 2015
PS: The original expression: http://dpaste.dzfl.pl/raw/e7a66aa067ab double someFunction(double AvgPriceChangeNormalized, double DayFactor, double TicksTenMinutesNormalized) { return ((((AvgPriceChangeNormalized)*(0.0868))*((DayFactor)*(TicksTenMinutesNormalized)))*(((AvgPriceChangeNormalized)*(0.0868))*(((((((((TicksTenMinutesNormalized)==0)?(1):((AvgPriceChangeNormalized)/(TicksTenMinutesNormalized)))-((TicksTenMinutesNormalized)+(DayFactor)))==0)?(1):((TicksTenMinutesNormalized)/((((TicksTenMinutesNormalized)==0)?(1):((AvgPriceChangeNormalized)/(TicksTenMinutesNormalized)))-((TicksTenMinutesNormalized)+(DayFactor)))))==0)?(1):(((TicksTenMinutesNormalized)+(-0.865))/((((((TicksTenMinutesNormalized)==0)?(1):((AvgPriceChangeNormalized)/(TicksTenMinutesNormalized)))-((TicksTenMinutesNormalized)+(DayFactor)))==0)?(1):((TicksTenMinutesNormalized)/((((TicksTenMinutesNormalized)==0)?(1):((AvgPriceChangeNormalized)/(TicksTenMinutesNormalized)))-((TicksTenMinutesNormalized)+(DayFactor)))))))*(TicksTenMinutesNormalized)))); }
May 21 2015
On Thu, 21 May 2015 11:36:14 +0000, Saurabh Das wrote:PS: The original expression: http://dpaste.dzfl.pl/raw/e7a66aa067ab =20 double someFunction(double AvgPriceChangeNormalized, double DayFactor, double TicksTenMinutesNormalized) { return ((((AvgPriceChangeNormalized)*(0.0868))*((DayFactor)*(TicksTenMinutesNormalized)))*(((AvgPriceChangeNormalized)*(0.0868))* (((((((((TicksTenMinutesNormalized)=3D=3D0)?(1):((AvgPriceChangeNormalized)= / (TicksTenMinutesNormalized)))-((TicksTenMinutesNormalized) +(DayFactor)))=3D=3D0)?(1):((TicksTenMinutesNormalized)/ ((((TicksTenMinutesNormalized)=3D=3D0)?(1):((AvgPriceChangeNormalized)/ (TicksTenMinutesNormalized)))-((TicksTenMinutesNormalized) +(DayFactor)))))=3D=3D0)?(1):(((TicksTenMinutesNormalized)+(-0.865))/ ((((((TicksTenMinutesNormalized)=3D=3D0)?(1):((AvgPriceChangeNormalized)/ (TicksTenMinutesNormalized)))-((TicksTenMinutesNormalized) +(DayFactor)))=3D=3D0)?(1):((TicksTenMinutesNormalized)/ ((((TicksTenMinutesNormalized)=3D=3D0)?(1):((AvgPriceChangeNormalized)/ (TicksTenMinutesNormalized)))-((TicksTenMinutesNormalized) +(DayFactor)))))))*(TicksTenMinutesNormalized))));}now i have to find a way to unsee it...=
May 21 2015
On Thursday, 21 May 2015 at 11:36:15 UTC, Saurabh Das wrote:PS: The original expression: http://dpaste.dzfl.pl/raw/e7a66aa067ab double someFunction(double AvgPriceChangeNormalized, double DayFactor, double TicksTenMinutesNormalized) { return ((((AvgPriceChangeNormalized)*(0.0868))*((DayFactor)*(TicksTenMinutesNormalized)))*(((AvgPriceChangeNormalized)*(0.0868))*(((((((((TicksTenMinutesNormalized)==0)?(1):((AvgPriceChangeNormalized)/(TicksTenMinutesNormalized)))-((TicksTenMinutesNormalized)+(DayFactor)))==0)?(1):((TicksTenMinutesNormalized)/((((TicksTenMinutesNormalized)==0)?(1):((AvgPriceChangeNormalized)/(TicksTenMinutesNormalized)))-((TicksTenMinutesNormalized)+(DayFactor)))))==0)?(1):(((TicksTenMinutesNormalized)+(-0.865))/((((((TicksTenMinutesNormalized)==0)?(1):((AvgPriceChangeNormalized)/(TicksTenMinutesNormalized)))-((TicksTenMinutesNormalized)+(DayFactor)))==0)?(1):((TicksTenMinutesNormalized)/((((TicksTenMinutesNormalized)==0)?(1):((AvgPriceChangeNormalized)/(TicksTenMinutesNormalized)))-((TicksTenMinutesNormalized)+(DayFactor)))))))*(TicksTenMinutesNormalized)))); }fair enough. I thought normally you'd want to have some sort of expression simplification in genetic programming, to avoid adding too many superfluous degrees of freedom? Aside from the obvious problems, those extra degrees of freedom can put you at risk of overfitting.
May 21 2015
fair enough. I thought normally you'd want to have some sort of expression simplification in genetic programming, to avoid adding too many superfluous degrees of freedom? Aside from the obvious problems, those extra degrees of freedom can put you at risk of overfitting.Yes - our evaluation criteria gives bonus points for simpler expressions. We also strongly constrain the degrees of freedom. Both these aim to reduce overfitting. The expression seems rather complex because every division is protected by a equal to 0 check. Since our data sets are vast and number of features is kept low, overfitting is less of a concern. We do watch out for it though. In release builds, the compiler does the job of simplifying the expression, so we don't input a simplified expression a-priori. We are currently building this framework because earlier Java frameworks were deficient in speed. Already we have achieved a ~ 1000x speedup, so right now we are looking to consolidate and stabilise. In the next iteration, we could think of adding a simplify expression feature. Thanks, Saurabh
May 21 2015
On Thursday, 21 May 2015 at 14:12:25 UTC, Kagamin wrote:If you're looking for speed, how about ldc?Absolutely - we are working on getting it to compile on ldc and/or gdc.
May 21 2015
double foo(double b) { return b / (b == 0) == 0; } Looks like this fails too.
May 21 2015
On Thursday, May 21, 2015 08:28:29 Saurabh Das via Digitalmars-d-learn wrote:Am I correct in assuming that an internal error in the compiler should be filed as a bug report?Yes. You should never see an ICE, and the compiler should never segfault. So, whenever you see either of those happen, please report it. - Jonathan M Davis
May 21 2015