--- Comment #71 from hp at gcc dot gnu dot org 2008-08-30 06:27 ---
Created an attachment (id=16169)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16169&action=view)
Patch, take 6.
Sigh. This just moves the TREE_STATIC check from the early-return to the
weak-test, since it's wron
--- Comment #5 from corsepiu at gcc dot gnu dot org 2008-08-30 05:13
---
With gcc-4.3.2, for me, the "j1.c" testcase doesn't segfault anymore.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36583
--- Comment #70 from hp at gcc dot gnu dot org 2008-08-30 03:37 ---
(In reply to comment #67)
> > - .IMPORT _ZNSoD1Ev,CODE
>
> If any of these functions is present in the .s, then there's a problem.
> The default for a 32-bit HP-UX symbol that isn't imported is DATA.
The problem
--- Comment #69 from hp at gcc dot gnu dot org 2008-08-30 03:20 ---
(In reply to comment #64)
> Not sure what you meant by that comment; that's not what happens here AFAICT.
> I stated that output_operand does not see the same symbol_ref as was passed to
> the rtl insn expander, so targe
--- Comment #1 from kargl at gcc dot gnu dot org 2008-08-30 02:58 ---
I may have a patch for this problem. Note, there is an ambiguity
due to a set of intrinsics such as ETIME, which has both a function
form and a subroutine form.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3322
--- Comment #68 from dave at hiauly1 dot hia dot nrc dot ca 2008-08-30
02:48 ---
Subject: Re: [4.4 Regression]: gcc.dg/weak/weak-1.c
> > If the encoding for function names is getting stripped, then
> > ASM_OUTPUT_EXTERNAL_REAL will fail to type the symbol correctly.
>
> Not sure what
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-08-30 01:41 ---
I have seen this in other cases even for the non doloop case, though I don't
know if it is because of -O1 or because it is not removing it.
Testcase:
int _bfd_xcoff_canonicalize_dynamic_reloc (unsigned long long l_sy
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |blocker
Target Milestone|--- |4.4.0
http:
Hi, it looks like some of the VRP enhancements for switch statements is causing
an ICE on some code in binutils.
Testcase:
_bfd_xcoff_canonicalize_dynamic_reloc (unsigned long long l_symndx)
{
if (l_symndx < 3)
{
switch (l_symndx)
{
case 0:
case 1:
break;
--- Comment #67 from dave at hiauly1 dot hia dot nrc dot ca 2008-08-30
01:19 ---
Subject: Re: [4.4 Regression]: gcc.dg/weak/weak-1.c
> If the extern references had been "sort -u":ed, they'd had looked like this,
> diff from unpatched to patched for the attachment in comment #61, compi
--- Comment #66 from hp at gcc dot gnu dot org 2008-08-30 01:08 ---
(In reply to comment #61)
> Created an attachment (id=16165)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16165&action=view) [edit]
> preprocessed source from hppa2.0w-hp-hpux11.11
Could you please dig out the c
--- Comment #65 from hp at gcc dot gnu dot org 2008-08-30 01:05 ---
If the extern references had been "sort -u":ed, they'd had looked like this,
diff from unpatched to patched for the attachment in comment #61, compiled with
-O2:
--- ../../../comboo/hppa2/gcc/hppa2.s 2008-08-29 22:32:
--- Comment #64 from hp at gcc dot gnu dot org 2008-08-30 00:39 ---
(In reply to comment #63)
> If the encoding for function names is getting stripped, then
> ASM_OUTPUT_EXTERNAL_REAL will fail to type the symbol correctly.
Not sure what you meant by that comment; that's not what happen
--- Comment #3 from mckelvey at maskull dot com 2008-08-30 00:14 ---
Created an attachment (id=16168)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16168&action=view)
Smaller test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37284
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-08-29 23:52 ---
change_dynamic_type should have been removed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from mckelvey at maskull dot com 2008-08-29 23:51 ---
Created an attachment (id=16167)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16167&action=view)
Compressed preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37284
Does not ICE without -fstrict-aliasing:
$ g++ -c -fstrict-aliasing PatternDriverTop.cc
In file included from
/usr/local/lib/gcc/i686-pc-cygwin/4.4.0/../../../../include/c++/4.4.0/i686-pc-cygwin/bits/c++allocator.h:40,
from
/usr/local/lib/gcc/i686-pc-cygwin/4.4.0/../../../../includ
--- Comment #7 from sam at gcc dot gnu dot org 2008-08-29 23:46 ---
I think the fix is wrong: when optimization_options() is called, user options
have not been processed yet. It is likely that section anchors are always
disabled by this change.
The patch for PR37283 at
http://gcc.gnu.or
--- Comment #13 from jsm28 at gcc dot gnu dot org 2008-08-29 23:31 ---
Subject: Bug 37086
Author: jsm28
Date: Fri Aug 29 23:30:18 2008
New Revision: 139792
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=139792
Log:
PR bootstrap/37086
* tree-vrp.c (find_switch_ass
--- Comment #3 from kargl at gcc dot gnu dot org 2008-08-29 23:20 ---
See
http://gcc.gnu.org/ml/gcc-patches/2008-08/msg02322.html
Your welcome.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36153
--- Comment #3 from sam at gcc dot gnu dot org 2008-08-29 22:53 ---
Right. There are two problems indeed, fix is being tested.
--
sam at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #63 from dave at hiauly1 dot hia dot nrc dot ca 2008-08-29
22:39 ---
Subject: Re: [4.4 Regression]: gcc.dg/weak/weak-1.c
> Looks like the HPPA port, like Darwin, transforms the original symbol_refs
> upon
> seeing them, such that output_operand doesn't see all required,
--- Comment #62 from hp at gcc dot gnu dot org 2008-08-29 20:51 ---
Looks like the HPPA port, like Darwin, transforms the original symbol_refs upon
seeing them, such that output_operand doesn't see all required,
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37170
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-08-29 20:48 ---
First the back-end does not disable section anchors for -fno-toplevel-reorder
so that is being produced.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37283
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pbrook at gcc dot gnu dot
|
--- Comment #1 from sam at gcc dot gnu dot org 2008-08-29 20:37 ---
Created an attachment (id=16166)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16166&action=view)
crtstuff.s produced by GCC
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37283
GCC (SVN trunk 139772) generates code that GNU as (Binutils 2.18.50.20080827)
refuses to assemble:
T=`${PWDCMD-pwd}`/ \
&& cd ../.././gcc \
&& make GCC_FOR_TARGET="/home/arm/build/gcc/./gcc/xgcc
-B/home/arm/build/gcc/./gcc/ -B/home/arm/install/arm-elf/bin/
-B/home/arm/install/arm-e
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2008-08-29 20:26
---
Remove --with-dwarf2, it is useless now.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #15 from pinskia at gcc dot gnu dot org 2008-08-29 19:46
---
(In reply to comment #14)
> I suspect this patch
>
> http://gcc.gnu.org/ml/gcc-patches/2008-08/msg01903.html
>
That patch enabled IRA by default, before it was only enabled via the -fira
flag. So please test be
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-08-29 19:45 ---
I think that patch is a mis labeled. Before that patch IRA was not enabled by
default so running the testsuite without -fira as the option passed to GCC to
one after that patch does not show the regressions.
--
--- Comment #1 from hjl dot tools at gmail dot com 2008-08-29 19:40 ---
On Linux/ia64, it caused
+FAIL: g++.dg/opt/eh3.C execution test
+FAIL: gfortran.dg/list_read_8.f90 -O0 execution test
+FAIL: gfortran.dg/list_read_8.f90 -O1 execution test
+FAIL: gfortran.dg/list_read_8.f90 -O2
On IRA branch, revision 139582 caused
+FAIL: 21_strings/basic_string/numeric_conversions/char/stoi.cc execution test
+FAIL: 21_strings/basic_string/numeric_conversions/char/stol.cc execution test
+FAIL: 21_strings/basic_string/numeric_conversions/char/stoul.cc execution test
+FAIL: gcc.target/i386
--- Comment #4 from vmakarov at redhat dot com 2008-08-29 19:17 ---
I believe that patch
http://gcc.gnu.org/ml/gcc-patches/2008-08/msg02279.html
solves the problem.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36539
--- Comment #6 from jakub at gcc dot gnu dot org 2008-08-29 19:11 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #5 from jakub at gcc dot gnu dot org 2008-08-29 19:09 ---
Subject: Bug 37261
Author: jakub
Date: Fri Aug 29 19:08:18 2008
New Revision: 139786
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=139786
Log:
PR c/37261
* fold-const.c (fold_binary): In (X |
--- Comment #4 from jakub at gcc dot gnu dot org 2008-08-29 19:00 ---
Subject: Bug 37261
Author: jakub
Date: Fri Aug 29 18:59:13 2008
New Revision: 139784
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=139784
Log:
PR c/37261
* fold-const.c (fold_binary): In (X |
--- Comment #7 from jakub at gcc dot gnu dot org 2008-08-29 18:48 ---
Subject: Bug 24790
Author: jakub
Date: Fri Aug 29 18:47:19 2008
New Revision: 139777
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=139777
Log:
PR fortran/24790
* trans-decl.c (create_function_
--- Comment #8 from jakub at gcc dot gnu dot org 2008-08-29 18:46 ---
Subject: Bug 23057
Author: jakub
Date: Fri Aug 29 18:45:25 2008
New Revision: 139775
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=139775
Log:
PR fortran/23057
* dwarf2out.c (gen_variable_die)
--- Comment #9 from paolo dot carlini at oracle dot com 2008-08-29 18:46
---
FWIW, this kind of contortion appear to work, but really I'd rather prefer not
using it...
namespace my_std
{
inline double
atan(double __x)
{ return __builtin_atan(__x); }
inline double
atanh(doubl
--- Comment #10 from jakub at gcc dot gnu dot org 2008-08-29 18:42 ---
Subject: Bug 29635
Author: jakub
Date: Fri Aug 29 18:41:19 2008
New Revision: 139773
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=139773
Log:
PR fortran/29635
PR fortran/23057
* debu
--- Comment #7 from jakub at gcc dot gnu dot org 2008-08-29 18:42 ---
Subject: Bug 23057
Author: jakub
Date: Fri Aug 29 18:41:19 2008
New Revision: 139773
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=139773
Log:
PR fortran/29635
PR fortran/23057
* debug
--- Comment #14 from hjl dot tools at gmail dot com 2008-08-29 18:24
---
I suspect this patch
http://gcc.gnu.org/ml/gcc-patches/2008-08/msg01903.html
is incorrect. Back it out from IRA branch fixed the testcase
in comment #11. I am running SPEC CPU 2000/2006 with IRA
branch using revi
--- Comment #61 from andreast at gcc dot gnu dot org 2008-08-29 17:16
---
Created an attachment (id=16165)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16165&action=view)
preprocessed source from hppa2.0w-hp-hpux11.11
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37170
--- Comment #4 from hp at gcc dot gnu dot org 2008-08-29 17:03 ---
A wee bit shorter:
extern int kallsyms_token_index[] __attribute__((weak));
extern int kallsyms_token_table[] __attribute__((weak));
void kallsyms_expand_symbol(int *result)
{
int len = *result;
int *tptr;
while(len
--- Comment #3 from manu at gcc dot gnu dot org 2008-08-29 17:00 ---
In GCC 4.4 we warn about this with -Wconversion.
warning: the result of the conversion is unspecified because 32 is outside
the range of type MyTypes::Type
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37281
--- Comment #2 from gmorin1 at bloomberg dot net 2008-08-29 16:57 ---
I thought it was correct because it seems that the standard allows to cast
explicity inside the range. The range is not the one of the integral type but
the one of smallest bit field that can stop all the values. So
--- Comment #1 from pinskia at gmail dot com 2008-08-29 16:39 ---
Subject: Re: New: bad code generation with enum and -m32
This code is undefined as the value of 32 is outside the range of the
enum.
Sent from my iPhone
On Aug 29, 2008, at 9:29, "gmorin1 at bloomberg dot net"
<[EM
This code is undefined as the value of 32 is outside the range of the
enum.
Sent from my iPhone
On Aug 29, 2008, at 9:29, "gmorin1 at bloomberg dot net" <[EMAIL PROTECTED]
> wrote:
This is a copy of a Debian report that I made (I thought I might as
well report
it directly here too): htt
--- Comment #3 from hp at gcc dot gnu dot org 2008-08-29 16:30 ---
This is fixed by the patch in PR37170.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37280
This is a copy of a Debian report that I made (I thought I might as well report
it directly here too): http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=496965
g++ generates bad code for this program on an amd64 machine. It works with
fine in 64-bit and with older versions of gcc.
#include
str
--- Comment #7 from vmakarov at gcc dot gnu dot org 2008-08-29 16:19
---
Subject: Bug 37251
Author: vmakarov
Date: Fri Aug 29 16:18:11 2008
New Revision: 139770
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=139770
Log:
2008-08-29 Vladimir Makarov <[EMAIL PROTECTED]>
--- Comment #13 from vmakarov at gcc dot gnu dot org 2008-08-29 16:18
---
Subject: Bug 37243
Author: vmakarov
Date: Fri Aug 29 16:16:45 2008
New Revision: 139769
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=139769
Log:
2008-08-29 Vladimir Makarov <[EMAIL PROTECTED]>
--- Comment #14 from jason at gcc dot gnu dot org 2008-08-29 16:09 ---
Dodji is right: since the variable is shared between all concrete instances,
there is no need to repeat anything about it in the concrete instance. The
debugger should find the information it wants in the abstract in
--- Comment #8 from paolo dot carlini at oracle dot com 2008-08-29 16:05
---
(In reply to comment #7)
> The strict c++98 standard, without GNU extensions, doesn't know anything about
> atanh - there isn't a single mention in the entire Standard - therefore I
> don't
> see why any diffe
--- Comment #1 from hp at gcc dot gnu dot org 2008-08-29 16:02 ---
(In reply to comment #0)
> I attached a preprocessed test case.
Where?
--- Comment #2 from andi-gcc at firstfloor dot org 2008-08-29 16:02 ---
Created an attachment (id=16164)
--> (http://gcc.gnu.org/bugzilla
--- Comment #1 from hp at gcc dot gnu dot org 2008-08-29 16:02 ---
(In reply to comment #0)
> I attached a preprocessed test case.
Where?
--
hp at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #7 from paolo dot carlini at oracle dot com 2008-08-29 16:01
---
The strict c++98 standard, without GNU extensions, doesn't know anything about
atanh - there isn't a single mention in the entire Standard - therefore I don't
see why any difference is wanted. Even less I see w
--- Comment #6 from paolo dot carlini at oracle dot com 2008-08-29 15:56
---
Why?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37276
--- Comment #12 from vmakarov at redhat dot com 2008-08-29 15:55 ---
Here is the analysis of regressions on pr36222 and pr36246. PR36222 contains
the following code:
p64:V4SI=vec_concat (p66:V2SI, p65:V2SI) dead p66 and p65
xmm0:V2DI=subreg:V2DI (p64:V4SI)
IRA allocates p65, p66, and p
--- Comment #5 from pinskia at gcc dot gnu dot org 2008-08-29 15:52 ---
I think this testcase is invalid without -std=c++98.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37276
--
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
--- Comment #6 from pault at gcc dot gnu dot org 2008-08-29 15:29 ---
Created an attachment (id=16163)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16163&action=view)
A reduced version of the testcase
I still do not feel much the wiser - making vector visible in class motion
make
The linux kernel doesn't build anymore with gcc version 4.4.0 20080826
The problem seems to be that one extern variable (kallsyms_token_index)
declared with __attribute__((weak)) does not get a ".weak" in the assembler
output
anymore (compared the gcc 4.3)
I attached a preprocessed test case.
B
--- Comment #2 from hubicka at gcc dot gnu dot org 2008-08-29 14:58 ---
Subject: Bug 37278
Author: hubicka
Date: Fri Aug 29 14:57:20 2008
New Revision: 139768
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=139768
Log:
PR middle-end/37278
* predict.c (optimize_lo
--- Comment #13 from dodji at gcc dot gnu dot org 2008-08-29 14:41 ---
Created an attachment (id=16162)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16162&action=view)
The debug info of the program
Okay, here is a more accurate analysis. I will refer to the debug info
attached.
--- Comment #1 from dominiq at lps dot ens dot fr 2008-08-29 14:40 ---
/opt/gcc/_gcc_clean/gcc/testsuite/gcc.c-torture/execute/builtins/memset-chk.c:
In function 'test6':
/opt/gcc/_gcc_clean/gcc/testsuite/gcc.c-torture/execute/builtins/memset-chk.c:557:
internal compiler error: Bus error
--- Comment #4 from paolo dot carlini at oracle dot com 2008-08-29 14:18
---
>From the "outside", without looking deeper, I agree it seems a front-end issue.
The following seg-faults only when built with the C++ compiler:
inline double
atanh(double __x)
{ return __builtin_atanh(__x); }
Last successful sparc testresult (sun or linux) is from 06Aug2008:
http://gcc.gnu.org/ml/gcc-testresults/2008-08/msg00636.html
"trunk revision 138734"
Whereas there were plenty of results before.
At trunk revision 139756 on sparc-unknown-linux-gnu I get during stage2:
build/genconfig ../../trun
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37099
--- Comment #2 from jwakely dot gcc at gmail dot com 2008-08-29 13:36
---
I think this is a regression against 4.2.2 as I have working compilers for
sparc-sun-solaris2.10 and sparc64-sun-solaris2.10 which were both configured
with --with-dwarf2 (although I didn't build them myself so I'
--- Comment #7 from manu at gcc dot gnu dot org 2008-08-29 13:28 ---
No warning in GCC 4.4 with any of those:
-O0 -Wall -Wextra -Wreturn-type -Wunreachable-code
-O1 -Wall -Wextra -Wreturn-type -Wunreachable-code
-O2 -Wall -Wextra -Wreturn-type -Wunreachable-code
-O3 -Wall -Wextra -Wretu
On Linux/ia32, revision 139760 causes
FAIL: g++.dg/tree-ssa/pr29902.C (internal compiler error)
FAIL: g++.dg/tree-ssa/pr29902.C (test for excess errors)
FAIL: gcc.c-torture/execute/builtins/memset-chk.c compilation, -O3
-fomit-frame-pointer (internal compiler error)
UNRESOLVED: gcc.c-torture/exe
(GCC) 4.4.0 20080829 (experimental)
2.796sg++ (GCC) 4.4.0 20080829 (experimental) with --param
max-inline-insns-auto=126
So I believe lack of inlining is the biggest 4.4's problem. We do not inline
3x3 matrix multiplication in benchmark loop.
While looking at it I found that einline2 dum
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-08-29 13:11 ---
Actually, it looks like we treat
namespace std
{
inline double
atanh(double __x)
{ return __builtin_atanh(__x); }
}
as a definition of ::atanh (with C linkage), and emit
atanh:
.LFB0:
pushq %rbp
.L
--- Comment #1 from jwakely dot gcc at gmail dot com 2008-08-29 13:11
---
Created an attachment (id=16161)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16161&action=view)
gcc/gtyp-input.list
Here is the generated file with the duplicate entry
--
http://gcc.gnu.org/bugzilla/
/home/wakelyjo/src/gcc/gcc-4.3.2/configure
--prefix=/home/wakelyjo/src/gcc/sol10-64/INSTALL
--with-gmp=/home/wakelyjo/src/gcc/sol10-64/INSTALL
--with-mpfr=/home/wakelyjo/src/gcc/sol10-64/INSTALL --with-dwarf2
Bootstrap fails with:
build/gengtype /home/wakelyjo/src/gcc/gcc-4.3.2/gcc gtyp-input.li
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-08-29 13:08 ---
Funny. (just look at the asm...)
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last re
--- Comment #1 from paolo dot carlini at oracle dot com 2008-08-29 13:04
---
I think it can be safely confirmed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37276
Hi, I'm getting this annoying run-time Seg-fault for the below. Apparently,
isn't a regression, but really, if we could fix it, the C++ library would
benefit a lot from the fix!
namespace my_std
{
inline double
atan(double __x)
{ return __builtin_atan(__x); }
inline doub
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37193
--- Comment #3 from jakub at gcc dot gnu dot org 2008-08-29 12:23 ---
Caused by PR33691 fix btw.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37261
--- Comment #2 from jakub at gcc dot gnu dot org 2008-08-29 11:55 ---
Testing a fix.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unass
--- Comment #12 from rguenth at gcc dot gnu dot org 2008-08-29 11:49
---
Fixed for the trunk.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Known t
--- Comment #11 from rguenth at gcc dot gnu dot org 2008-08-29 11:42
---
Subject: Bug 37236
Author: rguenth
Date: Fri Aug 29 11:40:47 2008
New Revision: 139763
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=139763
Log:
2008-08-29 Richard Guenther <[EMAIL PROTECTED]>
--- Comment #12 from dodji at gcc dot gnu dot org 2008-08-29 09:58 ---
This is an update of what we get with gcc-4_3-branch.
For the program (line numbers added for better legibility):
1 #include
2 class A {
3 public:
4A (int a, int b);
5int a_;
--- Comment #14 from ubizjak at gmail dot com 2008-08-29 09:44 ---
Fixed.
--
ubizjak at gmail dot com changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #13 from uros at gcc dot gnu dot org 2008-08-29 09:43 ---
Subject: Bug 37101
Author: uros
Date: Fri Aug 29 09:41:57 2008
New Revision: 139758
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=139758
Log:
Backport from mainline:
2008-08-14 Christophe Sao
--- Comment #10 from rguenth at gcc dot gnu dot org 2008-08-29 09:30
---
Mine.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassign
--- Comment #5 from pault at gcc dot gnu dot org 2008-08-29 08:54 ---
(In reply to comment #4)
> Does it have anything to do with 36374?
>
Salvatore,
I don't think so, since this PR is a regression. Anyway, I'll take a look at
them both together in a few days. I'm still not entir
--- Comment #4 from sfilippone at uniroma2 dot it 2008-08-29 08:46 ---
Does it have anything to do with 36374?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37274
--- Comment #3 from sfilippone at uniroma2 dot it 2008-08-29 08:39 ---
Yes, it's the release.
[EMAIL PROTECTED] type_ambiguity]$ gfortran -v -c type_ambiguity.f90
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.2.4/configure
Thread model: posix
gcc version 4.
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-08-29 08:37 ---
Subject: Bug 37207
Author: rguenth
Date: Fri Aug 29 08:36:10 2008
New Revision: 139754
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=139754
Log:
2008-08-29 Richard Guenther <[EMAIL PROTECTED]>
PR
--- Comment #2 from pault at gcc dot gnu dot org 2008-08-29 08:31 ---
Confirmed
Salvatore, what is the date on your 4.2.4? Is it the release version - ie.
19th May 2008?
Cheers
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #3 from svobodamo at gmail dot com 2008-08-29 07:53 ---
okay, i'll try to upgrade, thanks guys
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37268
--- Comment #1 from linuxl4 at sohu dot com 2008-08-29 07:52 ---
Created an attachment (id=16160)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16160&action=view)
the preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37275
gcc (GCC) 4.4.0 20080828 (experimental)
gcc -g -O2 -march=i686 -fstack-protector -c task.c -o task.o
--
Summary: ICE when compile libgomp/task.c
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
--- Comment #1 from sfilippone at uniroma2 dot it 2008-08-29 07:42 ---
Created an attachment (id=16159)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16159&action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37274
With the attached test case I get:
[EMAIL PROTECTED] type_ambiguity]$ gfortran -v -c type_ambiguity.f90
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.3.1/configure --prefix=/usr/local/gcc43
--with-mpfr=/usr/local/mpfr --with-gmp=/usr/local/gmp
Thread model: posix
gcc v
--- Comment #16 from jakub at gcc dot gnu dot org 2008-08-29 07:22 ---
It is not incorrect, but is a code quality regression, which counts too.
So I'd prefer the testcase to stay as is and let the RA get fixed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25199
100 matches
Mail list logo
