--- 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
--
tobi at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|tobi at gcc dot gnu dot org |unassigned at gcc dot gnu
|
--- 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.102
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed
--- 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
--- 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' i
--- 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-o
--- 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 f
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last recon
--- 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 neit
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de
|dot org |
--- 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 w
--- 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 accord
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/
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 m
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 sh
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--;
--- 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
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 workstatio
--- 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? (whic
--- 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
Statu
--- 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
-
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
Last reconfirmed|2007-08-06 14:06:57 |2007-10
--- 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 na
--- 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:4
--- 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-muench
--- 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
--- 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
-
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+LASTPRIV
--- 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 (v
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,
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()
IN
--- 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.".
--- 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-
--- 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 use
--
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
--- 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'
EN
--- 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
--- 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
---
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/h
--- 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.
We
--- 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
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 bi
--- 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) Processo
# 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=/m
--- 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_PRIVAT
--
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
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 jus
--- 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_
--- 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: a
--- 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/bu
--- 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
--
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
--- 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, i
--- 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.
--- 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 afte
--- 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 s
--- 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: Docume
--- 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
--- 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++/33
--- 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
St
--- 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
--- 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
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
--- 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
--- 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.
--
ht
--- 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
--- 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 t
--- 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.
--- 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|
70 matches
Mail list logo
