--- Comment #1 from ubizjak at gmail dot com 2008-03-17 06:48 ---
Please post patch with appropriate ChangeLog entry to gcc-patches mailing list.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35614
--- Comment #3 from xinliangli at gmail dot com 2008-03-17 06:36 ---
(In reply to comment #2)
> Hmm, reorder basic blocks already takes into the edge probability.
>
Yes, I checked that gcc is doing good job in code layout with FDO for better
icache utilization.
--
http://gcc.gnu.o
--
petrosyan at gmail dot com changed:
What|Removed |Added
Severity|normal |trivial
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35614
Traditionally it is accepted to pug GNU library info documentation files into
"Libraries" category. libgomp info file goes into "GNU Libraries" category.
The following patch fixes the bug:
--- libgomp.texi.old2008-03-17 00:07:13.0 -0400
+++ libgomp.texi2008-03-17 00:07:25.00
bind_c_usage_8.f03 in gcc/testsuite/gfortran.dg contains:
! PR fortran/32797
!
MODULE ISO_C_UTILITIES
USE ISO_C_BINDING
implicit none
CHARACTER(C_CHAR), DIMENSION(1), SAVE, TARGET, PRIVATE :: dummy_string="?"
CONTAINS
FUNCTION C_F_STRING(CPTR) RESULT(FPTR)
use, intrinsic :: iso_c_
bind_c_usage_8.f03 in gcc/testsuite/gfortran.dg contains:
! PR fortran/32797
!
MODULE ISO_C_UTILITIES
USE ISO_C_BINDING
implicit none
CHARACTER(C_CHAR), DIMENSION(1), SAVE, TARGET, PRIVATE :: dummy_string="?"
CONTAINS
FUNCTION C_F_STRING(CPTR) RESULT(FPTR)
use, intrinsic :: iso_c_
--- Comment #2 from danglin at gcc dot gnu dot org 2008-03-17 02:29 ---
Same failure is also present on hppa2.0w-hp-hpux11.11 (4.3.1) and
hppa64-hp-hpux11.11 (4.4.0). There are quite a few other libgomp
fails that are probably the same bug.
--
danglin at gcc dot gnu dot org changed:
--- Comment #1 from danglin at gcc dot gnu dot org 2008-03-17 02:16 ---
The test didn't fail in revision 133125.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35611
Executing on host: /home/dave/gnu/gcc-4.4/objdir/gcc/xgcc
-B/home/dave/gnu/gcc-4.4/objdir/gcc/
/home/dave/gnu/gcc-4.4/gcc/libgomp/testsuite/libgomp.c/omp-nested-1.c
-B/home/dave/gnu/gcc-4.4/objdir/hppa-linux/./libgomp/
-I/home/dave/gnu/gcc-4.4/objdir/hppa-linux/./libgomp
-I/home/dave/gnu/gcc-4.4/g
--- Comment #15 from gnu_andrew at member dot fsf dot org 2008-03-17 01:30
---
Created an attachment (id=15336)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15336&action=view)
Move towards a CPStringBuilder-using code base
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21869
--- Comment #14 from gnu_andrew at member dot fsf dot org 2008-03-17 00:37
---
Created an attachment (id=15335)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15335&action=view)
Abstract reflection elements of CPStringBuilder to a VM class
--
http://gcc.gnu.org/bugzilla/show_b
--- Comment #13 from gnu_andrew at member dot fsf dot org 2008-03-16 23:37
---
Created an attachment (id=15334)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15334&action=view)
Move towards a CPStringBuilder-using code base
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21869
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-03-16 23:06 ---
(In reply to comment #3)
> When i can understand which token is valid then?
By reading the C/C++ standards :). But basically in this case foo and ( are
two different tokens. Examples of valid tokens: "->", "foo",
--- Comment #3 from andry at inbox dot ru 2008-03-16 22:56 ---
(In reply to comment #2)
> ## only works to form a valid token, if it does not, then the code is invalid.
>
When i can understand which token is valid then?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35610
--- Comment #1 from starlight at binnacle dot cx 2008-03-16 22:49 ---
Hit this same issue. The problem is likely that the -fvisibility=hidden
option is also on the compile line. Removing it makes the problem go
away, at least for single-threaded mudflap.
Produced with gcc 4.2.3, x86_6
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-03-16 22:49 ---
## only works to form a valid token, if it does not, then the code is invalid.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35610
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-03-16 22:46 ---
Yes and GCC behavior is correct. pasting foo and ( don't make a valid
preprocessing token.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #12 from gnu_andrew at member dot fsf dot org 2008-03-16 22:45
---
Created an attachment (id=15333)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15333&action=view)
Move towards a CPStringBuilder-using code base
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21869
MSVC++ from 2003 to 2008 and comeau compiler v4.9.3b gives no errors about
that:
//-
#define CAT(a,b) a ## b
void foo(int a) {}
void foo(int a,int b) {}
int main() {
CAT(foo,(1)); //error
CAT(foo,(1,2)); //error
return 0;
}
//---
--- Comment #11 from gnu_andrew at member dot fsf dot org 2008-03-16 22:29
---
Created an attachment (id=15332)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15332&action=view)
Move towards a CPStringBuilder-using code base
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21869
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-03-16 21:32 ---
The warning works as designed, the PHI node in question that causes the
warning only has a single incoming edge:
testfunc ()
{
int alt_reloc;
int foo.0;
:
foo.0_1 = foo;
if (foo.0_1 > 19)
goto ;
else
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-03-16 21:30 ---
So Jump threading comes along and threads the jump for some reason makes the
PHI node go away.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35609
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Summary|[4.3/4.4 Regression] bogus |[4.3/4.4 Regression] "is
|"is used uninitialized in
some athwartanyone it apportion
<-- snip -->
$ cat test.c
int foo, bar;
void decode_reloc(int reloc, int *is_alt)
{
if (reloc >= 20)
*is_alt = 1;
else if (reloc >= 10)
*is_alt = 0;
}
void testfunc()
{
int alt_reloc;
decode_reloc(foo, &alt_reloc);
if (alt_reloc)
bar = 42;
}
$ gcc -O2 -Wall -c test.
--- Comment #9 from pault at gcc dot gnu dot org 2008-03-16 19:15 ---
Fixed on trunk
Thanks for the report
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #8 from pault at gcc dot gnu dot org 2008-03-16 19:15 ---
Subject: Bug 35470
Author: pault
Date: Sun Mar 16 19:14:17 2008
New Revision: 133279
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133279
Log:
2008-03-16 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Component|middle-end |tree-optimization
Priority|P3 |P2
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Known to fail||4.2.3
Known to work||4.3.0
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.2.4 |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32723
--- Comment #9 from rguenth at gcc dot gnu dot org 2008-03-16 17:32 ---
This will not be fixed on the 4.2 branch. Closing as fixed for 4.3.0.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #18 from rguenth at gcc dot gnu dot org 2008-03-16 17:29
---
This will not be fixed on the 4.2 branch. Closing as fixed in 4.3.0.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
-
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Known to fail|4.2.0 4.2.1 4.2.2 |4.2.0 4.2.1 4.2.2 4.2.3
Priority|P1
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Known to work||4.3.0
Priority|P4 |P5
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Known to work||4.3.0
Priority|P4 |P5
http://gcc
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Known to work||4.3.0
Priority|P4 |P5
http://gcc
--- Comment #8 from rguenth at gcc dot gnu dot org 2008-03-16 17:17 ---
What is the status on the 4.3 branch and the trunk?
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #3 from schwab at suse dot de 2008-03-16 17:17 ---
Not a bug.
--
schwab at suse dot de changed:
What|Removed |Added
Status|UNCONFIRMED
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Known to work||4.3.0
Priority|P4 |P5
http://gcc
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||ice-on-invalid-code
Priority|P4 |P
--- Comment #12 from danglin at gcc dot gnu dot org 2008-03-16 16:49
---
On hppa64-hp-hpux11.11,
FAIL: gcc.dg/tree-ssa/ssa-store-ccp-3.c scan-tree-dump-times optimized
"conststa
ticvariable" 1
The tree dump is the same as for darwin. This target is always pic.
--
danglin at gcc d
--- Comment #2 from mikpe at it dot uu dot se 2008-03-16 16:49 ---
(In reply to comment #1)
> This happens with 4.1, 4.2 and trunk on old ABI. Apparently it doesn't
> happen with EABI.
>
I see the problem too, on Linux/ARM/OABI with gcc-4.1.2.
However, the problem is in the test case
--- Comment #18 from danglin at gcc dot gnu dot org 2008-03-16 16:27
---
Executing on host: /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/
/te
st/gnu/gcc/gcc/gcc/testsuite/gcc.dg/tree-prof/pr34999.c -O2
-freorder-blocks-a
nd-partition -fprofile-use -D_PROFILE_USE -fno-show-
--- Comment #2 from jrp at dial dot pipex dot com 2008-03-16 16:07 ---
PASS: gcc.c-torture/compile/limits-structnest.c -O1 (test for excess errors)
Executing on host: /home/jrp/build/gcc/xgcc -B/home/jrp/build/gcc/ -O2 -w
-fn
o-show-column -c -o limits-structnest.o
/home/jrp/gcc/gc
--- Comment #7 from rguenth at gcc dot gnu dot org 2008-03-16 15:55 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #2 from dfranke at gcc dot gnu dot org 2008-03-16 15:55 ---
> function func2()
> type(bar) func2
> allocate(func1%baz(1))
> end function
In primary.c(match_variable), case FL_PROCEDURE, we here have a function that
satisfies the first if-clause, but does not trigger the
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-03-16 15:55 ---
What is the excess error (look in the gcc/testsuite/gcc/gcc.log file)? usually
this test blows memory/stack, so possibly just gets killed by the kernel.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35608
--- Comment #8 from danglin at gcc dot gnu dot org 2008-03-16 15:51 ---
Fixed by change.
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #7 from danglin at gcc dot gnu dot org 2008-03-16 15:50 ---
Subject: Bug 31510
Author: danglin
Date: Sun Mar 16 15:49:55 2008
New Revision: 133275
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133275
Log:
PR debug/31510
* dbxout.c (dbxout_expand_expr
--- Comment #6 from danglin at gcc dot gnu dot org 2008-03-16 15:48 ---
Subject: Bug 31510
Author: danglin
Date: Sun Mar 16 15:48:09 2008
New Revision: 133274
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133274
Log:
PR debug/31510
* dbxout.c (dbxout_expand_expr
--- Comment #6 from rguenth at gcc dot gnu dot org 2008-03-16 15:45 ---
Subject: Bug 35607
Author: rguenth
Date: Sun Mar 16 15:45:09 2008
New Revision: 133273
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133273
Log:
2008-03-16 Richard Guenther <[EMAIL PROTECTED]>
PR
com
GCC build triplet: 4.4.0 20080316 (experimental) (GCC)
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35608
--- Comment #1 from dominiq at lps dot ens dot fr 2008-03-16 13:46 ---
Reduced test case:
program prandtl meyer
implicit none
integer :: i, j
integer, parameter :: imax = 100
integer, parameter :: jmax = 40
real, dimension(0:jmax,0:imax) :: f1,
--- Comment #4 from dfranke at gcc dot gnu dot org 2008-03-16 13:01 ---
$> gfortran-svn -v
Target: i686-pc-linux-gnu
gcc version 4.4.0 20080315 (experimental) (GCC)
$> gfortran-svn -g -Wall -W transfer_assumed_size_1.f90
$> valgrind --tool=memcheck --leak-check=full a.out
[...]
==6291=
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dfranke at gcc dot gnu dot
|dot org
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-03-16 12:32 ---
One solution is to, in expand_simple_operations, expand all TREE_INVARIANT
operations so we end up with
# ivtmp.16_1 = PHI
instead which we can let pass verification without fatal effects.
The other solution is
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-03-16 12:23 ---
The concrete problem with allowing &foo[(int)z_4] in a PHI node argument is
that we cannot cope with immediate uses in PHI nodes and thus DCE z_4 and
end up with a reference to a deleted SSA_NAME during expansion (ye
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-03-16 12:20 ---
This invariantness of (unsigned int) D.1189_5 in
__fini_array_end.0_2 = (int) &__fini_array_end;
__fini_array_start.1_3 = (int) &__fini_array_start;
D.1188_4 = __fini_array_end.0_2 - __fini_array_start.1_3;
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-03-16 11:47 ---
Hm, no. This address isn't invariant at all.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35607
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-03-16 11:45 ---
force_gimple_operand doesn't gimplify
&__fini_array_start[(unsigned int) D.1189_5]
because is_gimple_min_invariant returns true for it.
And the verification failure is just an artifact of that. I have a patch.
extern void (*__fini_array_start []) (void);
extern void (*__fini_array_end []) (void);
void
__libc_csu_fini (void)
{
__SIZE_TYPE__ i = __fini_array_end - __fini_array_start;
while (i-- > 0)
(*__fini_array_start [i]) ();
}
./cc1 -quiet elf-init.i -O
elf-init.i: In function '__libc_csu_fin
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-03-16 10:57 ---
*** Bug 35605 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35604
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-03-16 10:57 ---
*** This bug has been marked as a duplicate of 35604 ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #5 from dfranke at gcc dot gnu dot org 2008-03-16 10:07 ---
Added testcase to testsuite. Backport unlikely as 4.3.0 (which works) is
released and manpower is limited. Closing.
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Add
--- Comment #4 from dfranke at gcc dot gnu dot org 2008-03-16 10:06 ---
Subject: Bug 35582
Author: dfranke
Date: Sun Mar 16 10:05:18 2008
New Revision: 133270
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133270
Log:
2008-03-16 Daniel Franke <[EMAIL PROTECTED]>
PR fo
Compiling this simple C++ file:
#pragma weak my_weak_function
extern "C" void my_function_to_be_renamed (void) asm ("my_renamed_function");
gives me the warning
foo.cc:2: warning: asm declaration ignored due to conflict with previous rename
This does not make sense, as there is no previous rena
This problem can be seen by compiling testsuite/gfortran.dg/g77/ndrm2.f. The
label reference (after x87 stack compensation edge is inserted) is updated only
in final jump insn, but other references to the same label are left untouched.
We enter stack pass with:
(insn:TI 19 20 18 4 dnrm2.f:33 (set
This problem can be seen by compiling testsuite/gfortran.dg/g77/ndrm2.f. The
label reference (after x87 stack compensation edge is inserted) is updated only
in final jump insn, but other references to the same label are left untouched.
We enter stack pass with:
(insn:TI 19 20 18 4 dnrm2.f:33 (set
--- Comment #7 from pault at gcc dot gnu dot org 2008-03-16 07:15 ---
(In reply to comment #6)
> You r 'this' is better than my 'Think' Passed regression testing here on
> x86-64.
>
Jerry,
I did not see that you were working on it - sorry that I trampled on your toes.
I took a copy of
69 matches
Mail list logo