--- Comment #3 from schwab at suse dot de 2008-07-24 08:29 ---
va_list can be any object type, including an array.
--
schwab at suse dot de changed:
What|Removed |Added
--- Comment #4 from burnus at gcc dot gnu dot org 2008-07-24 08:33 ---
(In reply to comment #3)
> Test case for the run-time check.
By itself this PR not related is PR 36909. However, both require that
gfc_conv_function_call passes on information. For PR 36909 one needs to have
the INTE
Maybe this could be handled by the Middle End, once the array operations in the
ME are implemented. This would save us from checking the alias information in
the FE.
Regarding the "Middle-End Array Expressions", see:
http://www.gccsummit.org/2008/gcc-2008-proceedings.pdf, pp. 33-42.
* * *
From:
OpenJDK (using the IcedTea6 build and patches) fails to build with 4.3 from the
4.3 branch, when the jvm built in stage1 is used for the first time in the
stage2 build:
-def-pcompile:
[javac] Compiling 2 source files to
/scratch/packages/openjdk/x/openjdk-6-6b11/openjdk/control/build/linux-i58
--- Comment #1 from doko at ubuntu dot com 2008-07-24 09:05 ---
Created an attachment (id=15948)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15948&action=view)
preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36917
--- Comment #2 from doko at ubuntu dot com 2008-07-24 09:06 ---
Created an attachment (id=15949)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15949&action=view)
tree dump (r136501 reverted)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36917
--- Comment #3 from doko at ubuntu dot com 2008-07-24 09:06 ---
Created an attachment (id=15950)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15950&action=view)
tree dump (r136501)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36917
--- Comment #4 from doko at ubuntu dot com 2008-07-24 09:07 ---
Created an attachment (id=15951)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15951&action=view)
diff of tree dump
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36917
--- Comment #5 from doko at ubuntu dot com 2008-07-24 09:15 ---
-O3 and -fwrapv, r136501 not reverted works
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36917
--- Comment #6 from pinskia at gcc dot gnu dot org 2008-07-24 09:27 ---
if -fwrapv works then is really a bug? Yes overflow is defined in java but c++
is not java.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #5 from tkoenig at gcc dot gnu dot org 2008-07-24 09:27 ---
Subject: Bug 29952
Author: tkoenig
Date: Thu Jul 24 09:26:43 2008
New Revision: 138112
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=138112
Log:
2008-07-24 Thomas Koenig <[EMAIL PROTECTED]>
PR fo
--- Comment #7 from doko at ubuntu dot com 2008-07-24 09:31 ---
Created an attachment (id=15952)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15952&action=view)
preprocessed source (no pch used)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36917
--- Comment #8 from rguenth at gcc dot gnu dot org 2008-07-24 09:31 ---
Looking at the source I don't see any integer overflows - the fact that
-fno-ivopts makes it work and the effect is on a variable introduced by
ivopts hints at a GCC bug more than a application bug.
So - now I canno
--- Comment #9 from rguenth at gcc dot gnu dot org 2008-07-24 09:52 ---
The difference comes from the second VRP pass which concludes that c_76 is
[1, +INF] from which it changes
# c_173 = PHI <0(7), c_76(12)>
to
# c_173 = PHI <0(7), 1(12)>
which it concludes from
c_76 = (Cell) D.15
--- Comment #1 from dfranke at gcc dot gnu dot org 2008-07-24 10:14 ---
Tobias, thanks for opening the PR.
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from victork at gcc dot gnu dot org 2008-07-24 12:30 ---
I'm going to submit a patch which will enable SLP vectorization on complex data
types. But SLP will handle only add, substruct, compare and other operations
which doesn't require permutation.
Adding ability to handl
--- Comment #3 from paolo dot carlini at oracle dot com 2008-07-24 12:44
---
(In reply to comment #2)
> Do you imply that it's source is universal? If so, can it be true that the GNU
> implementation of some lower level function called by 'rewind' is incorrect?
I meant simply that one
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-07-24 13:03 ---
See also PR36842 which would benefit as well.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #10 from rguenth at gcc dot gnu dot org 2008-07-24 14:34
---
Created an attachment (id=15953)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15953&action=view)
reduced testcase
Reduced testcase, -O2 -g --param ggc-min-expand=0 --param ggc-min-heapsize=0
--
http://
--- Comment #12 from hjl dot tools at gmail dot com 2008-07-24 13:15
---
[EMAIL PROTECTED] gcc]$ cat bar.i
typedef __builtin_va_list __gnuc_va_list;
extern void warning (int, const char *, ...) __attribute__ ((__format__
(__printf__, 2, 3))) __attribute__ ((__nonnull__ (2))) __attribute
--- Comment #1 from singler at gcc dot gnu dot org 2008-07-24 15:02 ---
The test program is wrong. The loop counter i is not mentioned in the parallel
clause, so it is *shared*. Thus, the two loops interfere and the calculation of
pi goes wrong. Add private(i) to the clause or declare it
--- Comment #11 from rguenth at gcc dot gnu dot org 2008-07-24 15:45
---
I have a patch.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedT
--- Comment #12 from rguenth at gcc dot gnu dot org 2008-07-24 15:51
---
Can you re-test bootstrap with
http://gcc.gnu.org/ml/gcc-patches/2008-07/msg01896.html
applied?
Thanks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36885
--- Comment #13 from hjl dot tools at gmail dot com 2008-07-24 15:51
---
ia64_override_options has
ia64_flag_schedule_insns2 = flag_schedule_insns_after_reload;
flag_schedule_insns_after_reload = 0;
If decode_options is called again without calling ia64_override_options,
ia64_flag
--- Comment #13 from rguenth at gcc dot gnu dot org 2008-07-24 16:12
---
Subject: Bug 36885
Author: rguenth
Date: Thu Jul 24 16:11:28 2008
New Revision: 138121
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=138121
Log:
2008-07-24 Richard Guenther <[EMAIL PROTECTED]>
--- Comment #4 from domob at gcc dot gnu dot org 2008-07-24 16:31 ---
This seems to be still in there... Any interest that I work on this? What's
about emitting a warning if either len= or a substring-reference expression is
of a KIND that can have larger values than the machine can ha
--- Comment #2 from domob at gcc dot gnu dot org 2008-07-24 17:03 ---
Isn't this maybe a general problem about optional string arguments? Or is this
really a eoshift-specific problem? I'm just thinking about a general solution
for this kind of problem if it isn't; in that case it would
As of 20080724, mainline doesn't bootstrap on sparc-sun-solaris2.11 (and
probably
every sparc target) like this:
checking for suffix of object files... configure: error: in
`/vol/gccsrc/obj/gcc-4.4.0-20080724/11-gcc/sparc-sun-solaris2.11/libgcc':
configure: error: cannot compute suffix
--- Comment #1 from ro at gcc dot gnu dot org 2008-07-24 17:21 ---
Michael, could you have a look? This seems to have been introduced by this
change:
2008-07-23 Michael Meissner <[EMAIL PROTECTED]>
Karthik Kumar <[EMAIL PROTECTED]>
[...]
* optc-gen.awk: Add suppo
--- Comment #14 from hjl dot tools at gmail dot com 2008-07-24 17:41
---
The following targets are affected by revision 138075:
arm/arm.c:flag_schedule_insns = flag_schedule_insns_after_reload = 0;
bfin/bfin.c: bfin_flag_var_tracking = flag_var_tracking;
bfin/bfin.c: bfin_flag_sc
--- Comment #15 from hjl dot tools at gmail dot com 2008-07-24 17:49
---
I don't think the middle-end should change optimization options
which have been overridden by the backend.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36907
--- Comment #2 from gnu at the-meissners dot org 2008-07-24 18:26 ---
Subject: Re: [4.4 regression] Bootstrap failure on
sparc: assertion failure in options.c
On Thu, Jul 24, 2008 at 05:21:10PM -, ro at gcc dot gnu dot org wrote:
>
>
> --- Comment #1 from ro at gcc do
--- Comment #3 from andreast at gcc dot gnu dot org 2008-07-24 18:36
---
I bootstrapped choice 1. No regressions.
I also prefer to save space where possible. So I'd like to avoid choice 3.
Can we also use 255 or 127 as value for DEFAULT_PCC_STRUCT_RETURN?
--
andreast at gcc dot gn
--- Comment #5 from gnu at the-meissners dot org 2008-07-24 18:49 ---
Subject: Re: [4.4 regression] Bootstrap failure on
sparc: assertion failure in options.c
On Thu, Jul 24, 2008 at 06:36:20PM -, andreast at gcc dot gnu dot org
wrote:
>
>
> --- Comment #3 from andrea
--- Comment #8 from domob at gcc dot gnu dot org 2008-07-24 18:53 ---
Subject: Bug 33141
Author: domob
Date: Thu Jul 24 18:52:51 2008
New Revision: 138122
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=138122
Log:
2008-07-24 Daniel Kraft <[EMAIL PROTECTED]>
PR fortran
--- Comment #14 from andreast at gcc dot gnu dot org 2008-07-24 18:58
---
Bootstrap passed. Tests will start soon.
Thanks.
--
andreast at gcc dot gnu dot org changed:
What|Removed |Added
As of 20080724, mainline fails to bootstrap on IRIX 6.5:
/vol/gccsrc/obj/gcc-4.4.0-20080724/6.5-gcc/./prev-gcc/xgcc
-B/vol/gccsrc/obj/gcc-4.4.0-20080724/6.5-gcc/./prev-gcc/
-B/vol/gcc/mips-sgi-irix6.5/bin/ -c -g -O2 -DIN_GCC -W -Wall -Wwrite-strings
-Wstrict-prototypes -Wmissing-prototypes
--- Comment #17 from andreast at gcc dot gnu dot org 2008-07-24 19:03
---
Just a comment, on the tuples branch, merged from main on 2008-07-23, the hangs
do not happen anymore. At least on x86_64-apple-darwin. i686-apple-darwin build
in progress.
--
http://gcc.gnu.org/bugzilla/show
--- Comment #1 from eric dot weddington at atmel dot com 2008-07-24 19:13
---
What 4.4 snapshot did you use to build?
I'm getting something very similar, but it's for avr5, not avr3:
../../../../gcc-4.4-20080718/libgcc/../gcc/config/avr/libgcc.S: Assembler
messages:
../../../../gcc-4.
--- Comment #9 from domob at gcc dot gnu dot org 2008-07-24 19:16 ---
Resolving fixed, discussion on better option names and minor changes welcome :)
--
domob at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #16 from gnu at the-meissners dot org 2008-07-24 19:19 ---
Subject: Re: [4.4 Regression]: Gcc failed to bootstrap
On Thu, Jul 24, 2008 at 05:49:02PM -, hjl dot tools at gmail dot com wrote:
>
>
> --- Comment #15 from hjl dot tools at gmail dot com 2008-07-24 17:4
--- Comment #17 from hjl dot tools at gmail dot com 2008-07-24 19:32
---
(In reply to comment #16)
> I haven't done a bootstrap built yet, but could you try this patch on the
> ia-64? When I try it via a cross compiler, it works fine, but I wonder
> whether
> random ports will do weir
--- Comment #1 from gcc at breakpoint dot cc 2008-07-24 19:48 ---
Does anybody care about this bug?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36047
--- Comment #6 from andreast at gcc dot gnu dot org 2008-07-24 19:50
---
Patch:
http://gcc.gnu.org/ml/gcc-patches/2008-07/msg01916.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36918
Building libicu from
http://packages.ubuntu.com/hardy/libicu38
using
configure --build=i686-pc-linux-gnu --host=arm-3d-linux-gnueabi
make
Configured and built without issue for a while then blew up;
arm-3d-linux-gnueabi-g++ -D_REENTRANT \
-I../common -I/tmp/icu/icu-3.8/icu/source/i1
--- Comment #1 from john dot spelis at 3dlabs dot com 2008-07-24 20:01
---
Created an attachment (id=15954)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15954&action=view)
save-temps file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36920
--- Comment #2 from john dot spelis at 3dlabs dot com 2008-07-24 20:01
---
Created an attachment (id=15955)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15955&action=view)
save-temps output
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36920
--- Comment #3 from john dot spelis at 3dlabs dot com 2008-07-24 20:02
---
Created an attachment (id=15956)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15956&action=view)
output file from save-temp
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36920
--- Comment #18 from gnu at the-meissners dot org 2008-07-24 20:11 ---
Subject: Re: [4.4 Regression]: Gcc failed to bootstrap
On Thu, Jul 24, 2008 at 07:33:01PM -, hjl dot tools at gmail dot com wrote:
>
>
> --- Comment #17 from hjl dot tools at gmail dot com 2008-07-24 19:3
--- Comment #19 from hjl dot tools at gmail dot com 2008-07-24 20:14
---
(In reply to comment #18)
> Subject: Re: [4.4 Regression]: Gcc failed to bootstrap
>
> Yes, I came to the same conclusion when trying a bootstrap. This patch adds a
> new SECONDARY_OVERRIDE_OPTION to be run in t
--- Comment #20 from gnu at the-meissners dot org 2008-07-24 20:21 ---
Subject: Re: [4.4 Regression]: Gcc failed to bootstrap
On Thu, Jul 24, 2008 at 08:14:35PM -, hjl dot tools at gmail dot com wrote:
>
>
> --- Comment #19 from hjl dot tools at gmail dot com 2008-07-24 20:1
--- Comment #18 from andreast at gcc dot gnu dot org 2008-07-24 20:23
---
I confirm that i686-apple-darwin on tuples branch does _not_ hang in these test
cases
Proposal, I know about plans to merge tuples in the next few days to trunk, so
we wait until this merge happened and see how t
In c++ the operators could be overloaded, therefore in special cases it could
have real and correct mathematical meaning. In my opinion, the bool-numeric
comparisons should be warned instead of the current solution.
--
Summary: comparsion does not have mathematical meaning is not
--- Comment #21 from hjl dot tools at gmail dot com 2008-07-24 20:29
---
(In reply to comment #18)
>
>
> +#ifdef SECONDARY_OVERRIDE_OPTIONS
> + /* Some machines may reject certain combinations of options. */
> + if (! first_time_p)
> +SECONDARY_OVERRIDE_OPTIONS;
> +#endif
> +
>
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-07-24 20:30 ---
Example?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Summary|compars
Current trunk is ICE'ing when trying to build CPU2006 benchmark 416.gamess with
-ftree-loop-linear.
run/build_base_gcc_64.0001> cat junk.f
SUBROUTINE GETCOF2(NP,FLM,ZLL,COEFF)
C
IMPLICIT DOUBLE PRECISION(A-H,O-Z)
PARAMETER (MAXCOF=23821)
DIMENSION COEFF(MAXCOF),
*
Trying to compile the following (already pre-processed) code causes ICE:
# 1 "gcc-ice.cpp"
# 1 ""
# 1 ""
# 1 "gcc-ice.cpp"
static float fraction( float _x )
{
int tmp;
asm ( "fld %0\n"
"fld %%st(0)\n"
"fisttp %1\n"
"fild %1\n"
"fxch\n"
"fsub %%st(1),%%st(0)\n"
: "=&t"( _x ), "=m"(
--- Comment #12 from andry at inbox dot ru 2008-07-24 21:14 ---
I have the same issue on i686-pc-mingw32.
It is slightly different issue, is about: "ld: no such file or directory".
I take a look in to generated Makefile and found this:
"LD = c:/mingw/bin/../lib/gcc/mingw32/3.4.5/../../..
--- Comment #13 from andry at inbox dot ru 2008-07-24 21:35 ---
I found which part of Makefile broken: "$CC -print-prog-name=ld".
This is means that mingw build already broken, if root mingw directory differs
from "mingw32" folder.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3633
On Linux/x86, revision 138087 caused
FAIL: ext/mt_allocator/deallocate_local_thread-5.cc execution test
FAIL: ext/mt_allocator/deallocate_local_thread-7.cc execution test
--
Summary: [4.4 Regression] Revision 138087 breaks libstdc++
Product: gcc
Version: 4.4.0
--- Comment #1 from paolo dot carlini at oracle dot com 2008-07-24 22:06
---
I suppose you can believe me if I tell you that I care about libstdc++-v3.
Then, commit 138087 cannot have anything to do with these failures, really,
believe me. Actually, I suspect 138092 is ""at fault"". Ar
--- Comment #18 from drow at gcc dot gnu dot org 2008-07-24 22:18 ---
Putting the regression marker back. The code doesn't matter; if it's a
regression, then it's regression.
--
drow at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from paolo at gcc dot gnu dot org 2008-07-24 22:48 ---
Subject: Bug 36924
Author: paolo
Date: Thu Jul 24 22:47:26 2008
New Revision: 138127
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=138127
Log:
2008-07-24 Paolo Carlini <[EMAIL PROTECTED]>
PR libstd
--- Comment #3 from paolo dot carlini at oracle dot com 2008-07-24 22:49
---
Reverted the commit because anyway we want to pursue a completely different
strategy. Really, my previous comment stays. Anyway.
--
paolo dot carlini at oracle dot com changed:
What|Removed
--- Comment #4 from hjl dot tools at gmail dot com 2008-07-24 23:17 ---
(In reply to comment #1)
> I suppose you can believe me if I tell you that I care about libstdc++-v3.
>
> Then, commit 138087 cannot have anything to do with these failures, really,
> believe me. Actually, I suspect
When I was looking up something in the Altivec PIM if "vector bool a;" was
valid, I
noticed a section which I had never read before, most likely because it is part
of the ABI
section of the Altivec PIM.
The specific section says:
3.5 malloc(), vec_malloc(), and new
In the interest of saving sp
--- Comment #5 from paolo dot carlini at oracle dot com 2008-07-24 23:20
---
(In reply to comment #4)
> librt will make stack limit very small. It is a known issue.
Ah, Ok, that is useful to know.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36924
While compiling 483.xalancbmk in SPEC CPU 2006, revision 138092
caused:
[EMAIL PROTECTED] build_base_o2.]$
/export/gnu/import/rrs/138092/usr/bin/g++ -c
-o NamespacesHandler.o -DSPEC_CPU -DNDEBUG -DAPP_NO_THREADS
-DXALAN_INMEM_MSG_LOADER -I. -Ixercesc -Ixercesc/dom -Ixercesc/dom/impl
-Ixerces
With the addition of the function specific attributes support, the #pragma that
the Altivec PIM describes can be implemented.
#pragma altivec_codegen on | off
When this pragma is on, the compiler may use AltiVec instructions. When you set
this
pragma off, the altivec_model pragma is also set to o
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-07-24 23:50 ---
please attach the preprocessed source and maybe even the backtrace.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #2 from hjl dot tools at gmail dot com 2008-07-24 23:55 ---
Program received signal SIGSEGV, Segmentation fault.
ipa_get_stmt_member_ptr_load_param (stmt=0x0) at ../../src/gcc/ipa-prop.c:611
611 if (TREE_CODE (stmt) != GIMPLE_MODIFY_STMT)
(gdb) bt
#0 ipa_get_stmt_membe
--- Comment #7 from dodji at gcc dot gnu dot org 2008-07-25 00:03 ---
Created an attachment (id=15957)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15957&action=view)
fixes DECL_CONTEXT() of the temporary variables in the initialiser
So this patch seems to make the crash go away
--- Comment #8 from dodji at gcc dot gnu dot org 2008-07-25 00:04 ---
By the way, I can reproduce the problem on trunk. I think I was lacking sleep
when I first said I could not reproduce it on trunk. Sorry.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36767
--- Comment #3 from hjl dot tools at gmail dot com 2008-07-25 00:11 ---
(gdb) f 1
#1 0x008e3619 in ipa_analyze_call_uses (info=0x2a9bed6998,
call=0x2a9bb25690, stmt=0x2a9bb285a0) at ../../src/gcc/ipa-prop.c:749
749 if ((rec = ipa_get_stmt_member_ptr_load_param (d1)))
--- Comment #4 from hjl dot tools at gmail dot com 2008-07-25 00:12 ---
(gdb) call debug_tree (def)
unsigned DI
size
unit size
align 64 symtab 0 alias set -1 canonical type 0x2a9ac8a3c0>
var def_stmt
version 46>
ar
--- Comment #5 from hjl dot tools at gmail dot com 2008-07-25 01:05 ---
Created an attachment (id=15958)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15958&action=view)
A testcase
[EMAIL PROTECTED] XSLT]$ /export/gnu/import/rrs/138092/usr/bin/g++ -O2 -S x.ii
x.cc: In member funct
--- Comment #9 from jason at gcc dot gnu dot org 2008-07-25 02:32 ---
I accidentally checked in the demangler patch with my defaulted/deleted
functions work today, so you don't need to worry about that. :)
As for the patch itself, does it work to scan for DECL_EXPRs instead of the
decl
The temporary is not needed in this case.
$ cat foo.f90
program main
real, dimension(10) :: a
read (10) a
a(2:10:2) = a (1:9:2)
end program main
$ gfortran -Warray-temporaries foo.f90
foo.f90:4.14:
a(2:10:2) = a (1:9:2)
1
Warning: Creating array temporary at (1)
--
--- Comment #19 from dominiq at lps dot ens dot fr 2008-07-25 06:56 ---
> I confirm that i686-apple-darwin on tuples branch does _not_ hang in these
> test cases
Is this a real fix, i.e., the cause(s) of the hanging has(ve) been understood
and fixed? or does it just happen that the han
79 matches
Mail list logo
