--- Comment #5 from kkojima at gcc dot gnu dot org 2006-01-05 06:04 ---
I proposed the patch in #3 at
http://gcc.gnu.org/ml/gcc-patches/2006-01/msg00174.html
and an SH maintainer has approved it. It's enough to check it in on 4.0,
though I believe that the patch for 3.4 branch needs
--- Comment #4 from vapier at gentoo dot org 2006-01-05 05:02 ---
awesome, that fixed it in my 3.4.5 cross-compiler, now it exits with:
conftest.c: In function `main':
conftest.c:3: error: impossible constraint in `asm'
will this fix be applied only to the 4.0 branch ?
--
http://gc
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-01-05 03:23 ---
Oh, I should note that on the mainline, libgfortran now should compile without
a need for stdint.h at all. So it might be okay to turn back on
target-libgfortan testing on mmix.
--
http://gcc.gnu.org/bugzilla/s
--- Comment #34 from pinskia at gcc dot gnu dot org 2006-01-05 03:21
---
The only patch left is
http://gcc.gnu.org/ml/gcc-patches/2005-12/msg01578.html
The rest was fixed by the patch which fixed PR 25259 which added a stdint.h to
include.
--
pinskia at gcc dot gnu dot org changed:
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-01-05 03:19 ---
This was fully fixed by the patch which fixed PR 25259. Also IIRC newlib
provides a stdint.h now too.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #4 from pluto at agmk dot net 2006-01-05 03:01 ---
(In reply to comment #3)
> (In reply to comment #2)
> > moreover the buildsystem doesn't propagate -I$target-headers-directory
> > specified in configure by --with-headers=$dir and build fails.
> >
> > below log comes from p
--- Comment #7 from danglin at gcc dot gnu dot org 2006-01-05 02:53 ---
The bug is as follows. The return from the call to
cxg1005__test_block__complex_pack__compose_from_cartesian___389
is in registers ret0 and ret1.
bl cxg1005__test_block__complex_pack__compose_from_cartesian
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-01-05 02:49 ---
(In reply to comment #2)
> moreover the buildsystem doesn't propagate -I$target-headers-directory
> specified in configure by --with-headers=$dir and build fails.
>
> below log comes from powerpc (host, build: ppc32
--- Comment #2 from pluto at agmk dot net 2006-01-05 02:45 ---
moreover the buildsystem doesn't propagate -I$target-headers-directory
specified in configure by --with-headers=$dir and build fails.
below log comes from powerpc (host, build: ppc32, target: ppc64):
(...)
GCC_FOR_TARGET='/
Last known to work with: "Mon Dec 12 22:04:54 UTC 2005 (revision 108426M)".
Known to fail with: "Mon Jan 2 13:08:54 UTC 2006 (revision 109236M)":
Running
/home/hp/combined/combined/gcc/testsuite/gcc.c-torture/execute/execute.exp ...
FAIL: gcc.c-torture/execute/960802-1.c execution, -O1
FAIL: gcc
--- Comment #13 from rakdver at gcc dot gnu dot org 2006-01-05 00:29
---
Subject: Bug 25632
Author: rakdver
Date: Thu Jan 5 00:29:34 2006
New Revision: 109369
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109369
Log:
PR c++/25632
* init.c (constant_value_1): U
--- Comment #4 from eedelman at gcc dot gnu dot org 2006-01-05 00:22
---
Subject: Bug 23675
Author: eedelman
Date: Thu Jan 5 00:22:39 2006
New Revision: 109368
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109368
Log:
2006-01-05 Erik Edelmann <[EMAIL PROTECTED]>
PR
--- Comment #3 from kkojima at gcc dot gnu dot org 2006-01-04 23:07 ---
Subject: Bug 25613
Author: kkojima
Date: Wed Jan 4 23:07:24 2006
New Revision: 109355
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109355
Log:
PR target/25613
* config/sh/sh.h (CONSTRAINT_
--- Comment #12 from rakdver at gcc dot gnu dot org 2006-01-04 22:46
---
Subject: Bug 25632
Author: rakdver
Date: Wed Jan 4 22:46:09 2006
New Revision: 109354
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109354
Log:
PR c++/25632
* init.c (constant_value_1): U
--- Comment #2 from falk at debian dot org 2006-01-04 22:39 ---
Actually, using a table is faster when the cache is hot (about 15%).
The problem is that libgcc doesn't unroll the loop.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25674
--- Comment #10 from steven at gcc dot gnu dot org 2006-01-04 22:35 ---
Re. comment #9, I don't understand how the way we hash would make load PRE
harder. Could you elaborate a bit on what is missing or done "wrong" for load
PRE of globals??
--
http://gcc.gnu.org/bugzilla/show_bug.
Testcase:
class f
{
public static double g(double a, double b)
{
return Math.min(a, b);
}
public static void main(String a[])
{
System.out.println (g(0.0, -0.0));
System.out.println (g(-0.0, 0.0));
}
}
This should print -0.0 and -0.0. Currently it prints 0.0 -0.0 fo
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-01-04 21:24 ---
*** Bug 25674 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-04 21:24 ---
I am going to close this as a dup of bug 21812 since that references popcountl
already.
*** This bug has been marked as a duplicate of 21812 ***
--
pinskia at gcc dot gnu dot org changed:
What|Re
http://devnet.developerpipeline.com/documents/s=9858/q=1/ddj0503d/0503d.html
int popcount(long long b)
{
b = (b & 0xLLU) + (b >> 1 & 0xLLU);
b = (b & 0xLLU) + (b >> 2 & 0xLLU);
b = (b + (b >> 4)) & 0x0F0F0F0F0F0F0F0FLLU
--- Comment #8 from rakdver at atrey dot karlin dot mff dot cuni dot cz
2006-01-04 20:55 ---
Subject: Re: cannot determine number of iterations for loops with <=
> Toon posted an updated patch here:
> http://gcc.gnu.org/ml/fortran/2006-01/msg00048.html
>
> (Toon, I had Andrew add you
--- Comment #3 from eedelman at gcc dot gnu dot org 2006-01-04 20:41
---
Patch here: http://gcc.gnu.org/ml/gcc-patches/2006-01/msg00079.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23675
--- Comment #7 from tobi at gcc dot gnu dot org 2006-01-04 20:32 ---
Toon posted an updated patch here:
http://gcc.gnu.org/ml/fortran/2006-01/msg00048.html
(Toon, I had Andrew add you to the CC list, because somehow I couldn't, and I
think dicussion of the patch should either take place
--- Comment #16 from alex at milivojevic dot org 2006-01-04 19:55 ---
(In reply to comment #15)
> Both in dgettext.c and dngettext.c at a minimum as far as I can see. Another
> possible path is to bootstrap the compiler with Sun cc or with gcc -std=c89.
Bootstrapping with 'gcc -std=c89
: ../gcc/configure --prefix=/Users/dir/gfortran
--enable-languages=c,f95
Thread model: posix
gcc version 4.1.0 20060104 (prerelease)
[dranta:~/tests/gfortran-D] dir% cat sage03.f90
implicit none
integer*8 cray64_int,ieee64_int,ia,itwo
integer ibits,n
itwo=2
ibits
--- Comment #2 from wouter at grep dot be 2006-01-04 19:51 ---
(In reply to comment #0)
> I found that the
> compiler produces code which assumes that no register inside the called
> function will clobber any register.
Uh -- for clarity, I meant to say "that no code inside the called fu
--- Comment #7 from mmitchel at gcc dot gnu dot org 2006-01-04 18:53
---
Fixed in 4.0.3.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Stat
--- Comment #6 from mmitchel at gcc dot gnu dot org 2006-01-04 18:50
---
Subject: Bug 24782
Author: mmitchel
Date: Wed Jan 4 18:50:07 2006
New Revision: 109344
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109344
Log:
PR c++/24782
* parser.c (cp_parser_nested_
--- Comment #5 from mmitchel at gcc dot gnu dot org 2006-01-04 18:49
---
Subject: Bug 24782
Author: mmitchel
Date: Wed Jan 4 18:49:21 2006
New Revision: 109343
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109343
Log:
PR c++/24782
* parser.c (cp_parser_nested_
--- Comment #4 from mmitchel at gcc dot gnu dot org 2006-01-04 18:48
---
Subject: Bug 24782
Author: mmitchel
Date: Wed Jan 4 18:48:38 2006
New Revision: 109342
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109342
Log:
PR c++/24782
* parser.c (cp_parser_nested_
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-01-04 17:13 ---
>From that page:
The 128-bit implementation differs from the IEEE standard for long double in
the following ways:
Supports only round-to-nearest mode. If the application changes the rounding
mode, results are undefi
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-01-04 17:04 ---
http://publib16.boulder.ibm.com/pseries/en_US/aixprggd/genprogc/128bit_long_double_floating-point_datatype.htm
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25661
--- Comment #10 from uttamp at us dot ibm dot com 2006-01-04 16:52 ---
*** Bug 25656 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25578
--- Comment #5 from uttamp at us dot ibm dot com 2006-01-04 16:52 ---
*** This bug has been marked as a duplicate of 25578 ***
--
uttamp at us dot ibm dot com changed:
What|Removed |Added
--
--- Comment #9 from uttamp at us dot ibm dot com 2006-01-04 16:51 ---
*** Bug 25657 has been marked as a duplicate of this bug. ***
--
uttamp at us dot ibm dot com changed:
What|Removed |Added
---
--- Comment #9 from uttamp at us dot ibm dot com 2006-01-04 16:51 ---
*** This bug has been marked as a duplicate of 25578 ***
--
uttamp at us dot ibm dot com changed:
What|Removed |Added
--
--- Comment #4 from uttamp at us dot ibm dot com 2006-01-04 16:50 ---
This has been fixed with todays mainline tree.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25656
--- Comment #8 from uttamp at us dot ibm dot com 2006-01-04 16:50 ---
This has been fixed with todays mainline tree.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25657
--- Comment #2 from joseph at codesourcery dot com 2006-01-04 16:47 ---
Subject: Re: Wrong long double to float conversion
On Wed, 4 Jan 2006, pinskia at gcc dot gnu dot org wrote:
> Hmm, actually there is no rounding from TF to DF except for the fact that
> upper
> potion of the TF
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-04 16:41 ---
Resummaryizing to make clearer.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from bonzini at gnu dot org 2006-01-04 16:38 ---
Patch posted. Andrew suggested another approach, but it is more complex and
I'm not going to work on it until more important issues are sorted out.
--
bonzini at gnu dot org changed:
What|Removed
--- Comment #12 from law at redhat dot com 2006-01-04 16:36 ---
Fixed by attached patch. Would appreciate it if folks could verify ada is
bootstrapping again on PPC, HPUX and any other platform reported as failing.
--
law at redhat dot com changed:
What|Removed
--- Comment #25 from paolo dot bonzini at lu dot unisi dot ch 2006-01-04
16:29 ---
Subject: Re: [4.1/4.2 Regression] Massive performance
regression for -ffast-math due to the recip tree pass
>For PowerPC, it is effective to use the instruction if
>there are multiple divides, such as
--- Comment #11 from law at gcc dot gnu dot org 2006-01-04 16:29 ---
Subject: Bug 24994
Author: law
Date: Wed Jan 4 16:29:32 2006
New Revision: 109335
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109335
Log:
PR ada/24994
* tree-cfg.c (bsi_replace): Remove the
I'm configuring gcc with:
./configure --prefix=/usr --infodir=/usr/share/info --mandir=/usr/share/man
--bindir=/usr/bin --libdir=/usr/lib --libexecdir=/usr/lib --disable-shared
--disable-threads --enable-languages=c,c++ --enable-c99 --enable-long-long
--disable-nls --with-gnu-as --with-gnu-ld --wi
--- Comment #15 from ebotcazou at gcc dot gnu dot org 2006-01-04 16:01
---
> Hmmm... If in dgettext.c I simply change the order the files are included,
> would that solve the problem? Or the fix is going to be more complex?
Both in dgettext.c and dngettext.c at a minimum as far as I
--- Comment #1 from bonzini at gnu dot org 2006-01-04 15:56 ---
Accepting this, but it is not a blocker as all-gcc is not even documented
anywhere.
--
bonzini at gnu dot org changed:
What|Removed |Added
-
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-04 15:33 ---
Confirmed, not a regression.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from pcarlini at suse dot de 2006-01-04 15:26 ---
(In reply to comment #7)
> But the warning is obviously bogus as you can check the errors after a couple
> readings and still be able to be catch error.
Well, I disagree: in my opinion, the compiler is correct that >> does
the code
int test_bit(unsigned long *words, int bit)
{
int wsize = (sizeof *words) * 8;
return (words[bit / wsize] & (1 << (bit % wsize))) != 0;
}
can compile to
xor %rax, %rax
bt %rsi, (%rdi)
setc %al
but instead compiles to a much longer sequence, using many more register
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-01-04 15:20 ---
But the warning is obviously bogus as you can check the errors after a couple
readings and still be able to be catch error. This is in a way like
(void)read(a, xx, y) issue that was filed but in reality it was a gli
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-04 15:17 ---
Hmm, actually there is no rounding from TF to DF except for the fact that upper
potion of the TF mode is taken only.
I am thinking this testcase is invalid for 128bit IBM long double format.
IBM 128bit long double
--- Comment #6 from pcarlini at suse dot de 2006-01-04 15:17 ---
(In reply to comment #5)
> Hmm, if I understood correctly, this means that the variable is not set if the
> reading operation fails. That sounds plausible, and in this case the warning
> is
> perfectly OK and should not b
--- Comment #5 from martin at mpa-garching dot mpg dot de 2006-01-04 15:15
---
(In reply to comment #4)
> (In reply to comment #3)
>
> > We really don't set __n in all cases here.
>
> And indeed we do *not* want to set __n in all cases: if for some reason the
> extraction fails __n *m
--- Comment #4 from pcarlini at suse dot de 2006-01-04 15:08 ---
(In reply to comment #3)
> We really don't set __n in all cases here.
And indeed we do *not* want to set __n in all cases: if for some reason the
extraction fails __n *must* be left untouched. Per the standard, there isn'
--- Comment #14 from alex at milivojevic dot org 2006-01-04 15:03 ---
Benjamin:
You are not alone. I hit that bug too ;-)
Andrew:
I can reproduce the bug on my system. I haven't done anything fancy. And I
made sure only standard Solaris header files/libraries were visible while
boots
--- Comment #3 from reichelt at gcc dot gnu dot org 2006-01-04 15:01
---
Looks like the culprit is the following part of Paolo's patch:
+ operator>>(int& __n)
+ {
+ // _GLIBCXX_RESOLVE_LIB_DEFECTS
+ // 118. basic_istream uses nonexistent num_get member functions.
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-04 15:00 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-01-04 14:51 ---
Reduced testcase:
nullify(i%e)
end program
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24958
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-01-04 14:51 ---
*** Bug 25660 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-04 14:51 ---
*** This bug has been marked as a duplicate of 24958 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #2 from reichelt at gcc dot gnu dot org 2006-01-04 14:50
---
Confirmed.
I get the warning with 4.2.0 20060104.
The preprocessed file triggers the warning also with the 4.1 branch.
It looks like Paolo's patch
2006-01-02 Paolo Carlini <[EMAIL PROTECTED]>
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-04 14:37 ---
This works on the mainline as of today but failed with 4.2.0 20051219.
Confirmed. Though I should note this is really weird as DOM is messing up in
that version of GCC and we still have 1 << -1 which is not being f
--- Comment #4 from paul dot richard dot thomas at cea dot fr 2006-01-04
14:26 ---
(In reply to comment #2)
> Actually assumed sized is not the full issue, see PR 18003.
You are right about this. Turn the declaration for a into an explicit
full-array, rather than assumed size.
I have
--- Comment #3 from paul dot richard dot thomas at cea dot fr 2006-01-04
14:25 ---
(In reply to comment #2)
> Actually assumed sized is not the full issue, see PR 18003.
You are right about this. Turn the declaration for a into an explicit
full-array, rather than assumed size.
I have
--- Comment #11 from pinskia at gcc dot gnu dot org 2006-01-04 14:11
---
And there needs to be a way to do the old way of "make all" without having to
reconfiguring as it means rebuilding the support libraries which is too slow as
it is.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-01-04 14:10
---
(In reply to comment #9)
> At this moment, I guess the most important thing is that how to "make"
> is clarified and Paolo is willing to fix any problem that might
> result from his change. I'm doing what Daniel J
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||bonzini at gnu dot org
Severity|major
I've configured with:
./configure --prefix=.../install --disable-nls --disable-libgcj
--enable-languages=c
Executed:
make all-gcc
Output:
...
make[2]: Leaving directory `.../intl'
cat: stage_last: No such file or directory
make: invalid option -- a
Usage: make [options] [target] ...
...
It app
--- Comment #18 from pcarlini at suse dot de 2006-01-04 13:58 ---
(In reply to comment #17)
>Not that
> I'm
> saying that means the code should stay, just at least one data point of
> someone
> who is using the current
--- Comment #17 from chris at bubblescope dot net 2006-01-04 13:53 ---
Just as a quick note, I've personally got code using the non-void return value
of generate_n (because I'm going along a list, and didn't want to have to
incremement n steps after filling the list, as that would cost).
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed|0 |1
Last r
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-01-04 13:47 ---
(In reply to comment #2)
> (In reply to comment #1)
> > Why are you trying to install 3.0.4? This version (3.0.x series) of GCC has
> > not been updated since 2002.
> > The only thing I can say is use a newer gcc in
--- Comment #2 from stener at univ dot trieste dot it 2006-01-04 13:44
---
(In reply to comment #1)
> Why are you trying to install 3.0.4? This version (3.0.x series) of GCC has
> not been updated since 2002.
> The only thing I can say is use a newer gcc instead of 3.0.x series GCC.
>
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-01-04 13:35 ---
Actually assumed sized is not the full issue, see PR 18003.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-04 13:34 ---
This actually might be related to PR 19777.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
subroutine foo (a)
real a(*)
call bar (a, LBOUND(a),2)
end subroutine foo
subroutine bar (b, i, j)
real b(i:j)
print *, i, j
print *, b(i:j)
end subroutine bar
real x(10)
x = 0.0
call foo (x)
end
???
This runs fine with other brand compilers but gfortran, patched or not, gives:
tobi.f90: In fu
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-04 13:31 ---
Why are you trying to install 3.0.4? This version (3.0.x series) of GCC has
not been updated since 2002.
The only thing I can say is use a newer gcc instead of 3.0.x series GCC.
--
pinskia at gcc dot gnu dot org
--
amodra at bigpond dot net dot au changed:
What|Removed |Added
URL||http://gcc.gnu.org/ml/gcc-
|
See http://gcc.gnu.org/ml/gcc-patches/2005-12/msg01815.html. New libgcc2.c
code results in a couple of functions that are well over twice as slow.
--
Summary: libgcc2.c __floattisf code quality regression
Product: gcc
Version: 4.2.0
Status: UNCONFIRM
Hi,
I am trying to install gcc-3.0.4 on my Itanium 2 linux machine,
these are the detailed os info:
Distribution: Red Hat Linux
Operating System: Linux
Distribution Version: Red Hat Linux Advanced Server release 2.1AS
(Derry)
Operating System Version: #
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-01-04 12:45 ---
/usr/bin/ld: warning: powerpc:common architecture of input file
`../build-powerpc64-unknown-linux-gnu/libiberty/libiberty.a(xmalloc.o)' is
incompatible with powerpc:common64 output
/usr/bin/ld: warning: powerpc:commo
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-01-04 12:40 ---
(In reply to comment #3)
> I'm seeing the same 4.0 regression on mainline as well.
Are you sure?
I don't see it on "4.2.0 20060103" unless it happens after that.
--
pinskia at gcc dot gnu dot org changed:
--- Comment #12 from jakub at gcc dot gnu dot org 2006-01-04 12:35 ---
Fixed even on 4.0 branch.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from jakub at gcc dot gnu dot org 2006-01-04 12:34 ---
Fixed on 4.0/4.1 branches and trunk.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from jakub at gcc dot gnu dot org 2006-01-04 12:33 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #4 from jakub at gcc dot gnu dot org 2006-01-04 12:33 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #11 from jakub at gcc dot gnu dot org 2006-01-04 12:32 ---
Subject: Bug 25294
Author: jakub
Date: Wed Jan 4 12:31:59 2006
New Revision: 109329
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109329
Log:
PR c++/25294
* directives.c (do_pragma): If prag
--- Comment #4 from jakub at gcc dot gnu dot org 2006-01-04 12:29 ---
Subject: Bug 25554
Author: jakub
Date: Wed Jan 4 12:29:14 2006
New Revision: 109327
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109327
Log:
PR target/25554
* config/i386/i386.md (testqi_ext
--- Comment #6 from jakub at gcc dot gnu dot org 2006-01-04 12:27 ---
Subject: Bug 25559
Author: jakub
Date: Wed Jan 4 12:27:48 2006
New Revision: 109326
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109326
Log:
PR c/25559
* c-common.c (handle_vector_size_attri
--- Comment #4 from reichelt at gcc dot gnu dot org 2006-01-04 12:21
---
> Using
>
> (ScalarCode >(CflFunctor<3>(omrot, vis_f)))(x, y);
>
> was a workaround for me, so I thought it indeed was the issue...
Adding parens in my example also makes the bug go away:
(A<0>(A<0>(0)));
We
--- Comment #2 from bonzini at gnu dot org 2006-01-04 12:21 ---
Patch committed, also fixes race conditions in bootstrap.
--
bonzini at gnu dot org changed:
What|Removed |Added
---
--- Comment #2 from bonzini at gnu dot org 2006-01-04 12:21 ---
Subject: Bug 24252
Author: bonzini
Date: Wed Jan 4 12:21:27 2006
New Revision: 109325
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109325
Log:
2006-01-04 Paolo Bonzini <[EMAIL PROTECTED]>
PR bootstrap/
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2006-01-04 12:16
---
With newer binutils (2.16.1), what happens is:
[EMAIL PROTECTED]:/tmp/debug/ibin/stage2-gcc$
/home/users/c/co/coudert/ppc64-linux/gfortran/gfortran_libs/ppc64-linux/bin/ld
--eh-frame-hdr -V -Qy -m elf64ppc -dynam
--- Comment #10 from fxcoudert at gcc dot gnu dot org 2006-01-04 12:14
---
Moving to "target" component. This bug is still present and it prevents
building gfortran on mips-sgi-irix6.5.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Ad
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-01-04 12:11 ---
Adding Mark in CC, because he caused this regression.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-01-04 12:10 ---
Using
(ScalarCode >(CflFunctor<3>(omrot, vis_f)))(x, y);
was a workaround for me, so I thought it indeed was the issue... maybe there
are two issues actually.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=
--- Comment #1 from reichelt at gcc dot gnu dot org 2006-01-04 12:07
---
Confirmed.
The call to operator() is not the problem, though, as the following shorter
testcase shows:
==
template struct A
{
A(int);
};
void foo()
{
A<0>(A<0>(0));
}
=
--- Comment #14 from charlet at adacore dot com 2006-01-04 11:54 ---
Subject: Re: FAIL: a85013b: *** glibc detected *** free(): invalid pointer:
0x00062a00 ***
> So my question is wether the record+storage array+align will work for all
> the C types in s-osinte* or is there an except
> So my question is wether the record+storage array+align will work for all
> the C types in s-osinte* or is there an exception (ie a non opaque C type)?
Now I understand your question ;-)
The answer is no, this approach can't be applied blindly to all C types.
This approach could most likely be
1 - 100 of 129 matches
Mail list logo
