[Bug fortran/57628] New: spurious error: division by zero in if statement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57628 Bug ID: 57628 Summary: spurious error: division by zero in if statement Product: gcc Version: 4.7.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: furue at hawaii dot edu Dear gfortran maintainers, Division by zero causes error even when it's not executed: program try implicit NONE real, parameter:: a = 0.0 if (a 0) then write(*,*) 1/a end if end program try $ /usr/bin/gfortran tmp.f90 tmp.f90:5.16: write(*,*) 1/a 1 Error: Division by zero at (1) $ If it's difficult to give a correct diagnosis, please demote this to a warning. I have a lot of constructs like this because I change the parameter often and so this behavior of gfortran is very inconvenient (because I have to rewrite my source code to be able to compile it). Regards, Ryo
[Bug fortran/57628] spurious error: division by zero in if statement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57628 kargl at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||kargl at gcc dot gnu.org Resolution|--- |INVALID --- Comment #1 from kargl at gcc dot gnu.org --- (In reply to Ryo Furue from comment #0) Dear gfortran maintainers, Division by zero causes error even when it's not executed: But, it is evaluated at compile time, and so, you'll get the error. If it's difficult to give a correct diagnosis, please demote this to a warning. You are getting the correct diagnosis!
[Bug fortran/57628] spurious error: division by zero in if statement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57628 --- Comment #2 from Ryo Furue furue at hawaii dot edu --- Thank you for the prompt response! But, it is evaluated at compile time, and so, you'll get the error. I understand that. You are getting the correct diagnosis! Of course. I agree with all your statements. And your entirely entirely miss the point! This is a quality of implementation issue. Since my code includes an expression that can be evaluated at compile time and it's a division by zero, the compiler has the right to treat it as error. (But, that's my guess. What does the standard say? The standard doesn't have the notion of compile time, so I wonder how such a case as this is treated in the standard.) The question is Is refusing to compile it the best way to deal with this error? My answer is no. Since, real, parameter:: a = 0 If (a 0) then write(*,*) 1/a !! this part end if the contents of the IF statement is unreachable, the compiler more appropriately would issue an unreachable statements warning and disregard the contents of the unreachable code. In my opinion. Cheers, Ryo
[Bug fortran/57628] spurious error: division by zero in if statement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57628 --- Comment #3 from Ryo Furue furue at hawaii dot edu --- (In reply to kargl from comment #1) Thank you for the prompt response! [This is a re-post. I missed the reply feature and made a typo. I would delete the other post, if possible.] But, it is evaluated at compile time, and so, you'll get the error. I understand that. You are getting the correct diagnosis! Of course. I agree with all your statements. And your statements entirely miss the point! This is a quality of implementation issue. Since my code includes an expression that can be evaluated at compile time and it's a division by zero, the compiler has the right to treat it as error. (But, that's my guess. What does the standard say? The standard doesn't have the notion of compile time, so I wonder how such a case as this is treated in the standard.) The question is Is refusing to compile it the best way to deal with this error? My answer is no. Since, real, parameter:: a = 0 If (a 0) then write(*,*) 1/a !! this part end if the contents of the IF statement is unreachable, the compiler more appropriately would issue an unreachable statements warning and disregard the contents of the unreachable code. In my opinion. Cheers, Ryo
[Bug fortran/57628] spurious error: division by zero in if statement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57628 --- Comment #4 from Andrew Pinski pinskia at gcc dot gnu.org --- Since my code includes an expression that can be evaluated at compile time and it's a division by zero, parameter are special in fortran. The expression is evaluated at compile time because of the parameter. a has to be replaced with 0 according to the fortran standard which is why you are getting this error.
[Bug fortran/57628] spurious error: division by zero in if statement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57628 --- Comment #5 from Ryo Furue furue at hawaii dot edu --- (In reply to Andrew Pinski from comment #4) parameter are special in fortran. The expression is evaluated at compile time because of the parameter. a has to be replaced with 0 according to the fortran standard which is why you are getting this error. I understand that! And I've realized my mistake in saying spurious in the title of my submission. I apologize. But, my main point stands. There should be a compiler option (or something) that lets the code like my go. You could replace the expression 1.0/0.0 with an IEEE Inf and let the code go, couldn't you? As a quality of implementation issue, the current behavior of gfortran isn't ideal. Having said that, are you sure the standard states 1) that a parameter must be substituted at compile time? The standard doesn't have the notion of compile time. 2) that this code should be rejected by the compiler? I'm pretty sure that the standard doesn't say (2). The compiler states what is legal code and what is illegal. But it doesn't say what to do with an illegal code. Cheers, Ryo
[Bug fortran/57628] spurious error: division by zero in if statement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57628 --- Comment #6 from Ryo Furue furue at hawaii dot edu --- (In reply to Ryo Furue from comment #5) I'm correcting two typos. Sorry. (In reply to Andrew Pinski from comment #4) parameter are special in fortran. The expression is evaluated at compile time because of the parameter. a has to be replaced with 0 according to the fortran standard which is why you are getting this error. I understand that! And I've realized my mistake in saying spurious in the title of my submission. I apologize. But, my main point stands. There should be a compiler option (or something) that lets the code like my lets the code like mine go. go. You could replace the expression 1.0/0.0 with an IEEE Inf and let the code go, couldn't you? As a quality of implementation issue, the current behavior of gfortran isn't ideal. Having said that, are you sure the standard states 1) that a parameter must be substituted at compile time? The standard doesn't have the notion of compile time. 2) that this code should be rejected by the compiler? I'm pretty sure that the standard doesn't say (2). The compiler states what The standard states what is legal . . . is legal code and what is illegal. But it doesn't say what to do with an illegal code. Cheers, Ryo
[Bug c++/22149] func pointer non-type template parm invalid access control
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22149 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||mouchtaris at gmail dot com --- Comment #6 from Paolo Carlini paolo.carlini at oracle dot com --- *** Bug 50586 has been marked as a duplicate of this bug. ***
[Bug c++/50586] Template argument of type pointer to function of a template class causes usage error if template is instantiated with pointer-to-private-static-member-function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50586 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com --- Dup. *** This bug has been marked as a duplicate of bug 22149 ***
[Bug c++/57172] [C++11][DR 1164] Template overload resolution ambiguous for T versus T
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57172 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||glisse at gcc dot gnu.org --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com --- Patch passes testing. Are you going to send it to the mailing list?
[Bug c++/57172] [C++11][DR 1164] Template overload resolution ambiguous for T versus T
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57172 --- Comment #5 from Marc Glisse glisse at gcc dot gnu.org --- Not soon, sorry (I am in Brazil). Feel free to take it up (or use a different approach).
[Bug c++/56493] Performance regression in google dense hashmap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56493 --- Comment #13 from Jakub Jelinek jakub at gcc dot gnu.org --- Created attachment 30312 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30312action=edit gcc49-pr56493.patch Untested patch that in the FE restores the performance on the simplified testcase. Haven't tried the original. Of course, having this optimization be performed in GIMPLE will be much more worthwhile, but likely not backportable.
[Bug fortran/52473] CSHIFT slow - inline it?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52473 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-06-16 Ever confirmed|0 |1 --- Comment #3 from Dominique d'Humieres dominiq at lps dot ens.fr --- I don't have access to pathf95, but the following test (modified for some IDRIS benchmarks) subroutine test_cshift() !- ! Test de la fonction intrinsèque cshift !- implicit none integer, parameter :: n=ordre integer:: i,j integer, dimension(n) :: vect=(/ (-i, i=1,n) /) real(kind=prec),dimension(n,n) :: t,td,t2,t1 real(kind=prec):: cste call impression_entete(test_cshift) print *, Order of matrix:, n ! Initialisations -- cste=exp(1._prec) t(:,:) = reshape( source=(/ (i*cste,i=1,n*n) /) , shape = (/ n,n /) ) td(:,:) = 0._prec call cpu_time( val_temps(1) ) td(:,:) = cshift(array=t(:,:), shift=vect(:), dim=1) call cpu_time( val_temps(2) ) t1(:,:) = td(:,:) call temps_consomme(test_cshift 1) CSHIFT) ! Décalage selon les lignes via des boucles td(:,:) = 0._prec call cpu_time( val_temps(1) ) do j=1,n do i=n+vect(j),1,-1 td(i-vect(j),j) = t(i,j) end do do i=1,-vect(j) td(i,j)=t(n+vect(j)+i,j) end do end do call cpu_time( val_temps(2) ) t2(:,:) = td(:,:) call temps_consomme(test__cshift 2) DO loop) if (sum(abs(t2-t1)) /= 0._prec) then print *,'Mauvais résultats ',sum(abs(t2-t1)) else print *,'Results OK' end if end subroutine test_cshift gives Call to test_cshift Order of matrix:1000 test_cshift 1) CSHIFT Used CPU time == 7.624 ms test__cshift 2) DO loop Used CPU time == 4.482 ms Results OK So CSHIFT is 50% slower than the DO loop. Note that I get similar results for EOSHIFT and RESHAPE: = Call to test_eoshift = Order of matrix:1000 test_eoshift 1) EOSHIFT Used CPU time == 7.443 ms test__eoshift 2) DO loop Used CPU time == 3.775 ms Results OK = Call to test_reshape = Order of matrix:1000 test__reshape 1) RESHAPE Used CPU time ==10.624 ms test__reshape 2) DO loop Used CPU time == 4.442 ms Results OK PR45689 should probably fixed at the same time.
[Bug fortran/45689] [F2003] Missing transformational intrinsic in the trans_func_f2003 list
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45689 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-06-16 Ever confirmed|0 |1 --- Comment #5 from Dominique d'Humieres dominiq at lps dot ens.fr --- Related or duplicate of PR52473.
[Bug c/57629] New: -Wmaybe-uninitialized does not catch some conditional initialization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57629
Bug ID: 57629
Summary: -Wmaybe-uninitialized does not catch some conditional
initialization
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: nszabolcs at gmail dot com
In the following example gcc should be able to prove that
x may be uninitialized, but it does not warn.
$ gcc-4.8 -c -O2 -Wmaybe-uninitialized example.c
$ cat example.c
int f(void);
int g(void) {
int x;
if (f())
x = 1;
return x;
}
With -O2 the generated code actually unconditionally returns 1
and discards the return value of f().
This is something the compiler can and should warn about when
specifically asked to.
$ gcc-4.8 -S -fno-asynchronous-unwind-tables -O2 -Wmaybe-uninitialized
example.c
$ cat example.s
.file example.c
.text
.p2align 4,,15
.globl g
.type g, @function
g:
subl$12, %esp
callf
movl$1, %eax
addl$12, %esp
ret
.size g, .-g
.ident GCC: (GNU) 4.8.0
.section.note.GNU-stack,,@progbits
[Bug c++/57172] [C++11][DR 1164] Template overload resolution ambiguous for T versus T
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57172 --- Comment #6 from Paolo Carlini paolo.carlini at oracle dot com --- Oh well, it can certainly wait a bit, just let's not forget about it (patches only attached to bug reports make me slightly nervous) ... or you can and it over to Alex (Oliva) ;)
[Bug fortran/48776] ICE(segfault) after -std=f95 diagnostic error involving PROCEDURE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48776 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-06-16 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr --- Still present at revision 200128.
[Bug rtl-optimization/57569] [4.8/4.9 Regression] wrong code for struct copy at -O3 on x86_64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57569 Jorn Wolfgang Rennecke amylaar at gcc dot gnu.org changed: What|Removed |Added CC||amylaar at gcc dot gnu.org --- Comment #4 from Jorn Wolfgang Rennecke amylaar at gcc dot gnu.org --- Created attachment 30313 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30313action=edit testcase for gcc.dg/torture This is the testcase adapted to fit into the gcc.dg/torture framework. On i686-pc-linux-gnu, with svn revision 200126, I see the following results: PASS: gcc.dg/torture/pr57569.c -O0 (test for excess errors) PASS: gcc.dg/torture/pr57569.c -O0 execution test PASS: gcc.dg/torture/pr57569.c -O1 (test for excess errors) PASS: gcc.dg/torture/pr57569.c -O1 execution test PASS: gcc.dg/torture/pr57569.c -O2 (test for excess errors) PASS: gcc.dg/torture/pr57569.c -O2 execution test PASS: gcc.dg/torture/pr57569.c -O3 -fomit-frame-pointer (test for excess errors) FAIL: gcc.dg/torture/pr57569.c -O3 -fomit-frame-pointer execution test PASS: gcc.dg/torture/pr57569.c -O3 -fomit-frame-pointer -funroll-loops (test for excess errors) FAIL: gcc.dg/torture/pr57569.c -O3 -fomit-frame-pointer -funroll-loops execution test PASS: gcc.dg/torture/pr57569.c -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions (test for excess errors) FAIL: gcc.dg/torture/pr57569.c -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions execution test PASS: gcc.dg/torture/pr57569.c -O3 -g (test for excess errors) FAIL: gcc.dg/torture/pr57569.c -O3 -g execution test PASS: gcc.dg/torture/pr57569.c -Os (test for excess errors) PASS: gcc.dg/torture/pr57569.c -Os execution test PASS: gcc.dg/torture/pr57569.c -O2 -flto -fno-use-linker-plugin -flto-partition=none (test for excess errors) PASS: gcc.dg/torture/pr57569.c -O2 -flto -fno-use-linker-plugin -flto-partition=none execution test PASS: gcc.dg/torture/pr57569.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects (test for excess errors) PASS: gcc.dg/torture/pr57569.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects execution test
[Bug fortran/55907] [4.7/4.8/4.9 Regression] ICE with -fno-automatic -finit-local-zero
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55907 --- Comment #8 from Dominique d'Humieres dominiq at lps dot ens.fr --- The patch in comment 5 regtests cleanly! Confirmed. Any reason why it has not been committed?
[Bug fortran/50221] Allocatable string length fails with array assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50221 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Keywords||wrong-code Status|UNCONFIRMED |NEW Last reconfirmed||2013-06-16 Ever confirmed|0 |1 --- Comment #3 from Dominique d'Humieres dominiq at lps dot ens.fr --- Still present at revision 200128.
[Bug fortran/57628] spurious error: division by zero in if statement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57628 --- Comment #7 from Dominique d'Humieres dominiq at lps dot ens.fr --- AFAICT the option -fno-range-check is what you are looking for.
[Bug fortran/48298] [F03] User-Defined Derived-Type IO (DTIO)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48298 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-06-16 Ever confirmed|0 |1 --- Comment #6 from Dominique d'Humieres dominiq at lps dot ens.fr --- Any progress with this PR?
[Bug fortran/41370] Function return-type declaration with specification expression rejected
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41370 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-06-16 Ever confirmed|0 |1 --- Comment #3 from Dominique d'Humieres dominiq at lps dot ens.fr --- Since gfortran 4.8, the errors are now pr41370_1.f90:6.19: character(len=mt%i) function foo(mt) 1 Error: Symbol 'mt' at (1) has no IMPLICIT type pr41370_1.f90:7.29: type(t), intent(in) :: mt 1 Error: Unexpected data declaration statement in CONTAINS section at (1) pr41370_1.f90:8.5: end function foo 1 Error: Expecting END MODULE statement at (1) for the test in comment #0 and pr41370_1.f90:6.19: character(len=mt%i) function foo(mt) 1 Error: Symbol 'mt' at (1) has no IMPLICIT type pr41370_1.f90:7.29: type(t), intent(in) :: mt 1 Error: Unexpected data declaration statement in CONTAINS section at (1) pr41370_1.f90:8.5: end function foo 1 Error: Expecting END MODULE statement at (1) for the test in comment #1.
[Bug c/19541] need another option to support what -I- did just besides -iquote
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19541 --- Comment #23 from Rodolfo Schulz de Lima rodolfo at rodsoft dot org --- How difficult is it to add a parameter to add paths to precompiled header search list *only*? We have a big code base with #include pch.h in some source files. If source file directory is always searched first for headers, this breaks out-of-source builds, unless the precompiled header is generated in the source tree. For read-only source trees, this solution is unacceptable. The ideal solution would be a parameter like -ipch path that adds path to be searched for precompiled headers *before* the current source directory. I could spend some time creating a patch, but seeing that others have come with patches that weren't applied, this kind of demotivate me.
[Bug fortran/57628] spurious error: division by zero in if statement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57628 --- Comment #8 from Steve Kargl sgk at troutmask dot apl.washington.edu --- On Sun, Jun 16, 2013 at 07:57:23AM +, furue at hawaii dot edu wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57628 --- Comment #2 from Ryo Furue furue at hawaii dot edu --- Of course. I agree with all your statements. And your entirely entirely miss the point! No, I did not miss your point. This is a quality of implementation issue. So, the compiler should just arbitrarily chose to evaluate some expression and ignore others? The question is Is refusing to compile it the best way to deal with this error? My answer is no. Since, real, parameter:: a = 0 If (a 0) then So, the compiler should evaluate a 0, but it should write(*,*) 1/a !! this part not evaluate 1/a. end if the contents of the IF statement is unreachable, the compiler more appropriately would issue an unreachable statements warning and disregard the contents of the unreachable code. DCE will take care of unreachable code in the middle-end. Just remove the PARAMETER attribute in your code, it it will do what you. real :: a = 0 if (a 0) then print *, 1/a else print *, 'doh!' end if end
[Bug tree-optimization/18501] [4.7/4.8/4.9 Regression] Missing 'used uninitialized' warning (CCP)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18501 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added CC||nszabolcs at gmail dot com --- Comment #62 from Manuel López-Ibáñez manu at gcc dot gnu.org --- *** Bug 57629 has been marked as a duplicate of this bug. ***
[Bug c/57629] -Wmaybe-uninitialized does not catch some conditional initialization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57629 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||manu at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #1 from Manuel López-Ibáñez manu at gcc dot gnu.org --- Dup *** This bug has been marked as a duplicate of bug 18501 ***
[Bug c++/13452] No error on invalid (I think) C++ code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13452 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC|gcc-bugs at gcc dot gnu.org| Severity|minor |normal
[Bug c++/26143] accepts invalid function pointer type return
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26143 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |RESOLVED CC|gcc-bugs at gcc dot gnu.org| Resolution|--- |DUPLICATE Known to fail|| --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com --- Dup. *** This bug has been marked as a duplicate of bug 13452 ***
[Bug c++/13452] No error on invalid (I think) C++ code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13452 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||mark at halcy0n dot com --- Comment #6 from Paolo Carlini paolo.carlini at oracle dot com --- *** Bug 26143 has been marked as a duplicate of this bug. ***
[Bug c++/57614] Friend declaration and qualified class member access
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57614 Daniel Krügler daniel.kruegler at googlemail dot com changed: What|Removed |Added CC||daniel.kruegler@googlemail. ||com --- Comment #1 from Daniel Krügler daniel.kruegler at googlemail dot com --- This problem also exists for gcc 4.9.0 20130609 (experimental)
[Bug c++/57626] [C++11] ICE with template alias and member function pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57626 Daniel Krügler daniel.kruegler at googlemail dot com changed: What|Removed |Added CC||daniel.kruegler@googlemail. ||com --- Comment #1 from Daniel Krügler daniel.kruegler at googlemail dot com --- An ICE also exists with gcc 4.9.0 20130609 (experimental), but the diagnostics is quite different for me: main.cpp|8|internal compiler error: tree check: accessed elt 3 of tree_vec with 2 elts in tsubst_pack_expansion, at cp/pt.c:9402
[Bug libfortran/48787] Invalid UP/DOWN rounding with F editing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48787 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-06-16 Ever confirmed|0 |1 --- Comment #29 from Dominique d'Humieres dominiq at lps dot ens.fr --- AFAICT the only remaining issue is the test in comment #22 print (RU,F7.0), 7500.0 ! 8. expected 7500. print (RD,F7.0), -7500.0 ! -8. expected -7500. which gives 7501. -7501. with 4.6 and 8. -8. with 4.7 and above.
[Bug libfortran/48906] Wrong rounding results with -m32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48906 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2013-06-16 Ever confirmed|0 |1 --- Comment #40 from Dominique d'Humieres dominiq at lps dot ens.fr --- This PR seems to have been fixed from 4.7.3 up to trunk. Could it be closed as fixed or is there some issue I am missing?
[Bug libstdc++/57263] std::set with user-defined allocator - compile error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57263 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|4.8.2 |4.9.0 --- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org --- This has been fixed for the containers that support the allocator-aware requirements: vector (which was already correct), forward_list and unordered_* I'll make sure it works when std::list and other containers are updated to meet the requirements. PR 57272 exists to deal with another custom pointer issue.
[Bug fortran/42934] Bogus variable_check
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42934 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2013-06-16 Ever confirmed|0 |1 --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr --- What result do you expect? Is it a 4.6/4.7 regression? Ping!
[Bug fortran/42934] Bogus variable_check
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42934 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #3 from Dominique d'Humieres dominiq at lps dot ens.fr --- No answer since over a year and the code in comment #0 seems to be gone. Finally closing as fixed. Please reopen if I am missing something.
[Bug fortran/55117] Programs fails to read namelist (contains derived types objects)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55117 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-06-16 Ever confirmed|0 |1 --- Comment #23 from Dominique d'Humieres dominiq at lps dot ens.fr --- Created attachment 29938 [details] FE patch for namelist read with type extension (+ test case) What happened to this patch?
[Bug fortran/41827] [Cleanup] Remove SET_EXPR_LOCATION in gfc_trans_code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41827 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2013-06-16 Ever confirmed|0 |1 --- Comment #4 from Dominique d'Humieres dominiq at lps dot ens.fr --- Moving to waiting.
[Bug fortran/45288] Double initialization: Warn if the value is different
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45288 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr --- *** Bug 49586 has been marked as a duplicate of this bug. *** --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr --- *** Bug 49586 has been marked as a duplicate of this bug. ***
[Bug fortran/45288] Double initialization: Warn if the value is different
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45288 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr --- *** Bug 49586 has been marked as a duplicate of this bug. *** --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr --- *** Bug 49586 has been marked as a duplicate of this bug. ***
[Bug fortran/49586] Multiple initialization with DATA: Warning and initialization order
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49586 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #7 from Dominique d'Humieres dominiq at lps dot ens.fr --- Duplicate of pr45288. *** This bug has been marked as a duplicate of bug 45288 *** --- Comment #8 from Dominique d'Humieres dominiq at lps dot ens.fr --- Duplicate of pr45288. *** This bug has been marked as a duplicate of bug 45288 ***
[Bug fortran/49586] Multiple initialization with DATA: Warning and initialization order
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49586 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #7 from Dominique d'Humieres dominiq at lps dot ens.fr --- Duplicate of pr45288. *** This bug has been marked as a duplicate of bug 45288 ***
[Bug fortran/45288] Double initialization: Warn if the value is different
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45288 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-06-16 Ever confirmed|0 |1 --- Comment #3 from Dominique d'Humieres dominiq at lps dot ens.fr --- Confirmed.
[Bug c++/57614] Friend declaration and qualified class member access
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57614 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-06-16 Ever confirmed|0 |1
[Bug c/57630] New: Error should include -std=c11 and friends
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57630 Bug ID: 57630 Summary: Error should include -std=c11 and friends Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: minor Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: lailavrazda1979 at gmail dot com The following message: error: 'for' loop initial declarations are only allowed in C99 mode minigen.c:88:2: note: use option -std=c99 or -std=gnu99 to compile your code should include -std=c11 and friends.
[Bug fortran/47674] gfortran.dg/realloc_on_assign_5.f03: Segfault at run time for deferred (allocatable) string length
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47674 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-06-16 Ever confirmed|0 |1 --- Comment #4 from Dominique d'Humieres dominiq at lps dot ens.fr --- Confirmed.
[Bug fortran/40756] Cleanup TREE_BLOCK
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40756 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 --- The patch at http://gcc.gnu.org/ml/gcc-patches/2009-07/msg00822.html no longer applies on trunk. Closing as fixed. Please reopen if I am missing something.
[Bug fortran/41724] PUREness/ELEMENTAL check missing for ACTUAL/DUMMY conformance
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41724 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2013-06-16 Ever confirmed|0 |1 --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr --- The test A is rejected by 4.5 up to trunk. The tests B and C are rejected by 4.6 up to trunk with pr41724_1.f90:29.13: call test(my_dcos) 1 Error: Interface mismatch in dummy procedure 'fun' at (1): Mismatch in PURE attribute except 4.6 which rejects them with pr41724_1.f90:29.13: call test(my_dcos) 1 Error: Expected a PURE procedure for argument 'fun' at (1) Is it still an issue?
[Bug c/57621] attribute error is interpreted even if it is switched with __builtin_constant_p on -Og
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57621 Hans-Peter Nilsson hp at gcc dot gnu.org changed: What|Removed |Added CC||hp at gcc dot gnu.org, ||pinskia at gcc dot gnu.org --- Comment #2 from Hans-Peter Nilsson hp at gcc dot gnu.org --- (In reply to Andrew Pinski from comment #1) Dup. I presume you refer to PR56977? Shouldn't this be marked resolved/duplicate, then, instead of resolved/fixed?
[Bug middle-end/56977] gcc -Og incorrectly warns about 'constant zero length parameter'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56977 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added CC||naruse at airemix dot jp --- Comment #3 from Andrew Pinski pinskia at gcc dot gnu.org --- *** Bug 57621 has been marked as a duplicate of this bug. ***
[Bug c/57621] attribute error is interpreted even if it is switched with __builtin_constant_p on -Og
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57621 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Resolution|FIXED |DUPLICATE --- Comment #3 from Andrew Pinski pinskia at gcc dot gnu.org --- (In reply to Hans-Peter Nilsson from comment #2) (In reply to Andrew Pinski from comment #1) Dup. I presume you refer to PR56977? Shouldn't this be marked resolved/duplicate, then, instead of resolved/fixed? That was my browser's fault it seems. I wanted to mark it as a dup but somehow it did not do that. *** This bug has been marked as a duplicate of bug 56977 ***
[Bug fortran/41599] [OOP] SELECT TYPE with associate-name = exp: Use (sometimes) a restricted pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41599 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2013-06-16 Ever confirmed|0 |1 --- Comment #3 from Dominique d'Humieres dominiq at lps dot ens.fr --- Both type t integer :: item end type !type(t),allocatable :: a class(t),allocatable :: bar allocate(t::bar) !allocate(t::a%bar) select type (foo = bar) type is (t) foo%item = 8 bar%item = 9 print *, foo%item, bar%item end select end and type t integer :: item integer, allocatable :: bar end type type t2 class(t),allocatable :: bar end type t2 type(t2), pointer :: a allocate(a) allocate(t::a%bar) select type (foo = a%bar) type is (t) foo%item = 8 a%bar%item = 9 print *, foo%item, a%bar%item end select end prints 9 9 It is what I'ld expect, but I don't know if the codes are valid. Compiling type t integer :: item integer, allocatable :: bar end type type t2 class(t) :: bar end type t2 type(t2) :: a allocate(t::a%bar) select type (foo = a%bar) type is (t) foo%item = 8 a%bar%item = 9 end select end gives an ICE Program received signal SIGSEGV, Segmentation fault. 0x0001000b9cc2 in gfc_type_compatible (ts1=value optimized out, ts2=value optimized out) at ../../work/gcc/fortran/symbol.c:4483 4483 ts1-u.derived-components-ts.u.derived-attr.unlimited_polymorphic) (gdb) bt #0 0x0001000b9cc2 in gfc_type_compatible (ts1=value optimized out, ts2=value optimized out) at ../../work/gcc/fortran/symbol.c:4483 #1 0x00010006b413 in gfc_match_allocate () at ../../work/gcc/fortran/match.c:3552 #2 0x00010007f61a in match_word (subr=value optimized out, old_locus=0x7fff5fbfd330, str=value optimized out) at ../../work/gcc/fortran/parse.c:65 #3 0x000100081ff5 in decode_statement () at ../../work/gcc/fortran/parse.c:383 #4 0x00010008253a in next_statement () at ../../work/gcc/fortran/parse.c:784 #5 0x00010008335d in parse_spec (st=value optimized out) at ../../work/gcc/fortran/parse.c:2741 #6 0x000100085599 in parse_progunit (st=value optimized out) at ../../work/gcc/fortran/parse.c:4121 #7 0x0001000866cc in gfc_parse_file () at ../../work/gcc/fortran/parse.c:4637 #8 0x0001000c6ea6 in gfc_be_parse_file () at ../../work/gcc/fortran/f95-lang.c:189 #9 0x00010078dd54 in compile_file () at ../../work/gcc/toplev.c:544 #10 0x00010078fe49 in toplev_main (argc=2, argv=0x7fff5fbfd718) at ../../work/gcc/toplev.c:1872 #11 0x0001a804 in start (pc=value optimized out, bases=0x0) at ../../../work/libgcc/config/unwind-dw2-fde-darwin.c:272
[Bug fortran/52333] Explicit etime interface should work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52333 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX --- Comment #8 from Dominique d'Humieres dominiq at lps dot ens.fr --- Closing as WONTFIX. Please reopen if you disagree.
[Bug fortran/52651] Fortran testsuite ICEs with -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52651 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-06-16 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr --- Still present at revision 200133.
[Bug target/57631] New: spurious warning for avr interrupts with asm labels
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57631
Bug ID: 57631
Summary: spurious warning for avr interrupts with asm labels
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: pebbles at riseup dot net
Hi,
Currently AVR interrupts do not mix well with asm labels, as:
// test.c ...
__attribute__((signal,used))
void __vector_1() { asm(); }
__attribute__((signal,used))
void pretendName() asm(__vector_2);
void pretendName() { asm(); }
// ... test.c
Gives:
$ avr-gcc test.c -S
test.c: In function ‘pretendName’:
test.c:6:6: warning: ‘pretendName’ appears to be a misspelled signal handler
[enabled by default]
'__vector_1' is accepted by the compiler fine, but 'pretendName' is rejected.
A quick view of test.s shows 'pretendName' is correctly translated to
'__vector_2'.
If one adds a main() function to test.c, links and objdumps the result, both
functions are properly inserted into the interrupt table.
There is no misspelling here. This warning should not be issued, and makes
-Werror die.
I'm on Debian Squeeze. I've tried with this version of gcc:
COLLECT_GCC=avr-gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/avr/4.7.2/lto-wrapper
Target: avr
Configured with: ../src/configure -v --enable-languages=c,c++ --prefix=/usr/lib
--infodir=/usr/share/info --mandir=/usr/share/man --bindir=/usr/bin
--libexecdir=/usr/lib --libdir=/usr/lib --enable-shared --with-system-zlib
--enable-long-long --enable-nls --without-included-gettext --disable-libssp
--build=i486-linux-gnu --host=i486-linux-gnu --target=avr
Thread model: single
gcc version 4.7.2 (GCC)
And also with trunk:
Using built-in specs.
COLLECT_GCC=/home/username/build/avr-gcc-master/bin/bin/avr-gcc
COLLECT_LTO_WRAPPER=/home/username/build/avr-gcc-master/bin/libexec/gcc/avr/4.9.0/lto-wrapper
Target: avr
Configured with: src/configure -v --enable-languages=c,c++
--prefix=/home/username/build/avr-gcc-master/bin --enable-shared
--with-system-zlib --enable-long-long --enable-nls --without-included-gettext
--disable-libssp --target=avr
Thread model: single
gcc version 4.9.0 20130614 (experimental) (GCC)
[Bug fortran/53296] Segfault on non-constant character array constructor containing kind spec
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53296 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-06-16 Ever confirmed|0 |1 --- Comment #3 from Dominique d'Humieres dominiq at lps dot ens.fr --- Still present at revision 200133.
[Bug c++/42067] Misleading error message for misusing a type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42067 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC|gcc-bugs at gcc dot gnu.org| Known to work||4.8.0, 4.9.0 Resolution|--- |FIXED --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com --- I think it's safe to say that this is fixed.
[Bug target/57631] spurious warning for avr interrupts with asm labels
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57631
--- Comment #1 from pebbles at riseup dot net ---
Here is a more complete test:
// test.c ...
__attribute__((signal,used))
void __vector_1() { asm(); } // should not trigger warning, should be placed
in __vectors
__attribute__((signal,used))
void pretendName() asm(__vector_2);
void pretendName() { asm(); } // should not trigger warning, should be placed
in __vectors
__attribute__((signal,used))
void __victor_3() { asm(); } // should trigger warning, not be placed in
__vectors
__attribute__((signal,used))
void __vector_4() asm(__victor_4);
void __vector_4() { asm(); } // should trigger warning, not be placed in
__vectors
int main() { return 0; }
// ... test.c
Really, I feel this should either be a disableable warning (if users are
expected to create interrupts and signals that will not be placed in the IV) or
an error.
[Bug fortran/57628] spurious error: division by zero in if statement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57628 --- Comment #9 from Ryo Furue furue at hawaii dot edu --- (In reply to Steve Kargl from comment #8) So, the compiler should just arbitrarily chose to evaluate some expression and ignore others? No, I don't mean that. I'm not saying which expression the compiler should evaluate. What I'm saying is, what is the best way to deal with the result of the evaluation? The compiler can (or should?) evaluate 1/a at compile time if a is a parameter. But, it's useful to provide an option that allows the compiler to let the code pass even if a == 0 (with a warning message, perhaps). That's what I argue. I don't think the compiler must evaluate 1/a or a0 at compile time. It's at the compiler's discretion. But, whatever it does should be maximally useful (as long as the chosen behavior does not violate the Fortran standard). Just remove the PARAMETER attribute in your code, it it will do what you. real :: a = 0 if (a 0) then print *, 1/a [. . .] Yes, I was about to come to that! I write my code that way because I plan to provide the value of a from an external module in the future. Currently I set the value with PARAMETER just as a convenience during the development of the code. So, you are right, that your solution is one workaround for my situation. But, I feel strongly uneasy looking at the code because real::a = 0 is a strong indication that the value of a will be altered after the definition. The codes we are showing in this message exchange are shortened versions and in my real codes, there are some lines between real, parameter:: a = 0 and the IF statement. When I see real:: a = 0.0, I expect the value of a will be altered because I don't see PARAMETER. Also, I still don't like this (sort of) inconsistency. It's more natural to expect the outcome of the code be the same whether it's real, parameter:: a = 0 or real:: a = 0. Another example is, real, parameter:: a = -1.0 if (a 0) write(*,*) sqrt(a) This does not compile. If we replace sqrt with yoursqrt, it compiles. (I know the reason why gfortran does this. That's not my question.) Overall, I think this kind of thing is better be a warning and that at least the compiler should allow the user to run such a code as this. The result of the run may be a disaster but it's the user's responsibility. To refuse to compile these codes is too much patronizing on the part of the compiler. Cheers, Ryo P.S. How does this interact with the IEEE support of F2003? I may be wrong, but I thought that replacing 1.0/0.0 with Inf at compile time would be a useful extension (without violating the Fortran standard, of course). Again, I'm not saying the compiler must do this. All I'm saying is that it may be useful.
[Bug fortran/57628] spurious error: division by zero in if statement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57628 --- Comment #10 from Ryo Furue furue at hawaii dot edu --- (In reply to Dominique d'Humieres from comment #7) AFAICT the option -fno-range-check is what you are looking for. Thanks! That's exactly it. But, I'm curious. The following code still fails to compile even with -fno-range-check : program try real, parameter:: a = -1.0 if (a 0) then write(*,*) sqrt(a) end if end program try $ gfortran -fno-range-check tmp.f90 tmp.f90:4.20: write(*,*) sqrt(a) 1 Error: Argument of SQRT at (1) has a negative value $ Is this an inconsistency in the implementation of -no-range-check ? I would be nice if there were an option to demote this type of error to a warning. Cheers, Ryo
[Bug target/57631] spurious warning for avr interrupts with asm labels
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57631 --- Comment #2 from pebbles at riseup dot net --- Created attachment 30314 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30314action=edit avr.c: avr_set_current_function: 'name' uses assembler name if set
[Bug rtl-optimization/55190] [SH] ivopts causes loop setup bloat
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55190
Oleg Endo olegendo at gcc dot gnu.org changed:
What|Removed |Added
Component|target |rtl-optimization
--- Comment #2 from Oleg Endo olegendo at gcc dot gnu.org ---
Looking at a simpler case (with -O2)
int test_0 (int* x, int y)
{
int sum = 0;
for (int i = 0; i y; ++i)
sum += x[i];
return sum;
}
cmp/pl r5
bf/s.L6
mov #0,r0
shll2 r5
add #-4,r5
shlr2 r5
add #1,r5// r5 = unsigned int)y 2) - 4) 2) + 1
.align 2
.L3:
mov.l @r4+,r1
dt r5
bf/s.L3
add r1,r0
.L6:
rts
nop
In this case, if 'y' initially has the value '0x7FFF' the resulting loop
count is truncated to '0x3FFF'. This is sort of OK, since the resulting
address would overflow and that is undefined behavior.
On the other hand, if an unlucky address for 'x' is passed in the first place,
the resulting address might overflow much earlier than that. Thus the loop
counter fiddling seems pointless.
The tree-ssa-ivopts pass converts the loop to this:
Replacing exit test: if (y_3(D) i_11)
int test_0(int*, int) (int * x, int y)
{
unsigned int ivtmp.6;
int i;
int sum;
unsigned int i.0;
unsigned int _1;
void * _2;
int _9;
unsigned int _19;
unsigned int _20;
unsigned int _21;
bb 2:
if (y_3(D) 0)
goto bb 3;
else
goto bb 7;
bb 3:
ivtmp.6_12 = (unsigned int) x_6(D);
_1 = (unsigned int) y_3(D);
_21 = _1 * 4;
_20 = (unsigned int) x_6(D);
_19 = _20 + _21;
bb 4:
# sum_16 = PHI sum_10(6), 0(3)
# ivtmp.6_15 = PHI ivtmp.6_14(6), ivtmp.6_12(3)
_2 = (void *) ivtmp.6_15;
_9 = MEM[base: _2, offset: 0B];
sum_10 = _9 + sum_16;
ivtmp.6_14 = ivtmp.6_15 + 4;
if (ivtmp.6_14 != _19)
goto bb 6;
else
goto bb 5;
bb 5:
# sum_18 = PHI sum_10(4)
goto bb 7;
bb 6:
goto bb 4;
bb 7:
# sum_13 = PHI sum_18(5), 0(2)
return sum_13;
}
... which uses address '(x + y * 4)' as the loop exit test.
It is expanded to RTL as '(x + (y 2))'
;; Generating RTL for gimple basic block 3
;; ivtmp.6_12 = (unsigned int) x_6(D);
(insn 38 37 0 (set (reg:SI 190 [ ivtmp.6 ])
(reg/v/f:SI 194 [ x ])) -1
(nil))
;; _19 = ivtmp.6_12 + _21;
(insn 39 38 40 (set (reg:SI 196 [ D.1617 ])
(ashift:SI (reg/v:SI 195 [ y ])
(const_int 2 [0x2]))) -1
(nil))
(insn 40 39 0 (set (reg:SI 191 [ D.1617 ])
(plus:SI (reg:SI 190 [ ivtmp.6 ])
(reg:SI 196 [ D.1617 ]))) -1
(nil))
... and remains until the loop2_doloop RTL pass, which converts the whole thing
into a decrement-and-test loop and adds the other loop counter modifications:
Analyzing operand (reg:SI 191 [ D.1617 ]) of insn (insn 45 44 46 4 (set (reg:SI
147 t)
(eq:SI (reg:SI 190 [ ivtmp.6 ])
(reg:SI 191 [ D.1617 ]))) sh_tmp.cpp:5 17 {cmpeqsi_t}
(expr_list:REG_DEAD (reg:SI 191 [ D.1617 ])
(nil)))
invariant (reg:SI 191 [ D.1617 ]) (in SI)
;; improved upper bound by one.
;; Determined upper bound -2.
Loop 1 is simple:
simple exit 4 - 7
number of iterations: (lshiftrt:SI (plus:SI (minus:SI (reg:SI 191 [ D.1617 ])
(reg:SI 190 [ ivtmp.6 ]))
(const_int -4 [0xfffc]))
(const_int 2 [0x2]))
upper bound: 1073741822
realistic bound: -1
The code in loop-iv.c works out the correct loop count if it gets the actual
loop count upper bound instead of the truncated address upper bound if the
tree-ssa-ivopts pass is turned off via -fno-ivopts.
I have also tried out the same code on ARM:
cmp r1, #0
ble .L4
mov r3, r0
add r1, r0, r1, asl #2
mov r0, #0
.L3:
ldr r2, [r3], #4
cmp r3, r1
add r0, r0, r2
bne .L3
bx lr
.L4:
mov r0, #0
bx lr
Since there is no doloop pattern on ARM, the code is left as it was output by
the tree-ssa-ivopts pass, i.e. the exit test uses 'x + (y 2)'.
So this doesn't seem to be a SH only issue. However, I'm not sure whether this
is more a problem of tree-ssa-ivopts or loop-iv.
If the tree-ssa-ivopts pass left the loop counter alone, the doloop pass would
pick it up and the upper bound calculations in this case would go away.
However, targets that can do better without doloop (such as ARM) would probably
suffer. So probably it would be better to handle this overflow case in
loop-iv.
[Bug fortran/44672] [F2008] ALLOCATE with SOURCE and no array-spec
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44672 Sean Santos quantheory at gmail dot com changed: What|Removed |Added CC||quantheory at gmail dot com --- Comment #2 from Sean Santos quantheory at gmail dot com --- Actually, this looks like a duplicate of 44529, although that one is tagged F03 when it should be F2008.
[Bug fortran/45440] [F03] ALLOCATE with SOURCE gives an ICE (segfault)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45440 Sean Santos quantheory at gmail dot com changed: What|Removed |Added CC||quantheory at gmail dot com --- Comment #10 from Sean Santos quantheory at gmail dot com --- If it should be an error to specify both a shape spec and a source array, then that's something that's only come up with this bug. Everything else is probably a duplicate of PR 44672 or PR 44529. However, you have to be careful, since it is legal to specify a shape spec and a source scalar, e.g.: integer, allocatable :: a(:) integer :: b = 2 allocate(a(3), source=b) print *,a end
[Bug fortran/57628] spurious error: division by zero in if statement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57628 --- Comment #11 from Steve Kargl sgk at troutmask dot apl.washington.edu --- On Sun, Jun 16, 2013 at 11:28:36PM +, furue at hawaii dot edu wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57628 --- Comment #9 from Ryo Furue furue at hawaii dot edu --- (In reply to Steve Kargl from comment #8) So, the compiler should just arbitrarily chose to evaluate some expression and ignore others? No, I don't mean that. I'm not saying which expression the compiler should evaluate. What I'm saying is, what is the best way to deal with the result of the evaluation? I think you found the answer. gfortran issues an error, so a user has the chance to fix her code. Just remove the PARAMETER attribute in your code, it it will do what you. real :: a = 0 if (a 0) then print *, 1/a [. . .] Yes, I was about to come to that! I write my code that way because I plan to provide the value of a from an external module in the future. Currently I set the value with PARAMETER just as a convenience during the development of the code. So, you are right, that your solution is one workaround for my situation. But, I feel strongly uneasy looking at the code because real::a = 0 is a strong indication that the value of a will be altered after the definition. Fortunately, Fortran allows more than a single character in a variable name (and comments). ! ! This a flag set by the programmer prior to compilation. ! Description of what the flag does goes here real :: immutable_flag = 0 The codes we are showing in this message exchange are shortened versions and in my real codes, there are some lines between real, parameter:: a = 0 and the IF statement. When I see real:: a = 0.0, I expect the value of a will be altered because I don't see PARAMETER. Not if the code is properly commented and the variable is suitably named. Overall, I think this kind of thing is better be a warning and that at least the compiler should allow the user to run such a code as this. The result of the run may be a disaster but it's the user's responsibility. To refuse to compile these codes is too much patronizing on the part of the compiler. I think that it is better to issue an error. but I thought that replacing 1.0/0.0 with Inf at compile time would be a useful extension (without violating the Fortran standard, of course). Again, I'm not saying the compiler must do this. All I'm saying is that it may be useful. gfortran does not support the IEEE 2003 standard. No one has stepped up to the plate. Here's your chance to make gfortran doe whatever you think the standard mandates.
[Bug fortran/57628] spurious error: division by zero in if statement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57628 --- Comment #12 from Steve Kargl sgk at troutmask dot apl.washington.edu --- On Sun, Jun 16, 2013 at 11:33:49PM +, furue at hawaii dot edu wrote: Is this an inconsistency in the implementation of -no-range-check ? No. I would be nice if there were an option to demote this type of error to a warning. Not going to happen.
[Bug c++/57632] New: Operator new overloads with stdc++11 enabled looses exception specifier (MacOsX)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57632 Bug ID: 57632 Summary: Operator new overloads with stdc++11 enabled looses exception specifier (MacOsX) Product: gcc Version: 4.8.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: b...@odd-e.com G++ on MacOsX acts different when enabling the new c++11 related to operator new overloads. If I compile the following code: #include stdlib.h #include new void* operator new(size_t mem) throw(std::bad_alloc); void* operator new(size_t mem) throw(std::bad_alloc); Then when compiling g++ new.cpp, it compiles fine. But when I compile g++ -std=c++11 new.cpp, then it results in this error: new.cpp:6:52: error: declaration of ‘void* operator new(size_t) throw (std::bad_alloc)’ has a different exception specifier void* operator new(size_t mem) throw(std::bad_alloc); ^ new.cpp:5:7: error: from previous declaration ‘void* operator new(std::size_t)’ void* operator new(size_t mem) throw(std::bad_alloc); ^ I've not been able to replicate this under linux and digging into it a bit, it seems to relate to the c++config.h definitions of _GLIBCXX_THROW.
