[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 --- 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 --- (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 --- >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 --- (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 --- (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 changed: What|Removed |Added CC||mouchtaris at gmail dot com --- Comment #6 from Paolo Carlini --- *** 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 changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Paolo Carlini --- Dup. *** This bug has been marked as a duplicate of bug 22149 ***
gcc-bugs@gcc.gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57172 Paolo Carlini changed: What|Removed |Added CC||glisse at gcc dot gnu.org --- Comment #4 from Paolo Carlini --- Patch passes testing. Are you going to send it to the mailing list?
gcc-bugs@gcc.gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57172 --- Comment #5 from Marc Glisse --- 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 --- Created attachment 30312 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30312&action=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 changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2013-06-16
Ever confirmed|0 |1
--- Comment #3 from Dominique d'Humieres ---
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 changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-06-16 Ever confirmed|0 |1 --- Comment #5 from Dominique d'Humieres --- 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
gcc-bugs@gcc.gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57172 --- Comment #6 from Paolo Carlini --- 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 changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-06-16 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- 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 changed: What|Removed |Added CC||amylaar at gcc dot gnu.org --- Comment #4 from Jorn Wolfgang Rennecke --- Created attachment 30313 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30313&action=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 --- > 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 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 --- 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 --- 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 changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-06-16 Ever confirmed|0 |1 --- Comment #6 from Dominique d'Humieres --- 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 changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-06-16 Ever confirmed|0 |1 --- Comment #3 from Dominique d'Humieres --- 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 --- 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 that adds 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 --- 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 --- > > 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 changed: What|Removed |Added CC||nszabolcs at gmail dot com --- Comment #62 from Manuel López-Ibáñez --- *** 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 changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||manu at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #1 from Manuel López-Ibáñez --- 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 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 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 --- 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 changed: What|Removed |Added CC||mark at halcy0n dot com --- Comment #6 from Paolo Carlini --- *** 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 changed: What|Removed |Added CC||daniel.kruegler@googlemail. ||com --- Comment #1 from Daniel Krügler --- 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 changed: What|Removed |Added CC||daniel.kruegler@googlemail. ||com --- Comment #1 from Daniel Krügler --- 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 changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-06-16 Ever confirmed|0 |1 --- Comment #29 from Dominique d'Humieres --- 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 changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2013-06-16 Ever confirmed|0 |1 --- Comment #40 from Dominique d'Humieres --- 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 changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|4.8.2 |4.9.0 --- Comment #4 from Jonathan Wakely --- 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 changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2013-06-16 Ever confirmed|0 |1 --- Comment #2 from Dominique d'Humieres --- > 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 changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #3 from Dominique d'Humieres --- 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 changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-06-16 Ever confirmed|0 |1 --- Comment #23 from Dominique d'Humieres --- > 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 changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2013-06-16 Ever confirmed|0 |1 --- Comment #4 from Dominique d'Humieres --- 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 --- *** Bug 49586 has been marked as a duplicate of this bug. *** --- Comment #2 from Dominique d'Humieres --- *** 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 --- *** Bug 49586 has been marked as a duplicate of this bug. *** --- Comment #2 from Dominique d'Humieres --- *** 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 changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #7 from Dominique d'Humieres --- Duplicate of pr45288. *** This bug has been marked as a duplicate of bug 45288 *** --- Comment #8 from Dominique d'Humieres --- 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 changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #7 from Dominique d'Humieres --- 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 changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-06-16 Ever confirmed|0 |1 --- Comment #3 from Dominique d'Humieres --- Confirmed.
[Bug c++/57614] Friend declaration and qualified class member access
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57614 Paolo Carlini 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 changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-06-16 Ever confirmed|0 |1 --- Comment #4 from Dominique d'Humieres --- Confirmed.
[Bug fortran/40756] Cleanup TREE_BLOCK
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40756 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #1 from Dominique d'Humieres --- 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 changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2013-06-16 Ever confirmed|0 |1 --- Comment #2 from Dominique d'Humieres --- 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 changed: What|Removed |Added CC||hp at gcc dot gnu.org, ||pinskia at gcc dot gnu.org --- Comment #2 from Hans-Peter Nilsson --- (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 changed: What|Removed |Added CC||naruse at airemix dot jp --- Comment #3 from Andrew Pinski --- *** 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 changed: What|Removed |Added Resolution|FIXED |DUPLICATE --- Comment #3 from Andrew Pinski --- (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 changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2013-06-16 Ever confirmed|0 |1 --- Comment #3 from Dominique d'Humieres --- 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=, ts2=) 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=, ts2=) 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=, old_locus=0x7fff5fbfd330, str=) 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=) at ../../work/gcc/fortran/parse.c:2741 #6 0x000100085599 in parse_progunit (st=) 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=, 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 changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX --- Comment #8 from Dominique d'Humieres --- 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 changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-06-16 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- 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 changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-06-16 Ever confirmed|0 |1 --- Comment #3 from Dominique d'Humieres --- 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 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 --- 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 --- (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 "a>0" 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 --- (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=30314&action=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 changed:
What|Removed |Added
Component|target |rtl-optimization
--- Comment #2 from Oleg Endo ---
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;
:
if (y_3(D) > 0)
goto ;
else
goto ;
:
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;
:
# sum_16 = PHI
# ivtmp.6_15 = PHI
_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 ;
else
goto ;
:
# sum_18 = PHI
goto ;
:
goto ;
:
# sum_13 = PHI
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 changed: What|Removed |Added CC||quantheory at gmail dot com --- Comment #2 from Sean Santos --- 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 changed: What|Removed |Added CC||quantheory at gmail dot com --- Comment #10 from Sean Santos --- 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 --- 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 --- > (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. ! 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 --- 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 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.
[Bug target/53425] No warnings are given for -mno-sse
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53425 jbeulich at novell dot com changed: What|Removed |Added CC||jbeulich at novell dot com --- Comment #4 from jbeulich at novell dot com --- I don't think this is quite right for 32-bit: For one, MMX types should be handled separately in that case. And there are now two warnings for both MMX and SSE types, i.e. the new one is redundant with the ones generated by function_arg_32(). I believe all that's needed is adding TARGET_64BIT to the conditional in type_natural_mode().
