[Bug tree-optimization/33866] [4.3 Regression] ICE in vect_get_vec_def_for_stmt_copy, at tree-vect-transform.c:1937
--- Comment #5 from irar at gcc dot gnu dot org 2007-10-25 07:26 --- Subject: Bug 33866 Author: irar Date: Thu Oct 25 07:25:55 2007 New Revision: 129623 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129623 Log: PR tree-optimization/33866 * tree-vect-transform.c (vectorizable_store): Check operands of all the stmts in the group of strided accesses. Get def stmt type for each store in the group and pass it to vect_get_vec_def_for_stmt_copy (). Added: trunk/gcc/testsuite/gcc.dg/vect/pr33866.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-transform.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33866
[Bug fortran/31487] Character array initialization in derived type: bad zero padding
-- tobi at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|tobi at gcc dot gnu dot org |unassigned at gcc dot gnu ||dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31487
[Bug tree-optimization/32921] [4.3 Regression] Revision 126326 causes 12% slowdown
--- Comment #36 from rguenth at gcc dot gnu dot org 2007-10-25 08:55
---
One reason why we see a regression here regarding to partitioning is that the
fortran FE now inlines allocate () producing three calls instead of one, which
spoils the partitioning heuristics:
{
void * D.1028;
logical4 D.1027;
int8 size.0;
int8 D.1025;
qs.dtype = 537;
qs.dim[0].lbound = 0;
qs.dim[0].ubound = (int8) (imax + -1);
qs.dim[0].stride = 1;
D.1025 = (int8) (imax + -1) + 1;
D.1027 = imax <= 0;
if (D.1027)
{
size.0 = 0;
}
else
{
size.0 = D.1025 * 8;
}
if (qs.data == 0B)
{
{
void * D.1030;
int8 D.1029;
D.1029 = size.0;
if (D.1029 < 0)
{
_gfortran_runtime_error (&"Attempt to allocate negative amount of
memory. Possible integer overflow"[1]{lb: 1 sz: 1});
}
else
{
D.1030 = __builtin_malloc (MAX_EXPR );
if (D.1030 == 0B)
{
_gfortran_os_error (&"Out of memory"[1]{lb: 1 sz: 1});
}
}
D.1028 = D.1030;
}
}
else
{
_gfortran_runtime_error (&"Attempting to allocate already allocated
array"[1]{lb: 1 sz: 1});
}
qs.data = D.1028;
qs.offset = 0;
}
if we mark the error functions as having no VOPs (I don't see that we need
to preserve or order memory operations for these particular functions that
do not return) then this should clean up the number of VOPs considerably.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32921
[Bug fortran/33317] CSHIFT/EOSHIFT: Rejects optional dummy for DIM=
-- jv244 at cam dot ac dot uk changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-10-25 09:00:05 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33317
[Bug fortran/33888] ICE - CHARACTER expression using an ELEMENTAL FUNCTION as actual arg
--- Comment #2 from pault at gcc dot gnu dot org 2007-10-25 09:20 --- (In reply to comment #1) For some reason, the interface mechanism in trans-expr.c is failing for this case of an elemental function (try a constant length for my_func or to make it non-elemental and array valued - both work fince). You can see this in the code that the testcase produces. The internal length variable, in my_func, '..length' is being referenced in the main program, with inevitable consequences! A workaround, for now, is to write a temporary, which can be allocatable if necessary. character(8) :: temp(4) ..snip.. temp = myfunc (indata)) call process (temp) A tricky alternative, to make use of automatic allocation and cleanup of allocatable components, would be type mytype character(8), allocatable :: c(:) end type mytype type(mytype) :: temp ..snip.. temp%c = myfunc (indata)) call process (temp%c) However, this segfaults for the same reason as the original. *sigh* Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33888
[Bug fortran/33317] CSHIFT/EOSHIFT: Rejects optional dummy for DIM=
--- Comment #3 from dominiq at lps dot ens dot fr 2007-10-25 09:39 --- On Darwin with revision 129623, the orginal code gives: pr33317.f90:8.51: print *, cshift([.true.,.true.,.true.,.true.],1,d) 1 Error: 'dim' argument of 'cshift' intrinsic at (1) must not be OPTIONAL while program test implicit none call sub(1) call sub() contains subroutine sub(d) integer, optional :: d if (present(d)) then print *, eoshift((/.true.,.true.,.true.,.true./),1,d) else print *, eoshift((/.true.,.true.,.true.,.true./),1) end if end subroutine end program test ICE with: pr33317_db_1.f90:9.61: print *, eoshift((/.true.,.true.,.true.,.true./),1,dim=d) 1 pr33317_db_1.f90:0: internal compiler error: Bus error -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33317
[Bug fortran/33759] Unequal character lengths in MERGE intrinsic not detected at run time
--- Comment #6 from dominiq at lps dot ens dot fr 2007-10-25 09:48 ---
> and survives "dg.exp=gfortran/transfer*".
Let me just point out that gfortran.dg/transfer_simplify_4.f90 fails
with any optimization starting at -O1 due to the failure of the reduced test:
! { dg-do run }
! { dg-options "-O0" }
! Tests that the in-memory representation of a transferred variable
! propagates properly.
!
implicit none
integer, parameter :: ip1 = 42
logical, parameter :: ap1 = transfer(ip1, .true.)
integer, parameter :: ip2 = transfer(ap1, 0)
logical :: a
integer :: i
i = ip1
a = transfer(i, .true.)
i = transfer(a, 0)
print *, i, ip1
if (i .ne. ip1) call abort ()
end
[karma] f90/bug% gfc -O1 transfer_simplify_4_red.f90
[karma] f90/bug% a.out
0 42
Abort
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33759
[Bug tree-optimization/32921] [4.3 Regression] Revision 126326 causes 12% slowdown
--- Comment #37 from pinskia at gcc dot gnu dot org 2007-10-25 10:05 --- _gfortran_runtime_error is marked as no return which means virtual operations should not be on it. Sounds like noreturn should be the same as no vops (maybe). You have to take care about exceptions as no return functions can still change global state and "return" via an exception (or a long jump). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32921
[Bug fortran/33884] data-initialized unused variables not detected
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-10-25 10:55:15 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33884
[Bug tree-optimization/32921] [4.3 Regression] Revision 126326 causes 12% slowdown
--- Comment #38 from rguenth at gcc dot gnu dot org 2007-10-25 11:02 --- Another thing is that for all of the mem_sym_stats we collect, we _only_ consider memory references through pointers(!), but not for example # VUSE D.1244_380 = du.dim[0].stride; the associated SFT will neither get indirect nor direct reads accounted. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32921
[Bug c++/33843] [4.1/4.2/4.3 regression] Broken diagnostic: 'bit_not_expr' not supported by pp_cxx_unqualified_id
-- pcarlini at suse dot de changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-10-25 11:06:27 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33843
[Bug tree-optimization/32921] [4.3 Regression] Revision 126326 causes 12% slowdown
--- Comment #39 from rguenth at gcc dot gnu dot org 2007-10-25 11:06
---
No, in general noreturn functions cannot be treated as novops. Consider
void __attribute__((noreturn,noinline)) my_main(int *ret)
{
exit(*ret);
}
int main()
{
int ret = 0;
my_main (&ret);
}
without VOPs we would remove the store to ret.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32921
[Bug fortran/33883] gfortran compile / LD_LIBRARY_PATH error
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-10-25 11:11 --- (In reply to comment #0) > configure: error: GNU Fortran is not working; the most common reason for that > is that you might have linked it to shared GMP and/or MPFR libraries, and not > set LD_LIBRARY_PATH accordingly. If you suspect any other reason, please > report > a bug in http://gcc.gnu.org/bugzilla, attaching > /home/rogerb/gcc-4.2.2/i686-pc-linux-gnu/libgfortran/config.log Roger, can you actually attach that file? Other than that, I think you're omitting some valuable information, like, are you trying to build a cross-compiler? (I see you have a host-i686-pc-linux-gnu) Are you building in the source tree? (which is not supported and strongly discouraged, see http://gcc.gnu.org/install/configure.html) Another way of debugging the problem is to manually run the following command on a simple Fortran source: /home/rogerb/gcc-4.2.2/host-i686-pc-linux-gnu/gcc/gfortran -v -B/home/rogerb/gcc-4.2.2/host-i686-pc-linux-gnu/gcc/ -B/usr/local/i686-pc-linux-gnu/bin/ -B/usr/local/i686-pc-linux-gnu/lib/ and see tell us what happens. (In reply to comment #1) > Try reversing the order here: I don't think that'll fix it; this is only needed for older GMP versions, which still included MPFR. (In reply to comment #2) > Also, you must enable c as well C is automatically added to the list of languages built if you ask for Fortran. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33883
[Bug g++ 3.4.4 ?] g++, -O2, static member data in line functions
I sent a bug report to [EMAIL PROTECTED] becasue I thought it was related
to cygwin, instead of g++, see
http://www.cygwin.com/ml/cygwin/2007-10/msg00507.html
The people at cygwin seem to have bassed the buck onto the gcc community;
see
http://www.cygwin.com/ml/cygwin/2007-10/msg00511.html
Here is my question: Is it true that there was a bug in g++ 3.4.4 related
to using static data in line functions ?
This is very important because template classes often have static member
data access functions that return data connected to each instance of a
template class. These accessor fucntions are often short and get inlined
when -O2 is used.
I am attaching the information for the bug report to this message:
bug.sh
Description: bash shell script for running the bug test
# include
class Element {
public:
std::string file;
static Element *root(void)
{ static Element r;
return &r;
}
};
# include "bug0.hpp"
extern void bug2(void);
int main(void)
{ std::string str("A");
char c = str[0];
Element *r = Element::root();
bug2();
return 0;
}
# include
# include "bug0.hpp"
void bug2(void)
{
Element *r = Element::root();
Element *s = Element::root();
assert( r != 0 );
}
BUG REPORT: Cygwin, g++, -O2, static member function, std::string
RUN COMMAND: ./bug.sh
RESULT: assertion "r != 0" failed
SIDE EFFECTS: the files ./bug0.hpp, bug1.cpp, and bug2.cpp are created.
uname -a
Linux lnx-brad.apl.washington.edu 2.6.17-1.2174_FC5 #1 Tue Aug 8 15:30:55 EDT
2006 i686 i686 i386 GNU/Linux
g++ --version
g++ (GCC) 4.1.1 20070105 (Red Hat 4.1.1-51)
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
g++ bug1.cpp bug2.cpp -O1 -o bug
./bug
g++ bug1.cpp bug2.cpp -O2 -o bug
./bug
BUG REPORT: Cygwin, g++, -O2, static member function, std::string
RUN COMMAND: ./bug.sh
RESULT: assertion "r != 0" failed
SIDE EFFECTS: the files ./bug0.hpp, bug1.cpp, and bug2.cpp are created.
uname -a
CYGWIN_NT-5.1 pc-bbell 1.5.24(0.156/4/2) 2007-01-31 10:57 i686 Cygwin
g++ --version
g++ (GCC) 3.4.4 (cygming special, gdc 0.12, using dmd 0.125)
Copyright (C) 2004 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
g++ bug1.cpp bug2.cpp -O1 -o bug
./bug
g++ bug1.cpp bug2.cpp -O2 -o bug
./bug
assertion "r != 0" failed: file "bug2.cpp", line 8
11 [sig] bug 1924 C:\cygwin\home\Brad\trash\bug.exe: *** fatal error - call
ed with threadlist_ix -1
./bug.sh: line 58: 1924 Hangup ./bug
[Bug libstdc++/33892] New: [libstdc++ v3 parallel mode] Parallel mode algorithms use critical sections with global scope
The libstdc++ v3 parallel mode uses #pragma omp critical in several places, like this: #pragma omp critical(writeOutput) output = r(output, result); However, this is a global per app lock, which could deteriorate performance. -- Summary: [libstdc++ v3 parallel mode] Parallel mode algorithms use critical sections with global scope Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: singler at ira dot uka dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33892
[Bug libstdc++/33893] New: [parallel mode] Algorithms rely on omp_set_dynamic(false)
The code in many places assumes that if it uses num_threads (num_threads), that many threads will be created. But that's not guaranteed if omp_set_dynamic (true) and the library shouldn't tweak that. num_threads will be the maximum number of threads that are created, that's guaranteed, but you should check omp_get_num_threads () at runtime to see how many were created and how to divide the work. There is no easy failing test case so far, since the algorithms initialize the num_thread clause with omp_get_max_threads(), which is already appropriately reduced by the runtime library in the dynamic setting, so everything works fine. Nevertheless, this issue should be addressed. -- Summary: [parallel mode] Algorithms rely on omp_set_dynamic(false) Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: singler at ira dot uka dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33893
[Bug libgomp/33894] New: [libgomp/parallel mode] pragma omp atomic broken
In code like this from include/parallel/workstealing.h (libstdc++ parallel
mode)
// After reaching this point, a thread's job list is empty.
if (iam_working)
{
//This thread no longer has work.
#pragma omp atomic
busy--;
iam_working = false;
}
the instruction belonging to the omp atomic pragma is skipped by the compiler,
i. e. busy is _not_ decremented.
Adding pragma omp flush before and after does not help either. Replacing the
two lines by "__sync_fetch_and_add(&busy, -1);" makes the program work
correctly.
Unfortunately, I have not yet succeeded in constructing a test case simpler
than calling e. g. parallel for_each, and checking the result. The problem
could maybe be caused by incorrect inlining.
--
Summary: [libgomp/parallel mode] pragma omp atomic broken
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgomp
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: singler at ira dot uka dot de
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33894
[Bug c++/33887] Reference to bitfield gets wrong value when optimizing
--- Comment #4 from ian at airs dot com 2007-10-25 13:25 --- Yes, of course it should sign extend. This is a wrong-code bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33887
[Bug c/33895] New: mips.c:6868: error: 'mips_output_dwarf_dtprel' defined but not used
I get the following error message when I attempt to compile gcc: /home/mrichmon/gcc-4.3-20071019/gcc/config/mips/mips.c:6868: error: 'mips_output_dwarf_dtprel' defined but not used It occurs under the following conditions: 1. Snapshot version of gcc 4.3 dated September 19 2. SGI R5000 workstation running Debian Linux 4.0 3. The "configure" script was invoked with the parameters "--enable-languages=c --prefix=$HOME/irun --build=mips-unknown-linux-gnu --enable-checking=release" The error does not occur with the snapshot version of gcc 4.3 dated August 31. -- Summary: mips.c:6868: error: 'mips_output_dwarf_dtprel' defined but not used Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: michael dot a dot richmond at nasa dot gov http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33895
[Bug fortran/33883] gfortran compile / LD_LIBRARY_PATH error
--- Comment #4 from rogerabq at yahoo dot com 2007-10-25 15:09 --- Thanks for the replies. I started from scratch, making sure I wasn't building from the source tree and this time it compiled just fine. Thank You! (In reply to comment #3) > Are you building in > the source tree? (which is not supported and strongly discouraged, see > http://gcc.gnu.org/install/configure.html) > -- rogerabq at yahoo dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33883
[Bug fortran/33883] gfortran compile / LD_LIBRARY_PATH error
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2007-10-25 15:17 --- Reopening... -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33883
[Bug fortran/33883] gfortran compile / LD_LIBRARY_PATH error
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2007-10-25 15:18 --- ... to closed as INVALID rather than FIXED (for later statistics). -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33883
[Bug fortran/32626] Run-time check for recursive functions
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement Last reconfirmed|2007-08-06 14:06:57 |2007-10-25 15:23:24 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32626
[Bug fortran/31608] wrong types in character array/scalar binop
--- Comment #41 from dave at hiauly1 dot hia dot nrc dot ca 2007-10-25 15:41 --- Subject: Re: wrong types in character array/scalar binop > While on x86_64-gnu-linux the dump has: > int8 S.5; > the variable on hppa-unknown-linux-gnu is: > int4 S___5; I wonder why the variables names differ. I'm not aware of any backend feature that controls this. Obviously, the check could be adjusted to handle both. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31608
[Bug fortran/31608] wrong types in character array/scalar binop
--- Comment #42 from Tobias dot Schlueter at physik dot uni-muenchen dot de 2007-10-25 15:48 --- Subject: Re: wrong types in character array/scalar binop dave at hiauly1 dot hia dot nrc dot ca wrote: > --- Comment #41 from dave at hiauly1 dot hia dot nrc dot ca 2007-10-25 > 15:41 --- > Subject: Re: wrong types in character array/scalar binop > >> While on x86_64-gnu-linux the dump has: >> int8 S.5; >> the variable on hppa-unknown-linux-gnu is: >> int4 S___5; > > I wonder why the variables names differ. I'm not aware of any > backend feature that controls this. Maybe (random shot in the dark) hp's assembler doesn't allow for dots in symbol names, and gcc, when generating the name for the symbol takes this into account even though this is on Linux? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31608
[Bug fortran/31608] wrong types in character array/scalar binop
--- Comment #43 from rguenther at suse dot de 2007-10-25 16:01 ---
Subject: Re: wrong types in character array/scalar binop
On Thu, 25 Oct 2007, Tobias dot Schlueter at physik dot uni-muenchen dot de
wrote:
>
>
> --- Comment #42 from Tobias dot Schlueter at physik dot uni-muenchen dot
> de 2007-10-25 15:48 ---
> Subject: Re: wrong types in character array/scalar binop
>
> dave at hiauly1 dot hia dot nrc dot ca wrote:
> > --- Comment #41 from dave at hiauly1 dot hia dot nrc dot ca 2007-10-25
> > 15:41 ---
> > Subject: Re: wrong types in character array/scalar binop
> >
> >> While on x86_64-gnu-linux the dump has:
> >> int8 S.5;
> >> the variable on hppa-unknown-linux-gnu is:
> >> int4 S___5;
> >
> > I wonder why the variables names differ. I'm not aware of any
> > backend feature that controls this.
>
> Maybe (random shot in the dark) hp's assembler doesn't allow for dots in
> symbol names, and gcc, when generating the name for the symbol takes
> this into account even though this is on Linux?
gimplify.c:
tree
create_tmp_var_name (const char *prefix)
{
char *tmp_name;
if (prefix)
{
char *preftmp = ASTRDUP (prefix);
remove_suffix (preftmp, strlen (preftmp));
prefix = preftmp;
}
ASM_FORMAT_PRIVATE_NAME (tmp_name, prefix ? prefix : "T",
tmp_var_id_num++);
return get_identifier (tmp_name);
}
yes indeed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31608
[Bug fortran/10220] attribute DW_AT_calling_convention not correct for fortran
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2007-10-25 16:06 --- Apparently, it has been decided that DW_AT_calling_convention should be set to DW_CC_program, because it's already done by other compilers (IBM, Sun, Intel): http://www.sourceware.org/ml/gdb/2007-10/msg00205.html Maybe that's not the ultimate Right Thing to do, but it sounds like the way to go for now. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2007-07-28 21:01:58 |2007-10-25 16:06:49 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10220
[Bug libgomp/33894] [libgomp/parallel mode] pragma omp atomic broken
--- Comment #1 from jakub at gcc dot gnu dot org 2007-10-25 16:09 --- Could you please attach a preprocessed testcase which shows this and what options you used? Thanks. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Keywords||openmp http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33894
gfortran openmp: lastprivate variable is private in outer context
Hi, I have an issue compiling the following fortran openmp code using gcc4.3 snapshot 20071910: SUBROUTINE foo(a, b, n) DOUBLE PRECISION a, b INTEGER*8 i1, i2, i3, n DIMENSION a(n,n,n), b(n,n,n) !$OMP PARALLEL !$OMP+DEFAULT(SHARED) !$OMP+PRIVATE(I3) !$OMP DO !$OMP+LASTPRIVATE(I1,I2) DO i3 = 2, n-1, 1 DO i2 = 2, n-1, 1 DO i1 = 2, n-1, 1 a(i1, i2, i3) = b(i1, i2, i3); 600CONTINUE ENDDO ENDDO ENDDO !$OMP END DO NOWAIT !$OMP END PARALLEL RETURN END gfortran -O2 -fopenmp foo.c -c -o foo.o fortran2.f:11: error: lastprivate variable "i2" is private in outer context fortran2.f:11: error: lastprivate variable "i1" is private in outer context I believe this code is compliant with the OPENMP 2.5 spec, since the DEFAULT(SHARED) clause should make the scope of i1, i2 shared in the enclosing parallel region. Pathscale 3.0, PGI 7.0.6 and Intel 10.0.026 compile the above code successfully. Replacing: !$OMP+DEFAULT(SHARED) with: !$OMP+SHARED(I1,I2) makes the code compile successfully with gfortran. Alternatively, keeping DEFAULT(SHARED) and fusing the OMP PARALLEL clause with the OMP DO clause (i.e. using OMP PARALLEL DO) also solves the problem. (this testcase is derived from a benchmark suite that doesn't allow source code modifications. gfortran should be able to compile this with no code changes - if this is indeed openmp-compliant code) Could this behavior be due to the following libgomp patch not getting all necessary information from the fortran front-end? http://gcc.gnu.org/ml/gcc-patches/2007-01/msg01940.html GCC4.3 snapshot 20071910 was built and bootstrapped with the following configuration on sles10-sp1: Target: x86_64-unknown-linux-gnu Configured with: /home/gcc-4.3-20071019/configure --with-gmp-lib=/usr/local/lib/ --with-gmp-include=/usr/local/include/ --with-mpfr-lib=/usr/local/lib --with-mpfr-include=/usr/local/include/ --enable-threads=posix --prefix=/opt/gcc4.3 Thread model: posix gcc version 4.3.0 20071019 (experimental) (GCC) thanks, - Vasilis
[Bug tree-optimization/33833] [4.3 Regression] ICE in build2_stat, at tree.c:3110 at -O3, tree-vectorizer
--- Comment #5 from irar at gcc dot gnu dot org 2007-10-25 16:42 --- Subject: Bug 33833 Author: irar Date: Thu Oct 25 16:41:45 2007 New Revision: 129628 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129628 Log: PR tree-optimization/33833 * tree-vect-analyze.c (vect_analyze_data_refs): Use POINTER_PLUS_EXPR and convert init to sizetype in inner_base construction. Added: trunk/gcc/testsuite/gcc.dg/vect/pr33833.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-analyze.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33833
[Bug libstdc++/33896] New: std::tr1::array has too-conservative alignment on _M_instance
std::tr1::array's only data member, _M_instance, has __attribute__((__aligned__)) which means that it potentially takes more space in memory than is required by the size and alignment of type _Tp. This makes tr1::array somewhat less attractive than C-style arrays, especially on low-memory systems, since there's an unnecessary hidden cost. Paolo mentioned that this was originally done to play it safe with some extensions, but that those extensions could be fixed. I don't know which extensions he was referring to. -- Summary: std::tr1::array has too-conservative alignment on _M_instance Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: atgraham at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33896
[Bug fortran/33897] New: Should an ENTRY in a contained function be visible from another contained routine?
gfortran links the following without error, whereas Compaq Fortran, Lahey Fortran, and g95 tell me that setbd is an unresolved external. MODULE ksbin1_aux_mod CONTAINS SUBROUTINE nxtstg() INTEGER :: i INTEGER :: setbd i = setbd() END SUBROUTINE nxtstg FUNCTION binden() INTEGER :: binden INTEGER :: setbd binden = 0 ENTRY setbd() setbd = 0 END FUNCTION binden END MODULE ksbin1_aux_mod PROGRAM test END PROGRAM test -- Summary: Should an ENTRY in a contained function be visible from another contained routine? Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: michael dot a dot richmond at nasa dot gov http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33897
[Bug libgomp/33894] [libgomp/parallel mode] pragma omp atomic broken
--- Comment #2 from singler at ira dot uka dot de 2007-10-25 16:55 --- The command line is: g++-trunk -D_GLIBCXX_PARALLEL -fopenmp -g3 -O0 ../../src/GCCTrunkTest.cpp -o GCCTrunkTest (GCC trunk revision 129315). Preprocessed source as attached. The program outputs "Wrong result.". It works with the proposed fix, and also if "balanced" is changed to "unbalanced". -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33894
[Bug debug/33739] [4.3 Regression] Failure of gfortran.dg/literal_character_constant_1_*.F with -m64 -g on Darwin
--- Comment #8 from dominiq at lps dot ens dot fr 2007-10-25 16:59 ---
I have reverted revision 129011:
+2007-10-04 Francois-Xavier Coudert <[EMAIL PROTECTED]>
+
+ PR fortran/33502
+ * scanner.c (gfc_advance_line): Call debug_hooks->end_source_file
+ and debug_hooks->start_source_file when appropriate, and set
+ dbg_emitted.
+ (gfc_define_undef_line): New function.
+ (load_file): Don't error out on #define and #undef lines.
+ * parse.c (next_statement): Call gfc_define_undef_line.
+ (gfc_parse_file): Call debug_hooks->start_source_file and
+ debug_hooks->end_source_file for the main source file if
+ required.
+ * gfortran.h (gfc_linebuf): Add dbg_emitted field.
+ (gfc_define_undef_line): New prototype.
+
and the failures disappeared. I do not understand the logic of
+ if (gfc_current_locus.lb->next
+ && gfc_current_locus.lb->next->file != gfc_current_locus.lb->file)
+{
+ if (gfc_current_locus.lb->next->file
+ && !gfc_current_locus.lb->next->dbg_emitted
+ && gfc_current_locus.lb->file->up ==
gfc_current_locus.lb->next->file)
+ {
+ /* We exit from an included file. */
+ (*debug_hooks->end_source_file)
+ (gfc_linebuf_linenum (gfc_current_locus.lb->next));
+ gfc_current_locus.lb->next->dbg_emitted = true;
+ }
+ else if (gfc_current_locus.lb->next->file != gfc_current_locus.lb->file
+ && !gfc_current_locus.lb->next->dbg_emitted)
+ {
+ /* We enter into a new file. */
+ (*debug_hooks->start_source_file)
+ (gfc_linebuf_linenum (gfc_current_locus.lb),
+gfc_current_locus.lb->next->file->filename);
+ gfc_current_locus.lb->next->dbg_emitted = true;
+ }
+}
+
If I understand it, if gfc_current_locus.lb->next->dbg_emitted is false, it is
set to true for both entering a new file and leaving an included file. With the
current scheme I don't see how the latter case can be reached.
--
dominiq at lps dot ens dot fr changed:
What|Removed |Added
CC||fxcoudert at gcc dot gnu dot
||org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33739
[Bug fortran/33897] Should an ENTRY in a contained function be visible from another contained routine?
--- Comment #1 from jv244 at cam dot ac dot uk 2007-10-25 17:33 --- this is a slightly modified testcase, which g95, NAG f95, IBM xlf90, ifort, pgf90 all compile & link while it fails to compile with gfortran. The error message by gfortran (Global name 'setbd' at (1) is already being used as a FUNCTION at (2)) suggests gfortran has a problem. Interestingly, it returns 1 with g95, NAG f95, IBM xlf90, pgf90 and 0 with ifort. MODULE ksbin1_aux_mod CONTAINS SUBROUTINE nxtstg() INTEGER :: i INTEGER :: setbd i = setbd() write(6,*) i END SUBROUTINE nxtstg FUNCTION binden() INTEGER :: binden INTEGER :: setbd binden = 0 ENTRY setbd() setbd = 0 END FUNCTION binden END MODULE ksbin1_aux_mod PROGRAM test USE ksbin1_aux_mod CALL nxtstg() END PROGRAM test INTEGER FUNCTION setbd() setbd=1 END FUNCTION setbd A simpler testcase is: MODULE M1 CONTAINS SUBROUTINE S2() ENTRY E2() write(6,*) 'C' END SUBROUTINE S2 END MODULE M1 SUBROUTINE S2() ENTRY E2() write(6,*) 'E' END SUBROUTINE S2 -- jv244 at cam dot ac dot uk changed: What|Removed |Added OtherBugsDependingO||32834 nThis|| Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||rejects-valid Last reconfirmed|-00-00 00:00:00 |2007-10-25 17:33:09 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33897
[Bug debug/33739] [4.3 Regression] Failure of gfortran.dg/literal_character_constant_1_*.F with -m64 -g on Darwin
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-10-25 17:39:08 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33739
[Bug fortran/33897] [4.1/4.2/4.3 Regression] Entries and modules
--- Comment #2 from jv244 at cam dot ac dot uk 2007-10-25 17:41 --- this works with gcc_4_0_branch, which makes this a regression. MODULE M1 CONTAINS SUBROUTINE S2() ENTRY E2() write(6,*) 'C' END SUBROUTINE S2 END MODULE M1 SUBROUTINE S2() ENTRY E2() write(6,*) 'E' END SUBROUTINE S2 USE M1 CALL E2() END -- jv244 at cam dot ac dot uk changed: What|Removed |Added Known to work||4.0.4 Summary|Should an ENTRY in a|[4.1/4.2/4.3 Regression] |contained function be |Entries and modules |visible from another| |contained routine? | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33897
[Bug fortran/31608] wrong types in character array/scalar binop
--- Comment #44 from dave at hiauly1 dot hia dot nrc dot ca 2007-10-25
18:03 ---
Subject: Re: wrong types in character array/scalar binop
> ASM_FORMAT_PRIVATE_NAME (tmp_name, prefix ? prefix : "T",
I'm still don't understand how we get underscores. We have in defaults.h:
#ifndef ASM_FORMAT_PRIVATE_NAME
# define ASM_FORMAT_PRIVATE_NAME(OUTPUT, NAME, LABELNO) \
do { const char *const name_ = (NAME); \
char *const output_ = (OUTPUT) = \
(char *) alloca (strlen (name_) + 32); \
sprintf (output_, ASM_PN_FORMAT, name_, (unsigned long)(LABELNO)); \
} while (0)
#endif
#ifndef ASM_PN_FORMAT
# ifndef NO_DOT_IN_LABEL
# define ASM_PN_FORMAT "%s.%lu"
# else
# ifndef NO_DOLLAR_IN_LABEL
# define ASM_PN_FORMAT "%s$%lu"
# else
# define ASM_PN_FORMAT "__%s_%lu"
# endif
# endif
#endif /* ! ASM_PN_FORMAT */
To the best of my knowledge, we don't define either ASM_FORMAT_PRIVATE_NAME
or NO_DOT_IN_LABEL. I believe NO_DOLLAR_IN_LABEL is defined on those PA
targets that include elfos.h.
In any case, the test should support the three formats in ASM_PN_FORMAT.
Dave
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31608
[Bug target/28583] [4.2 regression] ICE in default_secondary_reload, at targhooks.c:532 when building libgcc2.c as _divsc3.o
--- Comment #7 from rask at gcc dot gnu dot org 2007-10-25 18:04 --- This works fine in 4.3. Looking at the commit log, I'd say it was fixed by revision 121981. -- rask at gcc dot gnu dot org changed: What|Removed |Added Known to work||4.3.0 Summary|[4.2/4.3 regression] ICE in |[4.2 regression] ICE in |default_secondary_reload, at|default_secondary_reload, at |targhooks.c:532 when|targhooks.c:532 when |building libgcc2.c as |building libgcc2.c as |_divsc3.o |_divsc3.o http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28583
[Bug c/33898] New: Broken -I- vs -iquote behaviour
This may be me being stupid, but I don't understand the whole -I vs -iquote
thing. If I just use -I, and then a commandline like:
gcc -v -I/tmp/home-alexms-epage-generated/linux/x86/gcc/include
-I/home/alexms/epage/platform/linux/x86/gcc/include
-I/home/alexms/epage/platform/linux/x86/include
-I/home/alexms/epage/platform/linux/include -I/home/alexms/epage/include
-I/home/alexms/epage/libraries/ole/include -o api.o api.c
with libraries/ole/include containing a file called endian.h, I get:
#include "..." search starts here:
#include <...> search starts here:
/tmp/home-alexms-epage-generated/linux/x86/gcc/include
/home/alexms/epage/platform/linux/x86/gcc/include
/home/alexms/epage/platform/linux/x86/include
/home/alexms/epage/platform/linux/include
/home/alexms/epage/include
/home/alexms/epage/libraries/ole/include
/usr/local/include
/usr/lib/gcc/i486-linux-gnu/4.1.2/include
/usr/include
In file included from /usr/include/stdlib.h:43,
from
/home/alexms/epage/platform/linux/include/pal/pal-stdlib.h:18,
from /home/alexms/epage/platform/linux/include/pal/crt.h:23,
from /home/alexms/epage/include/epage/ustring.h:23,
from /home/alexms/epage/include/epage/error.h:40,
from /home/alexms/epage/libraries/ole/api.c:18:
/usr/include/bits/waitstatus.h:80: error: duplicate member '__w_retcode'
/usr/include/bits/waitstatus.h:80: error: duplicate member '({anonymous})'
/usr/include/bits/waitstatus.h:80: error: duplicate member '({anonymous})'
/usr/include/bits/waitstatus.h:81: error: duplicate member '__w_coredump'
/usr/include/bits/waitstatus.h:81: error: duplicate member '({anonymous})'
/usr/include/bits/waitstatus.h:81: error: duplicate member '({anonymous})'
/usr/include/bits/waitstatus.h:81: error: duplicate member '({anonymous})'
/usr/include/bits/waitstatus.h:82: error: duplicate member '__w_termsig'
/usr/include/bits/waitstatus.h:82: error: duplicate member '({anonymous})'
/usr/include/bits/waitstatus.h:82: error: duplicate member '({anonymous})'
/usr/include/bits/waitstatus.h:82: error: duplicate member '({anonymous})'
/usr/include/bits/waitstatus.h:82: error: duplicate member '({anonymous})'
/usr/include/bits/waitstatus.h:94: error: duplicate member '__w_stopsig'
/usr/include/bits/waitstatus.h:94: error: duplicate member '({anonymous})'
/usr/include/bits/waitstatus.h:94: error: duplicate member '({anonymous})'
/usr/include/bits/waitstatus.h:95: error: duplicate member '__w_stopval'
/usr/include/bits/waitstatus.h:95: error: duplicate member '({anonymous})'
/usr/include/bits/waitstatus.h:95: error: duplicate member '({anonymous})'
/usr/include/bits/waitstatus.h:95: error: duplicate member '({anonymous})'
Because the endian.h in libraries/ole/include overrides the system one. I
thought the whole point of -I was to be the "..." headers, and you used -j for
the system headers, so why are my -I headers being coerced into being bracketed
headers?
Obviously with -I-, this worked fine as all the -I headers remained as quoted
ones, and the /usr/include etc. headers were bracketed, so got
picked up correctly. So this seems broken to me, you shouldn't need to go
through and replace all your -I's with -iquote's, purely to give -I a behaviour
it was supposed to have in the first place, and use -j for system headers?
--
Summary: Broken -I- vs -iquote behaviour
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: archifishal at gmx dot co dot uk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33898
[Bug fortran/31608] wrong types in character array/scalar binop
--- Comment #45 from burnus at gcc dot gnu dot org 2007-10-25 18:17 --- (In reply to comment #44) > # define ASM_PN_FORMAT "%s.%lu" > # define ASM_PN_FORMAT "%s$%lu" > # define ASM_PN_FORMAT "__%s_%lu" > > In any case, the test should support the three formats in ASM_PN_FORMAT. Well, I think there are four: S.5, S$5, and __S_5 as defined above and S___5 as found in the dump?!? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31608
[Bug rtl-optimization/33796] valgrind error with -O2 for linux kernel code
--- Comment #7 from bergner at gcc dot gnu dot org 2007-10-25 18:46 --- >> So yes we do some uninitialized accesses to the sparse array, but that's >> ok. > > So absolutely *any* value is fine ? Yes, absolutely *any* value is fine. If you look at the code, you'll see that the result of the uninitialized read is used to index into the dense array, but only after guaranteeing that it is within bounds of the dense array. Therefore, we're not just widely accessing random memory locations. > Aren't there some machines where unaligned accesses to words fail ? These are uninitialized reads, not unaligned reads. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33796
[Bug target/33899] New: -maltivec option changes ABI
rs6000_return_in_memory has: /* Allow -maltivec -mabi=no-altivec without warning. Altivec vector modes only exist for GCC vector types if -maltivec. */ if (TARGET_32BIT && !TARGET_ALTIVEC_ABI && ALTIVEC_VECTOR_MODE (TYPE_MODE (type))) return false; The code below warns for big vectors and returns true. That means a function returning "__vector int" does so in an AltiVec register with -mabi=altivec, in r3 r4 r5 r6 with -maltivec only, and in memory without -maltivec. This means GDB can not tell where the return value goes and whether a reference argument is necessary, even when it knows whether -mabi=altivec was used. This comes from here: http://gcc.gnu.org/ml/gcc-patches/2004-11/msg02035.html I read through that entire thread and I still don't understand the behavior. If __vector int should be returned in four GPRs for -maltivec -mabi=no-altivec, then shouldn't we return it in four GPRs for non-AltiVec configurations too? In my simpler world, every option either affects the ABI or does not, -mabi=altivec does, and -maltivec does not. -- Summary: -maltivec option changes ABI Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: drow at gcc dot gnu dot org GCC target triplet: powerpc-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33899
[Bug target/30801] [4.3 Regression] performance regression on uint64_t operations
--- Comment #3 from rask at gcc dot gnu dot org 2007-10-25 18:58 --- I see a substantial improvent when testing on the compile farm hardware: processor : 3 vendor_id : AuthenticAMD cpu family : 15 model : 65 model name : Dual-Core AMD Opteron(tm) Processor 2212 stepping: 3 cpu MHz : 2000.240 cache size : 1024 KB ... $ gcc --version | head -n 1 gcc (GCC) 4.1.2 20061115 (prerelease) (Debian 4.1.1-21) $ gcc -O3 ~/pr30801.c && time ./a.out 064069fbc13963b920219c3e939225e38e38e38e3956d81c71c71c71c0ba0f00 real0m0.555s user0m0.552s sys 0m0.004s $ (cd ~/build/gcc-x86_64-unknown-linux-gnu/gcc && ./xgcc --version | head -n 1) xgcc (GCC) 4.3.0 20071022 (experimental) $ (cd ~/build/gcc-x86_64-unknown-linux-gnu/gcc && ./xgcc -B./ -O3 ~/pr30801.c && time ./a.out) 064069fbc13963b920219c3e939225e38e38e38e3956d81c71c71c71c0ba0f00 real0m0.455s user0m0.452s sys 0m0.004s Note that your -march=pentium4 option is rejected without -m32: $ gcc -march=pentium4 -O3 ~/pr30801.c && time ./a.out /home/rask/pr30801.c:1: error: CPU you selected does not support x86-64 instruction set /home/rask/pr30801.c:1: error: CPU you selected does not support x86-64 instruction set $ gcc -O3 ~/pr30801.c -m32 -march=pentium4 && time ./a.out 064069fbc13963b920219c3e939225e38e38e38e3956d81c71c71c71c0ba0f00 real0m2.234s user0m2.232s sys 0m0.004s $ (cd ~/build/gcc-x86_64-unknown-linux-gnu/gcc && ./xgcc -B./ -O3 ~/pr30801.c -m32 -march=pentium4 && time ./a.out) 064069fbc13963b920219c3e939225e38e38e38e3956d81c71c71c71c0ba0f00 real0m1.488s user0m1.484s sys 0m0.004s So GCC 4.3 is 22 % faster with just the default -m64 + no -march and an impressive 50 % faster with -m32 -march=pentium4. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30801
[Bug c++/33900] New: (exception handling) bad/inconsistent code generation
# On g++-sjlj.exe (GCC) 4.2.1-sjlj (mingw32 sjlj-unwind)
Using built-in specs.
Target: mingw32
Configured with: ../gcc-4.2.1/configure --with-gcc --enable-libgomp
--host=mingw32 --build=mingw32 --target=mingw32 --program-suffix=-sjlj
--with-arch=i486 --with-tune=generic --disable-werror --prefix=/mingw
--with-local-prefix=/mingw --enable-threads --disable-nls
--enable-languages=c,c++,fortran,objc,obj-c++,ada --disable-win32-registry
--enable-sjlj-exceptions --enable-libstdcxx-debug
--enable-cxx-flags=-fno-function-sections -fno-data-sections
--enable-version-specific-runtime-libs --disable-bootstrap
Thread model: win32
gcc version 4.2.1-sjlj (mingw32 sjlj-unwind)
# Also
# On gcc version 3.4.4 (cygming special, gdc 0.12, using dmd 0.125)
#include
#include
void signal_handler(int signo) {
fprintf(stderr,"signaled\n");
throw 1;
}
int main()
{ signal(SIGSEGV,signal_handler);
try {
printf((char*)9); //<---(A)
}
catch(...) {
fprintf(stderr,"exception caught");
}
}
---
#include
#include
void signal_handler(int signo) {
fprintf(stderr,"signaled\n");
throw 1;
}
int main()
{ signal(SIGSEGV,signal_handler);
try {
*(int*)0 = 0; //<---(B)
}
catch(...) {
fprintf(stderr,"exception caught");
}
}
//compiled as: g++sjlj testcase2.cc -g //gcc 4.2.1
int main()
4013f0: 8d 4c 24 04 lea0x4(%esp),%ecx
4013f4: 83 e4 f0and$0xfff0,%esp
4013f7: ff 71 fcpushl 0xfffc(%ecx)
4013fa: 55 push %ebp
4013fb: 89 e5 mov%esp,%ebp
4013fd: 51 push %ecx
4013fe: 83 ec 14sub$0x14,%esp
401401: e8 6a ff ff ff call 401370 <__main>
{ signal(SIGSEGV,signal_handler);
401406: c7 44 24 04 34 14 40movl $0x401434,0x4(%esp)
40140d: 00
40140e: c7 04 24 0b 00 00 00movl $0xb,(%esp)
401415: e8 46 7b 00 00 call 408f60
try {
*(int*)0 = 0; //<---(B)
40141a: b8 00 00 00 00 mov$0x0,%eax
40141f: c7 00 00 00 00 00 movl $0x0,(%eax)
401425: b8 00 00 00 00 mov$0x0,%eax
}
catch(...) {
fprintf(stderr,"exception caught");
}
}
40142a: 83 c4 14add$0x14,%esp
40142d: 59 pop%ecx
40142e: 5d pop%ebp
40142f: 8d 61 fclea0xfffc(%ecx),%esp
401432: c3 ret
and are identical except for (A),(B).
For , common:
Both (A) and (B) are supposed to throw no exception in C++ semantics. So no
need to generate the codes( hereafter) for adjusting the call site value
for (A),(B).
And the hole try block is supposed to throw no exception in C++ semantics. So
no need to generate the codes() for the catch block at all.
But Gcc generates codes differently: (Regardless of optimization)
For , Gcc generates the codes of both ,
while for , none as shown in ,
which crashs testcase2.
Are C++ exceptions considered to be thrown from extern "C" functions (under
some conditions) but not from signal handlers? If so, it matters as in the tese
cases above where C++ exceptions can be thrown from signal handlers.
Adding an option would be nice.
Microsoft VisualC++ has similar problem when optimizing with -EHs option.
But option -EHa forces the compiler to generate proper codes (regardless of
optimization), which makes the traslation from Windows exception to C++
exception safe.
--
Summary: (exception handling) bad/inconsistent code generation
Product: gcc
Version: 4.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: darkxun at paran dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33900
[Bug fortran/31608] wrong types in character array/scalar binop
--- Comment #46 from Tobias dot Schlueter at physik dot uni-muenchen dot de
2007-10-25 19:50 ---
Subject: Re: wrong types in character array/scalar binop
dave at hiauly1 dot hia dot nrc dot ca wrote:
> Subject: Re: wrong types in character array/scalar binop
>
>> ASM_FORMAT_PRIVATE_NAME (tmp_name, prefix ? prefix : "T",
>
> I'm still don't understand how we get underscores. We have in defaults.h:
>
> #ifndef ASM_FORMAT_PRIVATE_NAME
> # define ASM_FORMAT_PRIVATE_NAME(OUTPUT, NAME, LABELNO) \
> do { const char *const name_ = (NAME); \
>char *const output_ = (OUTPUT) = \
> (char *) alloca (strlen (name_) + 32); \
>sprintf (output_, ASM_PN_FORMAT, name_, (unsigned long)(LABELNO)); \
> } while (0)
> #endif
>
> #ifndef ASM_PN_FORMAT
> # ifndef NO_DOT_IN_LABEL
> # define ASM_PN_FORMAT "%s.%lu"
> # else
> # ifndef NO_DOLLAR_IN_LABEL
> # define ASM_PN_FORMAT "%s$%lu"
> # else
> # define ASM_PN_FORMAT "__%s_%lu"
> # endif
> # endif
> #endif /* ! ASM_PN_FORMAT */
>
> To the best of my knowledge, we don't define either ASM_FORMAT_PRIVATE_NAME
> or NO_DOT_IN_LABEL. I believe NO_DOLLAR_IN_LABEL is defined on those PA
> targets that include elfos.h.
~/src/hggcc/gcc/config tobi$ find . | xargs grep ASM_PN
./alpha/vms.h:#define ASM_PN_FORMAT "%s___%lu"
./h8300/h8300.h:#define ASM_PN_FORMAT "%s___%lu"
./ia64/ia64.h:#define ASM_PN_FORMAT (TARGET_GNU_AS ? "%s.%lu" : "%s?%lu")
./mmix/mmix.h:#define ASM_PN_FORMAT "%s::%lu"
./mn10300/mn10300.h:#define ASM_PN_FORMAT "%s___%lu"
./pa/pa.h:#define ASM_PN_FORMAT "%s___%lu"
./v850/v850.h:#define ASM_PN_FORMAT "%s___%lu"
It looks like you do :-)
I wonder why this name-mangling is necessary, it's not like these names
are going to appear in the assembly, is it?
Cheers,
- Tobi
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31608
[Bug libgomp/33275] Transient libgomp.fortran/omp_parse3.f90 -O0 failure
-- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Keywords||openmp Last reconfirmed|2007-09-02 15:55:23 |2007-10-25 20:16:20 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33275
[Bug c/33901] New: assumes target of a const pointer is read-only
Given the following code:
main ()
{
const char *foo = 0;
*foo = 0;
}
gcc will refuse to compile it with:
$ echo "main () { const char *foo = 0; *foo = 0; }" | gcc -x c -c - -o
/dev/null
: In function ‘main’:
:1: error: assignment of read-only location
Sure, foo is read-only, but *foo is just a memory location; one should be able
to write to it.
--
Summary: assumes target of a const pointer is read-only
Product: gcc
Version: 4.2.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rmh at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33901
[Bug libgomp/33275] Transient libgomp.fortran/omp_parse3.f90 -O0 failure
--- Comment #2 from jakub at gcc dot gnu dot org 2007-10-25 20:25 --- Subject: Bug 33275 Author: jakub Date: Thu Oct 25 20:25:12 2007 New Revision: 129631 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129631 Log: PR libgomp/33275 * testsuite/libgomp.fortran/omp_parse3.f90 (test_threadprivate): Make x and y integers rather than (implicit) reals. Add private (j) clause to the last omp parallel. Modified: trunk/libgomp/ChangeLog trunk/libgomp/testsuite/libgomp.fortran/omp_parse3.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33275
[Bug c/33901] assumes target of a const pointer is read-only
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-10-25 20:40 --- No const here applies to the char and not to the pointer type, if you want it to apply to the pointer type then write it as: char * const foo = 0; The mainline shows: t122.c: In function 'main': t122.c:6: error: assignment of read-only location '*foo' -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33901
[Bug c++/33900] (exception handling) bad/inconsistent code generation
--- Comment #1 from dannysmith at users dot sourceforge dot net 2007-10-25 20:41 --- My reading of 18.7.5 of C++98 standard says that throwing an exeception from a signal handler is implementation-defined, since such a signal handler is not a POF. Danny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33900
[Bug c++/33900] (exception handling) bad/inconsistent code generation
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-10-25 20:43 --- You need to use the option -fnon-call-exceptions to get exceptions boundaries at more than function calls. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33900
Re: [Bug fortran/31608] wrong types in character array/scalar binop
On 25 Oct 2007 19:50:54 -, Tobias dot Schlueter at physik dot
uni-muenchen dot de <[EMAIL PROTECTED]> wrote:
> I wonder why this name-mangling is necessary, it's not like these names
> are going to appear in the assembly, is it?
Those will not but other will like:
void f(void)
{
void g(void) {
}
g();
}
[Bug fortran/31608] wrong types in character array/scalar binop
--- Comment #47 from pinskia at gmail dot com 2007-10-25 20:45 ---
Subject: Re: wrong types in character array/scalar binop
On 25 Oct 2007 19:50:54 -, Tobias dot Schlueter at physik dot
uni-muenchen dot de <[EMAIL PROTECTED]> wrote:
> I wonder why this name-mangling is necessary, it's not like these names
> are going to appear in the assembly, is it?
Those will not but other will like:
void f(void)
{
void g(void) {
}
g();
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31608
[Bug debug/33739] [4.3 Regression] Failure of gfortran.dg/literal_character_constant_1_*.F with -m64 -g on Darwin
--- Comment #9 from dominiq at lps dot ens dot fr 2007-10-25 20:49 ---
I have done the following changes to gcc/fortran/scanner.c:
--- /opt/gcc/_gcc-clean/gcc/fortran/scanner.c 2007-10-04 17:26:43.0
+0200
+++ /opt/gcc/gcc-4.3-work/gcc/fortran/scanner.c 2007-10-25 22:28:09.0
+0200
@@ -324,6 +324,7 @@
/* We exit from an included file. */
(*debug_hooks->end_source_file)
(gfc_linebuf_linenum (gfc_current_locus.lb->next));
+ puts ("exit");
gfc_current_locus.lb->next->dbg_emitted = true;
}
else if (gfc_current_locus.lb->next->file != gfc_current_locus.lb->file
@@ -333,6 +334,7 @@
(*debug_hooks->start_source_file)
(gfc_linebuf_linenum (gfc_current_locus.lb),
gfc_current_locus.lb->next->file->filename);
+ puts ("enter");
gfc_current_locus.lb->next->dbg_emitted = true;
}
}
and I get:
[karma] f90/bug% gfc -m64 -g
/opt/gcc/_gcc-clean/gcc/testsuite/gfortran.dg/literal_character_constant_1_z.F
enter
ld64 warning: BINCL
(/opt/gcc/_gcc-clean/gcc/testsuite/gfortran.dg/literal_character_constant_1.inc)
missing EINCL in /var/tmp//cc3eAygx.o
i.e., the /* We exit from an included file. */ block is not reached (consistent
with the ld64 warning).
I also see the line
gfc_current_locus.lb = gfc_current_locus.lb->next;
does not it mean that "gfc_current_locus.lb->next->dbg_emitted" becomes
"gfc_current_locus.lb->dbg_emitted"? Unfortunatelly I do not understand the big
scheme behind the particular proc.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33739
[Bug fortran/31608] wrong types in character array/scalar binop
--- Comment #48 from dave at hiauly1 dot hia dot nrc dot ca 2007-10-25 20:57 --- Subject: Re: wrong types in character array/scalar binop > ./pa/pa.h:#define ASM_PN_FORMAT "%s___%lu" > ./v850/v850.h:#define ASM_PN_FORMAT "%s___%lu" > > It looks like you do :-) Yes, I found this after my last mail. I need to review this. The define is definitely not needed on linux. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31608
[Bug fortran/31608] wrong types in character array/scalar binop
--- Comment #49 from dave at hiauly1 dot hia dot nrc dot ca 2007-10-25 23:17 --- Subject: Re: wrong types in character array/scalar binop > Yes, I found this after my last mail. I need to review this. The define > is definitely not needed on linux. The HP assembler allows dots in symbols as long as the dot isn't the first character. Thus, the define appears unnecessary on the PA. I think deleting the define won't affect the ABI since it is only supposed to be used for internal static variables. I'm going to do some testing. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31608
[Bug fortran/29784] [doc] No I/O conversion of logical/integer
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-10-25 23:27 --- Subject: Bug 29784 Author: fxcoudert Date: Thu Oct 25 23:27:12 2007 New Revision: 129635 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129635 Log: PR fortran/29784 * gfortran.texi: Document that there is no logical/integer conversion performed during I/O operations. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/gfortran.texi -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29784
[Bug fortran/29784] [doc] No I/O conversion of logical/integer
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-10-25 23:27 --- Fixed. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29784
[Bug c++/33843] [4.1/4.2/4.3 regression] Broken diagnostic: 'bit_not_expr' not supported by pp_cxx_unqualified_id
--- Comment #1 from paolo at gcc dot gnu dot org 2007-10-25 23:43 --- Subject: Bug 33843 Author: paolo Date: Thu Oct 25 23:42:49 2007 New Revision: 129637 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129637 Log: 2007-10-25 Paolo Carlini <[EMAIL PROTECTED]> PR c++/33843 * cxx-pretty-print.c (pp_cxx_unqualified_id): Deal with BIT_NOT_EXPR. 2007-10-25 Paolo Carlini <[EMAIL PROTECTED]> PR c++/33843 * g++.dg/template/error32.C: New. Added: trunk/gcc/testsuite/g++.dg/template/error32.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cxx-pretty-print.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33843
[Bug libstdc++/33896] std::tr1::array has too-conservative alignment on _M_instance
--- Comment #1 from pcarlini at suse dot de 2007-10-25 23:45 --- This is already fixed in mainline. -- pcarlini at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33896
[Bug c++/33843] [4.1/4.2 regression] Broken diagnostic: 'bit_not_expr' not supported by pp_cxx_unqualified_id
--- Comment #2 from pcarlini at suse dot de 2007-10-25 23:46 --- Fixed in mainline. -- pcarlini at suse dot de changed: What|Removed |Added AssignedTo|pcarlini at suse dot de |unassigned at gcc dot gnu ||dot org Status|ASSIGNED|NEW Summary|[4.1/4.2/4.3 regression]|[4.1/4.2 regression] Broken |Broken diagnostic: |diagnostic: 'bit_not_expr' |'bit_not_expr' not supported|not supported by |by pp_cxx_unqualified_id|pp_cxx_unqualified_id http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33843
[Bug fortran/33499] Rejects valid module with a contained function with an ENTRY
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2007-10-26 02:22 --- FrRom my brief explorations, in resolve.c (resolve_entries) on or about line 560, we are NOT addressing the case for BT_DERIVED in the switch statement. If there we set sym = NULL for BT_DERIVED, we get past this section of code. Then we need to deal with the the same issue in resolve_unknown_f where we do not address setting the type for derived types, only, gfc_get_default_type which returns BT_UNKNOWN. I suspect we could fix this in more than one place. I was thinking in resolve_unknown_f . -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33499
[Bug c++/33902] New: alias warning returning typeid(void)
I distilled the following from boost, in the following discussion:
http://lists.boost.org/boost-users/2007/10/31690.php
namespace std { class type_info { }; }
struct Cow {
const std::type_info& moo() {
return typeid(void);
}
};
gcc4.3 -O2 -Wall -c reduced.cpp
Complains:
reduced.cpp: In member function 'const std::type_info& Cow::moo()':
reduced.cpp:5: warning: dereferencing type-punned pointer will break
strict-aliasing rules
This is gcc version 4.3.0 20071012 (experimental) (GCC).
The test case was reduced from something that #included the appropriate header
files for the type_info / typeid stuff; substitute that if you don't feel
comfortable with defining my own incompatible type_info.
--
Summary: alias warning returning typeid(void)
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: benoit dot hudson at gmail dot com
GCC target triplet: i386-apple-darwin8.10.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33902
[Bug c++/33902] alias warning returning typeid(void)
--- Comment #1 from benoit dot hudson at gmail dot com 2007-10-26 02:50 --- Perhaps I should mention the type in the typeid is irrelevant to whether this bug shows up, so it's not something funky about void. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33902
[Bug fortran/33499] Rejects valid module with a contained function with an ENTRY
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2007-10-26 03:15 --- I was in error, the function of interest is resolve_entries, here if the type is BT_UNKNOWN an attempt is made to get the type from the corresponding result. In this case the result is also BT_UNKNOWN. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33499
[Bug tree-optimization/23286] missed fully redundant expression
--- Comment #13 from astrange at ithinksw dot com 2007-10-26 04:08 --- The closed #32590 is a 4.3 regression, while this is only enhancement. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23286
[Bug other/31754] Include column number along line in error messages main.cpp:5:38
--- Comment #1 from tromey at gcc dot gnu dot org 2007-10-26 05:35 --- Note that even with mapped locations this gives the wrong result. The C++ parser has some column-number bugs. opsy. g++ -Wall -fsyntax-only z.cc z.cc: In function int main(): z.cc:8:61: error: wrong type argument to unary minus Column 61 is the closing paren around the "+" expression. Column 46 would be best. -- tromey at gcc dot gnu dot org changed: What|Removed |Added CC||tromey at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-10-26 05:35:43 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31754
[Bug middle-end/33581] OpenMP segmentation fault
--- Comment #7 from jakub at gcc dot gnu dot org 2007-10-26 06:49 --- Using -static for threaded programs is highly discouraged in glibc, for many reasons. If you want to do it anyway for whatever weird reason, you usually need to use -Wl,--whole-archive -lnptl -Wl,--no-whole-archive. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33581
[Bug libgomp/33275] Transient libgomp.fortran/omp_parse3.f90 -O0 failure
--- Comment #3 from jakub at gcc dot gnu dot org 2007-10-26 06:51 --- Fixed on the trunk. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33275
