public inbox for git-commits@fedoraproject.org
help / color / mirror / Atom feed
From: Jakub Jelinek <jakub@fedoraproject.org>
To: git-commits@fedoraproject.org
Subject: [rpms/gcc] rhel-f41-base: 4.3.0-0.6
Date: Mon, 29 Jun 2026 12:23:37 GMT [thread overview]
Message-ID: <178273581764.1.3164990782425944225.rpms-gcc-915778d05233@fedoraproject.org> (raw)
A new commit has been pushed.
Repo : rpms/gcc
Branch : rhel-f41-base
Commit : 915778d0523341dbe493b997e381e6fba686bae0
Author : Jakub Jelinek <jakub@fedoraproject.org>
Date : 2008-01-25T20:23:23+00:00
Stats : +172/-0 in 4 file(s)
URL : https://src.fedoraproject.org/rpms/gcc/c/915778d0523341dbe493b997e381e6fba686bae0?branch=rhel-f41-base
Log:
4.3.0-0.6
---
diff --git a/gcc43-late-visibility.patch b/gcc43-late-visibility.patch
new file mode 100644
index 0000000..de29ea8
--- /dev/null
+++ b/gcc43-late-visibility.patch
@@ -0,0 +1,23 @@
+2008-01-25 Jason Merrill <jason@redhat.com>
+
+ * decl2.c (is_late_template_attribute): Don't defer attribute
+ visibility just because the type is dependent.
+
+--- gcc/cp/decl2.c (revision 131825)
++++ gcc/cp/decl2.c (revision 131833)
+@@ -1014,9 +1014,12 @@ is_late_template_attribute (tree attr, t
+ || code == BOUND_TEMPLATE_TEMPLATE_PARM
+ || code == TYPENAME_TYPE)
+ return true;
+- /* Also defer attributes on dependent types. This is not necessary
+- in all cases, but is the better default. */
+- else if (dependent_type_p (type))
++ /* Also defer most attributes on dependent types. This is not
++ necessary in all cases, but is the better default. */
++ else if (dependent_type_p (type)
++ /* But attribute visibility specifically works on
++ templates. */
++ && !is_attribute_p ("visibility", name))
+ return true;
+ else
+ return false;
diff --git a/gcc43-pr31780.patch b/gcc43-pr31780.patch
new file mode 100644
index 0000000..aeb7ed7
--- /dev/null
+++ b/gcc43-pr31780.patch
@@ -0,0 +1,97 @@
+2008-01-25 Jason Merrill <jason@redhat.com>
+ Mark Mitchell <mark@codesourcery.com>
+
+ PR c++/31780
+ * call.c (standard_conversion): Allow conversion from integer/real
+ to complex.
+ (compare_ics): Such a conversion is worse than a normal arithmetic
+ conversion.
+
+--- gcc/cp/call.c (revision 131825)
++++ gcc/cp/call.c (revision 131833)
+@@ -846,8 +846,8 @@ standard_conversion (tree to, tree from,
+ }
+ /* We don't check for ENUMERAL_TYPE here because there are no standard
+ conversions to enum type. */
+- else if (tcode == INTEGER_TYPE || tcode == BOOLEAN_TYPE
+- || tcode == REAL_TYPE)
++ /* As an extension, allow conversion to complex type. */
++ else if (ARITHMETIC_TYPE_P (to))
+ {
+ if (! (INTEGRAL_CODE_P (fcode) || fcode == REAL_TYPE))
+ return NULL;
+@@ -5937,6 +5937,10 @@ compare_ics (conversion *ics1, conversio
+ from_type2 = t2->type;
+ }
+
++ /* One sequence can only be a subsequence of the other if they start with
++ the same type. They can start with different types when comparing the
++ second standard conversion sequence in two user-defined conversion
++ sequences. */
+ if (same_type_p (from_type1, from_type2))
+ {
+ if (is_subseq (ics1, ics2))
+@@ -5944,10 +5948,6 @@ compare_ics (conversion *ics1, conversio
+ if (is_subseq (ics2, ics1))
+ return -1;
+ }
+- /* Otherwise, one sequence cannot be a subsequence of the other; they
+- don't start with the same type. This can happen when comparing the
+- second standard conversion sequence in two user-defined conversion
+- sequences. */
+
+ /* [over.ics.rank]
+
+@@ -5977,6 +5977,21 @@ compare_ics (conversion *ics1, conversio
+ to_type1 = ics1->type;
+ to_type2 = ics2->type;
+
++ /* A conversion from scalar arithmetic type to complex is worse than a
++ conversion between scalar arithmetic types. */
++ if (same_type_p (from_type1, from_type2)
++ && ARITHMETIC_TYPE_P (from_type1)
++ && ARITHMETIC_TYPE_P (to_type1)
++ && ARITHMETIC_TYPE_P (to_type2)
++ && ((TREE_CODE (to_type1) == COMPLEX_TYPE)
++ != (TREE_CODE (to_type2) == COMPLEX_TYPE)))
++ {
++ if (TREE_CODE (to_type1) == COMPLEX_TYPE)
++ return -1;
++ else
++ return 1;
++ }
++
+ if (TYPE_PTR_P (from_type1)
+ && TYPE_PTR_P (from_type2)
+ && TYPE_PTR_P (to_type1)
+--- gcc/testsuite/g++.dg/ext/complex3.C (revision 0)
++++ gcc/testsuite/g++.dg/ext/complex3.C (revision 131833)
+@@ -0,0 +1,28 @@
++// PR c++/31780
++// { dg-do run }
++// { dg-options "" }
++
++// Test that we can implicitly convert to _Complex, but that it's worse
++// than a scalar arithmetic conversion.
++
++extern "C" void exit (int);
++
++int r = 0;
++
++void f (_Complex int) { ++r; }
++void f (double) { }
++
++void g (_Complex int) { }
++
++int main()
++{
++ f (1);
++ g (1);
++
++ return r;
++}
++
++void bar()
++{
++ r ? 0i : 0;
++}
diff --git a/gcc43-pr32244.patch b/gcc43-pr32244.patch
new file mode 100644
index 0000000..e72daf6
--- /dev/null
+++ b/gcc43-pr32244.patch
@@ -0,0 +1,46 @@
+2008-01-25 Richard Guenther <rguenther@suse.de>
+
+ PR middle-end/32244
+ * expr.c (expand_expr_real_1): Reduce result of LSHIFT_EXPR
+ to its bitfield precision if required.
+
+ * gcc.c-torture/execute/pr32244-1.c: New testcase.
+
+--- gcc/expr.c (revision 131825)
++++ gcc/expr.c (revision 131833)
+@@ -8920,8 +8920,11 @@ expand_expr_real_1 (tree exp, rtx target
+ target = 0;
+ op0 = expand_expr (TREE_OPERAND (exp, 0), subtarget,
+ VOIDmode, EXPAND_NORMAL);
+- return expand_shift (code, mode, op0, TREE_OPERAND (exp, 1), target,
++ temp = expand_shift (code, mode, op0, TREE_OPERAND (exp, 1), target,
+ unsignedp);
++ if (code == LSHIFT_EXPR)
++ temp = REDUCE_BIT_FIELD (temp);
++ return temp;
+
+ /* Could determine the answer when only additive constants differ. Also,
+ the addition of one can be handled by changing the condition. */
+--- gcc/testsuite/gcc.c-torture/execute/pr32244-1.c (revision 0)
++++ gcc/testsuite/gcc.c-torture/execute/pr32244-1.c (revision 131833)
+@@ -0,0 +1,20 @@
++struct foo
++{
++ unsigned long long b:40;
++} x;
++
++extern void abort (void);
++
++void test1(unsigned long long res)
++{
++ /* The shift is carried out in 40 bit precision. */
++ if (x.b<<32 != res)
++ abort ();
++}
++
++int main()
++{
++ x.b = 0x0100;
++ test1(0);
++ return 0;
++}
diff --git a/gcc43.spec b/gcc43.spec
index c1997f1..2194368 100644
--- a/gcc43.spec
+++ b/gcc43.spec
@@ -141,6 +141,9 @@ Patch11: gcc43-rh341221.patch
Patch12: gcc43-cpp-pragma.patch
Patch13: gcc43-java-debug-iface-type.patch
Patch14: gcc43-pr34965.patch
+Patch15: gcc43-late-visibility.patch
+Patch16: gcc43-pr31780.patch
+Patch17: gcc43-pr32244.patch
# On ARM EABI systems, we do want -gnueabi to be part of the
# target triple.
@@ -438,6 +441,9 @@ which are required to run programs compiled with the GNAT.
%patch12 -p0 -b .cpp-pragma~
%patch13 -p0 -b .java-debug-iface-type~
%patch14 -p0 -b .pr34965~
+%patch15 -p0 -b .late-visibility~
+%patch16 -p0 -b .pr31780~
+%patch17 -p0 -b .pr32244~
tar xzf %{SOURCE4}
next reply other threads:[~2026-06-29 12:23 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-29 12:23 Jakub Jelinek [this message]
-- strict thread matches above, loose matches on Subject: below --
2026-06-29 12:23 [rpms/gcc] rhel-f41-base: 4.3.0-0.6 Jakub Jelinek
2026-06-29 12:23 Jakub Jelinek
2026-06-29 12:23 Jakub Jelinek
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=178273581764.1.3164990782425944225.rpms-gcc-915778d05233@fedoraproject.org \
--to=jakub@fedoraproject.org \
--cc=git-commits@fedoraproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox