--- Comment #17 from jakub at gcc dot gnu dot org 2010-03-23 06:48 ---
But clearly it is not var-tracking that eats all the memory, instead it is the
scheduler, and it happens also with -g0, and doesn't happen with
-fno-schedule-insns -fno-schedule-insns2. So, please open a separate bug
--- Comment #3 from mirq-gccboogs at rere dot qmqm dot pl 2010-03-23 05:52
---
I checked some more variants of the simple asm() example - looks like I mixed
up compiler output files when preparing that one.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43471
--- Comment #2 from mirq-gccboogs at rere dot qmqm dot pl 2010-03-23 05:43
---
Hmm. I must have missed something while cutting down the test case as this
simple example works now...
Here is bigger test that might be related:
code:
struct a {
int f1, f2;
};
struct b {
--- Comment #9 from davek at gcc dot gnu dot org 2010-03-23 05:09 ---
I don't think you have any bug. Enjoy your DLL!
--
davek at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from davek at gcc dot gnu dot org 2010-03-23 05:05 ---
Subject: Bug 30445
Author: davek
Date: Tue Mar 23 05:05:35 2010
New Revision: 157662
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157662
Log:
PR libobjc/30445
* configure.ac (extra_ldflags_li
--- Comment #12 from davek at gcc dot gnu dot org 2010-03-23 04:03 ---
(In reply to comment #11)
> That's the next thing to try. I'm just testing a build of HEAD using your
> formula to see if it reproduces.
Well, nope, that's gone way past stage 1 by now and no sign of any problem
--- Comment #4 from davek at gcc dot gnu dot org 2010-03-23 03:52 ---
(In reply to comment #3)
> There is a bug in gcc-4_2 in that it won't let you make a new ABI (with a
> three
> stage build). So how can you switch ABIs?
No, there is/was not a bug. Switching ABIs isn't just a mat
--- Comment #6 from davek at gcc dot gnu dot org 2010-03-23 03:37 ---
This is mostly a HOWTO rather than a bug report. And 4.2 branch is retired
now, and cygwin has released 1.7, and pretty much everything's changed, so
closing it to tidy up BZ a bit.
--
davek at gcc dot gnu dot org
--- Comment #7 from davek at gcc dot gnu dot org 2010-03-23 02:45 ---
(In reply to comment #6)
> (In reply to comment #5)
> > And this is ok if you post it with a changelog :).
> >
>
> Good evening Andrew! I was just looking in MAINTAINERS to see who takes care
> of objc these days!
>
--- Comment #6 from davek at gcc dot gnu dot org 2010-03-23 02:14 ---
(In reply to comment #5)
> And this is ok if you post it with a changelog :).
>
Good evening Andrew! I was just looking in MAINTAINERS to see who takes care
of objc these days!
Yep, it built ok. I'm just checking
--- Comment #5 from pinskia at gcc dot gnu dot org 2010-03-23 02:12 ---
And this is ok if you post it with a changelog :).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30445
--- Comment #13 from wilson at codesourcery dot com 2010-03-23 02:11
---
Subject: Re: [ia64] Inappropriate address spills
On Mon, 2010-03-22 at 20:48 +, sje at cup dot hp dot com wrote:
> Since the proposed patch to meant to address non-optimimal code generation I
> decided to try
--- Comment #4 from davek at gcc dot gnu dot org 2010-03-23 02:11 ---
Created an attachment (id=20166)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20166&action=view)
Use libtool to build win32 shared library
This code is now simply obsoleted by libtool functionality, which we en
--- Comment #3 from davek at gcc dot gnu dot org 2010-03-23 02:09 ---
Good grief, I've managed to totally overlook objc during the dll-ification
frenzy from late last summer. Confirmed that this bug still exists on HEAD.
There is fortunately a very simple and safe solution enabled by r
--- Comment #5 from tglek at mozilla dot com 2010-03-23 02:07 ---
(In reply to comment #4)
> I suppose we could wrap rvalue uses in NOP_EXPR and lvalue uses in
> VIEW_CONVERT_EXPR.
>
> Taras: You aren't actually trying to do this sort of analysis after lowering
> to
> GIMPLE, are you?
--
davek at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40578
--
davek at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40807
--
davek at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41357
--
davek at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42271
--- Comment #4 from jason at gcc dot gnu dot org 2010-03-23 01:51 ---
I suppose we could wrap rvalue uses in NOP_EXPR and lvalue uses in
VIEW_CONVERT_EXPR.
Taras: You aren't actually trying to do this sort of analysis after lowering to
GIMPLE, are you?
--
jason at gcc dot gnu dot or
--- Comment #5 from jason at gcc dot gnu dot org 2010-03-23 01:46 ---
I would think the position of the declarator-id ("GetBlobLiteral") would be a
better choice.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43487
--- Comment #11 from wilson at gcc dot gnu dot org 2010-03-23 01:36 ---
Fixed on gcc-4.4 branch and mainline.
--
wilson at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from wilson at gcc dot gnu dot org 2010-03-23 01:22 ---
Subject: Bug 43348
Author: wilson
Date: Tue Mar 23 01:22:28 2010
New Revision: 157660
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157660
Log:
PR target/43348
* ia64.md (call_nogp, call_value_nogp, sibcall
--- Comment #9 from wilson at gcc dot gnu dot org 2010-03-23 01:16 ---
Subject: Bug 43348
Author: wilson
Date: Tue Mar 23 01:16:10 2010
New Revision: 157659
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157659
Log:
PR target/43348
* ia64.md (call_nogp, call_value_nogp, sibcall_
--- Comment #16 from wilson at gcc dot gnu dot org 2010-03-23 00:58 ---
The testcase checked into mainline is causing kernel panics on my debian
testing ia64-linux machine when I run the gcc testsuite. The kernel panic is
coming from the out-of-memory killer, when it runs out of process
--- Comment #2 from ramana at gcc dot gnu dot org 2010-03-23 00:41 ---
Though not a target bug. The crash happens when the compiler attempts to come
out of cfglayout mode and can also be replicated on x86_64-linux-gnu
--
ramana at gcc dot gnu dot org changed:
What|Re
--- Comment #6 from davek at gcc dot gnu dot org 2010-03-23 00:36 ---
Cygwin no longer uses install-sh any more, it uses /usr/bin/install; also the
.exe magic has been substantially reworked. Everything works on head and
series 3 is obsolete, so I'm closing this old bug.
--
davek at
--- Comment #11 from davek at gcc dot gnu dot org 2010-03-23 00:22 ---
(In reply to comment #10)
> Hsre's the cygcheck, which doesn't complain:
Indeed.
> I can try to debug cc1.exe next, I guess.
That's the next thing to try. I'm just testing a build of HEAD using your
formula t
--- Comment #14 from mrs at gcc dot gnu dot org 2010-03-23 00:10 ---
This has now been fixed.
--
mrs at gcc dot gnu dot org changed:
What|Removed |Added
Statu
--
mrs at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
Version|4.5.0 |4.4.0
http://gcc.
--- Comment #5 from meissner at gcc dot gnu dot org 2010-03-22 23:58
---
Subversion id 157525 does not abort, while subversion id 157540 does abort.
The GCC changelog includes these changes:
2010-03-18 Steven Bosscher
Eric Botcazou
PR rtl-optimization/43360
--- Comment #13 from ro at gcc dot gnu dot org 2010-03-22 23:57 ---
Sun ld implements the letter of the AMD64 TLS spec; we need to handle this.
--
ro at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #2 from rwahl at gmx dot de 2010-03-22 23:56 ---
Just checked with gcc-4.4 branch HEAD and it works there, too. So it will be in
gcc-4.4.4. I hope its released soon... ;-)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43459
--- Comment #27 from rearnsha at gcc dot gnu dot org 2010-03-22 23:48
---
The ARM ABI permits merging of unwind entries, so this should never default to
opt-in across the entire tool-chain. It might be that when GCC links java
programs that it should pass an option to the linker to di
--- Comment #3 from manu at gcc dot gnu dot org 2010-03-22 23:38 ---
I think we want this also for better diagnostics and in the long term for caret
diagnostics. At a minimum, we should handle the case
foo(
x, /* warning/error about x but location is that of either foo or the ';' */
y)
--
mrs at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23071
--- Comment #9 from mrs at gcc dot gnu dot org 2010-03-22 23:21 ---
This has now been fixed.
--
mrs at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #8 from mikestump at comcast dot net 2010-03-22 23:18 ---
The previous behavior was fairly broken, adding packed, _increased_ the
alignment. A user that adds packing, never wants more alignment:
struct Test {
double D __attribute__((packed,aligned(4)));
short X;
} x;
--- Comment #7 from mrs at gcc dot gnu dot org 2010-03-22 23:13 ---
Subject: Bug 23071
Author: mrs
Date: Mon Mar 22 23:13:10 2010
New Revision: 157654
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157654
Log:
PR target/23071
* config/rs6000/rs6000.c (darwin_rs60
--- Comment #1 from ramana at gcc dot gnu dot org 2010-03-22 23:04 ---
Are you using any optimization at all ?
With -O2 I see just a bx lr for Thumb2, Thumb1 and ARM.
a:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link regis
Programs similar to the following get compiler internal error in dfp
#define __STDC_WANT_DEC_FP__/* Tell implementation that we want DFP */
#define MAX_D10 9.999E384DD
int main(void){
if( MAX_D10 + MAX_D10 ){
return 1;
}else{
return 0;
}
}
--
Summary: Ge
--- Comment #2 from tglek at mozilla dot com 2010-03-22 22:42 ---
(In reply to comment #1)
> Which location do you want? For function calls, it will be part of the call
> expression (or rather the call statement). For variables, it is harder to
> keep
> track of that usage. But most
--- Comment #4 from pinskia at gcc dot gnu dot org 2010-03-22 22:41 ---
Wait wrong one.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43487
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-03-22 22:40 ---
In fact this changed with:
2009-12-01 Taras Glek
* parser.c (cp_parser_class_specifier): Set class location to that
of IDENTIFIER_NODE instead of '{' when possible.
:).
--
http://gcc.gnu.or
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-03-22 22:38 ---
I think at one point we had it being the open { but we changed it to the
closing ) recently.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43487
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43487
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-03-22 22:34 ---
is it really 1178 with the column of the ending parenthesis?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43487
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-03-22 22:33 ---
Which location do you want? For function calls, it will be part of the call
expression (or rather the call statement). For variables, it is harder to keep
track of that usage. But most statements have a line/colu
Following up on bug https://bugzilla.mozilla.org/show_bug.cgi?id=497972
Function locations do not make sense at the moment
1176 nsresult
1177 RDFServiceImpl::GetBlobLiteral(const PRUint8 *aBytes, PRInt32 aLength,
1178nsIRDFBlob **aResult)
Here the location of the F
--- Comment #8 from meissner at linux dot vnet dot ibm dot com 2010-03-22
22:29 ---
Subject: Re: Powerpc generates worse code for
-mvsx on gromacs even though there are no VSX instructions used
On Mon, Mar 22, 2010 at 10:16:56PM -, vmakarov at redhat dot com wrote:
>
>
> --
--- Comment #7 from meissner at linux dot vnet dot ibm dot com 2010-03-22
22:24 ---
Subject: Re: Powerpc generates worse code for
-mvsx on gromacs even though there are no VSX instructions used
On Mon, Mar 22, 2010 at 10:20:21PM -, vmakarov at redhat dot com wrote:
>
>
> --
Static analysis needs good location info in order to present useful errors.
Unfortunately in GIMPLE when you have a statement like
func( x ); There is no way to get a location for x and often it's hard to get a
location for func(ie if func takes form of some_namespace::func ( x )).
In Mozilla, we
--- Comment #6 from vmakarov at redhat dot com 2010-03-22 22:20 ---
(In reply to comment #4)
> FWIW, I seem to get considerably worse code from mainline than you -- for -O3
> -ffast-math -mcpu=power7 -mvsx -maltivec I get 140 stfs and 192 lfs insns
> (compared to 117 & 139 respectively t
--- Comment #5 from vmakarov at redhat dot com 2010-03-22 22:16 ---
(In reply to comment #0)
>
> In the enclosed test case, it generates the following spills for the options:
> -O3 -ffast-math -mcpu=power7 -mvsx -maltivec: 117 stfs, 139 lfs
> -O3 -ffast-math -mcpu=power5 -maltivec: 80 s
--- Comment #2 from kkojima at gcc dot gnu dot org 2010-03-22 22:02 ---
I've confirmed that this is 4.3/4.4 regression solved on trunk with
the patch mentioned in #1. I'll backport the patch to 4.3/4.4 branches
when it passes the usual test on those branches.
--
kkojima at gcc dot g
--- Comment #6 from ramana at gcc dot gnu dot org 2010-03-22 21:46 ---
This refers to the arm-linux and arm-elf configurations which are largely in
maintenance mode only now. Pulling priority down to P5 and marking as an
enhancement.
--
ramana at gcc dot gnu dot org changed:
On the small program below, "Something_Usefull" is never aborted: when I enter
a string, my CPU usage go to 100% but then Put_Line following the "select then
abort" is never executed.
This was observed on my Ubuntu Karmic with gnat-4.4 and gnat-4.3. A friend of
mine reproduced it with 4.4.3 and 4.
--- Comment #5 from paolo dot carlini at oracle dot com 2010-03-22 21:24
---
compare is not irreflexive, as it must be per 25.3/4.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #6 from ramana at gcc dot gnu dot org 2010-03-22 21:16 ---
Unrolling the loop still doesn't show better use of auto-incs.
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from pinskia at gcc dot gnu dot org 2010-03-22 21:04 ---
>-with-long-double-128 --enable-secureplt
Those two options might cause the difference for me. Let me reconfigure my
build and try again.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43484
--- Comment #3 from meissner at gcc dot gnu dot org 2010-03-22 21:02
---
I just replicated on my x86_64 cross compiler:
bug-43484.f: In function gcidav:
bug-43484.f:670:0: internal compiler error: in change_address_1, at
emit-rtl.c:1912
Please submit a full bug report,
with preproces
--- Comment #4 from richardlee at snowshoefox dot com 2010-03-22 20:55
---
Here is a very simplified version of the scenario that triggered the bug.
bool compare(int t1, int t2) {
return true;
}
int main(int argc, char** argv) {
vector v;
v.assign(32, 2);
--- Comment #4 from jason at gcc dot gnu dot org 2010-03-22 20:50 ---
Fixed.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #13 from jason at gcc dot gnu dot org 2010-03-22 20:49 ---
Fixed by reverting to old semantics in C++98 mode.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
-
: ../configure --target=powerpc64-linux-gnu --enable-tls :
(reconfigured)
Thread model: posix
gcc version 4.5.0 20100322 (experimental) [trunk revision 157646] (GCC)
COLLECT_GCC_OPTIONS='-B.' '-S' '-m32' '-mcpu=power4' '-O2' '-funroll-loops&#
--- Comment #12 from sje at cup dot hp dot com 2010-03-22 20:48 ---
Since the proposed patch to meant to address non-optimimal code generation I
decided to try the patch with SPEC2006 and see if it helped the performance. On
SPECint, I got a 3% slowdown, mostly due to 429.mcf slowing dow
--- Comment #9 from ro at gcc dot gnu dot org 2010-03-22 20:39 ---
Fixed for 4.5.0.
--
ro at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #12 from jason at gcc dot gnu dot org 2010-03-22 20:39 ---
Subject: Bug 4
Author: jason
Date: Mon Mar 22 20:38:57 2010
New Revision: 157652
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157652
Log:
PR c++/4
* tree.c (pod_type_p): Use old mean
--- Comment #3 from jason at gcc dot gnu dot org 2010-03-22 20:39 ---
Subject: Bug 43281
Author: jason
Date: Mon Mar 22 20:38:46 2010
New Revision: 157651
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157651
Log:
PR c++/43281
* pt.c (contains_auto_r): New fn.
--- Comment #3 from paolo dot carlini at oracle dot com 2010-03-22 20:26
---
The patch is incorrect for various formal reasons (eg, should be against
current mainline not vs a random old release; should use difference_type, not
int; should use an uglified __len) + should come with a det
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #2 from richardlee at snowshoefox dot com 2010-03-22 20:18
---
Created an attachment (id=20165)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20165&action=view)
Proposed patch using 'patch -up'... run patch in the 4.4.1/bits/ folder.
--
http://gcc.gnu.org/bugzilla
--- Comment #8 from ro at gcc dot gnu dot org 2010-03-22 20:12 ---
Subject: Bug 38085
Author: ro
Date: Mon Mar 22 20:12:34 2010
New Revision: 157648
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157648
Log:
gcc:
PR target/38085
* config/i386/i386.c (x86_
--- Comment #1 from meissner at gcc dot gnu dot org 2010-03-22 20:11
---
Created an attachment (id=20164)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20164&action=view)
Reduced function that causes the problem
To replicate this, use -m32 -O2 -mcpu=power4 -funroll-loops
--
If I build gamess and zeusmp with my normal spec optimization options, I get an
internal compiler error in the change_address_1 function in emit-rtl.c, due to
an address needing fixup has been generated after register allocation has been
done. I have narrowed the options down to -m32 -mcpu=power4
--- Comment #1 from paolo dot carlini at oracle dot com 2010-03-22 20:05
---
Please provide a complete, self-contained testcase, otherwise nothing will
happen.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
---
The STL sort implementation in stl_algo.h SIGSEVs under certain conditions due
to not checking the position of the __first and __last iterator positions.
Here is a diff between a working version and the buggy version in 4.4.1:
2228d2227
< int len = __last - __first;
2231c2230
< whil
--- Comment #4 from law at redhat dot com 2010-03-22 19:49 ---
FWIW, I seem to get considerably worse code from mainline than you -- for -O3
-ffast-math -mcpu=power7 -mvsx -maltivec I get 140 stfs and 192 lfs insns
(compared to 117 & 139 respectively that you reported).
Just for fun, I
--- Comment #1 from jakub at gcc dot gnu dot org 2010-03-22 19:16 ---
Several issues:
1) reassoc changes:
[pr43478.c : 6:9] D.2722_1 = h ();
[pr43478.c : 6:5] x_2 = D.2722_1 * 2;
[pr43478.c : 6:5] # DEBUG x => x_2
[pr43478.c : 7:9] D.2723_3 = h ();
[pr43478.c : 7:5] y_4 = D.272
--- Comment #9 from pinskia at gcc dot gnu dot org 2010-03-22 18:57 ---
*** Bug 43481 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #6 from pinskia at gcc dot gnu dot org 2010-03-22 18:57 ---
*** This bug has been marked as a duplicate of 33120 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #5 from developer at sandoe-acoustics dot co dot uk 2010-03-22
18:55 ---
(In reply to comment #3)
> Also, unless "turley" has a copyright assignment on file with the FSF (didn't
> find him/her in the MAINTAINERS file), the patch unfortunately cannot be
> accepted.
for the
--- Comment #18 from tglek at mozilla dot com 2010-03-22 18:40 ---
Perhaps someone could turn this into a landable patch
https://bugzilla.mozilla.org/attachment.cgi?id=352646&action=edit
This seemed to fix the problem for us
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19351
--- Comment #2 from jakub at gcc dot gnu dot org 2010-03-22 18:22 ---
In the second testcase it is actually TER that breaks this (both on the trunk
and 4.4-RH).
In *.nrv we still have:
[d.c : 4:4] l_2 = l_1(D) + 1;
[d.c : 4:4] # DEBUG l => l_2
[d.c : 6:9] # DEBUG h => n_3(D)
[d.c
--- Comment #19 from tromey at gcc dot gnu dot org 2010-03-22 18:21 ---
Created an attachment (id=20163)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20163&action=view)
undebugged patch to track macro expansion locations
I wanted to record my unfinished patch to track macro expan
--- Comment #1 from jakub at gcc dot gnu dot org 2010-03-22 18:01 ---
Well, in this particular case I believe it is correct.
In *.optimized we have:
f ()
{
:
# DEBUG y => 1
# DEBUG x => 1
return 1;
}
where return 1, the only actual statement left, has the function body lexical
bloc
--- Comment #2 from jan dot kratochvil at redhat dot com 2010-03-22 17:55
---
Checked-in:
http://gcc.gnu.org/viewcvs?view=revision&revision=157645
2010-03-22 Jan Kratochvil
Fix *.log tests output containing "===".
* dg-extract-results.sh (/\===/): Rename to ...
--- Comment #11 from paolo dot carlini at oracle dot com 2010-03-22 17:07
---
We discussed a bit the issue with Jason in Pittsburgh *before* realizing that
likely the C++1x WD is wrong about not categorizing strPOD as POD, which now
seems the real issue. My personal point of view is sti
--- Comment #4 from developer at sandoe-acoustics dot co dot uk 2010-03-22
16:59 ---
(In reply to comment #3)
> Also, unless "turley" has a copyright assignment on file with the FSF (didn't
> find him/her in the MAINTAINERS file), the patch unfortunately cannot be
> accepted.
It's fro
--- Comment #10 from matz at gcc dot gnu dot org 2010-03-22 16:54 ---
Hmm, well, but there's code out there that expects the "old" TR1 semantic,
namely blocxx, and if the definition is indeed muddled than IMNSHO we should
retain the behaviour as it was in older GCC versions, instead of b
--- Comment #3 from jb at gcc dot gnu dot org 2010-03-22 16:51 ---
Seems to be a target bug, nothing to do with the Fortran frontend.
Also, unless "turley" has a copyright assignment on file with the FSF (didn't
find him/her in the MAINTAINERS file), the patch unfortunately cannot be
a
--- Comment #9 from paolo dot carlini at oracle dot com 2010-03-22 16:43
---
Michael, I'm not sure to follow all the philosophical details of the issue. To
be sure:
1- __is_pod implements, to date, the correct C++0x semantics, modulo ISO DRs
(probably forthcoming, but a resolution seems
--- Comment #8 from matz at gcc dot gnu dot org 2010-03-22 16:34 ---
Re comment #6: well, then we still need to fix the c++98 case.
Re comment #7: note carefully how I have avoided is_pod<> in the testcase,
but instead used the internal mean to implement the former. That's the
regressio
--- Comment #9 from rguenth at gcc dot gnu dot org 2010-03-22 16:33 ---
Subject: Bug 43415
Author: rguenth
Date: Mon Mar 22 16:32:58 2010
New Revision: 157641
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157641
Log:
2010-03-22 Richard Guenther
Backport from mainlin
--- Comment #8 from rguenth at gcc dot gnu dot org 2010-03-22 16:33 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #1 from jan dot kratochvil at redhat dot com 2010-03-22 16:30
---
Created an attachment (id=20162)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20162&action=view)
Fix.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43482
--- Comment #4 from matz at gcc dot gnu dot org 2010-03-22 16:30 ---
Fixed.
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
Posted at, creating PR as its tracker:
http://gcc.gnu.org/ml/gcc-patches/2010-03/msg00309.html
while *.sum files were OK the *.log files sometimes miss the content present
in *.sum results. For example [GDB gdb.base/bitfields.exp output was missing
while gdb.base/bitfields.exp output was presen
--- Comment #3 from matz at gcc dot gnu dot org 2010-03-22 16:29 ---
Subject: Bug 43475
Author: matz
Date: Mon Mar 22 16:28:51 2010
New Revision: 157640
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157640
Log:
PR middle-end/43475
* recog.c (validate_replace_rtx
--- Comment #2 from developer at sandoe-acoustics dot co dot uk 2010-03-22
16:21 ---
Created an attachment (id=20161)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20161&action=view)
provisional fix against 157594
this is plagiarized in its entirety from apple/llvm 4.2 (was fixe
1 - 100 of 152 matches
Mail list logo
